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

From: Brian Haberman <[email-masked]>
Date: Tue, 24 Feb 2009 08:21:19 -0500

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.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Feb 2009 12:17:08 -0800

Here are my comments. Draft text comes first and indented and my  
comments follow.

> The argument made by the draft authors is that since multicast
> packets already have a UDP header with a checksum, there is no
> additional benefit and indeed some cost to nodes to both compute and
> check the UDP checksum of the outer (encapsulating) header.  However,
> Consequently, IPv6 should make an exception to the rule that the UDP
> checksum MUST not be 0, and allow tunneling protocols to set the
> checksum field of the outer header only to 0 and skip both the sender
> and receiver computation.

It is worse than that for AMT. Since the control packets are  
encapsulated in an IGMP packet format. There is an IGMP checksum  
performed as well, then on top of that encapsulated in UDP, with the  
UDP checksum performed there too.

So please note that the burden might be less in the control-plane, but  
it is less necessary to do UDP checksum as well in this case. I think  
you shouldn't deprecate the behavior in the spec, but outline how  
double check-summing is occurring in this case.

>  3.  Exception for lightweight tunneling: Amend IPv6 to allow a 0
>        value in the UDP checksum field for leightweight tunneling
>        protocols which allows them to bypass any checksum  
> computation in
>        the outer header if the inner packet is protected.  Rules for
>        usage in this case must be developed.

Be more clear that the encapsulator does not have to compute a  
checksum on packet forwarding and the decapsulator, because the UDP  
checksum is 0, does not need to check the checksum.

>    4.  Another possibilty is to allow an exception for the AMT  
> protocol
>        only.  This may seem undesirable, but it would restrict the
>        implementation of a zero checksum UDP header over IPv6 only to
>        the AMT endpoints.  Any misdelivered packets (i.e. arriving  
> at a
>        non-AMT endpoint) would simply be discarded.

There are other protocols coming that will use UDP encapsulation. It  
is becoming popular to use UDP so you get LAGs to work inside of the  
tunnel as well as an easier way to get through firewalls.

One example is LISP.

>   Others on the mailing list have pointed out other issues with
>    changing the IPv6 specification to allow a checksum of 0 on the  
> outer
>    packet header.  In particular, Matt Mathis points out that some
>    tunneling devices ignore the DF bit and fragment silently.  This
>    would allow two fragmented UDP packets to be spliced together and  
> be
>    decapsulated and forwarded by a tunnel endpoint.

But can we make a mention that link-layer CRC, ECC, and checksum do  
find high percentage of link errors, so there is another level of  
protection we can rely on. Please state that somewhere in the spec.

>  Magnus Westerlund proposed some restrictions on using a UDP header
>    checksum of 0.  These are:

Since Magnus is being referred to multiple times in this draft, I  
suggest you put his contact info at the end.

>  2.  The tunneling protocol and implementation must not use
>        fragmentation of the inner packets being carried.

I would change "must not" to "should not".

>    We would suggest the following elaborations of the above
>    restrictions, if a change in the IPv6 specification moves forward:
>
>    o  An inner IPv4 packet with a UDP checksum equal to 0 must not be
>       tunneled.
>
>    o  Non-IP inner packets must have a CRC or other mechanism for
>       checking packet integrity.
>
>    o  Other tunneling protcocols that use the UDP checksum equal to 0
>       MUST NOT be tunneled themselves, even if more deeply  
> encapsulated
>       packets have checksums or other integrity checking mechanisms.
>
>    o  We would recommend that general protocol stack implementations  
> do
>       NOT implement this change.  The exception should remain  
> restricted
>       to devices serving as endpoints of the lightweight tunneling
>       protocol adopting the change.
>
>    In addition, we would recommend that a security analysis be done in
>    order to assess whether any new vulnerabilities are introduced by
>    such a change.

This is to strong of language. You create more work for hardware  
implementations to adhere to this. Which means they will just ignore it.

I would change all occurences of "must" to "should".

Thanks,
Dino

On Feb 24, 2009, at 5:21 AM, Brian Haberman wrote:

> for IPv6.  I would appreciated if discussions of this draft occur on  
> the 6MAN mailing list ([email-masked]).
>
> Regards,
> Brian
>
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 24 Feb 2009 15:50:28 -0800

On Tue, Feb 24, 2009 at 12:17 PM, Dino Farinacci <[email-masked]> wrote:
> Here are my comments. Draft text comes first and indented and my comments
> follow.
>
> It is worse than that for AMT. Since the control packets are encapsulated in
> an IGMP packet format. There is an IGMP checksum performed as well, then on
> top of that encapsulated in UDP, with the UDP checksum performed there too.
>
> So please note that the burden might be less in the control-plane, but it is
> less necessary to do UDP checksum as well in this case. I think you
> shouldn't deprecate the behavior in the spec, but outline how double
> check-summing is occurring in this case.

Dino, I believe the current spec must be deprecated because it
specifically forbids a 0 checksum.

Greg

