-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Hesham Soliman
Sent: Monday, December 01, 2008 2:33 AM
To: Colin Perkins
Cc: TSV Dir; ietf(_at_)ietf(_dot_)org; mext(_at_)ietf(_dot_)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(_at_)csperkins(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf