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

[Tom Herbert <[e-mail]>]

On Tue, Jul 16, 2019 at 5:43 PM C. M. Heard <[e-mail]> wrote:
>
> 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.
>
Mike,

UDP options should not need to change the specified behavior of UDP
checksum. In IPv4, if the checksum is zero, the packet is accepted. In
IPv6, if the checksum is zero then the packet is dropped with the
narrow exception that that a tunneling protocol is used and the port
is explictly configured to allow zero checksums. That's what the specs
say and that's what's currently implemented.

Also, if you say "is or is not allowed for the socket in question"
that implies that we have to perform a socket lookup in the fast path
just to decide whether to basic packet verification. That's not cheap
and some devices performing the checksum verification might not even
have a way to configure this. It's much better just be deterministic
without needing state or configuration and verify the packet solely
based on its contents and what the protocol specification says to do.

Tom

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