Subject: [Fwd: I-D Action:draft-eubanks-chimento-6man-00.txt]

From: Marshall Eubanks <[email-masked]>
Date: Wed, 25 Feb 2009 14:35:18 -0500

I haven't seen any discussion of this on this list - there has been  
some on MBONED.

So far, we have as users for this flexibility

AMT (the original need)

LISP and

(According to Dave Thaler) maybe UDP-ESP (RFC 3948) across a NAT64.

If people here have comments on these uses, or know of other uses,  
please comment
on this list. Of course, any and all other comments, suggestions, or  
brickbats will be welcomed.

Regards
Marshall

P.S. Please note that this draft was largely written by Philip  
Chimento. I don't know how the XML process
lead to me being the only author - this will be fixed in the next round.

Begin forwarded message:

> From: Brian Haberman <[email-masked]>
> Date: February 24, 2009 8:21:19 AM EST
> To: [email-masked]
> Subject: [MBONED] [Fwd: I-D Action:draft-eubanks-chimento-6man-00.txt]
>
> All,
>     Here is the draft that proposes to loosen the UDP checksum rule  
> for IPv6.  I would appreciated if discussions of this draft occur on  
> the 6MAN mailing list ([email-masked]).
>
> Regards,
> Brian
>
>
> -------- Original Message --------
> Subject: I-D Action:draft-eubanks-chimento-6man-00.txt
> Date: Mon, 23 Feb 2009 10:45:01 -0800 (PST)
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : UDP Checksums for Tunneled Packets
> 	Author(s)       : M. Eubanks
> 	Filename        : draft-eubanks-chimento-6man-00.txt
> 	Pages           : 7
> 	Date            : 2009-02-23
>
> We address the problem of computing the UDP checksum on tunneling
> IPv6 packets when using lightweight tunneling protocols.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-eubanks-chimento-6man-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 Feb 2009 21:28:26 +1030

Hi,

On Wed, 25 Feb 2009 14:35:18 -0500

> brickbats will be welcomed.

I've had a very, very brief look at the AMT draft. It seems that the
UDP ports are being used as some sort of AMT session identifier, which
then creates the need to tunnel over UDP, causing this IPv6 UDP checksum
issue.

Would there be any possibility of using something like the idea of
transient IPv6 addresses for AMT session identifiers over IPv6, as
described in:

"Transient Addressing for Related Processes: Improved Firewalling by
Using IPV6 and Multiple Addresses per Host", Peter M. Gleitz and Steven
M. Bellovin.

If that's possible, you then wouldn't need UDP, and you'd then not have
the overhead of manditory UDP over IPv6 checksums (and a little less
tunnel overhead too, of course).

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 26 Feb 2009 15:16:47 -0500

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.

Cheers
Suresh

On 25/02/09 02:35 PM, Marshall Eubanks wrote:
> I haven't seen any discussion of this on this list - there has been some 
> on MBONED.
> 
> P.S. Please note that this draft was largely written by Philip Chimento. 
> I don't know how the XML process

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 26 Feb 2009 15:34:54 -0500

Hello;

On Feb 26, 2009, at 3:16 PM, Suresh Krishnan wrote:

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

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

Regards
Marshall

>> on this list. Of course, any and all other comments, suggestions,  
>> or brickbats will be welcomed.
>> Regards
>> Marshall
>>> for IPv6.  I would appreciated if discussions of this draft occur  
>>> on the 6MAN mailing list ([email-masked]).
>>>
>>> Regards,
>>> Brian
>>>
>>>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 26 Feb 2009 16:32:48 -0500

Hi Marshall,

On 26/02/09 03:34 PM, Marshall Eubanks wrote:
>> 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.
>>
> 

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

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 26 Feb 2009 17:26:00 -0500

On Feb 26, 2009, at 4:32 PM, Suresh Krishnan wrote:

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

Yes, we did think about this. This seems like a rather low threat to  
me - but probably something to add
to the security implications.

Regards
Marshall

> I was not thinking of this as an attack vector. Just an unhandled  
> error with non-malicious senders.
>
> Cheers
> Suresh
>
>
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 26 Feb 2009 17:53:30 -0500

Hi John,

On 26/02/09 05:25 PM, John Zwiebel wrote:
> 
> On Feb 26, 2009, at 11:32 AM, Suresh Krishnan wrote:
>> interpreted wrongly as payload for that application. Imagine that the 
>> port gets changed to 80 and the tunneled packet is interpreted as http.
>>
> 
> Do you have any statistics which would give us a clue that a packet was
> changed and all the other checksums on that packet (ethernet frame for 
> instance)
> would be recalculated and correct but only the UDP checksum was bad?
> 
> My gut feeling is this would be a pretty remote possibility.

Yep. This is remote but possible. Consider a router that corrupts the 
packet when moving packet between queues. But I guess this is the reason 
we have an end-to-end checksum. Otherwise we could just depend on the L2 
checksums.

Cheers
Suresh

---

From: John Zwiebel <[email-masked]>
Date: Thu, 26 Feb 2009 12:25:06 -1000

On Feb 26, 2009, at 11:32 AM, Suresh Krishnan wrote:

>>>
>> But, if the checksum was there, wouldn't the packet be dropped ?  
>> So isn't the result a dropped packet
>> anyway ?
>

Do you have any statistics which would give us a clue that a packet was
changed and all the other checksums on that packet (ethernet frame  
for instance)
would be recalculated and correct but only the UDP checksum was bad?