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

Thanks Colin,

I agree with your rationale but I wonder if we need to support every broken
device out there. In any case, if we have to, I prefer to require encryption
than to add the XORED address option. I'd like to hear what people in MEXT
think about this, comments from MEXT?

Hesham

On 1/12/08 9:13 PM, "Colin Perkins" <csp@csperkins.org> wrote:

> 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.

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