[LINK] There goes the neighbourhood...

[Kim Holburn]

On 2011/May/11, at 9:48 PM, Karl Auer wrote:

> On Wed, 2011-05-11 at 19:58 +1000, Kim Holburn wrote:
>> If both the source and destination are private then no amount of
>> stuffing is going to help.  Packets need the right addresses.  Putting
>> the IP addresses in the data doesn't help anyone.  Routers don't have
>> access to the data, only the headers.  I'm not sure why the designers
>> of those protocols did that.  It was probably before the widespread
>> use of NAT.  Still a lot of P2P protocols get around the problem of
>> both parties being behind a NAT.
> 
> Kim, forgive me if this is way off the mark, but you are starting to
> sound like someone who doesn't actually know what they are talking
> about.
> 
> Lots of very clever people put IP addresses in payloads; it is not a
> sin, and it is a sensible solution to many problems. In networking as in
> computing generally, there are many situations where a self-referential
> solution is the right solution. Crypto is the poster-child for that, or
> course.

Maybe crypto was the original reason for this.  Using IP address as a crypto key is probably not such a great idea and doesn't work so well in an environment where many clients are in a private address space.  

> NAT, however, breaks such protocols. Many protocols worked that way and
> still work that way, and each and every one of them required a different
> ALG to be added into every NAT device on the planet. It is not the
> protocols that were broken, it was and is NAT that is broken.

I'd have to disagree there.  I don't think that the network guarantees that the IP addresses in headers are going to stay the same from source to destination and so stay the same as any copies of such in the data.  

> The network *should* be transparent by default. Of course people add NAT
> and firewalls and load balancers and what have you, but it is *their
> problem* to work properly - that is, to either preserve or to accurately
> fake network transparency. NAT does neither (unless you count port
> forwarding).

I thought that the application layer was a separate layer and should leave ip layer details to the ip layer.  Probably not an absolute rule but a reasonable principle.  If there is a good reason for doing this at the application layer then fine but if not, what's the point?

> As to P2P protocols getting around NAT - well, yes. That's the problem.
> Instead of being literally peer-to-peer, these protocols must jump
> through all sorts of complicated hoops. If they did not have to do that,
> they would be simpler, faster and more reliable (and that's just the
> beginning).

And much more open and less private.  (Just thinking out loud here).

>> But will present a lot of people with other problems - like it will
>> break the old internet adage: "On the internet nobody knows you're a
>> dog."  NAT isn't all bad.
> 
> Actually NAT *is* pretty much all bad. Not sure what you mean about
> dogs. NAT has one saving grace[1] - it multiplexes few addresses into
> many. That need was dire in IPv4; that need will disappear with IPv6.
> The fates willing, NAT will disappear too.
> 
>>> OK, they could have embedded DNS names instead of IP addresses
>> 
>> No they couldn't have, that just adds a DNS lookup to the mix.  If you
>> can make a connection you only need the IP addresses in the headers.
>> If you can't make a connection it doesn't matter. 
> 
> You miss the point in your first sentence, but even if you hadn't, the
> DNS idea would still be bad :-)

Not my idea.

> But to make a connection - at least, an inbound connection through NAT -
> you need MORE than the IP addresses in the headers.

Yes.

> [1] Please don't trot out "NAT is security". We had that discussion in
> excruciating detail on Link last year. I'm sure you can find it in the
> archives.

Heh heh.

-- 
Kim Holburn
IT Network & Security Consultant
T: +61 2 61402408  M: +61 404072753
mailto:kim at holburn.net  aim://kimholburn
skype://kholburn - PGP Public Key on request