Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

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

On Tue, Jul 16, 2019 at 2:33 PM Black, David wrote:
> In other words the receiver does one of two things:
>
> - If UDP CS != 0, expect to find that OCS !=0.  If OCS == 0, something
>   is wrong. (MUST check OCS).
>
> - If UDP CS == 0, don’t bother doing anything with OCS, even if OCS is
>   non-zero. (I think “don’t bother” winds up being: SHOULD ignore OCS).

What I intended to say might be more accurately expressed by saying
that the default receive behavior is:

- If UDP CS != 0, perform the UDP checksum validation and discard the
  entire packet if the validation fails. In addition, if a surplus area
  is present, perform the OCS validation, and discard the surplus area
  if the validation fails.

- If UDP CS == 0, do not perform either of those checks. Accept or
  discard the UDP datagram and its surplus area depending on whether
  UDP CS == 0 is or is not allowed for the socket in question.

Implementations MAY, but need not, support the following configuration
options: (a) disable checking of OCS when UDP CS != 0 and (b) enable
checking of OCS when UDP CS == 0.

That is more liberal than David's suggestion, which does not allow (a),
and turns (b) from MAY into SHOULD NOT. I could live with either.

I do have an issue with the "expect to find" language because I
explicitly do not want to levy a requirement on an implementation
to have to look around in the trailer to see if an OCS option is
present before doing the surplus area checksum validation. Looping
through the option TLVs is best done AFTER the OCS is validated.

That may be less of a concern if OCS changes from an option to a 16-bit
word at a fixed offset and we gauge the presence/absence of OCS by whether
it is zero or non-zero. However, having OCS at a fixed offset relative to
the beginning of the surplus area interacts badly with LITE as currently
specified, as LITE is required to come first. And if that fixed offset is
relative to end of the surplus area, then in IPv6 we'd be relying on the
IP Payload Length, which owing to the lack of an IPv6 header checksum has
no error checking apart from that provided by the OCS.

> The UDP CS == 0 case is subtle, even if the receiver SHOULD ignore OCS
> as indicated above.  The reason is that OCS increases the likelihood of
> packet delivery, leading to Tom advocating that OCS MUST be used in this
> case.  As noted earlier, I’m ok with a “SHOULD use OCS” requirement here
> based on increased likelihood of packet delivery, but not a “MUST” even
> with a “receiver SHOULD ignore OCS” requirement.

I was aware from slides-103-maprg-a-tale-of-two-checksums-tom-jones-00 of
dramatic improvements in packet delivery with OCS (there called CCO), from
around 50% delivery rate to over 90% (this is based in the results for paths
to HTTP servers, where the tests look for an ICMP error message and so do not
depend upon getting an answer from the application layer). Those measurements
involved packets with a correct UDP checksum and options. I was not aware
that there was evidence that use of OCS/CCO increases the rate of packet
delivery when UDP CS == 0 is combined with options. Can you point to where
I might find that evidence? I am asking because it's counter-intuitive that
OCS/CCO over the options area would make a difference in that case. It is
constructed to make packet delivery possible through middleboxes that do
either UDP Length Checksum, UDP length Pseudoheader
or Full Payload Checksum, IP length Pseudoheader.

FWIW, one of the authors of that work, Raffaele Zullo, recently did some
measurements for UDP CS=0 over IPv6 with and without options, which he
generously shared with me and gave me permission to share with TSVWG. They
are attached below. I do not know whether the options included CCO, but
apart from that, you'll find a fairly complete explanation of the methodology
near the tail of the thread. The short version is that numbers for case B1
represent the chance that a packet with CS=0 will get to the router one hop
away from the destination. The most recent results show a success rate of
between 62% and 75% without options and between 61% and 65% with options.
That's not very good.

Mike Heard


On Tue, Jul 2, 2019 at 5:25 PM Raffaele Zullo wrote:
>
> Hello Mike,
> Sorry for the very late reply.
>
> There was no problem citing those results, I hope you have been in touch
> with Gorry about this.
>
>
> I actually had only one concern since the measurements I provided were
> related to IPv6 UDP CS=0 only and not UDPO.
> AFAICR the discussion at the time was about the general traversal
> chances of UDP CS=0 with IPv6 and not restricted to UDPO.
>
> However I've run the same measurements including UDPO.
> The meaning of A, B and B1 is the same as before, the second column
> reports the cases in which A,B and B1 happen for both UDP CS=0 and UDPO
> CS=0.
>
> The results are not so different: the drop, more visible for DNS, is due
> to paths that are OK with CS=0 but not with UDP Options.
>
> DNS
>       UDP   UDPO
> A)    2%     1%
> B)   88%    72%
> B1)  75%    65%
>
> HTTP
>       UDP   UDPO
> A)   18%    18%
> B)   76%    74%
> B1)  62%    61%
>
>
> Hope this helps.
> (I haven't had yet the chance to follow the most recent discussion on
> TSVWG).
>
>
> Cheers,
> Raffaele Zullo
>
>
> PS
> Please note a 1-2% difference with the results provided in April: I have
> used the same list of addresses but 3-4% of them did not reply in the
> last measurements.
>
>
>
> On 2019-06-23 15:04, C. M. Heard wrote:
> > Raffaele,
> >
> > I am preparing to make some comments to the TSVWG list regarding the
> > use of UDP CS=0 as a means to get packets with UDP options to traverse
> > middleboxes. I would like to cite your B1 figures as showing that
> > 26%-26% of paths in your measurements block IPv6 packets with UDP
> > CS=0; in fact I'd actually like to forward the trailing message to the
> > list with me comments, if you don't mind. Would that be OK?
> >
> > Mike Heard
> >
> > On Sat, Apr 20, 2019 at 2:49 AM Raffaele Zullo
> > <[e-mail]> 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 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
> > > >
> > >
> >
>