Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling

[Marshall Eubanks <[e-mail]>]

Dear Margaret;

On Sep 11, 2009, at 9:25 PM, Margaret Wasserman wrote:

>
> On Sep 11, 2009, at 6:24 PM, Sam Hartman wrote:
>
>>>>>>> "Margaret" == Margaret Wasserman <[e-mail]> writes:
>>
>>  Margaret> I have a new issue that should probably go in the
>>  Margaret> tracker (for resolution in -05 or later, not to hold
>>  Margaret> anything up now).
>>
>>  Margaret> The UDP-TUNNELS document contains the following
>>  Margaret> restriction:
>>
>> Margaret, I think this would be a duplicate of an open issue.  Your
>> existing issue requires us to normatively reference a spec that makes
>> appropriate standards track changes to permit what we're doing.
>>
>> If you believe that Marshall's draft doesn't do that, then we either
>> need to convince Marshall to do what we want or reference another
>> draft.

I might point out that our draft has not yet been accepted by 6Man,  
and we are certainly open to changes. This
entire discussion here has been very good for our draft.

>>
>> I don't see how an extra issue will help.
>>
>> Does this work for you?
>
> No, I don't see why this is a duplicate.  I am saying that if we use  
> IPv6/UDP zero checksums, the UDP-TUNNELS spec contains a restriction  
> that we can't send fragments.

It says " The tunneling protocol and implementation must not use
       fragmentation of the inner packets being carried."

This comes from an email of Magnus Westerlund
-----
[MBONED] WGLC for <draft-ietf-mboned-auto-multicast-08.txt> - UDP  
checksum?
	Date: 	December 5, 2007 3:12:05 PM EST
I think it will be acceptable to update RFC 2460 to say that the UDP
checksum may be turned of[f] under the following restrictions:

1. The UDP payload must have the capability to verify its integrity by
itself, for example by being a complete IP packet in itself.

2. That IP packet fragmentation must not be used.
------
We interpreted "2" as coming from "1" - i.e., the total "outer" packet  
could be fragmented, but the "inner" packet should not be a fragment  
of the original "inner" packet, as then I could not  verify its  
integrity by itself.

We also interpreted this as both a AD proscription, and as feedback  
from IPv6 guru's, so we didn't question it much. However, the issue  
can certainly be raised here.

I personally think that we could live with fragments. Here is my  
reasoning

- If I want to send fragments over IPv6 LISP, my understanding is that  
only the first will have the inner UDP header, and thus the inner  
fragments after the first will not have any data checks _inside their  
fragment_. However, when the inner packet is reassembled, it _will_  
have a checksum check. This to me fits within the "other integrity  
checks" mentioned below.

- The current draft draft-ietf-lisp-04.txt says (Section 5)

   It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.

I am assuming that the discussion in Section 5.4.1 applies to IPv6 as  
well as IPv4.

Section 5.4.1 :

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

So, again, this would lead to unprotected fragments but errors in the  
inner packet should be caught at the end. In the Tunneling draft
there is an implicit assumption that catching errors only at the end  
is acceptable.

In IPv6 itself, it is also not possible to perform a checksum test  
except at the end node, as there is
no separate checksum for any fragments, so if tunneling was not used,  
any errors would still only be caught at the end.

Magnus might care to provide more insight as to the push-back here, so  
I have cc:ed him.

>
> After reading Fred Templin's mail, I realize that there is another  
> possible solution to this problem -- to state in the fragmentation  
> section that you MUST NOT set the UDP/IPv6 chekcsum to zero for  
> packets that contain fragments.
>
> The UDP-TUNNELS draft is written with a different notion of tunnels  
> than LISP -- like somehow the tunnel will be used for one  
> application or one type of traffic.  So, it doesn't actually talk  
> about using zero checksums for some packets and non-zero checksums  
> for others.  It just says that you must discard, or can't send,  
> certain types of packets.  Presumably we don't want LISP ITRs to  
> simply discard packets that are not integrity checked, but I think  
> it would be consistent with UDP-TUNNELS to just use non-zero IPv6/ 
> UDP checksums for those packets...
>

It certainly would.

- draft-eubanks-chimento-6man is intended to allow for tunneling uses  
without an outer packet checksum in the case where the inner packet  
does have a checksum. That way, on an end to end basis, the packets  
will be checked.

- Yes, that does imply it is intended for applications that only send  
inner packets with checksums or check to verify that the inner packet  
checksum is present.

- My understanding is that LISP is such a situation, and that is how I  
read the draft.

I regard how stringently this should be enforced as open to discussion  
and debate (i.e., what other integrity checks are acceptable), but I  
don't think we are going to get a "ignore all checksums" addition to  
IPv6.

Regards
Marshall

> Margaret
>
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>