[180463] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jun 4 05:14:41 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <556F2382.8010409@matthew.at>
Date: Thu, 4 Jun 2015 10:11:39 +0100
To: Matthew Kaufman <matthew@matthew.at>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
>>>=20
>>> IPv4 with NAT, standard NAT/firewall traversal techniques are used =
so that things inside your house are reachable as necessary. Almost =
nobody configures their firewall to open up anything.
>>=20
>> HuH?
>>=20
>> How do I SSH into my host behind my home NAT firewall without =
configuration of the firewall?
>=20
> Nobody but you and a few hundred other people on this mailing list SSH =
into hosts at your home.
SSH, VNC, HTTP, HTTPs, LPD, whatever=85 Pick your service. SSH was just =
an example.
> Everyone else in the entire world reaches hosts at their house through =
their firewall just fine because those hosts are their Nest thermostat, =
or their Dropcam, or their PC running Skype, or maybe (in rare cases) =
something like LogMeIn.
I=92d argue that SSH is several thousand, not a few hundred. In any =
case, I suppose you can make the argument that only a few people are =
trying to access their home network resources remotely other than via =
some sort of proxy/rendezvous service. However, I would argue that such =
services exist solely to provide a workaround for the deficiencies in =
the network introduced by NAT. Get rid of the stupid NAT and you no =
longer need such services.
Even if you want to consider all of those services, the reality is that =
their codebases could be substantially improved and simplified as well =
as their security posture improved by eliminating NAT.
> None of those people ever touch the settings of the device they had =
delivered by their ISP and/or purchased at Best Buy. Not ever.
Sure=85 They all live like sheeple not even realizing that they=92ve =
been handed a deficient and limited internet incapable of living up to =
its potential. They remain blissfully ignorant that they are a rat in a =
digital cage because they are unaware of life outside the cage. What=92s =
your point?
Are you claiming this makes cages a good thing? Are you claiming that =
since the rats are not demanding to be let out of their cages, we =
shouldn=92t seek to create an environment where cages are not needed?
>> You are making no sense here. NAT Traversal techniques provide for =
outbound connections and/or a way that a pseudo-service can create an =
inbound connection that looks like an outbound connection to the =
firewall.
>>=20
>> It does not in any way provide for generic inbound access to ordinary =
services without configuration.
>=20
> So what?
>=20
> Nobody (to several levels of statistical significance) needs "generic =
inbound access to ordinary services". Heck, the only "ordinary services" =
that exist any more are HTTP/HTTPS.
This simply isn=92t true. To the limited extent that it is true, the =
reality is that it is a consequence of the limitations of IPv4 and NAT =
rather than a state that anyone other than you ever really considered =
desirable.
>>>> IPv6 =97 I add a permit statement to the firewall to allow the =
traffic in to each host/group of hosts that I want and I am done.
>>>=20
>>> IPv6, standard NAT?firewall traversal techniques are used so that =
things inside your house are reachable as necessary. Still almost nobody =
configures their firewall to open up anything.
>>=20
>> Why would one use NAT with IPv6=85 You=92re making no sense there.
>=20
> I didn't say you would... but you need firewall traversal, and the =
"standard NAT and firewall traversal techniques" are how you traverse =
your IPv6 firewall.
That=92s an awful lot of icky overhead vs. the simple clean solution of =
permitting desired traffic.
I suspect that in the IPv6 world, eventually, rather than silly hacks =
like UPnP, STUN, etc., we will see, instead, standardized APIs for =
authenticating with the firewall and automated mechanisms for adding =
permission after authentication.
>>> For those who do, the work needed to open up a few host/port =
mappings in IPv4 is basically identical to opening up a few hosts and =
ports for IPv6.
>>=20
>> Not really=85
>>=20
>> For example, let=92s say you have 20 machines for whom you want to =
allow inbound SSH access. In the IPv4 world, with NAT, you have to =
configure an individual port mapping for each machine and you have to =
either configure all of the SSH clients, or, specify the particular port =
for the machine you want to get to on the command line.
>=20
> Ok, you go find me 1000 households where nobody in the house is on the =
NANOG list but where there are 20 machines running SSH already =
installed.
OK, half a dozen Video Game consoles or whatever other service you want =
to imagine.
Just because the standard way to do things today is with silly =
workarounds required by the lack of address transparency created by NAT, =
that doesn=92t mean we have to continue to do things so badly in the =
future.
>> On the other hand, with IPv6, let=92s say the machines are all on =
2001:db8::/64. Further, let=92s say that I group machines for which I =
want to provide SSH access within 2001:db8::22:0:0:0/80. I can add a =
single firewall entry which covers this /80 and I=92m done. I can put =
many millions of hosts within that range and they all are accessible =
directly for SSH from the outside world.
>>=20
>> Takes about 20 seconds to configure my firewall once and then I never =
really need to worry about it again.
>>=20
>=20
> Yeah, so there you are manually configuring your firewall again. Which =
isn't surprising, because you also want to have 20 hosts offering SSH to =
the world... which makes you an outlier.
Right=85 Once per service or once per host per service worst case. =
Eventually, there will be APIs for this, but today, it=92s manual.
It=92s manual today because being able to make use of it makes me an =
outlier. In the future, with address transparency, being able to deploy =
services will not make you a outlier.
>> Further, in the IPv4 case, I need special client configuration or =
client invocation effort every time, while with the IPv6 case, I can =
simply put the hostname in DNS and then use the name thereafter.
>=20
> Sure... because like most homeowners, you're proficient at editing =
BIND config files.
Who needs to edit BIND config file to put something in DNS? Sure, you =
can, and I do, but there are at least a dozen web-based DNS providers =
where you can host a zone file for free and manage it through a web GUI.
>>>> I do not see the above as being equal effort or as yielding equal =
results.
>>>=20
>>> For the automatic traversal cases, the end-user effort is identical.
>>=20
>> Sure, but automatic traversal is the exception not the rule when =
considering internet services.
>>=20
>=20
> I don't know what world you're living in, but every single person I =
know is a user of one or more software or hardware devices that work =
just fine behind a firewall, either because they're just uploading =
things to a service, or periodically checking in with a service, or =
using automatic traversal techniques.
I=92m living in a world where at least some people want to be peers =
rather than mere consumers. A world where the thought of being able to =
make phone calls without a phone company has appeal to at least some =
people. A world where peer to peer information and communication is =
considered a good and healthy thing.
Sure, if you want to live in the ABC/DIsney/Comcast/NBC/Micr0$0ft =
fantasy world where people are mindless subjects of their corporate =
overlords, strictly consuming information and only that which has the =
approval of said corporate overlords, then the path you advocate makes =
perfect sense.
>>> For the incredibly rare case of manual configuration (which as NANOG =
participants we often forget, since we're adjusting our routers all the =
time) there is almost no difference for most use cases.
>>=20
>> Not true as noted above.
>=20
> Most people never configure.
>=20
> Most of the people who do configure need exactly one address and port =
to work, in which case the work is about the same.
Try configuring port forwarding for a household where there is an Xbox =
One and a PS/3. Not all that uncommon a scenario. Common enough that =
both Micr0$0ft and Sony technical support have stock scripts for telling =
you which home gateways you can buy that will work and how to configure =
them.
> You have 20 SSH hosts. You're an outlier, and so yes, in IPv6 there's =
less typing.
Picking apart the specifics of a random example doesn=92t actually make =
the general situation less relevant.
> I'm an outlier too... my house has a Juniper SRX-240 that I configure =
from the command line at its border. That's not normal. I'm not normal. =
And that's ok.
On this, we can agree.
>>>> As such, I=92d say that your statement gets added to the great =
myths of Matthew Kauffman rather than there being any myth about this =
being an IPv6 advantage.
>>>>=20
>>>> I can assure you that it is MUCH easier for me to remote-manage my =
mother=92s machines over their IPv6 addresses than to get to them over =
IPv4.
>>>=20
>>> Only because you've insisted on doing it the hard way, instead of =
using something like teamviewer or logmein which "just works=94.
>>=20
>> So does vmc://hostname <vmc://hostname> (if I have IPv6 or non-NAT =
IPv4).
>=20
> With default out-of-the-box firewall settings as your device arrives =
from Best Buy?
If I were to answer strictly the question as asked, yes.
However, no, but let=92s compare the costs=85
Assuming a 3 year life-cycle on that piece of shit you bought at Best =
Buy...
Logmein Pro for Users (cheapest alternative I could find) $99/year
One-time configuration of firewall: $PIZZA for local computer whiz kid =
every 3 years.
I=92d argue that the need to configure the firewall is a very cost =
effective alternative with a less than one month break even.
Over a 20 year timeframe, you=92ve gone from $1980 (Logmein) to $105 =
(assuming you pay as much as $15 per pizza which is high).
>>>> I live in California and have native dual-stack without NAT. She =
lives in Texas and has native dual-stack with NAT for her IPv4.
>>>=20
>>> And I assume your mother opened up her IPv6 firewall all on her own?
>>=20
>> As a matter of fact, she did open up the first connection which then =
provided me the necessary access to configure the rest for her.
>=20
> So it isn't actually that hard. Just like it isn't that hard for one =
address and port for the user of a Slingbox or whatever other random =
product you can find that doesn't have full traversal capabilities in =
it.
It wasn=92t hard because there was address transparency via IPv6 and a =
simple permit was all that was needed. No port forwarding, no mapping, =
just a =93Allow inbound packets to port XX TCP=94.
>>> Most people won't have the technical skills to adjust the IPv6 =
firewall that comes with their CPE and/or "Wireless Router" any more =
than they have the skills to set up IPv4 port mapping.
>>=20
>> My mother is about as non-technical as you would imagine the typical =
grandmother portrayed in most such examples. Technically, she=92s a =
great grandmother these days.
>>=20
>=20
> Congratulations to her.
>=20
>>>=20
>>>>> IPv6 has exactly one benefit... there's more addresses. It comes =
with a whole lot of new pain points, and probably a bunch of security =
nightmare still waiting to be discovered. And it for sure isn't free.
>>>> IPv6 comes with at least one design-advantage =97 More addresses.
>>>>=20
>>>> However, more addresses, especially on the scale IPv6 delivers them =
comes with MANY benefits:
>>>>=20
>>>> 1. Simplified addressing
>>>> 2. Better aggregation
>>>> 3. Direct access where permitted
>>>> 4. Elimination of NAT and its security flaws and disadvantages
>>>> 5. Simplified topologies
>>>> 6. Better subnetting
>>>> 7. Better network planning with sparse allocations
>>>=20
>>> All of those are benefits for the network operator, not the end =
user.
>>=20
>> I can see that all of those benefit the network operator.
>>=20
>> However, with the exception of 2 and 7, I would argue that all of =
them are also of benefit to at least some fraction of end-users.
>>=20
>=20
> Some fraction, sure. But since that fraction is well under 0.1%, I'm =
sticking with my position.
I disagree. I think 3, especially, will be a growing fraction of users =
as address transparency becomes the norm and developers start to make =
use of it.
>> I am an end user and I am seeing benefits from all but 2. I use =
sparse address allocation to allow me to classify hosts for convenience, =
for example.
>=20
> Outlier.
Today. We=92re talking about the future. I=92m talking about the =
advantages of moving forward. You=92re making excuses for remaining =
mired in the past.
>> Note, the original item 6 (corrected above) was autocorrected from =
subnetting to sunbathing. I have restored it to subnetting.
>>=20
>=20
> I preferred sunbathing.
Please, go make yourself as crispy as you desire. Fortunately, for you, =
the sun is not behind a NAT firewall.
>>>> 8. Simpler application code
>>>=20
>>> Might be true *if* there was only IPv6. If there's also the need to =
support IPv4 then supporting *both* is harder than supporting just one.
>>=20
>> Only because the need to support NAT traversal comes as overhead in =
supporting IPv4.
>=20
> The same code is needed to do IPv6 firewall traversal.
But IPv6 firewall traversal isn=92t necessary.
>> Otherwise, most applications can be written for IPv6 and set the =
socket option IPV6_V6ONLY=3DFALSE (which should be the default) and on a =
dual-stack host, the application will simply work and deal with both =
protocols without ever caring about IPv4. (IPv4 connections are =
presented to the application as an IPv6 connection from a host with =
address ::ffff:IP:v4 (where IP:v4 is the 32-bit IPv4 address of the =
source host).
>=20
> For an operating system and TCP/IP stack where that is true, sure. =
When you're trying to squeeze things into a Cortex M4 that you want to =
hang on someone's wall, dual-stack takes more Flash.
Yes, having two stacks in the box takes marginally more flash than one. =
According to=20
http://www.ipso-alliance.org/wp-content/media/lightweight_os.pdf =
<http://www.ipso-alliance.org/wp-content/media/lightweight_os.pdf>, an =
IPv6 stack shouldn=92t require more than about 15k of flash.
These days, that =92s not a lot even in a small ARM Cortex M4.
>>>> 9. Reduced complexity in:
>>>> Proxies
>>>> Applications
>>>> Firewalls
>>>> Logging
>>>> Monitoring
>>>> Audit
>>>> Intrusion Detection
>>>> Intrusion Prevention
>>>> DDoS mitigation
>>>=20
>>> Matters not to most home users.
>>=20
>> Until it does. I=92ve had lots of complaints from end users where =
they didn=92t know that the issue was a proxy problem, application =
coding error with NAT traversal, Firewall problem, etc., but upon =
investigation, these were exactly the source of said end-user=92s =
problem.
>=20
> Define "lots". Most users are having great luck with their current =
IPv4-only connection and the devices they're buying to use with it.
No, most users are suffering in silence because they have no idea where =
to go to get their problems solved. Most users haven=92t experienced a =
working internet, so the current level of dysfunction is normal to them =
and they tolerate it because they have no idea that there are better =
alternatives available.
>>> Doesn't help corporate users because they also need all that for =
IPv4 indefinitely.
>>=20
>> See above. The more traffic that corporate users can get off of IPv4, =
the less trouble these things will cause for them. As such, your =
argument falls flat.
>=20
> If I'm still getting support tickets due to IPv4 issues, the problems =
haven't gone away. Again, tell me when I can switch IPv4 off entirely.
Sure=85 I didn=92t say reducing IPv4 utilization would eliminate IPv4 =
issues. I said it would reduce them.
However, i=92m confused=85 If nobody has problems with IPv4 as you =
describe above, why are you now complaining about the number of IPv4 =
tickets you get. Seems you want to have your cake and eat it too here.
>>>> 10. The ability to write software with hope of your codebase =
working for the next 10 years or more.
>>> I'll bet that there's IPv4 devices running happily 10 years from =
now.
>>=20
>> Maybe, but I bet within 10 years, there=92s very little, if any, IPv4 =
running across the backbone of the internet.
>=20
> I'd take that bet.
I=92ll put $100 on it.
>>>> I=92m sure there are other benefits as well, but this gives you at =
least 10.
>>>>=20
>>>> There are those that would argue that other design advantages =
include:
>>>>=20
>>>> 1. Fixed length simplified header
>>>=20
>>> Maybe.
>>>=20
>>>> 2. Stateless Address Autoconfiguration
>>>=20
>>> Disaster, given that I'm still stuck needing DHCPv6 to configure =
everything that SLAAC won't. Or things that SLAAC only picked up =
recently (like setting your DNS server) and so are still unsupported in =
all sorts of gear.
>>=20
>> Not a disaster, but perhaps slightly less convenient for your =
particular situation.
>>=20
>> In my situation, most hosts don=92t need anything more than an IP =
address, default gateway, and Recursive Nameserver. RAs provide all of =
that and my hosts just work fine with SLAAC out of the box.
>=20
> Not too many WinXP machines at your house I guess.
Nope=85 I=92m very proud to say that there are NO Micr0$0ft boxes in my =
house.
>>>> 3. Mobile IP
>>>=20
>>> Remains to be seen if this matters.
>>=20
>> I=92ve found it quite useful as have several other people I know.
>>=20
>=20
> Outlier.
This seems be your answer to anything that you don=92t like. Outlier or =
not, the protocol is useful.
>>>> 4. A much cleaner implementation of IPSEC
>>>=20
>>> Sure, but the IPv4 IPSEC seems to work just fine everywhere I've =
deployed it.
>>=20
>> For some definition of work. The additional overhead, increased =
complexity of configuring it, incompatible implementations, and other =
nightmares I have encountered in IPv4 IPSEC vs. the relative ease and =
convenience of using it in IPv6 strikes me as quite worth while.
>>=20
>> A treadle sewing machine works if you choose to use one. That doesn=92t=
mean that an electric sewing machine with CNC stitching capabilities =
for embroidery, etc. is not a better alternative.
>>=20
>=20
> Given that the security provided by both is identical, I'm not sure =
that's a good example, but it was creative.
The security provided by IPv4 IPSEC and IPv6 IPSEC is nearly identical =
as well. The difference is the difficulty of use.
>>>> I=92m sure there are more, but this is a quick list off the top of =
my head.
>>>=20
>>> There's a bunch of myths too... and "every device will be directly =
reachable from the entire Internet" is on there.
>>=20
>> That=92s not a myth, it=92s just an incomplete statement that people =
like you love to truncate for the sake of claiming it is a myth.
>>=20
>> The complete statement is =93Every device can be directly reachable =
from the entire internet to the extent allowed by policy.=94
>>=20
>> The complete statement is quite true. The incomplete statement is =
false only because it contains a scope which is beyond the ability of =
what a protocol can deliver, due to the missing words.
>>=20
>=20
> Yes. But those extra words mean that I need to carry around exactly =
the same tricks I use to get through IPv4 NAT/firewall cases.
Not really=85 If policy permits you to pass the firewall, then you can =
pass without tricks. If policy doesn=92t allow it, you may be able to =
traverse the firewall with tricks, but then the question becomes should =
you?
True, if you are the one determining the policy, there is that pesky =
step of expressing the policy to the firewall. In your preferred world, =
this is done by adding substantial overhead to each and every piece of =
software and creating profound limitations on how you can use your =
software.
In my preferred world, this is done by configuring the policy in the =
firewall once and simplifying the application code and increasing the =
probability that the security policy enforced is the security policy =
intended.
I guess to each their own.
Owen
