Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
draft-ietf-6man-udpzero-12

[Ballot comment]
My complaint with this document was that it needed to justify why we need a new zero-checksum mechanism for IPv6 UDP, in particular why it is any better than UDP-Lite. Two changes were made in version -11:

Section 1.3.1 adds:

      However, use of the zero UDP checksum
      does not fully fulfill this need, because only certain classes of
      middleboxes, (i.e. ones that do not modify or evaluate the UDP
      checksum) will support zero UDP checksum traffic, other
      middleboxes will require an update to support this traffic.

That makes things worse. It says that this mechanism won't work in many middleboxes. If it won't work, why should we do it?
 
It is not until the new section 2.4, buried in the 5th paragraph, that the document finally makes a justification:

  Many existing classes
  of middleboxes do not verify or change the transport checksum.  For
  these middleboxes, IPv6 with a zero UDP checksum is expected to
  function where UDP-Lite would not.

That's the only justification in the document. I really think you should make two changes still:

1. Move the text you inserted into 1.3.1 into section 3. It is an "anti"-motivation, not a motivation for this work.
2. Add to (or rewrite) section 1.3.4 to say that there *are* many existing classes of middleboxes that will work with a zero UDP checksum that won't work with other mechanisms (e.g., other tunneling protocols and UDP-Lite). Right now, 1.3.4 says that the new mechanism won't work with existing middleboxes. Again, that tells me to *not* do this work.

Personally, I'd really like you to call out why this thing is at all useful much earlier in the document. The current text is completely ambivalent on whether this thing is a useful mechanism at all.

[Ballot discuss]
The authors have not addressed my discuss from the earlier version
of the draft (included below).

Specifically the text  "There is no current evidence that such cases
are rare in the modern Internet, nor that they may not be applicable
to IPv6.", and the reference to the 12 year old paper, illustrates
a disconnect between the transport community and the routing
community.

I believe that this text, which is a lynch pin for many arguments
that follow, overstates the case.

Packet corruption is not raised as a problem by the customers
of routers, even those customers providing services with a high SLA,
and therefore I would deduce that the level of IP packet corruption
was trivial in the modern Internet. Indeed I would suggest that the
reason that there have been no studies less than 12 years old is
because the problem was successfully addressed by the router
vendors.

A very large number of packets spend most of their life carried in
MPLS which has no c/s and misdelivery due to header corruptions
is not on anyone's radar, despite the disruptive consequences of
such misdelivery. Thus I conclude that MPLS header corruption
is rare. I cannot see why IP packet headers would be
any more likely than MPLS packet headers to be corrupted.

If the operator and router vendor community tell me that
I am wrong and packet corruption is not rare, I will withdraw
the discuss and apologize to the authors, but the implicit
assertion that there continues to be  significant packet
corruption in the Internet is contra to my experience
with Internet technologies.

===============
This discuss applies to both this draft and draft-ietf-6man-udpchecksums-04

Fundamentally I support the liberalization of the position regarding IPv6 UDP checksums  when UDP is used for tunnels and hope to get to a yes position on both drafts. However, there is some text  that needs discussion, and then we need to discuss the consequences of that discussion. The rational for the slightly conservative position taken in the case of tunnels seems to based on the following text:

"IP packets may be corrupted as they traverse an Internet path.
Evidence has been presented [Sigcomm2000] to show that this was once
an issue with IPv4 routers, and occasional corruption could result
from bad internal router processing in routers or hosts.  These
errors are not detected by the strong frame checksums employed at the
link-layer [RFC3819].  There is no current evidence that such cases
are rare in the modern Internet, nor that they may not be applicable
to IPv6. It therefore seems prudent not to relax this constraint.
The emergence of low-end IPv6 routers and the proposed use of NAT
with IPv6 further motivate the need to protect from this type of
error."

However we do have a body of evidence that is not discussed in the document. Firstly we have a decade of experience with MPLS VPNs where the VPN Identifier label, which is used to steer the traffic to a particular customer network (i.e. is functionally equivalent to an address), is not protected by a checksum. I am not aware of any concerns expressed by operators in this regard, and I am not aware of any work in the MPLS WG to introduce checksum like protection.

