Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt

From: Joe Touch <[email-masked]>
Date: Mon, 27 Feb 2017 15:30:59 -0800

Hi, all,

A new version of the UDP options proposal has been posted.

It adds:

    - fragmentation based on IPv6's mechanism (thanks to Mark Smith)

    - MSS (thanks to Mark Smith) and TS based on TCP's mechanism

    - auth/encryption based on TCP-AO and its extensions

It clarifies the report of a non-compliant legacy device (thanks to Mike
Heard).

It also adds a discussion on control block caching, ala RFC2140 for TCP.

Feedback welcome.

Joe

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-touch-tsvwg-udp-options-05.txt
Date: 	Mon, 27 Feb 2017 15:24:32 -0800
From: 	[email-masked]
To: 	Joseph Touch <[email-masked]>, Joe Touch <[email-masked]>

A new version of I-D, draft-touch-tsvwg-udp-options-05.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	05
Title:		Transport Options for UDP
Document date:	2017-02-27
Group:		Individual Submission
Pages:		20
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-05.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-05

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP by indicating the
   location, syntax, and semantics for UDP transport layer options.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 28 Feb 2017 16:37:51 +0000

> A new version of the UDP options proposal has been posted.

I quite like the described scheme,  a few comments below:

Section 5 question on must implement:

Personally I'd say the most interesting / useful are (in order):
  MSS, FRAG, TIME, LITE, ACS, AE
So that would inform my choice of which to make mandatory

Section 5.4 (Alternate checksum):

By inference one can deduce that 'UDP payload only'
must refer to the data region which figure 3 names as the
'UDP user data', and hence also excludes any Lite data.
Maybe this (UDP user data) should be explicitly stated?

Also which CRC16?  I've seen a few.  Maybe state its polynomial?

Section 7 (UDP options vs. UDP-Lite):

4th para seems to refer to a prior scheme for a LITE
option.  With the described swap mechanism,  there is
no need for an EOL option (for Lite purposes),  and
the Lite data ends up directly following the normal
data vs this text stating they are disjoint.

So this could be reduced to just the portion comparing
the default delivery (or not) of the Lite data.

Section 5.3 (Option Checksum)

It looks like the described scheme was needed for
compatibility with a prior version of the Lite
mechanism.

You could simplify the option checksum handling by
simply defining the first 2 bytes of the surplus
area as a 16 bit checksum over the whole of the
surplus area while in its Figure 10 form, i.e. not
including the Lite data.

This would be compatible with the LITE swap scheme
you describe in section 5.5, just with one having
to swap 6 bytes rather than 4 bytes.  It would also
take no more space than the existing checksum - assuming
such was always included.

I can see that this would make the job of a middle
box which chose to modify an option (say MSS clamping) easier,
but I'd suggest the main gain is simply following
a more familiar scheme of the same 16 bit ones complement
as elsewhere (even if not negated as one usually does).

Section 5.1 (End of Options List)

Given the above change to the options checksum, and the
stale text in section 7, it would seem that there is no
need for the EOL option,  and NOP could become 0; however
that probably doesn't matter either way.

Section 5.8 (Fragmentation)

A trivial point,  but should this be referred to a segmentation instead?

I forsee the confused conversations in future when one is
refering to UDP fragments, or Fragmented UDP and having
to clarify if one means an IP fragment or this transport
level fragmentation scheme.

Figure 15 shows a 64 bit Identification field, yet the text
refers to a 32 bit field.  Which is correct?

If fragmentation is present with Lite, and two such packets
are received to be reassembled, what happens to the Lite data
from each packet?  Should this combination be rejected, or
defined in some fashion?

I've not really looked at Seciton 5.9, as I'd need to refresh
myself on the TCP option behaviour.

DF

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 11:29:09 -0800

Hi, Derek,

Thank you for the feedback.

Below are my responses...

Note - one of the caveats is that I'd really like to see this become a
WG doc. at some point. I'd prefer to have running code and got very
close this past fall (the issue was student cycles, not protocol
design), FWIW.

Joe

> So that would inform my choice of which to make mandatory

The set I picked are the minimum required to make the option work. OCS
is included because it is default-on, as per previous discussions.

I'm glad to have the WG determine what others would be required. IMO, it
wouldn't be hard to make MSS, FRAG, TIME, LITE, and ACS required. AE is
completely specified (believe it or not - all that was required was to
declare the ISN values to substitute for UDP for traffic key
generation), but it's also clearly very heavyweight compared to the rest
of the options.

