Re: [lisp] IPv6 UDP checksum issue

[Gorry Fairhurst <[e-mail]>]

I'd be very concerned if the IETF consensus was to introduce a change to 
the UDP checksum without fully evaluating the implications for the 
network and before considering the procedures by which new protocols 
could access a zero-checksum mode.

As I understand, the proposal to update RFC 2460 is NOT just concerning 
LISP routers, there would be host uses, at least for AMT, and likely 
future other applications too, their would be implications on 
middleboxes and possibly on existing applications.

I think the list below is a good summary of key issues. I'd like to use 
this as the basis for a summary of the tradeoffs. I am aware there's 
been quite a lot of discussion on the list while I was on vacation (both 
before and after this email), and also some more quite some months ago 
elsewhere. I'm going to try to compile what I understand under these 
headings... and get back soon.

Gorry

Margaret Wasserman wrote:
> 
> 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
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>