Hi Marshall,
On 26/02/09 03:34 PM, Marshall Eubanks wrote:
Hello;
On Feb 26, 2009, at 3:16 PM, Suresh Krishnan wrote:
Hi Marshall,
I had a quick glance over the draft and I am not convinced that it
will handle a certain class of errors.
Consider that the UDP header of the encapsulating IPv6 packet gets
corrupted and the destination port gets changed to say 2280 from the
AMT port (2268). This error will never be detected by the receiver and
the receiver will not be able to decapsulate the multicast packet and
send it on its way. If the UDP checksum was properly calculated, this
error would have been detected.
But, if the checksum was there, wouldn't the packet be dropped ? So
isn't the result a dropped packet
anyway ?
If the checksum was there, the packet would not be passed on to a wrong
application (the app listening on port 2280) and probably be interpreted
wrongly as payload for that application. Imagine that the port gets
changed to 80 and the tunneled packet is interpreted as http.
We thought about security issues here (suppose a man in the middle
attack changes the port to, say, 80), but
we couldn't figure out a security issue that the attacker couldn't just
do anyway (they don't need AMT to throw
random packets to port 80, and could recalculate the checksum if it were
used anyway).
I was not thinking of this as an attack vector. Just an unhandled error
with non-malicious senders.
Cheers
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