> Maybe this (UDP user data) should be explicitly stated?

Good point - I'll clarify. It will be the same data covered by the
current UDP checksum (UDP header, UDP payload as indicated by the UDP
header, and IP pseudoheader).

> Also which CRC16?  I've seen a few.  Maybe state its polynomial?
Good point - I don't have a preference, but I'll pick one in common use.

> option.  
Yes -

> With the described swap mechanism,  there is

Agreed - I'll clean that up. The EOL option still needs to be included
(IMO) for similar reasons to the TCP option - to help shortcut option
processing when trailer padding is used (e.g., for word-aligned payloads).

> the default delivery (or not) of the Lite data.
Agreed. Will do...

> compatibility with a prior version of the Lite
This came out of WG discussions, notably because the option area is not
covered by the UDP checksum. It predates the inclusion of the Lite
mechanism and has no relation.

> surplus area while in its Figure 10 form, i.e. not
I agree with the second point (simplified processing), but not the first
(requiring OCS), unless we agree that OCS is always required (it is not
right now; it is default active, but could be turned off to save space -
though I'm not sure why that amount of space would matter).

> such was always included.
It takes two additional bytes - we can't redefine the existing checksum
and be compatible with legacy receivers.

> as elsewhere (even if not negated as one usually does).
I don't want to design a transport protocol capability based on what a
middlebox might do. That's "laws for the lawless", IMO, and there's
little point. So I'd rather not address this.

> that probably doesn't matter either way.
I'm in favor of keeping EOL because the code to handle it is easy and it
might enable other capabilities in the future (i.e., available space
after the header). It might be useful to mention that.

> A trivial point,  but should this be referred to a segmentation instead?

I'm fine with whatever the WG prefers.

> refers to a 32 bit field.  Which is correct?
32. I think larger isn't needed. I'll fix that...

> from each packet?  Should this combination be rejected, or
Good point. I'll think about this and create an ordering list.

> myself on the TCP option behaviour.
OK - glad to have that feedback too.

-----

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Feb 2017 11:40:07 -0800

>     - auth/encryption based on TCP-AO and its extensions

Hi Joe,

You might also want to look at the HMAC for IPv6 SR option for
authentication. This method might be more appropriate for connectionless
transport. We defined an extension based on it for GUE authentication and
are working to generalize the Linux implementation to allow different
protocols to use the same authentication mechanism.

Tom

> To: Joseph Touch <[email-masked]> <[email-masked]>, Joe Touch
> <[email-masked]> <[email-masked]>
>

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 28 Feb 2017 20:46:07 +0000

On Tue, Feb 28, 2017 at 11:29:09a.m. -0800, Joe Touch wrote:
> WG doc. at some point.

Seems like a good idea.

> > So that would inform my choice of which to make mandatory

Well that was just the order from which I'd chose the mandatory set,
I wasn't necessarily suggesting that all be mandatory.

For me the suggested mandatory additions would probably be MSS and FRAG,
then possibly TIME due to the timing points with reassembly which
you mention.

> right now; it is default active, 

I view requiring it to always be present is a sensible choice
as that allows for some level of validation that the surplus
area actually is options.  As I believe you mention later
in the draft.

> but could be turned off to save space -

Quite.  I'd say the cost/benefit weighs in favour of using
the space to always have the options summed.

> and be compatible with legacy receivers.

Sorry,  I've lost the thread here.

I was not suggesting altering how the normal UDP checksum works.

I was mainly driving at how in implementing this in a host stack I'd
like to verify the options.  Namely that in the absense of the Lite
option,  it would allow one to use the existing checksum validation
routine to run across the whole of the surplus area, and if it summed
to the usual (1's complement) zero,  it is good.

In the presence of Lite option it only becomes slightly more complex,
in that one performs the check as two partial sums.

This could be combined with whatever logic is extracting/detecting
the presence of the options.  That would obviously requiring using
the usual 1s complement of the 1s complement sum.  It would have
to occur before normal UDP processing, and be driven off the UDP
length and the IP header payload length being different

[I'm assuming the presence of a routine like:
   uint16_t ip_partial_checksum(uint16_t old_sum, void *start, uint16_t length)
 which sums the supplied range in to the old_sum, returning the new value.
 Initialisation and final 1s-complement being done outside that routine.
]

Or are you referring to existing implementations of your current
option code?

> little point. So I'd rather not address this.

The reference to middle boxes was an unimportant side comment,
please forget I mentioned it.

The significant point was allowing the same style of checksum
as already exists, and hence using the same (or similar)
set of routines.  Especially since if we assume the checksum
is always present, it costs no more in terms of payload that
the 8 bit scheme.

> after the header). It might be useful to mention that.

I'm fine either way.

> Good point. I'll think about this and create an ordering list.

Tom's suggestion here was interesting.  It would seem to be
re-defining the FRAG+LITE case where the UDP User Data is zero length,
such that the LITE is now segmented,  and non-Lite.  I'm not sure
about that yet,  it feels a bit weird.

However, the overall checksum he mentioned could itself be in an
option,  and would only need to be in one of the fragments.

DF

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Feb 2017 13:07:38 -0800

> is always present, it costs no more in terms of payload that
Agreed, probably want to stick with the normal 16-bit Internet
checksum it will probably be more efficient since we've optimized
implementation of that anyway.

> option,  and would only need to be in one of the fragments.
Pretty much all NICs now days can set/verify UDP checksums on TX/RX so
we basically get it for free. This is why I doubt we'll ever see
UDP-lite in real deployment-- it is far less efficient than using the
UDP checksum. In a similar vein, applying a checksum over a packet
that is then fragmented is not easily supported in HW, for TX it
requires TSO logic for RX we might be able to deduce the reassembled
checksum from the checksummed individual fragments but it's a lot of
work. I think the LITE functionality is probably here for
completeness. CRC might be more interesting though.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 13:16:07 -0800

Hi Derek,

On 2/28/2017 12:46 PM, Derek Fawcus wrote:
> ...
> ...
I'm not sure I see that.
The existing checksum runs over the IP pseudoheader, the UDP header, and
the UDP body.

OCS runs over just the option area.

Even in the absence of LITE, the UDP checksum wouldn't cover the option
area.

> Or are you referring to existing implementations of your current

The spec. There are two checksum options:
    OCS - over just the option area
    ACS - a stronger replacement for the UDP checksum over the same area
as the UDP checksum carries (though it might need to just be the body,
since a NAT is going to mess up the IP pseudoheader and UDP ports)
> is always present, it costs no more in terms of payload that
The offload routines could be adapted to handle this, sure.

> option,  and would only need to be in one of the fragments.
Right - that would be reassembly verification checksum.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 13:17:16 -0800

Hi, Tom,

OK - so I think you and Derek are basically arguing for an Internet
checksum to verify reassembly, rather than using a new or stronger one.

That's fine with me.

Joe

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 28 Feb 2017 21:36:20 +0000

> Even in the absence of LITE, the UDP checksum wouldn't cover the option

We're at cross purposes here...

I'm not suggesting altering the UDP checksum,  I'm referring to replacing
(discarding) the OCS option.

So in section 4, figure 3 where you describe the surplus area, which is
essentially an array of bytes used for options.  I'm proposing instead to
give it a structure:

    +------+-------+
    |   checksum   |
    +------+-------+
    ... options ...
    +------+-------+

Where options is zero or more options as you describe (omitting OCS).

Where checksum is the usual checksum algorith over the whole of the
surplus area.  i.e. such that when the receiver sums the whole of the
area checksum through to the end of options, it should sum to 1s-complement
zero.  (taking in to consideration the length of options being odd).

Then for your LITE header scheme,  still require that the LITE header
be the first option,  and rather than swap 4 bytes (the LITE header)
as you describe,  instead swap 6 bytes (the checksum followed by the
LITE header).  Hence why I was the referring to partial sums.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 28 Feb 2017 21:46:48 +0000

> checksum to verify reassembly, rather than using a new or stronger one.

Actually,  I made a mistake.  I attributed to Tom what was I believe
was actually suggested by C. M. Heard - namely the suggestion to
combine FRAG+LITE as a way of allowing existing hosts to discard fragments.

In that he was suggesting adding an overall reassembled checksum,
which would be necessary as otherwise the repurposed reassembled
Lite payloads would not have a checksum.  I was simply pointing
out that in that scenario,  the same could be achieved with a
single CHECKSUM option, carried in only one of the FRAG packets.

So there would be no need to change the FRAG header definiton to
add a checksum there.

In the normal case of reassembling FRAG'ed payloads,  I don't see
that an overall checksum gains us anything.

Possibly an overall CRC would have some value?  That would seem to
require a second type of ACS-like option, i.e REASSEMBLE-ACS?
Again it would only need to be sent with only one of the FRAG
containing packets.  Is such an addition worth it?

DF

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 14:18:33 -0800

Hi, Derek,

> single CHECKSUM option, carried in only one of the FRAG packets.
It matters whether the options are considered to apply before or after
reassembly.

The trick is what is being reassembled - is it the UDP payload only or
something larger?

Again, I need to think about this a little more. I'd really like to
stick to something simple.

> containing packets.  Is such an addition worth it?

The two options are:

- add a checksum inside the FRAG option that applies the reassembled whole
- define the options in such a way that some apply before reassembly
(e.g., before each FRAG option in each received UDP packet) and some
apply after (we'd have to be careful in defining what is created as a
result.

The second variant is cleaner if there's a way to do it. However we have
some possibly conflicting issues:

    - OCS clearly ought to apply for each fragment (otherwise you might
err in reassembly and wait too long to catch it)
    - AE should apply to each fragment (same rule as OCS - you have
enough info to prevent an attack on reassembly)
    - ACS would usefully apply after reassembly
    - FRAG shouldn't appear more than once
    - TIME is useful only before FRAG
    - MSS is useful only before FRAG (and we might want two different
MSS values - the conventional MSS and a UDP reassembly MSS!)
 
Again, this deserves a bit more digestion...

Joe
    -

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Feb 2017 14:19:18 -0800

> containing packets.  Is such an addition worth it?
I would guess not. I think from an implementation point of view it's
almost always better to perform integrity checks, authentication,
encryption, or any other packet transforms over each individual
fragment. If necessary, fragmentation might include it's on integrity
check at reassembly but that might only be over few fields in each
fragment not over all the data. This is how we defined processing
order in GUE fragmentation occurs before other options are set so that
the other options (auth, csum, etc.) are applied per fragment;
receiver processes all other options before attempting reassembly.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 14:20:07 -0800

Hi, Derek,

> essentially an array of bytes used for options.  I'm proposing instead to
We discussed that before. The issue is whether OCS is optional or not.
If it isn't, yes - it can come first as you note.

> LITE header).  Hence why I was the referring to partial sums.

I see now. Yes, that's another possibility. It depends on what the WG
wants in terms of whether OCS is optional or not.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 14:21:29 -0800

Hi, Tom,

The issue of whether a reassembled unit should have an integrity
checksum depends on whom you ask.

SEAL/AERO include one, but other protocols do not.

Again, I'm open to figuring this out. I'd like a lightweight solution
where possible, of course.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 14:51:39 -0800

Hi, all,

Thanks for the lively discussion! I hope this bodes well for accepting
this as a WG doc. Again, I'd prefer if I had deployable running code,
but we do have multiple implementations that worked, just not ready for
prime time.

Here's a quick summary of the issues just raised, both for me (for the
next edit) and in case any new issues are of interest.

