Subject: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS)

From: "Ronald Bonica" <[email-masked]>
Date: Tue, 09 Oct 2012 11:57:26 -0700

Ronald Bonica has entered the following ballot position for
draft-ietf-6man-udpzero-06: 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:
----------------------------------------------------------------------

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?

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Oct 2012 10:59:29 +0200

> for more information about IESG DISCUSS and COMMENT positions.

That is a good question. And the answer is it depends. If you are
considering a tunnel protocols which target deployment area is one where
you have very low rates of corruption, lets say below 10^-6 then a
factor of 2 or even 10 might be fine as the resulting end-to-end basic
IP service may still be fine. But if that same tunnel is supposed to
support something that requires a packet loss rate below 10^-6 then any
increase in corruption might be to high.

> any additional encapsulation that comes between the UDP header and the

I think the formulation actually is considering that. If the
IPv6/UDP/FOO tunnel protocol carries IP and FOO is senesitive to
corruption then isn't the payload of the tunnel, i.e. the inner IP going
to suffer an increased corruption rate.

> significantly increase the rate of corruption of the inner IP packet?

That is something you have to statistically analyze when designing the
protocol and deciding on using zero-checksum.

> the UDP header and the inner IP header?

Yes, this is a design analysis which includes the tunnel protocols headers.

> harm to the application listening on that port?

Clearly it can't include a guarantee that it will not harm what ever is
at the randomly chosen port. But one part we try to get across in this
document is that this is the reason we want to ensure that default
remains to have the UDP checksum enabled to avoid having applications
not having considered this in their design or at least been analyzed to
be safe enough to get zero checksummed packets.

The next step is the question of potential harm is a statistics game.
And the more traffic that are transported over the network with
zero-checksum the higher the probability that you will get a packet not
intended for your context. Thus you will have to deal with it. Here I
think most tunnel egresses are reasonably simple to analyze what
happens. You attempt to decapsulate it according to whats in the packet.
If that is not a mismatch you try to do the next step for the inner
packet, switching or forwarding that based on whats there. That either
matches or not the context and are thus sent further or discarded. If
there is a checksum on that level it can help discarding packets that
completely misses the context.

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: Wed, 10 Oct 2012 13:51:37 +0100

> increase in corruption might be to high.
A useful and relevant question, which is worth asking the user to consider
is what exactly are those loss rates. A lot of systems do much better than
10^-6. At 10Gb/s that is 10^4 errors/sec, so you can see they have to
do better that that. I am not sure what state of the art is, but the
range 10^-12  is often quoted as a working number.

Maybe we need to text of the form where the underlying IPv6 network is
considered to have an acceptably low error rate, that may indicate that
it is safe to operate without a UDP checksum, without further analysis
consideration of the protocols to be carried over the UDP tunnel.

> protocol and deciding on using zero-checksum.
My concern is that is impractical, the tunnel payload is opaque.
Remember the UDP tunnel will in many cases be the functional
equivalent of GRE, and we neither have the ability to include
a c/s for IPv6/GRE, nor the ability to predict the payload type.

BTW, you need to realize that it's going to be very difficult
to do the do the c/s checking in a fast tunnel router and will
often need h/w changes. Unlike a common transport protocol
stack implementation a fast tunneling router does not
have access to all the packet data to run the c/s check.
For that reason alone, I predict that most of these routers
will neither impose or verify the UDP c/s in the tunnel case.
> completely misses the context.
Let me take another cut on this. We accept that IPv6/GRE is safe, since
we did not update GRE for IPv6, and we have not deprecated it.
Why are we not simply saying :

"It will commonly be the case that the use of a UDP tunnel is
functionally equivalent to GRE, and consequently when the
UDP c/s is not used, there  may be some level of undetected
data corruption in the tunnel which is propagated to the recipient
of the tunnel payload. Thus, where the UDP c/s is not used
in a tunnel application, the same consideration of data integrity
apply to both UDP tunnels as apply to GRE tunnels, and must
be taken into consideration by the tunnel provider."

That is probably the necessary and sufficient text for the the
reader to understand the context and the design considerations.

- Stewart

---

From: [email-masked]
Date: Wed, 10 Oct 2012 15:38:50 +0100

See comments in-line.

Gorry

>>> Please refer to
>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
I don't think that is what we need to debate or comment upon. We were
never intending to review the PILC WG recommendations on link design. I
suggest that link error rate will dictate the need for link CRC.

