Subject: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT)

From: "Stewart Bryant" <[email-masked]>
Date: Sun, 07 Oct 2012 20:37:07 -0700

Stewart Bryant has entered the following ballot position for
draft-ietf-6man-udpchecksums-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to
get to yes on this draft also, since I support the liberalization of this
protocol design when used for tunnelling. Specifically point 6 in this
draft is relevant to this discussion.
Additionally a tunnel may not have any way of knowing if the payload is
protected (as you suggest), since normally a tunnel has no knowledge of
the payload characteristics. 

In point 7 you suggest that an application cannot rely on packet length.
When PWs are used for tunneling we rely on exactly that (except in the
case of packets shorter than 64 octets for Ethenet padding reasons), and
I am not aware of any reported issues. Thus when the application is
tunnel encap/decap there is a body of evidence that suggests that this
OK.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There is some text in the earlier part of document that looks like it
should be written in RFC2119 format. In this case it is not important
because the normative change is later and this used RFC2119 directives,
however the authors should consider making the document self consistent
in this regard.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 8 Oct 2012 14:29:56 +0200

Hi Stewart,

See inline for comments

> for more information about IESG DISCUSS and COMMENT positions.

Acknowledged

> the payload characteristics. 

No, but a tunnel know what general class of traffic it encapsulates. Is
it IPv4 that has at least IPv4 header checksums and possibly non-zero
transport checksums, or are they some type of other L2 frames that has
checksums as part of their frame headers. It is this type of knowledge
in the tunnel payload we want the tunnel designer to consider if they
need additional checksums or not.

> tunnel encap/decap there is a body of evidence that suggests that this

First of all, I would like to understand a bit more about these
experiences from pseudowires. Which type of psuedowires are we talking
about here. And the derived experiences over which type of lower layer
are being used. Is this IPv6/UDP or something else like MPLS?

Secondly, it is likely that psuedowires is designed such that an error
in the length field do not result in any corruption of any state or
irregularities in processing that cause any substantial issues beyond
possibly loosing that packet from its intended context.

>From my perspective, trying to say that there is no risk with removing
the UDP checksum even for a limited context is like trying to prove a
negative. I am certain that some environments have very low corruption
rates, but there might be other environments for IPv6 where it is much
higher.

I wished someone would repeat Stone and Patridge's investigation to get
better understanding of the behaviors of IPv4 and IPv6 in this regards
at different points in today's Internet.

I guess you are referring to some text in the discussion. There are
similarities in the discussion with the specification text as it is
motivation why things are like they are. But I think the section
differences and in addition the actual normative text is formulated in a
different way that makes it unsuitable to apply RFC 2119 text on that
earlier sections.

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: Stewart Bryant <[email-masked]>
Date: Mon, 08 Oct 2012 18:22:41 +0100

Hi Magnus,

> need additional checksums or not.
Sure you know if you are carrying IP or L2, but L2 mostly carries
IP anyway. However you do not actually know what the user
is going to carry over L2, and really have no right to know. You
have to treat it as opaque traffic.

In any case, as I said we take no precautions in PWs and we do
not observe any issues carrying 'L1' or L2 over PW over MPLS
without a c/s at either the network or the tunnel layer.

> are being used. Is this IPv6/UDP or something else like MPLS?
I am talking about PW/MPLS. Although PW/L2TP/IP exist in theory
there is very little deployment. The most common PWs seem to be
Ethernet (carrying whatever the Ethernet is carrying, IP but other
protocols as well), ATM and TDM. There is also some Frame Relay
(again with c/s removed and reconstructed), in all cases
carried directly over MPLS.

> possibly loosing that packet from its intended context.
Yes, PWs are stateless, but the application receiving the packet
has unknown properties and if we make a mistake on the length
the application will get a corrupt packet with a valid datalink c/s.
However I have never heard this type of error discussed.

> at different points in today's Internet.

My point is that we have a practical experiment ongoing with the
huge number of PWs in deployment running over MPLS without
c/s protection at the tunnel or network layer and I have never seen
anyone raise an issue in either the PWE3 or MPLS WG. Hence
my conclusion that whilst there is a theoretical risk, the evidence
is that there are no reported issues.

Note that I am only discussing the tunnel case, I make no comment
on any other type of application.

> different way that makes it unsuitable to apply RFC 2119 text on that
OK, I leave this to your judgement.

- Stewart

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Oct 2012 20:13:29 +0200

> is that there are no reported issues.