Please do let me know if I missed or incorrectly summarized anything
below...

Thanks!

Joe

-----------------------------------------------------

Editorial:

- fix Identification field length in Fig 15v s. text (should be 32 bits)

-----------------------------------------------------

Use cases:

- add DNSSEC impact on segment size and IP fragment problems with
network traversal

    add ref to draft-muks-dns-message-fragments app-layer solution

    note that FRAG works well when request is small because it can
indicate FRAG support for large response

- discuss impact to UDP API

    who sets these? OS or app?

    which ones are transparent? which are NOT?

-----------------------------------------------------

Option design:

FRAG:

    - should FRAG have a reassembly checksum?

    - should FRAG have a post-reassembly length verification?

    - use LITE to support backwards transparent FRAG (thanks, C. M. 
Heard!) (if so, need final reassembly checksum!)

    - what happens if LITE and FRAG are present with non-trivial
covered/not-covered areas?

    - rename "segmentation" to avoid confusion with IP layer mechanism?
(or is SAR too overloaded with ATM?)

ACS:

    - address ACS interaction with LITE and FRAG (ACS covers UDP
payload, but NOT IP or UDP header except len?)

    - clarify ACS covers each received UDP segment or fragment, NOT
reassembled result

    - indicate which CRC-16 polynomial