We also have a decade of experience with pseudowires. With one exception that we will discuss in a minute, none of the PW designs have any form of data integrity protection other than the CRC imposed by the network datalink at each hop. In the specific case of the Ethernet PW, there are two modes: one in which the CRC is stripped at ingress to the PW and recalculated at egress, and another where it is preserved end to end. There is very little, if any, deployment of the end to end CRC preservation mode. Given that there must be some low level of corruption of the frames, I would conclude that the protocols that are likely to be tunneled are sufficiently hardened that the occasional corruption is of no practical consequence.

Thus I would conclude that the level of corruption is sufficiently rare and of sufficiently minor consequence that at least in the case of service provider networks implementing UDP tunneling, it is safe to omit the UDP checksum without analysis of the application.

I would propose that the text should include some acknowledgement of this recent body of evidence and that the recommendation be aligned in consequence to unconditionally allow C/S free tunneling, at least within a well managed domain without additional consideration.

[Ballot discuss]
1.3.4: Something is seriously missing from this section. You say:

  Use of a zero UDP
  checksum with IPv6 requires firewalls to be updated before the full
  utility of the change is available.
 
  It can be expected that datagrams with zero UDP checksum will
  initially not have the same middlebox traversal characteristics as
  regular UDP (RFC 2460).  However when implementations follow the
  requirements specified in this document, we expect the traversal
  capabilities to improve over time.  We also note that deployment of
  IPv6-capable middleboxes is still in its initial phases.  Thus, it
  might be that the number of non-updated boxes quickly become a very
  small percentage of the deployed middleboxes.

This seems to say that middleboxes will need to be upgraded to accommodate zero UDP checksums in IPv6, no matter what mechanism is used. But that implies, as far as middleboxes are concerned, that UDP-Lite is a perfectly acceptable solution, because middleboxes will need to be updated anyway, which is directly contradictory to section 2.2.

This section needs to justify that UDP with a zero checksum will be deployable without upgrade to middleboxes. Otherwise, the correct answer is "Use UDP-Lite" and be done with it.

I've got no objection to this document going forward *if* it justifies the need. But the current text is not fully justifying the need.

[Ballot comment]
1.3.2: I don't understand the meaning of the following sentence:

  The argument concerning redundant processing costs is valid regarding
  the integrity of a tunneled packet.

Also, nowhere in this section does it actually say that calculating checksums is expensive. It says in the last sentence that off-loading isn't possible in some implementations, but you'd think it would say somewhere that the actual cost of calculation is high.

1.3.3: I think this section needs to be clearer that it is tunnel ingress endpoints, not routers in general, for whom this makes a difference. A regular router can simply ignore the checksum and pass the packet along. It is ingress into a tunnel where a new checksum has to be calculated for the new encapsulating UDP packet and therefore where you have to see the whole packet, and then only certain architectures.

3.1.1 and 3.1.2 are not impacted positively or negatively by UDP checksum being present or not. Why do these need to be mentioned? (I really don't understand why most of section 3 exists, since problems of IP header corruption are not addressed by UDP checksum, and this section doesn't separate out those issues that are risks attributable to solely UDP checksum absence.)

IANA has reviewed draft-ietf-6man-udpzero-08, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA
Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: SECOND Last Call:  (Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Applicability Statement for the use of IPv6 UDP Datagrams with Zero
  Checksums'
  as Proposed Standard

This Last Call is the second IETF Last Call for this document.  The first
Last Call was to publish this document as an Informational document.
The draft has been restructured as an applicability statement and is intended
to be published as a 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
ietf@ietf.org mailing lists by 2012-12-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides an applicability statement for the use of UDP
  transport checksums with IPv6.  It defines recommendations and
  requirements for the use of IPv6 UDP datagrams with a zero UDP
  checksum.  It describes the issues and design principles that need to
  be considered when UDP is used with IPv6 to support tunnel
  encapsulations and examines the role of the IPv6 UDP transport
  checksum.  An appendix presents a summary of the trade-offs that were
  considered in evaluating the safety of the update to RFC 2460 that
  updates use of the UDP checksum with IPv6.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ballot/


No IPR declarations have been submitted directly on this I-D.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums) to Informational RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Applicability Statement for the use of IPv6 UDP Datagrams with Zero
  Checksums'
  as Informational RFC

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
ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides an applicability statement for the use of UDP
  transport checksums with IPv6.  It defines recommendations and
  requirements for the use of IPv6 UDP datagrams with a zero UDP
  checksum.  It describes the issues and design principles that need to
  be considered when UDP is used with IPv6 to support tunnel
  encapsulations and examines the role of the IPv6 UDP transport
  checksum.  An appendix presents a summary of the trade-offs that were
  considered in evaluating the safety of the update to RFC 2460 that
  updates use of the UDP checksum with IPv6.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
