Re: [lisp] IPv6 UDP checksum issue

Margaret Wasserman <mrw@sandstorm.net> Tue, 04 August 2009 19:39 UTC

Return-Path: <mrw@sandstorm.net>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C4628C101; Tue, 4 Aug 2009 12:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.146, 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 irQilZeHe0yI; Tue, 4 Aug 2009 12:39:45 -0700 (PDT)
Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id EEEF428C2F2; Tue, 4 Aug 2009 12:39:28 -0700 (PDT)
Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74Jbxjo098021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 15:37:59 -0400 (EDT) (envelope-from mrw@sandstorm.net)
Message-Id: <41CC608D-E261-4CD8-A22E-86FCFEE220FD@sandstorm.net>
From: Margaret Wasserman <mrw@sandstorm.net>
To: Marshall Eubanks <tme@americafree.tv>
In-Reply-To: <E883B21D-1DC9-423B-90D4-DF1BB1D774C9@americafree.tv>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 04 Aug 2009 15:37:58 -0400
References: <F3FC18FF-E085-47E9-8376-2C4DA00D9F03@americafree.tv> <FA1A0C09-FDE5-4ACD-AEA1-476B090C702D@cisco.com> <C3C481AD-5AB6-462C-A48C-F16E968DE03D@nokia.com> <C8F93853-FB91-4ABC-9CF5-E599FD27490E@cisco.com> <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <DB892549-640F-437C-BB4C-2C12A985C4F1@cisco.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <E883B21D-1DC9-423B-90D4-DF1BB1D774C9@americafree.tv>
X-Mailer: Apple Mail (2.935.3)
X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [lisp] IPv6 UDP checksum issue
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2009 19:39:46 -0000

On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote:
> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
>
> We intend to rev this shortly and comments would be appreciated.

If you do rev this document, I would like to see:

(1) An explanation of the difference in applicability between this  
mechanism
       and UDP-Lite.

(2) A specific applicability statement for when this mechanism can  
(and can't)
       be used.  Would we be allowing this mechanism _only_ for cases  
where
       IP is tunneled inside UDP/IP?   What about the AMT case?

(3) A section listing considerations that must be documented for  
protocols
       that use this mechanism, including:

     (3a) What happens when the destination IP address is corrupted in  
transit?
             (Note:  This isn't a concern in IPv4, as the IP header  
checksum will result
             in this packet being discarded by the receiving IP stack).

         (3a.i) What if a node that does not implement this protocol  
receives the
                    packet?
         (3a.ii) What if a node that does implement this protocol  
receives a packet
                    destined for another node?

     (3b) What happens when the source IP address is corrupted in  
transit?
             (Note:  This isn't a concern in IPv4, as the IP header  
checksum will result
             in this packet being discarded by the receiving IP stack).

	(3b.i) What happens when a node that does not implement this protocol
                    receives the ICMP "port unreachable" error?
         (3b.ii) What happens when a node that does implement this  
protocol
                    receives an ICMP "port unreachable" error for a  
packet it didn't send?

     (3c) What happens if one or both of the UDP ports are corrupted  
in transit?
             (Note:  This can happen in IPv4 in the zero checksum  
case, too, but not
             with UDP checksums turned on and/or UDP-Lite).

     (3d) What types of middleboxes does the protocol need to cross  
(routers,
              NAT boxes, firewalls, etc.), and how will those  
middleboxes deal with
              these packet

I don't really have enough knowledge to answer these questions for  
LISP.  I
tried to go down this path in an earlier message, and Dino didn't  
understand what
I was saying, but I'll try to do it once again.  Please correct me if  
I am missing
something.

I am making the assumption that (unlike AMT), all LISP packets will be  
sent to
a specific UDP port assigned to LISP.  Also, I am making the  
assumption that
if we write this document, some other protocols (besides LISP) will  
make use of
it, so some IP stacks on non-LISP nodes will process these packets.

(3a.i)  If a node that doesn't implement LISP receives this packet, it  
may be
            passed up to UDP (if zero checksums are supported).  At  
that point,
            though, it will be thrown away because there is no process  
listening
            on the LISP port and an ICMPv6 "port unreachable" error  
will be
            generated.  (This is different than the IPv4 case, where  
the packet
            will never make it to UDP).

(3a.ii) If a node that does implement LISP receives this packet, it  
will be
            sent to the LISP process, which will recognize that it is an
            encapsulated LISP packet.  What then?  (Note:  Again, this
            wouldn't happen in IPv4, as the packet would be discarded by
            the receiving IP stack.).

(3b.i) If a node that doesn't implement LISP receives an ICMP port
           unreachable for the LISP port, it may have a process that is
           using the local port from the original LISP packet.  Will  
that
           process receive the destination unreachable?  Or will the
           message be thrown away because the destination port doesn't
           match?  I think this might depend on how the process was
           bound to its socket, or something.  Can someone help me
           out here?  (Note:  This won't happen in IPv4, because the
           packet would have been discarded by IP, not by UDP).

(3b.ii) If a node that does implement LISP receives an ICMP port
            unreachable, it still might not have a process that is using
            the corresponding source port (right?).  In that case, I  
think
            that this is the same as 3b.i...  Would another process
            receive this error?  And, if so, how would it respond?

(3c) If the ports were corrupted in transit, we might get packets
         delivered to the wrong process (on the right machine)
         and/or responses or errors sent to the wrong process (on
         the right machine).  I think this all would have been covered
         by the above cases.

(3d) I don't know how middleboxes will deal with this...  What
         do IPv6 routers do today with zero-checksum UDP packets?
         What other IPv6 middleboxes exist today, and what would
         they do?

Personally, I think this is something we would need to understand
pretty fully before we could decide that turning off IPv6 UDP checksums
is a superior choice to using IP-in-IPv6 encapsulation (no UDP),
IP-in-IPv6/UDP-Lite encapsulation or UDP with checksums.

These are also areas that we should explore in a general sense before
we decide to publish Marshall's document as an alternative to using
IP-in-IPv6 encapsulation, UDP-Lite, or UDP with checksums.

Margaret