OCS:

    - clarify OCS covers header within each received UDP segment or
fragment, NOT reassembled result

    - should OCS be mandatory, and if so, make it just the UDP checksum
on the option area?

LITE

    - revise Sec 7 vs. UDP Lite and omit EOL discussion (not relevant
given new swap mechanism)

EOL

    - explain possible uses (given removal from Section 7)

    - if removed, consider changing NOP to 0

Another security option?

    - HMAC for IPv6 SR option(see Tom Herbert's GUE variant)

ALL (general):

    - revisit MUST IMPLEMENT list (add MSS, FRAG, TIME?)

    - create a list of required ordering

        OCS first (always)

        AE next (if it appears)

        TIME, MSS

        FRAG (last? otherwise security/safety mechanisms wouldn't
protect the reassembly process?)

-----------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Feb 2017 15:02:24 -0800

> It also adds a discussion on control block caching, ala RFC2140 for TCP.
Joe,

>From section 9:

"It is useful that the above requirements prevent using UDP options to
implement transport-layer fragmentation and reassembly unless that
capability has been negotiated with an endpoint in advance for a socket
pair. Legacy systems would need to be able to interpret the transport
payload fragments as individual transport datagrams."

This can probably more broadly be worded as saying that any option that
cannot be safely ignored requires the capability to be negotiated. So that
clearly includes fragmentation, encryption, and any other option that
modifies the payload of the original UDP packet. We can also include
authentication in that list since that needs key negotiation also. So
probably the next question is whether a checksum or CRC can be ignored by a
receiver.

Note, VXLAN and LISP have already taken liberty to allow a non-zero
received UDP checksum to be ignored, however this contrary to RFC1122 which
says:

"If a UDP datagram is received with a checksum that is non-zero and
invalid, UDP MUST silently discard the datagram."

There is similar wording for IP and TCP checksums.

I think this is the correct and robust policy for checksum/CRC. If a sender
took the time to compute them and set them in the packet then it should be
incumbent on the receiver to verify them. The whole point of enabling
integrity checks is to catch errors and corruption, if we don't catch the
errors at this layer we can only hope that they are caught later on but
there's no guarantee. What's worse if I'm debugging an issue and snoop
packets on the wire and see that sender is sending checksums but receiver
is not catching bad packets then this is completely misleading. Allowing a
receiver to ignore checksums undermines usefulness of the mechanism.

So IMO, checksums and CRCs are in the class of options that cannot be
ignored by a receiver and would need to be negotiated. That leaves TS and
MSS options which probably can be safely ignored.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 15:13:43 -0800

Hi, Tom,

On 2/28/2017 3:02 PM, Tom Herbert wrote:
> capability has been negotiated with an endpoint in advance for a
> socket pair. Legacy systems would need to be able to interpret the
> transport payload fragments as individual transport datagrams."
> This can probably more broadly be worded as saying that any option
> that cannot be safely ignored requires the capability to be
> negotiated. So that clearly includes fragmentation, encryption, and
> any other option that modifies the payload of the original UDP packet.

It depends; the variant that Mike proposed for FRAG using LITE with a
zero-size UDP user payload is backward compatible, but just ends up
dropping everything at a legacy receiver). We could actually pull the
same trick with any other mechanism that would have corrupted the
receiver, FWIW (not just FRAG) (see below, though).

