Subject: Comments on draft-ietf-6man-udpchecksums-00

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Apr 2011 14:01:25 +0200

(resend due to bad author alias address)
Hi,

I have made a review of the draft and have some comments on it.

1. Needs to indicate that it updates RFC2460 (when approved). This
usually goes into the header of the front page. The abstract and as part
of the introduction.

2. The abstract is way to meager. It needs to make clear, what it does,
that there are limitations and that it updates RFC 2460.

3. Style of writing. This is a document that updates and will be the
specification of a change of the IPv6 specification. Currently it still
reads like a change proposal. From my perspective it needs to be more
authoritative. This is something we have decided to do. Thus the
document should be written like:
1. Introduction: We are changing the UDP zero checksum rule in IPv6.
2. Short motivation why.
3. Change to specification. Old text that is replaced. New text.

Some places where this is evident:
- Section 1, last paragraph on page 3: Not long term relevant and using
terms that make less sense in an RFC.
- Section 1.4 "Recommend Solution": Wrong title. Should be its own main
section. First paragraph.

4. Section 1.4:
      In cases, where the encapsulating
      protocol uses a zero checksum for UDP, the receiver of packets in
      the allowed port range MUST NOT discard packets with a UDP
      checksum of zero.

"in the allowed port range" seems wrong, isn't "to a port that has been
enabled to receive zero checksum" so that the full sentence reads:

In cases, where the encapsulating protocol uses a zero checksum for UDP,
the receiver of packets to a port that has been enabled to receive zero
checksum MUST NOT discard packets with a UDP checksum of zero.

5. Section 1.4 bullet 1:
      1.  IPv6 protocol stack implementations SHOULD NOT by default
          allow the new method.  The default node receiver behaviour
          MUST discard all IPv6 packets carrying UDP packets with a zero
          checksum.

I think "new method" is unclear in this sentence. Yes, I know it is from
my draft. However, in the context of actually doing the change it needs
to be more crisp and clear.

6. Section 1.4, bullet 3:
      3.  RFC 2460 specifies that IPv6 nodes should log UDP datagrams
          with a zero-checksum.  This should remain the case for any
          datagram received on a port that does not explicitly enable
          zero-checksum processing.  A port for which zero-checksum has
          been enabled MUST NOT log the datagram.

Should we clarify that it MUST NOT log for the reason of it having a
zero checksum. It may still be logged but for other reasons. The
simplest change appears to say:

A port for which zero-checksum has been enabled MUST NOT log the
datagram for that reason.

7. Section 1.4, bullet 5:
      5.  UDP Tunnels that encapsulate IP MUST rely on the inner packet
          integrity checks provided that the tunnel will not
          significantly increase the rate of corruption of the inner IP
          packet.  If a significantly increased corruption rate can
          occur, then the tunnel MUST provide an additional integrity
          verification mechanism.  An integrity mechanism is always
          recommended at the tunnel layer to ensure that corruption
          rates of the inner most packet are not increased.

I think the first "MUST" is actually not correct. I think "MAY" is
actually more correct. If you transport IP as inner packet, then you MAY
rely on that being corruption verified by itself, the outer header
doesn't need to take that responsibility providing that the corruption
rate will not be increase. However disallowing additional checks was not
the intention here.

8. Section 1.5 should have its own main section.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Chimento, Philip F." <[email-masked]>
Date: Thu, 14 Apr 2011 08:09:17 -0400

Hi Magnus: 
Very good comments, thank you. We'll make the changes and address these.

Marshall: Do you have the latest XML? If you send it to me, I can try to get
these comments addressed by early next week (Mon or Tue).
Thanks. 
Regards, Phil 

> 8. Section 1.5 should have its own main section.

Regards, 
Phil Chimento

JHU/APL
240-228-1743
443-778-1743
[email-masked]
--

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 14 Apr 2011 14:57:24 +0100

I agree with the comments from Magnus. I can promise to also check the 
next revision for consistency with the udpzero draft, but that would be 
easier with the  reorganisation, that Magnus has suggested.

I also add the following:

There are some pointers to use-cases in the introduction that are not 
referenced, whereas I would have expected quite tightly-defined 
use-cases in line with the udpzero draft.
   "More recently, a discussion on the DCCP mailing list covered
    the UDP over IPv6 checksum issues.
- I recall this in the context of DCCP-over-UDP, but the conclusion was 
that UDP MUST provide a checksum. I think if you want to discuss DCCP, 
you should also state the conclusion and rationale why (i.e. because of 
the need to protect the header fields).
The draft later also says:
"o  A key cause of this issue generally is the lack of protocol
     support in middleboxes.  Specifically, new protocols, such as
     DCCP, are being forced to use UDP tunnels just to traverse an end-
     to-end path successfully and avoid having their packets dropped by
     middleboxes.  If this were not the case, the use of UDP-lite might
     become more viable for some (but not necessarily all) lightweight
     tunneling protocols."
- However, the DCCP working group specifically chose not to use a tunnel 
approach, and instead used a double encapsulation, in which the 
processing at the receiver uses both the UDP and DCCP header fields, 
specifically the UDP checksum was mandated. Maybe this is not the best 
example?

I'm not sure whether UDP-Lite will be supported over IPv6 middleboxes, 
because I don't personally know about significant deployment of either.

   "Other users of UDP as a tunneling
    protocol, for example, L2TP..."
- Do you envisage this as a host tunnel?

In section 1.3 the draft describes:
   "UDP keep-alive packets with checksum zero can be sent to validate
    paths, given that paths between tunnel endpoints can change and so
    middleboxes in the path may vary during the life of the
    association."
- I agree. Are these being defined for this specification? What 
functions are required? And if so, are the keep-alive datagrams of any 
specific format, periodicity, and how do they validate the path, i.e., 
are the datagrams acknowledged?

The draft also says:
"We suggest
  that decoupling IPv6 header protection from transport generally
  should be studied in this workgroup.  One approach might be to
  consider an extension header for IPv6 containing (at least) a
  header checksum.  However, that is beyond the scope of this draft."
- I'm not for or against this, but there are considerations and we need 
to be clear if this is an IETF recommendation, or a good idea for some 
future work: There have been other initiatives in the IETF that have 
looked at the pros and cons of separating the endpoint and routing 
functions.

I'd be most happy to do a detailed review of a new version.

Gorry

On 14/04/2011 13:09, Chimento, Philip F. wrote:
> On 4/14/11 8:01 AM, "Magnus Westerlund"<[email-masked]>
> wrote:
>