The draft is about a transport checksum and the focus of the draft is on
two cases: end-to-end paths and tunnel paths between network endpoints,
but done over transport layer connections. In these cases we worry about
not just cables - middlebox manipulations (RTP mixers, load balancers,
NAPT, firewalls, etc)  and end stack implications are arguably more
important.

> a c/s for IPv6/GRE, nor the ability to predict the payload type.
If one uses GRE, there are indeed no issues providing you stick with the
requirement that encapsulated data itself uses a UDP checksum - I don't
see GRE as an end-to-end transport.

> will neither impose or verify the UDP c/s in the tunnel case.
Isn't this discussed already?

For an end host, it can even be that a zero checksum will be replaced by
an actual checksum in common hardware interfaces!

> reader to understand the context and the design considerations.
No, I think we've lost context here about how end hosts handle UDP packets
and what the implications are - that precisely why there are two drafts on
this topic and it has taken quite some debate at the IETF to get to the
stage of this particular update request. I'm sure you'd agree that end
hosts can be tunnel end points and that linux-based routers are common,
hence we need to treat packets with GRE header different to those with
UDP.

>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 10 Oct 2012 23:05:02 -0400

Magnus,

I think that we are on the same page and I am nearly ready to clear my DISCUSS. 

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?

                        Ron

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, October 10, 2012 4:59 AM
> To: Ronald Bonica
> Cc: The IESG; [email-masked]; draft-ietf-6man-
> [email-masked]; [email-masked]
> Subject: Re: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06:
> (with DISCUSS)
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet
> points
> > in Section 5.1.
> >
> > Bullet 5
> > ======
> > - What does it mean to *significantly* increase the rate of
> corruption
> > of the inner IP packet?
> 
> considering a tunnel protocols which target deployment area is one
> where you have very low rates of corruption, lets say below 10^-6 then
> a factor of 2 or even 10 might be fine as the resulting end-to-end
> basic IP service may still be fine. But if that same tunnel is supposed
> to support something that requires a packet loss rate below 10^-6 then
> any increase in corruption might be to high.
> 
> > - 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?
> 
> corruption then isn't the payload of the tunnel, i.e. the inner IP
> going to suffer an increased corruption rate.
> 
> > - 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?
> 
> > 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?
> 
> And the more traffic that are transported over the network with zero-
> checksum the higher the probability that you will get a packet not

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Oct 2012 10:24:23 +0100

Hi,

Only having thought about this shortly, I think this is reasonable to
add. I might have another opinion when we actually start writing it. But
in that case I will come back and tell why I have another opinion.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 12 Oct 2012 09:51:44 -0400

Magnus,

Thanks! I will downgrade my DISCUSS to a comment and trust you to make that change.

                                                 Ron

> Sent: Friday, October 12, 2012 5:24 AM
> To: Ronald Bonica
> add. I might have another opinion when we actually start writing it.
> But in that case I will come back and tell why I have another opinion.
> 
> Cheers
> 
> Magnus
> 
> > 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
> > ===========
> > 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.
> >
> > The bullet list, below, provides an estimate of the frequency with
> which each of the above mentioned fields will be corrupted:
> >
> >>> 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
> >>> -
> >> -
> >>> -
> >> -
> >> where you have very low rates of corruption, lets say below 10^-6
> >> then a factor of 2 or even 10 might be fine as the resulting
> >> end-to-end basic IP service may still be fine. But if that same
> >> tunnel is supposed to support something that requires a packet loss
> >> rate below 10^-6 then any increase in corruption might be to high.
> >>
> >> That is something you have to statistically analyze when designing
> >> the protocol and deciding on using zero-checksum.
> >>
> >>>
> >>> Bullet 7
> >>> =====-
> >>> (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?
> >>
> >>> encapsulated inner packet were delivered to any randomly chosen
> >>> port, it would not cause any harm to the application listening on
> >>> that
> >> port?
> >>
> >> Clearly it can't include a guarantee that it will not harm what ever
> >> is at the randomly chosen port. But one part we try to get across in
> >> this document is that this is the reason we want to ensure that
> >> default remains to have the UDP checksum enabled to avoid having
> >> applications not having considered this in their design or at least
> >> been analyzed to be safe enough to get zero checksummed packets.
> >>
> zero-
> >> packet, switching or forwarding that based on whats there. That
> >> either matches or not the context and are thus sent further or
> >> discarded. If there is a checksum on that level it can help
> >> discarding packets that completely misses the context.
> >>
> >>
> >> Cheers
> >>
> >> Magnus Westerlund
> >>
> -
> >> - Multimedia Technologies, Ericsson Research EAB/TVM
> -
> >> -