Subject: [tsvwg] Questions about UDP options AUTH and ENCR

From: "C. M. Heard" <[email-masked]>
Date: Sun, 12 Sep 2021 13:26:49 -0700

Joe,

I think I have (finally) absorbed enough of RFC 5925 and
draft-touch-tcp-ao-encrypt-09 to get a basic understanding of how AUTH and
ENCR are expected to work, and I have some questions for you and the WG.

1.) Why are there no KeyID and RNextKeyID parameters in these options?
Those parameters seem to be rather fundamental to the usage of MKTs (Master
Key Tuples), and it seems like their omission must be an oversight. If not,
an explanation of how we do without them would be much appreciated.

2.) It seems to me that AUTH and ENCR cannot provide replay protection
owing to UDP's lack of sequence numbers. If so, that should be noted.

3.) How is a connection identified when NAT Traversal is enabled? I
had understood from RFC 5925 that <Source IP, Source Port, Dest ID, Dest
Port> was used for this purpose, but a NAT can change the source or
destination address and port in unpredictable ways. I wasn't able to figure
out this point from RFC 6978, so an explanation would be helpful.

4.) The -13 UDP options draft has informative references to TCP-AO (RFC
5925) TCP-AO-NAT (RFC 6978), and draft-touch-tcp-ao-encrypt-09. I don't
believe that there is enough information in the draft to figure out how to
implement AUTH and ENCR without consulting these references, so it seems to
me that they should be normative. Promoting RFC 5925 to a normative
reference should be fine, since it is an IETF standards track RFC. But RFC
6978 is an experimental individual submission, hence would be a downref,
and draft-touch-tcp-ao-encrypt-09 is not a stable reference at all. I think
it would be easy to rework the description of ENCR so as to make the
reference to draft-touch-tcp-ao-encrypt-09 informative, though maybe it
should be noted that the BTNS-style of encryption does not apply to UDP.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 12 Sep 2021 14:17:05 -0700

Hi, Mike, 

Some answers below.

Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 12, 2021, at 1:26 PM, C. M. Heard <[email-masked]> wrote:
> 
> Joe,
> 
> I think I have (finally) absorbed enough of RFC 5925 and draft-touch-tcp-ao-encrypt-09 to get a basic understanding of how AUTH and ENCR are expected to work, and I have some questions for you and the WG.
> 
> 1.) Why are there no KeyID and RNextKeyID parameters in these options? Those parameters seem to be rather fundamental to the usage of MKTs (Master Key Tuples), and it seems like their omission must be an oversight. If not, an explanation of how we do without them would be much appreciated.

Fig 17 should be corrected; the intent is to just copy the format from 5925 by reference, as indicated in the text just above that figure.

However, see the suggestion in response to #2 below.

> 2.) It seems to me that AUTH and ENCR cannot provide replay protection owing to UDP's lack of sequence numbers. If so, that should be noted.

Agreed. 

It can also be addressed in other ways, e.g., we could instead let the AUTH and ENCR field contents be determined by the same endpoint coordination required to coordinate key values and algorithms. FWIW, I prefer this approach

> 3.) How is a connection identified when NAT Traversal is enabled? I had understood from RFC 5925 that <Source IP, Source Port, Dest ID, Dest Port> was used for this purpose, but a NAT can change the source or destination address and port in unpredictable ways. I wasn't able to figure out this point from RFC 6978, so an explanation would be helpful.

The same as for TCP-AO-NAT; both endpoints are configured to map a given socket pair to the configuration (key, alg, etc.). The only difference is that one or more of the port and address fields are omitted from the HMAC calculation or crypto input.

> 4.) The -13 UDP options draft has informative references to TCP-AO (RFC 5925) TCP-AO-NAT (RFC 6978), and draft-touch-tcp-ao-encrypt-09. I don't believe that there is enough information in the draft to figure out how to implement AUTH and ENCR without consulting these references, so it seems to me that they should be normative. Promoting RFC 5925 to a normative reference should be fine, since it is an IETF standards track RFC. But RFC 6978 is an experimental individual submission, hence would be a downref, and draft-touch-tcp-ao-encrypt-09 is not a stable reference at all. I think it would be easy to rework the description of ENCR so as to make the reference to draft-touch-tcp-ao-encrypt-09 informative, though maybe it should be noted that the BTNS-style of encryption does not apply to UDP.

Agreed; if we stay as-is, we should make those normative, with the NAT version considered experimental for UDP as well and the suggestion of how to extend this to ENCR be informative. We could, however, leave all the field content for AUTH and ENCR be informative refs and simply say “as agreed by the endpoints”.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 12 Sep 2021 14:23:13 -0700

Sounds good. I'll wait for -14 (or -15 if need be) to have a second look.

On Sun, Sep 12, 2021 at 2:17 PM [email-masked] <[email-masked]>
wrote:

> Fig 17 should be corrected; the intent is to just copy the format from
> 5925 by reference, as indicated in the text just above that figure.
>
> It can also be addressed in other ways, e.g., we could instead let the
> AUTH and ENCR field contents be determined by the same endpoint
> coordination required to coordinate key values and algorithms. FWIW, I
> prefer this approach
>
> The same as for TCP-AO-NAT; both endpoints are configured to map a given
> socket pair to the configuration (key, alg, etc.). The only difference is
> that one or more of the port and address fields are omitted from the HMAC
> calculation or crypto input.
>
> and draft-touch-tcp-ao-encrypt-09 is not a stable reference at all. I
> think it would be easy to rework the description of ENCR so as to make the
> Agreed; if we stay as-is, we should make those normative, with the NAT
> version considered experimental for UDP as well and the suggestion of how
> to extend this to ENCR be informative. We could, however, leave all the
> field content for AUTH and ENCR be informative refs and simply say “as
> agreed by the endpoints”.
>
> Joe
>
>
> Mike Heard
>
>
>