Subject: Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 1 Dec 2008 10:13:21 +0000

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/

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Dec 2008 12:06:35 +0100

Hesham Soliman skrev:
> 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?
> 

I don't think we should go to far to correct this bug in
implementations. My understanding is that this have been observed but is
not a common behavior as these generic ALGs do break things randomly and
horribly. I would only do something about if it has no minimal impact on
the specification and any deployed implementations. Otherwise the fix is
likely to cause more grief than the few devices that are broken.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Colin Perkins <[email-masked]>
Date: Mon, 1 Dec 2008 11:12:11 +0000

On 1 Dec 2008, at 11:06, Magnus Westerlund wrote:
> Hesham Soliman skrev:
>> 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?
>

Right - the issue should be documented, and if there is a trivial fix  
it should be recommended, but this isn't a big issue.

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

---

From: Matt Mathis <[email-masked]>
Date: Mon, 1 Dec 2008 09:13:05 -0500 (EST)

On Mon, 1 Dec 2008, Hesham Soliman wrote:

> => 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?

I'd really hate to have address 32.116.104.101   (" the")....
Such devices can't possibly survive, can they?

Aghast,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 1 Dec 2008 16:25:48 +0200

On Monday 01 December 2008 16:13:05 ext Matt Mathis, you wrote:
> > => 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

Depends what you need to survive...

If you only do DNS and a few TCP-based protocols which the brain-damaged ALG 
would not affect, it might just work. We probably don't care about MIP not 
passing through such abomination though.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 01 Dec 2008 20:00:35 +1100

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 01 Dec 2008 21:33:15 +1100

Thanks Colin,

Hesham

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Dec 2008 13:32:55 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hesham Soliman
> Sent: Monday, December 01, 2008 2:33 AM
> To: Colin Perkins
> Cc: TSV Dir; [email-masked]; [email-masked]
> Subject: Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
> 
> Thanks Colin,
> 

(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