Subject: [tsvwg] Issues with the specification of AUTH and UENC in draft-ietf-tsvwg-udp-options-18

From: "C. M. Heard" <[email-masked]>
Date: Sat, 26 Mar 2022 19:10:25 -0700

Greetings.

I have the following concerns about the specification of AUTH that I didn't
notice before.

1. The description of the option in Section 9.9 relies normatively on RFC
5925, but this RFC is listed only as an informative reference. I'm in total
agreement with the policy of incorporating by reference all of the
information in RFC 5925, and I think that the description in Section 9.9 is
sufficient to implement the option, provided that RFC 5925 is consulted to
gain the necessary understanding of the format of the option (cf. Figure
16) and of the use and content of Master Key Tuples (MKTs), but the
information in Section 9.9 is insufficient by itself.

2. Similarly, the MKT extensions needed to enable NAT traversal are fully
described only in RFC 6978, but this RFC is also listed only as an
informative reference. One complication with citing RFC 6978 is that it is
Experimental, not Standards Track, and citing it would create a downref. It
could be argued that the MKT extensions are sufficiently simple that the
necessary information can be inferred from the final paragraph of Section
9.9, but my preference would be to see RFC 6978 cited normatively as a
justifiable downref.

3. It might be useful to mention in Section 9.9 that AUTH is not useful as
a per-datagram option unless protection of the option area is configured.
That is obvious after reflecting on the fact that fragments do not contain
UDP user data, only options, but it's easily missed.

4. Section 9.9 does an excellent job of specifying how AUTH failures are to
be handled for reassembled (or unfragmented) UDP datagrams: deliver the
data and an indication that AUTH failed. It's not clear to me how this is
conveyed when AUTH is used as a per-datagram option. That is why I proposed
to accumulate AUTH failures on fragments (i.e., OR all the individual
fragment failure flags together) and report them cumulative failure
indication to the upper layer. That was the genesis of "WG QUESTION: SHOULD
WE ACCUMULATE THOSE OPTIONS? OR DISCARD THEM?" in Section 13.

Similarly, I have the following concerns about UENC:

1. The description in Section 10.1 relies normatively on both RFC 5925 and
(IMO) RFC 6978, and in addition, also relies normatively on [To18], which
is draft-touch-tcp-ao-encrypt-09. My understanding is that Internet Drafts
cannot be cited as normative references. Would it be possible to fast-track
draft-touch-tcp-ao-encrypt for publication on the Independent Stream, as
was done for RFC 6978? It would be a downref but at least it could be cited.

2. There is a gap in the description of what happens when UENC is
configured to include the option area: the whole option -- not just the MAC
-- needs to be excluded from the encryption process and has to appear first
in the option area (possibly preceded by other unencrypted options) so that
implementations that do not support UENC will know to discard it. It's also
necessary so that implementations that do support UENC can see the
unencrypted KeyID (otherwise, it's not in possible to decrypt unless KeyID
is constant for the life of the association). AFAICT this same omission
afflicts draft-touch-tcp-ao-encrypt-09.

3. It might be useful to mention in Section 10.1 that AUTH is not useful as
a per-datagram option unless protection of the option area is configured.
Again, that is obvious after reflecting on the fact that fragments do not
contain UDP user data, only options, but it's easily missed.

4. Sections 10 and 12 do an excellent job of specifying how failures of
UENC or any other unsafe option are to be handled for reassembled (or
unfragmented) UDP datagrams: deliver a zero-length datagram to the upper
layer. That was a change between -16 and -18 motivated by one of my
technical comments on -16, specifically this:

#Section 10.1, UENC: consider adding the following sentence at the end of
the only paragraph in the section:

   Unlike AUTH, if UENC fails, the packet and its options are silently
discarded.

That comment was badly mis-stated -- I was thinking specifically of what
happens when a per-fragment UENC fails. Clearly, a failed UENC on a
fragment will cause a reassembly failure. So. what gets delivered to the
user in this case, or more generally, in case  of any reassembly failure?

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 26 Mar 2022 21:30:31 -0700

Hi, Mike,

...
> On Mar 26, 2022, at 7:10 PM, C. M. Heard <[email-masked]> wrote:
> 
> Greetings.
> 
> I have the following concerns about the specification of AUTH that I didn't notice before.
> 
> 1. The description of the option in Section 9.9 relies normatively on RFC 5925,...
> 2. Similarly, the MKT extensions needed to enable NAT traversal are fully described only in RFC 6978, ...

Agreed on both moving to normative.

> 3. It might be useful to mention in Section 9.9 that AUTH is not useful as a per-datagram option unless protection of the option area is configured. That is obvious after reflecting on the fact that fragments do not contain UDP user data, only options, but it's easily missed.

Not sure I can parse what you’re saying here.

