Subject: Re: [lisp] #9: Sending UDP Zero Checksums Violates RFC 2460

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 08 Dec 2009 10:17:24 -0000

#9: Sending UDP Zero Checksums Violates RFC 2460
-------------------------------+--------------------------------------------
Reporter:  mrw@…               |        Owner:                 
    Type:  technical           |       Status:  closed         
Priority:  major               |    Component:  draft-ietf-lisp
Severity:  -                   |   Resolution:  fixed          
Keywords:  udp checksums       |  
-------------------------------+--------------------------------------------
Changes (by hartmans-ietf@…):

  * status:  new => closed
  * resolution:  => fixed

Old description:

> The use of zero UDP checksums in IPv6 is forbidden by RFC 2460.  This
> issue could be addressed in one of two ways:  (1) move to any
> standards-compliant encapsulation, or (2) include a normative
> reference to a standards-track document that updates RFC 2460 to allow
> UDP zero checksums.

New description:

 The use of zero UDP checksums in IPv6 is forbidden by RFC 2460.  This
 issue could be addressed in one of two ways:  (1) move to any
 standards-compliant encapsulation, or (2) include a normative
 reference to a standards-track document that updates RFC 2460 to allow
 UDP zero checksums.

--

Comment:

 From a 15 September 2009 message from Sam Hartman acting as chair:

 Folks, we've spent a lot of bits discussing UDP checksums.  I think
 we're going in circles at this point and are not significantly
 covering new ground.

 remember that what we were trying to do was to describe what LISP
 would do well enough that we could put this issue aside until 6man and
 the rest of the IETF decided for the IETF as a whole.  Obviously,
 we'll go along with whatever IETF consensus emerges.  So, we don't
 need to get this perfect.  It's not actually clear we needed to say
 anything at all, although I believe a lot of us see value in telling
 implementations what is going on today.

 I don't think there is more value in discussing the referenced UDP
 issues (and see a separate note on #12 I'll send)

 So, to remind ourselves, especially for the tracker:

  * We get significant benefit from using UDP or TCP because  it makes
 working with existing ECMP/LAG boxes possible.
  * For IPv6 the current specs do not allow sending 0 UDP checksum; we
 believe that there are significant hardware  implementations that cannot
 calculate UDP checksums without forcing the checksum calculation to
 software.  That's a non-starter for some of the deployment environments
 that these vendors want to use their hardware implementation in because
 the load would be higher than what could be handled in software.
  * We believe there are implementations that would be difficult to change
 to send 0 checksums
     ** Several commodity operating systems  have removed the configuration
 parameter to send 0 checksums; where it exists, it tends to be per-system
 and not per socket/flow.
     ** Existing commodity IP stacks definitely don't send 0 checksums for
 IPv6.
     ** One implementor and several individuals have indicated that is
 desirable to be able to implement on commodity IP stacks.
  *  We don't actually need to require that you send 0 checksums; there is
 debate about whether you should do so when you can.
  * For hardware implementations that cannot reasonably send UDP checksums
 to be able to turn them off, all receivers must be able to receive 0
 checksums.
  * There are implementations of IP and UDP that would be very difficult to
 change in order to accept 0 checksums for UDP for IPv6.  There are
 hardware, software and politics issues, depending on the implementation
 * Based on the discussion I think it likely that we will not achieve
 universal interoperability for lisp over IPv6 if 0 checksums are sent.
 It's unclear how big of a problem this will be in practice.

 Alternatives proposed:
  * Give up on the LAG/ECMP requirement.
     ** It's not clear how soon we need LAG/ECMP for V6; some have said
 today, but other WG participants questions this.
     ** It seems that it might be a full hardware cycle (7 years? 10
 years?) before you could depend on different LAG behavior.
  * Use multiple source addresses--twiddle the V6 IID in order to work with
 ECMP/LAG and use something other than UDP
     ** The chairs called for people to flesh out such alternatives but
 none were fleshed out
     ** Doing this is very tricky.  For example, the control plane needs to
 be adapted so that things like locator reachability work.
     ** Some participants have claimed this is impossible.  I don't think
 that claim has been substantiated.  However there is no version of this
 proposal fleshed out sufficiently to be evaluated, and we have given ample
 opportunity for such a proposal to be developed.

 Sausage was made.  There was a lot of discussion.  In the judgment of
 the chairs, the LISP working group has reached rough consensus on the
 text in Dino's Friday diff.  We do not believe that additional
 discussion of the same issues will yield a better result within the
 LISP working group.

 Someone's going to ask when it would be appropriate to re-open this
 discussion.  This is my personal opinion; I have not discussed in
 detail with Darrel.

  * When the IETF comes to consensus on handling UDP encapsulation for
 tunnels we will need to revisit this issue.  Even if what is now our
 preferred behavior  is permitted by IETF standards track documents, it is
 quite conceivable that the larger discussion will bring forward
 information that changes our thinking.
  * #13 discusses analysis that we need to do in order to confirm that LISP
 itself does not require integrity protection and that LISP will not damage
 other Internet hosts.  I think we should leave concerns about damaging
 other Internet hosts  to the rest of the IETF, at least until they tell us
 what the bar is.  If we find that LISP itself needs integrity protection,
 we could potentially revisit  this discussion, although we should probably
 prefer other approaches.
  * I don't think we've come to an informed consensus about the tradeoff
 between various classes of implementation and for example how bad it would
 be not to have interop with commodity IP stacks.  In particular, the WG
 has not become sufficiently informed about the lisp deployment model.  I
 think there is a presumption in the WG (one I suspect that once I
 understand the deployment model I'll probably support) that it's really
 important for LISP  to be able to run on high-end routers.  I think there
 is a presumption in the WG that it is less important for it to be able to
 run on stock IP stacks.   If the deployment discussion significantly
 changes our thinking, we may revisit this issue for that reason.  However
 I think it would have to be a significant shift for it to be worthwhile.

 Jari has asked the chairs to make it clear that this is a broader
 issue and that we'll align with what the. IETF does.  So, I'm asking
 Dino to take his Friday text plus a sentence noting that we will align
 with the IETF when it is done.  I have not wordsmithed this; I'd like
 to go with this for 04, and we can revise in 05 if really needed.
 However I ask you to carefully consider whether you really want to
 re-open this can of worms before you propose textual changes.

    UDP Checksum:  this field SHOULD be transmitted as zero by an ITR
 for
       either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].
 When a
       packet with a zero UDP checksum is received by an ETR, the ETR
       MUST accept the packet for decapsulation.  When an ITR
 transmits a
       non-zero value for the UDP checksum, it MUST send a correctly
       computed value in this field.  When an ETR receives a packet with
       a non-zero UDP checksum, it MAY choose to verify the checksum
       value.  If it chooses to perform such verification, and the
       verification fails, the packet MUST be silently dropped.  If the
       ETR chooses not to perform the verification, or performs the
       verification successfully, the packet MUST be accepted for
       decapsulation.  The handling of UDP checksums for all tunneling
       protocols, including LISP, is under active discussion within the
       IETF.  When that discussion concludes, any necessary changes
       will be made to align LISP with the outcome of the broader
       discussion.

-- 
Ticket URL: <http://tools.ietf.org/wg/lisp/trac/ticket/9#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues