Subject: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jan 2013 15:05:37 -0800

Hi, all,

I read both this and 6man-udpchecksums, and have comments below.

Joe

-----

First, I'm a bit bothered that this issue is spread across two 
documents. IMO, these two ought to be merged into a single statement. 
It's confusing that neither doc includes a complete description of the 
issue and solution.

This doc (6man-udpzero) is confusing - it lists 4 separate reasons for 
the need for zero checksums (sec 1.3.1), yet the first three restate the 
first one (reduced forwarding costs), and the last one (load balancing) 
isn't sufficiently motivated to the need to avoid checksums. This 
section should be revised to differentiate the separate issues and 
justify those that remain as being tied to avoiding the checksum.

I do not see sufficient reason to implement this solution vs. UDP-lite. 
In both cases there is a need to revise the endpoints that process UDP 
packets, and in both cases an unmodified endpoint would drop the packets 
unless updated. That argues against the need for a unique solution for 
UDP vs. using UDP-lite. I.e., any packet that parses UDP headers would 
drop v6 zero-checksum UDPs unless modified, and any modification could 
support UDP-lite instead.

Further, UDP-lite allows protection of portions of the UDP header that 
might benefit from this, even when the underlying packet has its own 
checksums.

---

6man-udpchecksums further remains incomplete. The doc gives specific 
text to update RFC 2460, but that text refers obscurely to 
"zero-checksum mode" without defining it anywhere (including inside the 
replacement text). IMO, there ought to be a very direct discussion of 
what that mode means and how it is achieved both on the send and receive 
side.

I also wonder whether an interface that enables zero checksum mode 
should handle non-zero checksums. If these are intended for a tunnel, 
then IMO that use ought to be sufficiently constrained as to suggest 
that nonzero checksums might be a clear indication of an error 
(including a DOS attack on computation resources at a receiver).

----

On 12/14/2012 7:47 AM, Jose Saldana wrote:
> Hi all. I have read draft-ietf-6man-udpchecksums-06.txt. I support it.
>
>
> Only these comments (I hope they are useful):
>
> - Although the difference between "tunneling packet" and "tunneled packet"
> is clear, I think something similar could be done when talking about
> "tunneling protocols". The document sometimes talks about "tunnel protocols"
> and other times about "tunneling protocols". Perhaps the term could be
> unified.
>
>
> Sentences which could be improved:
>
> - " These different examples each help to significantly reduce the
> likelihood that a corrupted inner tunneled packet is finally delivered to a
> protocol listener that can be affected by the packet." Sounds very
> complicated, IMHO.
>
> - "similar effects that reduce the likelihood that an mis-delivered packet
> are delivered." Could say " similar effects that reduce the likelihood that
> a mis-delivered packet is delivered."
>
> - " A corruption will commonly only effect the single packet, not
> established protocol state." Could say "A corruption will commonly affect a
> single packet, not the established protocol state."
>
> - " Tunnel protocols encapsulating IP this will generally be safe," could
> say "In tunnel protocols encapsulating IP, this will generally be safe,"
>
>
> A small typo:
>
> - "Corruption of the address information in an encapsulating packets," could
> say " Corruption of the address information in an encapsulating packet"
>
>
> Best regards,
>
> Jose Saldana
>
>> -----Mensaje original-----
>> De: [email-masked] [mailto:[email-masked]] En nombre de
>> Magnus Westerlund
>> Enviado el: jueves, 13 de diciembre de 2012 10:20
>> Para: [email-masked]
>> CC: [email-masked]
>> Asunto: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-
>> udpzero
>>
>> Hi,
>>
>> I do hope we will get some reviews from TSVWG. But I would like to point
>> out that the target is Standards Track.
>>
>> I also would recommend that you take a look at the document implementing
>> the change in the IPv6 Specification also after having reviewed
>> draft-ietf-6man-udpzero-08:
>>
>>
>> The IESG has received a request from the IPv6 Maintenance WG (6man) to
>> consider the following document:
>> - 'IPv6 and UDP Checksums for Tunneled Packets'
>>    <draft-ietf-6man-udpchecksums-06.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
> final
>> comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2012-12-25. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the beginning
> of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>     This document provides an update of the Internet Protocol version 6
>>     (IPv6) specification (RFC2460) to improve the performance in the use
>>     case when a tunnel protocol uses UDP with IPv6 to tunnel packets.
>>     The performance improvement is obtained by relaxing the IPv6 UDP
>>     checksum requirement for suitable tunneling protocol where header
>>     information is protected on the "inner" packet being carried.  This
>>     relaxation removes the overhead associated with the computation of
>>     UDP checksums on IPv6 packets used to carry tunnel protocols.  The
>>     specification describes how the IPv6 UDP checksum requirement can be
>>     relaxed for the situation where the encapsulated packet itself
>>     contains a checksum.  The limitations and risks of this approach are
>>     described, and restrictions specified on the use of the method.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>> On 2012-12-12 09:09, [email-masked] wrote:
>>> This message starts a two week TSVWG Working Group on advancing:
>>>
>>>           Title           : Applicability Statement for the use of IPv6
> UDP
>>> Datagrams with Zero Checksums
>>>           Author(s)    : Godred Fairhurst
>>>                                Magnus Westerlund
>>>           Filename     : draft-ietf-6man-udpzero-08.txt
>>>           Pages          : 37
>>>           Date            : 2012-12-11
>>>
>>>           https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/
>>>
>>> This document is intended to be published as BCP via the 6MAN WG.
>>>
>>> This last call is being done given the number of changes and the time
>>> since the earlier last calls.  The changes were discussed at the
>>> Atlanta IETF 6man & TSVWG sessions.  The authors believe these changes
>>> will resolve the open IESG Discusses.  Our AD will start a concurrent
>>> IETF last call as well.
>>>
>>> Substantive comments and statements of support for advancing this
>>> document should be directed to the tsvwg or 6man mailing list.
>>> Editorial suggestions can be sent to the authors.  This last call will
>>> end on 26 December 2012.
>>>
>>> James, David & Gorry
>>> TSVWG Co-Chairs.
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> 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: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Jan 2013 12:00:08 +0100