Like TCP-AO, whether AUTH covers options or not seems like a configuration option. That seems to work as expected for non-fragmented datagrams, but would not make sense for fragments. Is that what you’re staying? 

> 4. Section 9.9 does an excellent job of specifying how AUTH failures are to be handled for reassembled (or unfragmented) UDP datagrams: deliver the data and an indication that AUTH failed. It's not clear to me how this is conveyed when AUTH is used as a per-datagram option.

Again, not sure what you mean here - why wouldn’t that be the same behavior?

> That is why I proposed to accumulate AUTH failures on fragments (i.e., OR all the individual fragment failure flags together) and report them cumulative failure indication to the upper layer. That was the genesis of "WG QUESTION: SHOULD WE ACCUMULATE THOSE OPTIONS? OR DISCARD THEM?" in Section 13.

That’s the general question - AFAICT, SAFE options on fragments just accumulate the same way the list of options of a datagram would. UNSAFE options would terminate reassembly.

Would that rule work?

> 1. The description in Section 10.1 relies normatively on both RFC 5925 and (IMO) RFC 6978, and in addition, also relies normatively on [To18], which is draft-touch-tcp-ao-encrypt-09. My understanding is that Internet Drafts cannot be cited as normative references. Would it be possible to fast-track draft-touch-tcp-ao-encrypt for publication on the Independent Stream, as was done for RFC 6978? It would be a downref but at least it could be cited.

I can definitely do that if needed. It doesn’t appear to need anything to proceed, except as noted below.

> 2. There is a gap in the description of what happens when UENC is configured to include the option area: the whole option -- not just the MAC -- needs to be excluded from the encryption process and has to appear first in the option area (possibly preceded by other unencrypted options) so that implementations that do not support UENC will know to discard it. I

To18 needs to be updated to indicate that when TCP options are included in encryption, that applies only to options that appear AFTER the encryption option (it always applies to user data, if present). Alternately, they can be not encrypted. The same would apply here to UDP.

> t's also necessary so that implementations that do support UENC can see the unencrypted KeyID (otherwise, it's not in possible to decrypt unless KeyID is constant for the life of the association). AFAICT this same omission afflicts draft-touch-tcp-ao-encrypt-09.

Yes - see above.

> 3. It might be useful to mention in Section 10.1 that AUTH is not useful as a per-datagram option unless protection of the option area is configured. Again, that is obvious after reflecting on the fact that fragments do not contain UDP user data, only options, but it's easily missed.

It could be used before fragmentation as a per-datagram option, in which case it does not need to include the per-datagram options.

If used as per-fragment, it would need to include options because there’s no user data to encrypt.

> 4. Sections 10 and 12 do an excellent job of specifying how failures of UENC or any other unsafe option are to be handled for reassembled (or unfragmented) UDP datagrams: deliver a zero-length datagram to the upper layer. That was a change between -16 and -18 motivated by one of my technical comments on -16, specifically this:
> 
> #Section 10.1, UENC: consider adding the following sentence at the end of the only paragraph in the section:
> 
>    Unlike AUTH, if UENC fails, the packet and its options are silently discarded.
> 
> That comment was badly mis-stated -- I was thinking specifically of what happens when a per-fragment UENC fails. Clearly, a failed UENC on a fragment will cause a reassembly failure. So. what gets delivered to the user in this case, or more generally, in case  of any reassembly failure?

Each failed fragment causes a zero-length delivery to the user. When the overall reassembly fails, I don’t know that anything additional would need to happen, though.

Thoughts?

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2022 03:49:37 -0700

Hi Joe,

Trimming this back just to things that need further discussion:

On Sat, Mar 26, 2022 at 9:30 PM tJoe TOuch wrote:

> Hi, Mike,
>
> ...
>
> On Mar 26, 2022, at 7:10 PM, C. M. Heard wrote:
>
> ...
>

> Like TCP-AO, whether AUTH covers options or not seems like a configuration
> option. That seems to work as expected for non-fragmented datagrams, but
> would not make sense for fragments. Is that what you’re staying?
>

I just meant what you say below about encryption: if used as per-fragment,
AUTH would need to include options because there’s no user data to
authenticate. Is that clear enough?

> 4. Section 9.9 does an excellent job of specifying how AUTH failures are
> to be handled for reassembled (or unfragmented) UDP datagrams: deliver the
> conveyed when AUTH is used as a per-datagram option.
>
>
> That is why I proposed to accumulate AUTH failures on fragments (i.e., OR
> all the individual fragment failure flags together) and report
> them cumulative failure indication to the upper layer. That was the genesis
> of "WG QUESTION: SHOULD WE ACCUMULATE THOSE OPTIONS? OR DISCARD THEM?" in
> Section 13.
>
>
> That’s the general question - AFAICT, SAFE options on fragments just
> accumulate the same way the list of options of a datagram would. UNSAFE
> options would terminate reassembly.
>
> Would that rule work?
>

