[LINK] There goes the neighbourhood...

[Paul Brooks]

On 11/05/2011 7:58 PM, Kim Holburn wrote:
> On 2011/May/11, at 7:12 PM, Paul Brooks wrote:
>
>> On 11/05/2011 6:51 PM, Kim Holburn wrote:
>>> The main reason NAT is a problem for VOIP/SIP/H323 is that they put IP addresses in the data.  If they relied on IP headers like every sensible protocol designer it would never have been an issue.  You wouldn't need STUN servers or anything else.  Just the packets.  The other fault is that they splatter udp connections with lots of ports.  Not necessary.
>> However, when the IP addresses that need to be transported around refer to third-party
>> hosts (i.e. neither of the source or destination hosts of the IP stream) there isn't
>> really anywhere else to stuff them than inside the data fields being transported. Not
>> every problem is solved by  a simple bilateral protocol like Telnet.
> 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.

I specifically said 'third party hosts' - protocols where A needs to tell B to go talk
to C. You have to carry Cs address somewhere in the data payload fields, because it
does not exist in the IP headers between A and B - it has nothing to do with public or
private.

For instance, the SIP INVITE message in the signalling session has to include the IP
address of another host to tell the caller where to try to direct the media session -
SIP signalling can travel between two completely different hosts from the audio path.

SIP has the capability to 'fork' the audio path and have several handsets ring at
once, and to transfer the call from one handset to another (please ignore the
quaintness of the word 'handset' for the moment). Somehow, somewhere one host has to
tell another host 'don't send anything back to me, send it over THERE - and THERE and
THERE' - the moment you have to indicate 'THERE, NOT ME' you have to embed an address
in a data field.

Its not just higher-order protocols - heck even the ICMP REDIRECT message has to have
an IP address embedded in the data field.


>> NAT is a problem because NAT is the problem. Remove the need for NAT as IPv6 allows,
>> and voila there is no longer any problem with having IP addresses embedded within data
>> streams, since they no longer have to be munged.
> 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.
NAT doesn't help or break this. Even with NAT, the outside Internet knows you by the
publicly visible source IP address. I think you are referring to a different issue of
receiving dynamic public IP addresses, so the public IP address changes
periodically.   Embedding these dynamic IP addresses into data fields doesn't break
anything, since the dynamic IP address doesn't change within the lifetime of the
packet or session.

You can have dynamic addressing without needing NAT - and without breaking
IP-addresses-inside-data-fields - providing the dynamic address doesn't change while
the session is in progress (and even then some of the funky mobility signalling can
cope with it) - and so you can still have the illusion of anonymity that dynamic
addressing provides. Its still only an illusion, since the ISP knows which IP address
anyone was using at any particular instant and can call it up out of the logs if required.

(Besides, that adage had nothing to do with trying to hide your identity from analysis
of your IP address. It was coined back when person-to-person communications was by
typed text, in chat programs, email and IM systems - where you couldn't hear or see
the other person, so didn't really know if they were man, woman, or dog, or the early
AI experiment Eliza the chat-bot.) (Back when hosts had fixed and public IP addresses)
 
cheers....
    Paul.