Version -07, along with the corresponding changes to the udpchecksums-05 document, satisfy my concerns, and I'm happy to clear the DISCUSS and switch to YES.

[Ballot discuss]
See my DISCUSS for draft-ietf-6man-udpchecksums:
http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/

Update for -07:
This is exactly what I had in mind.  Assuming that the WG is happy with this, when the corresponding changes are made to the udpchecksums doc my concerns will be well addressed.

[Ballot comment]
Would you be willing to add a short section in an Appendix that illustrates the kind of analysis that you are requiring of a protocol that wants to rely on UDPZero? I am thinking of something like the following:

Sample Text
===========
Protocol Foo encapsulates an IP datagram within the following:

- a foo header
- a UDP header
- an outer IPv6 header

Because the UDP checksum is set to zero, the following fields are unprotected:

- foo header: field1
- foo header: field2
- UDP header: source port
- UDP header: destination port
- outer IPv6 header: source address
- outer IPv6 header: destination  address

The consequence of corruption in field1 of the foo header is mumble. The consequence of corruption in field2 of the foo header is grumble, but only if some other condition is true. The consequence of corruption in any other field is, at worst, loss of the packet.

Assume a tunnel with the following characteristics:

- sustained data rate of 1 Gbps
- Bit error rate of 10**-12 on each of 4 constituent links
- average packet size equal to 1500 bytes

The bullet list, below, provides an estimate of the frequency with which each of the above mentioned fields will be corrupted:

- foo header: field1 (once per N seconds)
- foo header: field2 (once per N seconds)
- UDP header: source port (once per N seconds)
- UDP header: destination port (once per N seconds)
- outer IPv6 header: source address (once per N seconds)
- outer IPv6 header: destination  address (once per N seconds)

==========================
End sample text

Does this sound reasonable?

[Ballot comment]
Updated Comment with an additional point.

A couple of thoughts about this document which I am not raising as a
Discuss, but I hope the authors will have a look at.

---

Section 5.1

  2.  Implementations must provide a way to signal the set of ports
      that will be enabled to receive UDP datagrams with a zero
      checksum.  An IPv6 node that enables reception of UDP packets
      with a zero-checksum, must enable this only for a specific port
      or port-range.  This may be implemented via a socket API call, or
      similar mechanism.

I believe "signal" is a confusing word here. Signalling means (to me)
that the implementation builds a message and sends it to the remote end.
So, "implementations" cannot provide this mechanism - it is the protocol
specification that must do it. And a sockets API call provides a way for
an implementation to request the zero-checksum feature locally, but it
does not provide a way to "signal the set of ports that will ..."

Probably, the consistancy of this requirement would be most easily
obtained by s/signal/register/

However, that change would leave open the question of how two end points
coordinate (i.e. signal) on which ports they will use zero checksum.
That is a requirement on the specification of transported protocols,
which is exactly what this section is about.

---

Section 9 seems to make a valid point, so I am surprised that no
conclusions are drawn from what it says.

It also seems to me that it is important to drop and log corrupted
packets as early as possible. This offers three benefits:
1. Corruptions in the tunnelling encapsulation are detected so that
  mis-delivery of the tunnelled packets is less likely
2. Causes of corruption can be more effectively isolated (for example,
  was it the encapsulation mechanism, the transmission, or the
  storage of the tunnelled packet that introduced the corruption). In
  particular, where the corruption is the result of an attack, this may
  be valuable information.
3. The later the corruption is detected and the packet dropped, the more
  processing has been "wasted" handling the packet. Thus, late
  detection offers a way to waste transmission/receiver resources.

I found some of these points hinted at in the body of the document and
in the Summary. Maybe Section 9 is just positioned a little late in the
document meaning that the authors didn't feel there was muych to say by
the time the reader got there? Might be nice to beef up the Section a
little and arrange for it to come before the Summary.

---

