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

[Marshall Eubanks <[e-mail]>]

On Sep 13, 2009, at 9:24 AM, Margaret Wasserman wrote:

>
> Hi Marshall,
>
> Just FYI -- the UDP-TUNNEL draft is now expired.  You might want to  
> update (or resubmit) it.
>
> On Sep 12, 2009, at 1:45 PM, Marshall Eubanks wrote:
>> 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.
>
> These issues  can definitely be discussed further, alhtough perhaps  
> it would be better to discuss them in 6man.  I'll wait for an  
> explanation from Magnus about why he proposed this restriction  
> before stating an opinion on whether or not to remove it.  In  
> general, though,  it would be good to explain the reasons for all of  
> the restrictions in your draft, so that people won't be inclined to  
> ignore them without realizing why they are important.  If we can't  
> give a good explanation of the reasons for a particular restriction,  
> perhaps we should take it out.

I think that is a good principle, and one that would certainly apply  
here.

>
>>> 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.
>
> LISP currently does nothing to ensure that "inner" packets have any  
> sort of integrity checking.  LISP does not (currently) discard UDP  
> packets that have zero checksums before tunneling them as required  
> in UDP-TUNNELS, and it doesn't do anything else to check that the  
> inner packets have integrity checks.
>

It also, AFAIKT, verify those integrity checks in any way.

IPv6 in IPv6 tunnels and IPv6 in IPv4 tunnels in LISP should not have  
this problem, correct ? (As incoming UDP packets, they would be  
subject to RFC 2460.)
Now, IPv4 in  IPv4 is not an issue, and that leaves IPv4 in IPv6  
tunnels - do you agree with this reasoning ?

It might be possible to treat 4n6 traffic as a corner case. Suppose,  
for example, that LISP requires 4n6 traffic to have checksums. Now, if  
the same traffic arrives for a 4n4 tunnel, and the ITR _doesn't check  
the incoming checksum_ and puts the traffic in the tunnel, it seems to  
me that that the 4n4 traffic is also unprotected end-to-end.

A question that occurs to me is to what extent control traffic (i.e.,  
non-UDP and non-TCP traffic) would be carried over LISP, and to  
whether any of that
traffic is not protected by other means.

> The LISP documents also describe a case where LISP packets would be  
> tunneled in another LISP outer header for Traffic Engineering  
> purposes.  In that case,  encapsulating an existing LISP packet  
> (with a zero UDP checksum) in an  IPv6/UDP/LISP header with a zero  
> UDP checksum would clearly violate the restrictions in UDP-TUNNELs.

I look forward to the thrashing out of the needs for this in LISP, and  
also the reasons not to allow unprotected tunnels-in-tunnels.

>>
>> 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.=
>
> I do understand that some of this could change, and hopefully LISP  
> Folks will work with 6man to try to get our needs met.  But in the  
> meantime, we have two drafts, one of which normatively references  
> the other, that are incompatible in certain ways.
>
> IMO, we should log a LISP issue indicating that LISP (-04) is not  
> fully compatible with UDP-TUNNEL (-00) in four ways:
>
> (2) LISP does not discard packets with zero UDP checksums before  
> enapsulating them in IPv6/UDP with a zero UDP checksum.
> (2) LISP does not ensure that all encapsulated packets contain an  
> inner integrity checking mechanism before encapsulating in IPv6/UDP  
> with a zero UDP checksum.
> (3) LISP contains an option that would result in fragmentation of  
> inner packets, and it does not indicate that non-zero UDP checksums  
> must be used when these packets are encapsulated in an IPv6 LISP  
> header.
> (4) The LISP specifications provide for encapsulating LISP packets  
> within a second LISP header and it does not indicate that non-zero  
> UDP checksums must be used when the new outer header is an IPv6 LISP  
> header.
>
> This issue will insure that we don't forget to check for  
> compatibility between LISP and UDP-TUNNELS before we publish the  
> LISP RFCs.
>
> After we enter the issue in the tracker, I think we should park the  
> issue (for the LISP group, at least) and re-visit it after the 6man  
> group (with help from those of us who participate) reaches consensus  
> on the final form (if any) of the UDP-TUNNEL document.  When UDP- 
> TUNNEL is no longer a moving target, we can assess what changes (if  
> any) will be required for LISP to use it properly.
>

I think that all of this is reasonable. We will our this draft soon,  
and I hope to summarize all of this discussion at 6Man in Hiroshima.

Regards
Marshall

> Margaret
>
>
>
>
>
>
>
>