> We can also include authentication in that list since that needs key
> negotiation also.
AE wouldn't (just as TCP-AO doesn't); both rely on predeployed keys.

> So probably the next question is whether a checksum or CRC can be
> ignored by a receiver.
> received UDP checksum to be ignored, however this contrary to RFC1122
> which says:
> I think this is the correct and robust policy for checksum/CRC. If a
> sender took the time to compute them and set them in the packet then
> it should be incumbent on the receiver to verify them. The whole point
> of enabling integrity checks is to catch errors and corruption, if we
> don't catch the errors at this layer we can only hope that they are
> caught later on but there's no guarantee. What's worse if I'm
> debugging an issue and snoop packets on the wire and see that sender
> is sending checksums but receiver is not catching bad packets then
> this is completely misleading. Allowing a receiver to ignore checksums
> undermines usefulness of the mechanism.
I agree that a required checksum cannot be ignored...
> ignored by a receiver and would need to be negotiated. That leaves TS
> and MSS options which probably can be safely ignored.
ACS is intended to provide better protection for receivers that support
them, but are intended to be ignored by those that do not.

Using ACS before reassembly would imply "drop if it fails if you support
it" - by design.

Using a CRC after reassembly would not, though - it MUST be dropped (but
then we'd know it was supported if the reassembly succeeded).

Joe