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

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of Hesham Soliman
> Sent: Monday, December 01, 2008 2:33 AM
> To: Colin Perkins
> Cc: TSV Dir; ietf@ietf.org; mext@ietf.org
> Subject: Re: 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?

(catching up on email after a long vacation; sorry for the delay.)

FYI, Teredo also found NATs that meddled with IP addresses on
32 bit boundaries.  From RFC4380,

   Other investigation in the behavior of NAT also outlined the
   "probabilistic rewrite" behavior.  Some brands of NAT will examine
   all packets for "embedded addresses", IP addresses, and port numbers
   present in application payloads.  They will systematically replace
   32-bit values that match a local address by the corresponding mapped
   address.  The Teredo specification includes an "obfuscation"
   procedure in order to avoid this behavior.

-d

> 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.
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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