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

["Black, David" <[e-mail]>]

Mike, 

Top-posting on a few items (still as an individual, not a WG chair).

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

Good - I agree with the two main bullets.   On the two additional items, (a) and (b) for non-LITE cases:

- For (a), I'm convinced that a "MAY disable" requirement is a mistake (too weak) because it provides the network with "enough rope" to hang the less-than-expert endpoint implementer.  I could live with "SHOULD NOT disable" but prefer "MUST NOT disable" for simplicity (as with the exception of mixing of LITE and non-LITE data in the same packet, I've not seen a good reason for not checking OCS when the UDP CS is non-zero).

- For (b), I can see the utility of checking OCS in the non-LITE case where there's another integrity check in the protocol stack that doesn't cover UDP options.  This text is likely to be subtle because RFC 6936 recommends (SHOULD) but does not require (SHALL/MUST) such an integrity check, so both the cases of presence and absence of that integrity check will merit attention.  I remain somewhat unclear about what's going on in the LITE case, in particular about how the service level for LITE data ought to be reflected in the service level for the UDP options.

As I noted previously, I think LITE ought to be split out from the main design and worked through separately, more below ...

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

I agree - the OCS MUST be present and always be in the same place.  The only exception that I can think of is that LITE might replace OCS, if the OCS position is always at the start of the UDP options, more below ...

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

+1 - just do that...

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

... IMHO, this is one more reason to split out LITE as a separate discussion topic as I suggested in a prior message.

A brute-force straw proposal would be that to define two variants of OCS - plain OCS that MUST NOT be used with LITE, and also define a special OCSLITE that is used only with LITE, and then only if we decide that a UDP options integrity check makes sense with LITE in some situations.  The merit of this design proposal is that if the OCS comes at the start of the UDP options area (which seems to be its preferred location), then this design proposal inflicts the resulting special-case processing of UDP options integrity checks for LITE on LITE implementations, which seems to be where that burden belongs ;-).

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

There isn't any, my mistake.  I confused the LITE case that uses a nonzero UDP CS with the zero UDP CS case - mea culpa.

Thanks, --David

> -----Original Message-----
> From: C. M. Heard <[e-mail]>
> Sent: Tuesday, July 16, 2019 8:43 PM
> To: Black, David
> Cc: Joe Touch; tsvwg
> Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
> 
> 
> [EXTERNAL EMAIL]
> 
> 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
> > > > >
> > > >
> > >
> >