Yes, that is exactly what I had in mind.

Moving on:

To18 needs to be updated to indicate that when TCP options are included in
> encryption, that applies only to options that appear AFTER the encryption
> option (it always applies to user data, if present). Alternately, they can
> be not encrypted. The same would apply here to UDP.
>

Agreed.

> 3. It might be useful to mention in Section 10.1 that AUTH is not useful
> as a per-datagram option unless protection of the option area is
> configured. Again, that is obvious after reflecting on the fact that
> fragments do not contain UDP user data, only options, but it's easily
> missed.
>
>
> It could be used before fragmentation as a per-datagram option, in which
> case it does not need to include the per-datagram options.
>

Exactly.

> Each failed fragment causes a zero-length delivery to the user. When the
> overall reassembly fails, I don’t know that anything additional would need
> to happen, though.
>
> Thoughts?
>

I think this is fine, but reading back the message just to make sure that
it was properly understood:

 A "failed fragment" is a UDP fragment whose UDP checksum is good but with
an error that causes the entire option area to be discarded. Yes, it makes
sense for that to result in a zero-length UDP datagram with no options
(since it's technically indistinguishable from such). That's consistent
with agreed-upon text, and I'm fine with that.

If we get a reassembly timeout -- whether from a failed fragment,
non-delivery of a fragment, or any other reason (e.g., lack of buffer
space) -- both the partially reassembled datagram AND any accumulated
per-fragment options will be silently discarded. I'm fine with that, I just
wanted to see it made explicit.

Thanks

Mike

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 27 Mar 2022 08:07:40 -0700

Notes below...
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 27, 2022, at 3:49 AM, C. M. Heard <[email-masked]> wrote:
> 
> Hi Joe,
> 
> I just meant what you say below about encryption: if used as per-fragment, AUTH would need to include options because there’s no user data to authenticate. Is that clear enough?

OK, so then AUTH is not useful as a per -FRAGMENT option… right?

...
> I think this is fine, but reading back the message just to make sure that it was properly understood:
> 
>  A "failed fragment" is a UDP fragment whose UDP checksum is good but with an error that causes the entire option area to be discarded. Yes, it makes sense for that to result in a zero-length UDP datagram with no options (since it's technically indistinguishable from such). That's consistent with agreed-upon text, and I'm fine with that.
> 
> If we get a reassembly timeout -- whether from a failed fragment, non-delivery of a fragment, or any other reason (e.g., lack of buffer space) -- both the partially reassembled datagram AND any accumulated per-fragment options will be silently discarded. I'm fine with that, I just wanted to see it made explicit.

All the data and options would be discarded, though - because the data was options at that point anyway.

Hmm. I wonder if we should be delivering one or more zero-length packets in that case, just to again not change behavior, though…

??

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2022 08:14:14 -0700

On Sun, Mar 27, 2022 at 8:07 AM Joe Touch wrote:

>> 3. It might be useful to mention in Section 9.9 that AUTH is not useful
>> configured. That is obvious after reflecting on the fact that fragments do
>> not contain UDP user data, only options, but it's easily missed.
>>
>>
>> Like TCP-AO, whether AUTH covers options or not seems like a
>> configuration option. That seems to work as expected for non-fragmented
>> datagrams, but would not make sense for fragments. Is that what you’re
>> staying?
>>
>

It's not useful unless it's configured to protect the options. But it might
be useful when it IS set up to protect the options.

> Hmm. I wonder if we should be delivering one or more zero-length packets
> in that case, just to again not change behavior, though…
>

I guess it wouldn't hurt, but I have no strong opinion either way, as long
as the spec is clear on what to do.

Mike

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 27 Mar 2022 08:17:38 -0700

To clarify...

> On Mar 27, 2022, at 8:14 AM, C. M. Heard <[email-masked]> wrote:
> 
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Mar 27, 2022, at 3:49 AM, C. M. Heard <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Joe,
>> 
> It's not useful unless it's configured to protect the options. But it might be useful when it IS set up to protect the options.

Right. I was just restating your text, which originally said “AUTH is not user as a per-datagram option”.

I think you meant “per-fragment” there, that’s all.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2022 08:21:00 -0700

On Sun, Mar 27, 2022 at 8:17 AM Joe Touch wrote:

>> I just meant what you say below about encryption: if used as
>> per-fragment, AUTH would need to include options because there’s no user
>> data to authenticate. Is that clear enough?
>>
>>
> It's not useful unless it's configured to protect the options. But it
> might be useful when it IS set up to protect the options.
>
>
> That's right, my mistake.

Mike

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 27 Mar 2022 08:37:16 -0700

One note - mostly as a reminder to me to address, but just to note it was not overlooked:

- both AUTH and UENC need text to describe how the traffic keys are created, notably given UDP has no ISNs, basically (IMO) by using zeros where ISNs are needed

Joe