Subject: [tsvwg] UDP Options: on forcing the use of UDP CS=0 in connection with FRAG+LITE

From: "C. M. Heard" <[email-masked]>
Date: Fri, 28 Jun 2019 09:22:40 -0700

Greetings,

Apologies for the late follow-up on this matter.

I notice the following on the "Pending Changes" slide for the UDP Options
draft (draft-ietf-tsvwg-udp-options-07) from IETF 104:

• Update LITE+FRAG discussion
 – Force CS=0 even if user doesn’t ask
 – User choice of CS=0/not should follow in use of reassembly CS

I strenuously object to the first part of this proposed change.

The proposal is intended to address the problem of LITE not being covered
by OCS. This lack of coverage is by design: it would defeat the purpose of
LITE if it were covered by OCS. Unfortunately, the LITE data not being
covered by OCS means that the checksum compensation needed to achieve a
high probability of middlebox traversal is not present. The proposal to
force CS=0 for LITE+FRAG was made ins an attempt to work around the
middlebox traversal issue.

For IPv6, at least, it seems that UDP CS=0 does not have very good middlebox
traversal properties. Raffaele Zullo has shared with me the results of some
(admittedly small-scale) measurements he did to look specifically at this,
and the results were not especially encouraging: depending on the test case,
between 26% and 36% of the paths blocked UDP CS=0 over IPv6 from reaching
the final router before the  destination (see results for test cases B1
below). By contrast, a UDP packet with a properly compensated checksum was
seen in previous measurements to have around a 94% chance of getting to the
destination under comparable circumstances (see results for IPv6 HTTP in
https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00
).

There are other issues with forcing UCP CS=0, specifically that doing
so would leave the UDP header fields (and in particular the UDP length)
unprotected. The poor middlebox traversal properties, when combined with
these other disadvantages, IMO make the case against forcing CS=0 decisive.

In order to remedy this problem, it is necessary (a) to divorce FRAG from
LITE and (b) to protect the FRAG data by OCS, at least when the user has
enabled the UDP checksum for unfragmented datagrams. Fortunately, there is
a way to do this that is no more complex than the proposal in the existing
method specified in defined in draft-ietf-tsvwg-udp-options-07. I will
provide a detailed proposal in a follow-on e-mail.

Thanks and regards,

Mike Heard

On Sat, Apr 20, 2019 at 2:49 AM Raffaele Zullo wrote:
>
> Hello Mike,
> Hello Gorry,
>
> You made quite curious about the traversal of IPv6 UDP CS=0, so I run
> the traceroute measurements from my own host only for this case.
> These are the results:
> A)  paths working end-to-end (as explained in a previous email)
> B)  paths in which last discovered router is the same for UDP with
> correct CS and UDP with CS=0
> B1) paths in which last discovered router is the same for UDP with
> correct CS and UDP with CS=0 and it's 1 TTL from the destination server
>
> DNS
> A)   2%
> B)  87%
> B1) 74%
>
> HTTP
> A)  16%
> B)  77%
> B1) 64%
>
> Obviously this is not enough to say that these paths are compatible with
> v6 CS=0 but it still suggests that its traversal chances are higher than
> the bare end-to-end percentage.
>
> Happy Easter,
> Raffaele Zullo
>
>
>
> On 2019-04-07 16:11, C. M. Heard wrote:
> > Hello Raffaele,
> >
> > Thank you for taking the time to dig out this information.
> >
> > I see that the response rates for UDP CS=0 over IPv6 are quite low,
> > with
> > or without UDP options.  However, as you point out, the measurements
> > cannot distinguish cases where middleboxes in the path discard CS=0
> > packets from cases where the server itself does so.  In order to draw
> > firm conclusions about the the proportion of paths that drop IPv6 UDP
> > CS=0,
> > it seems that one would need some independent means to estimate
> > the proportion of servers that discard IPv6 UDP CS=0.
> >
> > Do you think it would be useful to share this data with the TSVWG list?
> >
> > Good luck on the job hunt.
> >
> > Mike Heard
> >
> > On Sun, Apr 7, 2019 at 6:25 AM Raffaele Zullo wrote:
> > >
> > > Hello Gorry,
> > > Hello Mike,
> > >
> > > Sorry for the late reply.
> > > I've got lost in a few other things (basically job hunting is a job).
> > >
> > > Anyway I finally got my VPN access to the lab network restored so I
> > > could retrieve measurements data.
> > >
> > >
> > > We tested a limited number of (paths to) IPv6 servers, obtained from
> > > Alexa top-1m:
> > > 17110 authoritative DNS servers
> > > and
> > > 12184 HTTP servers.
> > >
> > > DNS servers were tested with well-crafted DNS queries.
> > > The first packet was a regular UDP packet with correct CS.
> > > If the server replied to the query then it was tested with CS=0,
> > > Options, etc.
> > >
> > > Paths to HTTP servers were instead tested with padded packets sent to
> > > UDP port 80.
> > > The first packet was again a regular UDP packet with correct CS.
> > > If the server replied with ICMP Port Unreachable, then it was tested
> > > with CS=0, Options, etc.
> > >
> > > Out of 17110 DNS servers
> > > 1.75% replied to UDP CS=0
> > > 1.43% replied to UDP+Opt CS=0
> > >
> > > Out of 12184 HTTP servers
> > > 17.21% replied to UDP CS=0
> > > 16.67% replied to UDP+Opt CS=0
> > >
> > >
> > > These are the raw data.
> > >
> > >
> > > I would add that the portion of paths OK with IPv6 UDP CS=0 can be
> > > underestimated.
> > > Since we are measuring paths to servers, the server itself can affect
> > > the measurement,
> > > for instance if the path is clean but the server's stack discards IPv6
> > > with UDP CS=0, the outcome of the measurement will be negative.
> > >
> > >
> > > Cheers,
> > > Raffaele
> > >
> >
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Jun 2019 14:30:45 -0700