Hi Jose,

Many thanks for your review. An updated version has just been submitted.
This should address your feedback.

Thanks

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Jan 2013 13:27:42 +0100

Hi Joe,

Thanks for your review. See response to your comments below.

> It's confusing that neither doc includes a complete description of the

There is historic reasons why this ended up like it did. It is far from
optimal. But enough is enough. The documents I think are coherent in
regards to each other. I will claim good enough.

> justify those that remain as being tied to avoiding the checksum.

Is the differences really unclear after you have read 1.3.2-1.3.5 which
goes into detail of what these bullets means?

> support UDP-lite instead.

Joe, you where yourself present in some of the 6man meeting where this
was discussed. I would also preferred that UDP-lite was deployed for
this use cases. However, UDP zero checksum actually has less places
which requires modification to get this working, for example the load
balancers are not needed to be updated to support zero-checksum UDP, but
need to do that for UDP-Lite.

> might benefit from this, even when the underlying packet has its own

Agreed, it from this perspective a better solution.

> what that mode means and how it is achieved both on the send and receive

This has been addressed with the new 07 version:

      An IPv6 node associates a mode with each active UDP port.

      Whenever originating a UDP packet for a port in the default mode,
      an IPv6 node MUST compute a UDP checksum over the packet and the
      pseudo-header, and, if that computation yields a result of zero,
      it MUST be changed to hex FFFF for placement in the UDP header.
      IPv6 receivers MUST by default discard UDP packets containing a
      zero checksum, and SHOULD log the error.

      As an alternative, certain protocols that use UDP as a tunnel
      encapsulation, MAY enable the zero-checksum mode for a specific
      port (or set of ports).  Any node implementing the zero-checksum
      mode MUST follow the node requirements specified in Section 4 of
      "Applicability Statement for the use of IPv6 UDP Datagrams with
      Zero Checksums" [I-D.ietf-6man-udpzero].

      Any protocol that enables the zero-checksum mode for a specific
      port or ports MUST follow the usage requirements specified in
      Section 5 of "Applicability Statement for the use of IPv6 UDP
      Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero].

      Middleboxes supporting IPv6 MUST follow requirements 9, 10 and 11
      of the usage requirements specified in Section 5 of "Applicability
      Statement for the use of IPv6 UDP Datagrams with Zero Checksums"
      [I-D.ietf-6man-udpzero].

Is this clearer what i meant with the zero-checksum mode?

> (including a DOS attack on computation resources at a receiver).

My view is that they absolutely need to handle both if zero-checksum is
enabled. The primary reasons in to be able to checksum control traffic
for the tunnel.

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Jan 2013 10:51:30 -0800

Hi, Magnus (et al.),

> goes into detail of what these bullets means?

Yes; I considered that context.

> need to do that for UDP-Lite.

That might be pointed out more directly. Is that the only reason? (maybe 
NAT traversal?)

>        An IPv6 node associates a mode with each active UDP port.

I'm not sure what an "active UDP port" is; it might be useful to clarify 
this. Apps can send to ports they aren't listening on, e.g.

>        it MUST be changed to hex FFFF for placement in the UDP header.

It might be useful to add "as per existing requirements." (to underscore 
that this isn't a change). This clearly explains how checksums are 
computed in the default.

>        port (or set of ports).

Destination port? Source port? or port pairs?

>        Any node implementing the zero-checksum

It omits the corresponding re-statement of zero-checksum mode - notably 
the direct statement that a value of zero is inserted in the checksum 
field. (I realize that seems obvious, but it could also have meant that 
the checksum is omitted and the data starts earlier).

> enabled. The primary reasons in to be able to checksum control traffic

But wouldn't that traffic have some other defining property - different 
port, different encapsulation, etc.?

Joe