One reason the occasional misdirected packet is not causing problems here might be that there are higher level headers that prevent delivery to an application (be it for a checksum mismatch or more likely because the higher level addresses just don't point in the direction of trouble).  Which would mesh fine with the argument made in the draft that UDP zero checksum is fine for tunnels but not so much for other applications like end-to-end.

I definitely agree with the subtext that the udpzero issue is often seen a bit more dogmatic than needs be, but I also think that having this degree of robustness in a widely deployed protocol is a desirable property that shouldn't be given up lightly.

Grüße, Carsten

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 9 Oct 2012 13:20:46 +0200

Hi Stewart,

Comments inline.

> without a c/s at either the network or the tunnel layer.

Are you really certain that PW doesn't have taken precautions. I took a
look at RFC 4448 Ethernet over MPLS. That specification contains the
following text:

4.4.4.  Frame Error Processing

   An encapsulated Ethernet frame traversing a pseudowire may be
   dropped, corrupted, or delivered out-of-order.  As described in
   [PWE3-REQ], frame loss, corruption, and out-of-order delivery are
   considered to be a "generalized bit error" of the pseudowire.  PW
   frames that are corrupted will be detected at the PSN layer and
   dropped.

   At the ingress of the PW, the native Ethernet frame error processing
   mechanisms MUST be enabled.  Therefore, if a PE device receives an
   Ethernet frame containing hardware-level Cyclic Redundancy Check
   (CRC) errors, framing errors, or a runt condition, the frame MUST be
   discarded on input.  Note that defining this processing is part of
   the NSP function and is outside the scope of this document.

Which I interprets that for an Ethernet PW over MPLS there will be
verification of the Ethernets CRC, thus any assembly or payload errors
are likely to be detected. This leaves primarily errors in the label
addressing on the MPLS layer. What I lack in knowledge is to analyze how
likely this is to occur and secondly what the effects are. How likely is
it that a miss-labeled ethernet frame actually arrive in a context where
it is either harmful to the receiver or actually ends up in some higher
layer context not intended. I would guess due to the ethernet addressing
an ethernet frame delivered to the wrong physical network will just be
discarded due to lack of recipient in the domain it arrived in.

I guess other L2 may look different but my understanding is that any PW
must fulfill the basic requirements and assumptions on L1 that the
carried L2 has. I think few L2 protocols are assuming an error free
channel. And those who does requires PW encapsulation to meet these goals.

> carried directly over MPLS.

The first if it is RFC4448 encapsulated then there is Ethernet layer
CRCs that take care of most of the issues as discussed above.
The second appear more interesting due to the lack of C/S at that layer.
Question is what assumptions the thing on top of frame relay have done.
If most of that traffic has checksums then a higher layer verification
happens.

> is that there are no reported issues.

Well, without more knowledge about what is actually being run I am not
certain that you actually are getting data that doesn't have a higher
layer protection against errors.

> on any other type of application.

To try to come to some conclusions from my perspective. What you raise
as an issue that the formulation may be to strict in regards to using
unchecksumed information. I think the examples you have brought up
appears to use higher layer checksum to verify the usage of an
checksummed field. Nor does it result in accumulation of state.  Thus
the impact of using such a field are limited to a potential for
increased residual errors. It is not like the error rate will be
significantly higher due to these assumption errors. I would assume that
a packet corruption will in most cases be non reversible, thus the need
for a checksum would simply be to avoid propagating the error.

But, if you do solutions that uses unverified fields in larger construct
the effect amount of data might be larger and thus create significant
larger error impact and thus warrant additional checks at lower layer.
This have to be analyzed on a protocol to protocol basis.

That is the goal of the list. Please be aware of the following and
consider if you are impacted by them.

Cheers

Magnus Westerlund

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 09 Oct 2012 13:43:52 +0100

> I definitely agree with the subtext that the udpzero issue is often seen a bit more dogmatic than needs be, but I also think that having this degree of robustness in a widely deployed protocol is a…

Carsten

I think you are correct the few packets that have errors and actually 
get delivered probably then either get caught by the packet parser, or 
hit an idempotent system that corrects the state based
on a later packet or local state.

Let's look at this from another perspective for a moment. The tunnel use 
of UDP is really "GRE that goes through firewalls and gets ECMPed". GRE 
has no c/s and as far as I know has no c/s added for IPv6 and thus is 
subject to the same issues that we are talking about here.

What is going to happen in practice is that the tunnel implementers are 
all going to say (for reasons in the text) that c/s is too hard, we will 
not do c/s and the application had better look after itself. You can see 
this is what is happening in LISP, which is one of the protocols that 
triggered
this document pair. Thus my goal here is to align the text with actually 
is happening and is likely to continue to happen, since I think that 
benefits the community in the long term.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 09 Oct 2012 14:40:17 +0100

>     frames that are corrupted will be detected at the PSN layer and
This is saying that Ethernet frames may be delivered out of order
and that if we get a CRC  failure in the PSN we will simple drop
the packet.
> verification of the Ethernets CRC,
At ingress only. The CRC is then discarded. There was no CRC
retention mode when RFC4448 was written.

> thus any assembly or payload errors
> are likely to be detected.
No, there is no assembly. RFC4448 describes Ethernet PW over MPLS
and MPLS has no fragmentation.
> This leaves primarily errors in the label
> addressing on the MPLS layer.
They exist, but if the payload gets corrupted in a PE or an LSR
packet buffer, it stays corrupted and gets played out with a good
CRC.
> What I lack in knowledge is to analyze how
Yes, there is some protection due to the Ethernet addressing, but
not all PWs have this. Frame Relay for example reconstructs the
DLCI at egress.
> channel. And those who does requires PW encapsulation to meet these goals.
The PWE3 WG has some pretty blunt advice to it's user community. We
explain the simplifications, and if the quality of emulation is not
good enough, then the user is advised to either design a better
emulation, or to use a real service. However so far the cost efficiencies
of the extremely simple emulations, combined with the low error
rate and relatively hard applications have meant that the simple
emulations are overwhelmingly used.

My prediction is that this will be the case for the UDP as a tunnel
class of applications.
> CRCs that take care of most of the issues as discussed above.
No, there is no Ethernet CRC in an RFC4448 encapsulated packet.
Please see RFC4720, which states it more clearly. Noting that
RFC4720 is hardly implemented.
> If most of that traffic has checksums then a higher layer verification
The applications just see the datalink as a datalink, and don't
realize they are being sent over a PW, or understand what the
PW is doing to the datalink CRC.
> layer protection against errors.
Sure, that is what is keeping the system afloat against the error,
but that is also true of L2 and L3 protocols tunneled over UDP.
> checksummed field.
No, the deployed PW/MPLS cases run without a datalink CRC.

>   Nor does it result in accumulation of state.  Thus

Understand that at the end of the day, I am not going to stand in the
way of the draft, what I am trying to do here is to help it reflect the
reality of existing tunnel experience and to be closer to the path that
the UDP tunnel designer's appear to be taking anyway.

- Stewart