On Fri, Jun 28, 2019 at 9:23 AM C. M. Heard <[email-masked]> wrote:

> Greetings,
>
> Apologies for the late follow-up on this matter..
>
> <https://datatracker..ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00>
> ).
>
> Also, this is would be violation of RFC8200: "IPv6 receivers must discard
UDP packets containing a zero checksum and should log the error". So it's
not just middleboxes, end hosts will also have problems with UDPv6 zero
checksums.

Tom

> these other disadvantages, IMO make the case against forcing CS=0
> decisive..
>
> Also, this is a direct violation of RFC8200:

> > > the proportion of servers that discard IPv6 UDP CS=0..
> > >

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 28 Jun 2019 23:30:42 -0700

> On Fri, Jun 28, 2019 at 9:23 AM C. M. Heard <[email-masked]> wrote:
...

> .For IPv6, at least, it seems that UDP CS=0 does not have very good
>> middlebox
>> Also, this is would be violation of RFC8200: "IPv6 receivers must
> discard UDP packets containing a zero checksum and should log the error".
> So it's not just middleboxes, end hosts will also have problems with UDPv6
> zero checksums.
>

Yes, of course -- the low DNS response rate in Raffaele's data below bear
that out -- but if the intent is to use it for the FRAG option, then hosts
would need modifications anyway.

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 Jun 2019 06:55:45 -0700

See sec 8.1, which incorporates rfc 6936:

As an exception to the default behavior, protocols that use UDP as a tunnel encapsulation may enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. Any node implementing zero-checksum mode must follow the requirements specified in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].

Frag is a kind of such a tunnel because it adds its own reassembly CS.

But that also means middleboxes should allow relaying these since 6936 was passed.

Joe

> On Jun 28, 2019, at 11:30 PM, C. M. Heard <[email-masked]> wrote:
> 
>>> .For IPv6, at least, it seems that UDP CS=0 does not have very good middlebox
>>> https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00).
>>> 
>> Also, this is would be violation of RFC8200: "IPv6 receivers must discard UDP packets containing a zero checksum and should log the error". So it's not just middleboxes, end hosts will also have problems with UDPv6 zero checksums.
> 
> Yes, of course -- the low DNS response rate in Raffaele's data below bear that out -- but if the intent is to use it for the FRAG option, then hosts would need modifications anyway.
>