Section 5.1 should probably also talk about the management requirements. Can ports be manually configured for zero checksum? Should implementations provide management access to say on which ports zero checksum is operated?

[Ballot comment]
A couple of thughts about this document which I am not raising as a
Discuss, but I hope the authors will have a look at.

---

Section 5.1

  2.  Implementations must provide a way to signal the set of ports
      that will be enabled to receive UDP datagrams with a zero
      checksum.  An IPv6 node that enables reception of UDP packets
      with a zero-checksum, must enable this only for a specific port
      or port-range.  This may be implemented via a socket API call, or
      similar mechanism.

I believe "signal" is a confusing word here. Signalling means (to me)
that the implementation builds a message and sends it to the remote end.
So, "implementations" cannot provide this mechanism - it is the protocol
specification that must do it. And a sockets API call provides a way for
an implementation to request the zero-checksum feature locally, but it
does not provide a way to "signal the set of ports that will ..."

Probably, the consistancy of this requirement would be most easily
obtained by s/signal/register/

However, that change would leave open the question of how two end points
coordinate (i.e. signal) on which ports they will use zero checksum.
That is a requirement on the specification of transported protocols,
which is exactly what this section is about.

---

Section 9 seems to make a valid point, so I am surprised that no
conclusions are drawn from what it says.

It also seems to me that it is important to drop and log corrupted
packets as early as possible. This offers three benefits:
1. Corruptions in the tunnelling encapsulation are detected so that
  mis-delivery of the tunnelled packets is less likely
2. Causes of corruption can be more effectively isolated (for example,
  was it the encapsulation mechanism, the transmission, or the
  storage of the tunnelled packet that introduced the corruption). In
  particular, where the corruption is the result of an attack, this may
  be valuable information.
3. The later the corruption is detected and the packet dropped, the more
  processing has been "wasted" handling the packet. Thus, late
  detection offers a way to waste transmission/receiver resources.

I found some of these points hinted at in the body of the document and
in the Summary. Maybe Section 9 is just positioned a little late in the
document meaning that the authors didn't feel there was muych to say by
the time the reader got there? Might be nice to beef up the Section a
little and arrange for it to come before the Summary.

[Ballot comment]
No objection to the publication of this document, but I really would
like to have the following points clarified.

-  2.  Implementations MUST provide a way to signal the set of ports
          that will be enabled to receive UDP datagrams with a zero
          checksum.

What is an implementation? The application running over the tunnel? You
refer to "An encapsulating protocol" in the sentence before the bullet
points, is this what you mean?
If yes, signal from where to whom?
Or maybe by "implementation" you mean "IPv6 protocol stack implementation"

- Section 3.1.2  Corruption of the source IP address

Please mention Unicast Reverse Path Forwarding, which might discard packets.

[Ballot discuss]
This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points in Section 5.1.

Bullet 5
======
"Tunnels that encapsulate IP may rely on the inner packet
  integrity checks provided that the tunnel will not significantly
  increase the rate of corruption of the inner IP packet."

- What does it mean to *significantly* increase the rate of corruption of the inner IP packet?
- Shouldn't we also be concerned about corruption of the UDP header and any additional encapsulation that comes between the UDP header and the inner IP packet?
- How does a tunnel ingress node know whether the tunnel will significantly increase the rate of corruption of the inner IP packet?

Bullet 7
=====-
  " UDP applications that support use of a zero-checksum, should not
      rely upon correct reception of the IP and UDP protocol
      information (including the length of the packet) when decoding
      and processing the packet payload.  In particular, the
      application must be designed so that corruption of this
      information does not result in accumulated state or incorrect
      processing of a tunneled payload."

- How could any application achieve this goal? Possibly by analyzing the consequences if any field in the IPv6 or UDP header were corrupted? (draft-ietf-6man-udpchecksums begins this analysis.)  Again, wouldn't the analysis have to include any additional encapsulation that comes between the UDP header and the inner IP header?

- Wouldn't the analysis, mentioned above, have to include assurances regarding the case when the destination port is corrupted? Specifically, would it have to include a guarantee that if the encapsulated inner packet were delivered to any randomly chosen port, it would not cause any harm to the application listening on that port?

[Ballot comment]
In section 4.1, is there a reference to the "proposal to simply ignore
the UDP checksum value on reception at the tunnel egress" that can be
cited to give more background?

