Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt

On 1 Dec 2008, at 09:00, Hesham Soliman wrote:
>>> => Well, I'm not sure how a NAT can do that. You mean the NAT will
>>> parse the binding update message deep inside the IPv6 extension
>>> header in the inner IP packet? This is where the original address
>>> is preserved. To do that, a NAT would have to understand the
>>> various MIPv6 options, and if it did, it would know not to do
>>> that :) The inner header is IPv6, so a NAT should not touch that.
>>
>> My understanding from the STUN work is that NATs have been observed
>> which rewrite any sequence of four aligned bytes matching the source
>> IP address, irrespective of its location within the packet (section
>> 15.2 of RFC 5389).
>
> => Sounds freightning! May be we need to mandate encryption and  
> hope that no 4-byte sequence matched the IP address? What do they  
> do with encrypted packets? How do they know they're encrypted?

One would assume these broken devices will potentially corrupt  
encrypted packets, the same as they will potentially corrupt any  
other packet. Hiding the source address when it appears in the  
payload (either by encryption, or using some trivial obfuscation as  
does STUN) simply reduces the probability of such corruption so it's  
no longer 100% guaranteed that the payload will be mangled.

-- 
Colin Perkins
http://csperkins.org/

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