Re: [lisp] IPv6 UDP checksum issue

Margaret Wasserman <mrw@lilacglade.org> Thu, 30 July 2009 16:50 UTC

Return-Path: <mrw@lilacglade.org>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC693A6BF8 for <ipv6@core3.amsl.com>; Thu, 30 Jul 2009 09:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level:
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ+vph7+PysD for <ipv6@core3.amsl.com>; Thu, 30 Jul 2009 09:50:04 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id A9C6D3A70B5 for <ipv6@ietf.org>; Thu, 30 Jul 2009 09:50:04 -0700 (PDT)
Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id NEUy1c00A0cZkys5BGq7iF; Thu, 30 Jul 2009 16:50:07 +0000
Received: from dhcp-53f4.meeting.ietf.org ([130.129.83.244]) by OMTA10.westchester.pa.mail.comcast.net with comcast id NGpr1c0015GHNbm3WGpu8w; Thu, 30 Jul 2009 16:50:05 +0000
Message-Id: <A17F9C93-6BFD-4FBC-BCA8-E1C1367F23F2@lilacglade.org>
From: Margaret Wasserman <mrw@lilacglade.org>
To: Dino Farinacci <dino@cisco.com>
In-Reply-To: <FA1A0C09-FDE5-4ACD-AEA1-476B090C702D@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: [lisp] IPv6 UDP checksum issue
Date: Thu, 30 Jul 2009 12:49:49 -0400
References: <F3FC18FF-E085-47E9-8376-2C4DA00D9F03@americafree.tv> <FA1A0C09-FDE5-4ACD-AEA1-476B090C702D@cisco.com>
X-Mailer: Apple Mail (2.935.3)
Cc: ipv6@ietf.org, lisp@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 16:50:05 -0000

On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:

>> This is a reminder that  draft-fairhurst-6man-tsvwg-udptt and
>>
>> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
>>
>> are still open and will be discussed at the 6man meeting Wednesday.
>>
>> Basically, one prescribes no checksum for the "outer" packet in
>> IPv6 encapsulations, the other a fixed checksum per flow. My
>> understanding is that this matter is relevant to LISP.
>>
>> If you are interested, please try to attend as a decision may be  
>> made soon.
>
> Sorry, I have a conflict right now. But here is the position of one  
> LISP implementor and a coauthor of the LISP specifications:
>
> From a practical perspective, we prefer that a LISP encapsulator  
> (ITR and PTR) not incurred additional work when encapsulating  
> packets. The main LISP spec indicates:
>
> (1) The UDP checksum in the outer header MUST be set to 0 by an  
> encapsulator.
> (2) The decapsulator MUST ignore the UDP checksum.
>
> We stand by this text and see no reason to change it.

Are you using "we" to refer to yourself as both an implementor and a  
co-author?  ;-)

FWIW, I have serious concerns about draft-fairhurst-6man-tsvwg-udptt,  
as it involves overloading the UDP "next-header" value to refer to two  
different header types (real UDP and UDP-TT).

However, I also have serious concerns about using zero UDP checksums  
with IPv6.
>
> There are no practical reasons to use outer header UDP checksums  
> regardless of the 4 combinations of packet types (v4-in-v4, v6-in- 
> v6, v6-in-v4, or v4-or-v6) being forwarded by LISP routers.

I think that this statement is answering the wrong question...

Since we have standards-track protocols that indicate that UDP  
checksums must not be zero in IPv6 (for good reasons), I believe that  
we should use valid UDP checksums in IPv6 outer headers, unless we can  
provide practical (and compelling) reasons why _not_ to do so.  So,  
what are those reasons?

If we do manage to achieve consensus that it makes sense to zero-out  
the UDP checksum in IPv6 outer headers, there are a number of  
questions we will have to answer...

The problem with eliminating the UDP checksum in UDP over IPv6 is that  
(unlike in IPv4) the IPv6 source and destination addresses are not  
protected.  So, the packet may be corrupted such that it is sent to  
the wrong destination.  When it arrives at the wrong destination, it  
may be processed by an IP stack that is unaware of LISP.

We need to consider what will happen if one of these packets is  
received by a non-LISP node.  Are you assuming that non-LISP stacks  
will simply throw away these packets, because they have zero (and  
therefore invalid) UDP checksums?  That's only a good assumption if we  
assume that LISP is the _only_ protocol that will allow the use of  
zero checksums.  If the packet is processed by the stack, there  
shouldn't be a non-LISP application on port 4342, so the packet should  
be dropped.  We should define, however, how the sending LISP node will  
deal with an ICMPv6 "port unreachable" error, so that an error  
received from the wrong destination does not interfere with  
communication with the right destination.

We also need to consider the possibility that a packet will be  
received by a different LISP node than the one for which it was  
intended, or that it will arrive at the correct LISP destination with  
the wrong source address in the external header.  What happens in  
those cases?

Margaret