Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue

From: [email-masked] (Noel Chiappa)
Date: Tue, 11 Aug 2009 20:08:15 -0400 (EDT)

> From: Fred Baker <[email-masked]>

    > I think that I would word this as:
    > UDP Checksum: this field MAY be transmitted as zero, and the receiver
    > MAY ignore the checksum on receipt.

Now that I think about it, while this may pass muster in terms of meeting
standards, from an engineering standpoint, this is a bad idea. In giving
people the option to _not_ ignore the checksum, while also allowing people to
not _set_ it, it creates situations which go against one of the key
architectural principles of the Internet, Postel's Principle:
'Be liberal in what you receive'.

Consider a case where one has an ITR which has availed itself of the
opportunity to not set UDP checksums on user-data traffic (perhaps it has no
choice, being run on router hardware which doesn't even give the forwarding
engine access to the entire packet), trying to send packets to an ETR which
has decided not to accept packets which don't have a checksum. Needless to
say, the ETR won't accept any packets from that ITR.

Even if we say 'OK, so the ETR can only check checksums on packets that have
them', we still have the issue that there are lots of deployed boxes that
bash checksums without checking to make sure they are zero, before so doing.
So if there's one of those on the path, we're back to the same situation: a
'no-checksum' ITR can't talk to a 'wants-checksum' ETR.

So if the spec does eventually say something like the above (i.e. allow both
not setting checksums on transmission, and checking them on reception), it
needs to have something like this in it:

  "Note that an ETR which checks checksums may not be able to accept packets
  from an ITR which is not setting them. Since there are expected to be many
  such ITRs in service, such ETRs may thus have limited utility."

I mean, I think we are obligated to warn people who 'implement to the spec'
up front, and very plainly, that certain implementation choices will result
in devices with limited usability.

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2009 23:17:36 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> From: Fred Baker <[email-masked]> I think that I would word
    >> this as: UDP Checksum: this field MAY be transmitted as zero,
    >> and the receiver MAY ignore the checksum on receipt.

    Noel> Now that I think about it, while this may pass muster in
    Noel> terms of meeting standards, from an engineering standpoint,
    Noel> this is a bad idea. 

It doesn't pass muster from a standards point of view, exactly because
of the reason you cite below.

    Noel> In giving people the option to _not_
    Noel> ignore the checksum, while also allowing people to not _set_
    Noel> it, it creates situations which go against one of the key
    Noel> architectural principles of the Internet, Postel's
    Noel> Principle: 'Be liberal in what you receive'.

    Noel> Consider a case where one has an ITR which has availed
    Noel> itself of the opportunity to not set UDP checksums on
    Noel> user-data traffic (perhaps it has no choice, being run on
    Noel> router hardware which doesn't even give the forwarding
    Noel> engine access to the entire packet), trying to send packets
    Noel> to an ETR which has decided not to accept packets which
    Noel> don't have a checksum. Needless to say, the ETR won't accept
    Noel> any packets from that ITR.

Thanks for pointing this out.

You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST
accept a 0 checksum and MAY ignore the checksum completely.  And of
course we'd need to confirm that can actually be implemented.  In
particular, hardware that verifies UDP checksums on receive needs to
be checked to make sure it permits 0 checksums.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Aug 2009 10:25:32 -0400

Hi Noel,

> 'Be liberal in what you receive'.

By "MAY ignore checksums", I don't think Fred meant to indicate that  
such an ETR would throw out packets with zero checksums. The process  
of checking a zero UDP checksum is to notice that it is zero and  
stop.  What it does mean is that ITRs may send non-zero checksums, and  
ETRs may check those non-zero checksums.

BTW, the above wording is _not_ RFC compliant.  The "MAY be  
transmitted as zero" is compliant for IPv4, but not for IPv6 (RFC  
2460).  And, the "MAY ignore [non-zero] checksums on receipt" is not  
compliant with RFCs 768, 1122, 1812 and/or 2460.

Like you, though, my main concern is not compliance with those old  
RFCs.  If we determine that the right choice, technically/ 
architecturally, is to do something that doesn't comply with those  
RFCs, we just need to write another RFC that indicates when and why an  
exception is acceptable, and convince the IETF to publish it.  If our  
technical/architectural reasons is correct, that should be possible.   
Before we can do that, though, I think we need to reach agreement  
amongst ourselves as to what is the best technical/architectural choice.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Aug 2009 08:22:59 -0700

> accept a 0 checksum and MAY ignore the checksum completely.  And of

Anyone object to me putting this text in the -04 spec now?

Then, could we close this issue?

Dino

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Aug 2009 11:38:18 -0400

> Anyone object to me putting this text in the -04 spec now?

While this doesn't address all of my concerns about the UDP checksum  
handling, I consider this text to be much better than the current  
text, so go ahead and include it.

You should include a normative reference to Marshall's IPv6 zero  
checksum draft after "ITRs MAY send a zero checksum", because you will  
need a normative reference to a standards track RFC that says this is  
an okay thing to do in IPv6.  His draft can be found here:

http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt

You should also include a "[Ref Needed]" placeholder, or something  
similar, after "MAY ignore the checksum completely", because you will  
need a normative reference to a standards track RFC that indicates  
that this is an okay thing to do for both IPv4 and IPv6, as well.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 12:43:28 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote:
    >> You'd need to word it as an ITR MAY send a zero checksum, an
    >> ETR MUST accept a 0 checksum and MAY ignore the checksum
    >> completely.  And of

    Dino> Anyone object to me putting this text in the -04 spec now?

    Dino> Then, could we close this issue?

Well, you haven't yet opened the issue, which makes closing it
difficult.:-)

However this only addresses part of the issue raised.  You'll also
need to add a normative reference to Marshall's document or some other
document that updates the RFCs to make your behavior permitted.

I'd prefer that we make all the changes related to an issue like this
at once, but that's a fairly mild preference.  If you do make this
change but not add the normative reference, then leave the issue open,
but note this change in a comment.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Aug 2009 09:51:45 -0700

> but note this change in a comment.

I am so confused with this process that I'm going to ask you to  
contribute text to me and I will include it. Issue closed in my mind  
for now.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Aug 2009 13:10:33 -0400

Hi Dino,

> Then, could we close this issue?

I missed this question the first time...

I sent seven separate issues to the list that I gleaned from the UDP  
checksum discussion.  Some were mine, and some were raised by other  
people...

I would be comfortable closing two of those issues based on your  
suggested text update, but I can't tell you the issue numbers to close  
until they are in the database.  They were issues #2 and #4 in my list.

Margaret