>>       protocols which allows them to bypass any checksum computation in
> Be more clear that the encapsulator does not have to compute a checksum on
> packet forwarding and the decapsulator, because the UDP checksum is 0, does
> not need to check the checksum.
>
>>   4.  Another possibilty is to allow an exception for the AMT protocol
>>       the AMT endpoints.  Any misdelivered packets (i.e. arriving at a
> There are other protocols coming that will use UDP encapsulation. It is
> becoming popular to use UDP so you get LAGs to work inside of the tunnel as
> well as an easier way to get through firewalls.
>
> One example is LISP.
>
>>   changing the IPv6 specification to allow a checksum of 0 on the outer
>>   would allow two fragmented UDP packets to be spliced together and be
> But can we make a mention that link-layer CRC, ECC, and checksum do find
> high percentage of link errors, so there is another level of protection we
> can rely on. Please state that somewhere in the spec.
>
> Since Magnus is being referred to multiple times in this draft, I suggest
> you put his contact info at the end.
>
>>      MUST NOT be tunneled themselves, even if more deeply encapsulated
>>   o  We would recommend that general protocol stack implementations do
>>      NOT implement this change.  The exception should remain restricted
>>    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
>>
>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Feb 2009 16:07:02 -0800

>> encapsulated in

The AMT spec?

Dino

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 24 Feb 2009 16:10:55 -0800

>> specifically forbids a 0 checksum.

No, sorry. The IPv6 UDP spec which does not allow 0 checksum.

Greg

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Feb 2009 16:11:56 -0800

Right agree.

Dino

On Feb 24, 2009, at 4:10 PM, Greg Shepherd wrote:

>>>> in
>>>> an IGMP packet format. There is an IGMP checksum performed as  
>>>> well, then
>>>> on
>>>> top of that encapsulated in UDP, with the UDP checksum performed  
>>>> there
>>>> too.
>>>>
>>>> So please note that the burden might be less in the control- 
>>>> plane, but it
>>>> is

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 24 Feb 2009 19:36:46 -0500

> No, sorry. The IPv6 UDP spec which does not allow 0 checksum.

Correct.

Note that I do not think that it is appropriate to say that we are  
"deprecating" IPv6, or IPv6 UDP.

We are adding flexibility that is needed to support applications,  
including (but not limited to)
AMT. In most cases, checksums WILL still be required, and the spec  
will be unchanged. But in cases like this,
where the flexibility is needed, it will be there.

<Wearing no hats at all>
Marshall

---

From: Dave Thaler <[email-masked]>
Date: Tue, 24 Feb 2009 21:15:10 -0800

You don't need to do a "deprecate" per se to do this.  You just need
to do an "updates" as far as I know.

Another protocol that I believe would want a 0 checksum is if you
want to use UDP-ESP (RFC 3948) across a NAT64.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Marshall Eubanks
> Sent: Tuesday, February 24, 2009 4:37 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MBONED] [Fwd: I-D Action:draft-eubanks-chimento-6man-
> 00.txt]
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Feb 2009 21:55:11 -0800

> to do an "updates" as far as I know.

Well, that's what I was thinking (but didn't say it). I meant  
deprecate the text and not the spec.

> want to use UDP-ESP (RFC 3948) across a NAT64.

Yep. But can you kill NAT64?

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 25 Feb 2009 06:45:34 -0500

> want to use UDP-ESP (RFC 3948) across a NAT64.

This plus LISP makes 2 protocols beyond AMT that need this. If you  
know of others, please send them to the list.

My feeling is that this is likely to be widely used, if it gets  
through the process.

Regards
Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 25 Feb 2009 10:14:03 -0800

Maybe Marshall, you should send this request to a wider list than just  
multicast people.

Dino

On Feb 25, 2009, at 3:45 AM, Marshall Eubanks wrote:

>>>>>>>> additional benefit and indeed some cost to nodes to both  
>>>>>>>> compute
>>>>>>>> and
>>>>>>>> Consequently, IPv6 should make an exception to the rule that  
>>>>>>>> the
>>>>>>>> UDP

---

From: "Chimento, Philip F." <[email-masked]>
Date: Thu, 26 Feb 2009 11:22:06 -0500

Dino: Some quick repsonses inline.  With this draft, we wanted to get the basic points into the draft and get it out so that people could focus discussion on it....Clearly it will need some revisions...

> checksum is 0, does not need to check the checksum.

OK. We'll clarify that in the next version.

> tunnel as well as an easier way to get through firewalls.

OK. We should make mention of that-I think that we need to understand whether there
are any wrinkles that these other protocols bring to the table...

> protection we can rely on. Please state that somewhere in the spec.
Right, but the CRC won't protect against the kind of error that Matt mentioned.
The paper that he pointed to is pretty interesting, since it talks about how errors creep in other
than by line hits.

> suggest you put his contact info at the end.
I'll contact Magnus and see how he wants us to do that...

> I would change all occurences of "must" to "should".

Well, I think that this is something that is worth discussion on the lists...

Regards,
Phil Chimento

JHU/APL
240-228-1743
443-778-1743
[email-masked]
--

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 26 Feb 2009 11:39:58 -0500

On Feb 26, 2009, at 11:22 AM, Chimento, Philip F. wrote:

> Dino: Some quick repsonses inline.  With this draft, we wanted to  
> get the basic points into the draft and get it out so that people  
> could focus discussion on it....Clearly it will need some revisions...
>
>
> OK. We’ll clarify that in the next version.
>
> OK. We should make mention of that—I think that we need to  
> understand whether there
> Right, but the CRC won’t protect against the kind of error that Matt  
> mentioned.

I think that that is only appropriate for co-authors. If Magnus wants  
to be a co-author, we can certainly
discuss it.

Marshall

>
> I’ll contact Magnus and see how he wants us to do that...
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Feb 2009 12:11:53 -0800

Sure, thanks.

Dino

---

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.
> 
> 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,
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

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

>> I haven't seen any discussion of this on this list - there has been  
>> some on MBONED.
>> 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
>>> 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: 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 ?
>
> 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.

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.

---

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

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:
>> interpreted wrongly as payload for that application. Imagine that the 
>> port gets changed to 80 and the tunneled packet is interpreted as http.
>>
> 
> changed and all the other checksums on that packet (ethernet frame for 
> instance)

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