Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[William Herrin <bill () herrin us>]

On Mon, Feb 23, 2015 at 10:02 AM, Eric Germann <ekgermann () cctec com> wrote:
> In spitballing, the boat hasn't sailed too far to say "Why not
> use 100.64/10 in the VPC?"
>
> The only one I can see is if the customer has a service provider
> with their external interface in 100.64 space.  However, this
> approach would have a more specific in that space so it
> should fire it down the tunnel for their allocated customer
> block (/28) vs. their external side.

Hi Eric,

The main risk is more or less as you summarized it.  Customer has no
firewall or originates the VPN directly from their firewall. Customer
buys a non-hosting commodity Internet product that uses carrier NAT to
conserve IP addresses. The customer's assigned address AND NETMASK
combined overlap some of the hosts you're trying to publish to them.



Mitigations for that risk:

Can you insist that the customer originate connections from inside
their firewall (on RFC1918 space)?

Most service providers using 100.64/10 either permit customers to opt
out (getting dynamic globally routable addresses) or offer customers
the opportunity to purchase static global addresses for a nominal fee.
Are you comfortable telling impacted customers that they have to do
so?


A secondary risk comes in to play where a customer may wish to
interact with another service provider doing the same thing as you.
That essentially lands you back in the same problem you're having now
with RFC1918.


One more question you should consider: what is the nature of your
customer's networks? Big corps that tend to stretch through 10/8 won't
let their users originate VPN connections in the first place. They
also don't touch 100.64/10 except where someone is publishing a
service like yours.  Meanwhile, home and SOHO users who are at liberty
to originate VPNs might currently hold a 100.64/10 address. But they
just about never use the off-bit /16s in 10/8. By off-bit I mean the
ones with 4 or 5 random 1-bits in the second octet.


My opinion: The likelihood of collisions in 100.64/10 increases
significantly if you use them on servers. I would confine my use to
client machines and try to put servers providing service to multiple
organizations on globally unique IPs. Confining 100.64/10 to client
machines, you're unlikely to encounter a problem you can't readily
solve.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin () dirtside com  bill () herrin us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>