Re: [tae] [tsv-area] Transport negotiation

On Dec 10, 2008, at 14:12, Joe Touch wrote:
>
> AFAICT, the demultiplexing is really:
>
> 	3) IPaddr, [transportproto, port]

Actually, the rules a port-muxing NAT must enforce at demuxing time  
are always dependent first on the transport protocol.  After that, the  
rules get murky.

For example, in the case of TCP, the translated destination is a  
function of the entire 4-tuple of remaining address parameters, i.e.  
source address, source port, destination address, destination port.

On the other hand, in the case of UDP, the translated destination can  
be the result of any of three different functions involving the 2- 
tuple of the destination address and destination port, the source  
address and the source port, according to the UDP endpoint mapping  
behavior of the NAT function in play.  (Incidentally, a similar  
explosion of possibility arises for TCP when considering unsolicited  
inbound SYN packets received at destination address and destination  
port pairs already in use by another connection state, i.e. it's  
according to the TCP endpoint mapping behavior of the NAT function.)

Likewise, other transport protocols, e.g. IPsec ESP, don't even have  
source and destination ports, and also some, e.g. SCTP, use an  
association identifier with the destination address and they don't  
translate the source or destination ports at all.

It's messy, but if we're going to end our anti-NAT jihad, then I'm  
looking forward to seeing proposals for ways we can simplify all  
this.  Hopefully, those proposals will be ones that won't get shot to  
pieces in the everlasting battles over security vs. transparency for  
which IETF has been the battleground since forever.

--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering

_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae