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

["C. M. Heard" <[e-mail]>]

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
> > >
> >
>