In section 4.2.1, "The methods that ignores the checksum has an
additional downside" needs to be plural or singular throughout.

The first paragraph of section 5 tells me it identifies requirements
for protocols carried without UDP checksum.  Section 5.1 talks only
about "zero checksum"; does the proposal to ignore the checksum at the
tunnel egress also fit here?  Also, stylistically, I think the section
header for 5.1 can simply be dropped.

In section 5.1, I can't parse out what list item 5 is trying to
convey.  What is the "tunnel layer" and is it always recommended and
required for some tunnel mechanisms?

[Ballot discuss]
This discuss applies to both this draft and draft-ietf-6man-udpchecksums-04

Fundamentally I support the liberalization of the position regarding IPv6 UDP checksums  when UDP is used for tunnels and hope to get to a yes position on both drafts. However, there is some text  that needs discussion, and then we need to discuss the consequences of that discussion. The rational for the slightly conservative position taken in the case of tunnels seems to based on the following text:

"IP packets may be corrupted as they traverse an Internet path.
Evidence has been presented [Sigcomm2000] to show that this was once
an issue with IPv4 routers, and occasional corruption could result
from bad internal router processing in routers or hosts.  These
errors are not detected by the strong frame checksums employed at the
link-layer [RFC3819].  There is no current evidence that such cases
are rare in the modern Internet, nor that they may not be applicable
to IPv6. It therefore seems prudent not to relax this constraint.
The emergence of low-end IPv6 routers and the proposed use of NAT
with IPv6 further motivate the need to protect from this type of
error."

However we do have a body of evidence that is not discussed in the document. Firstly we have a decade of experience with MPLS VPNs where the VPN Identifier label, which is used to steer the traffic to a particular customer network (i.e. is functionally equivalent to an address), is not protected by a checksum. I am not aware of any concerns expressed by operators in this regard, and I am not aware of any work in the MPLS WG to introduce checksum like protection.

We also have a decade of experience with pseudowires. With one exception that we will discuss in a minute, none of the PW designs have any form of data integrity protection other than the CRC imposed by the network datalink at each hop. In the specific case of the Ethernet PW, there are two modes: one in which the CRC is stripped at ingress to the PW and recalculated at egress, and another where it is preserved end to end. There is very little, if any, deployment of the end to end CRC preservation mode. Given that there must be some low level of corruption of the frames, I would conclude that the protocols that are likely to be tunneled are sufficiently hardened that the occasional corruption is of no practical consequence.

Thus I would conclude that the level of corruption is sufficiently rare and of sufficiently minor consequence that at least in the case of service provider networks implementing UDP tunneling, it is safe to omit the UDP checksum without analysis of the application.

I would propose that the text should include some acknowledgement of this recent body of evidence and that the recommendation be aligned in consequence to unconditionally allow C/S free tunneling, at least within a well managed domain without additional consideration.

Section 5.1 seems to be duplicated in the two drafts. It would be better if the text were just in one RFC and the other pointed to it.

[Ballot comment]
You also note that an application may rely on the checksum to protect it against packets that may damage it. I find this very weak argument, since such an application would be vulnerable to packets deliberately malformed by an attacker, or malformed by a software bug in a peer. The correct approach is surely to harden the application, and thus the checksum argument is not persuasive.

You note the need to signal the agreement not to use c/s, I think that you need to include the configuration of this property as an alternative, and note that configuration may be implicit in the definition of the UDP payload.

IANA has reviewed draft-ietf-6man-udpzero-06, which is currently in
Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6 UDP Checksum Considerations) to Informational RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'IPv6 UDP Checksum Considerations'
  as Informational RFC

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
ietf@ietf.org mailing lists by 2012-10-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document examines the role of the UDP transport checksum when
  used with IPv6, as defined in RFC2460. It presents a summary of the
  trade-offs for evaluating the safety of updating RFC 2460 to permit
  an IPv6 UDP endpoint to use a zero value in the checksum field as an
  indication that no checksum is present.  This method is compared with
  some other possibilities.  The document also describes the issues and
  design principles that need to be considered when UDP is used with
  IPv6 to support tunnel encapsulations.  It concludes that UDP with a
  zero checksum in IPv6 can safely be used for this purpose, provided
  that this usage is governed by a set of constraints.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ballot/


No IPR declarations have been submitted directly on this I-D.