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

[Gorry Fairhurst <[e-mail]>]

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:
> 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
>
>
> On 4/14/11 8:01 AM, "Magnus Westerlund"<[e-mail]>
> wrote:
>
>> (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  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>
> Regards,
> Phil Chimento
>
> JHU/APL
> 240-228-1743
> 443-778-1743
> [e-mail]