Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[Chuck Lever <[e-mail]>]

> On Apr 22, 2020, at 1:50 PM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi,
> 
> Regarding this last issue.
> 
> On Wed, 2020-04-22 at 12:08 -0400, Chuck Lever wrote:
>>> On Apr 22, 2020, at 11:57 AM, Magnus Westerlund <
>>> [e-mail]> wrote:
>>> 
>>> E. Section 5.1.2:
>>> 
>>> When using connectionless operation, each DTLS session endpoint is
>>> identified 
>>> by its 5-tuple -- the source and destination IP address and port numbers, 
>>> along with the UDP transport protocol number (17). When using connected 
>>> operation, the DTLS session endpoints are identified by connection ID
>>> (CID), 
>>> as described in [I-D.ietf-tls-dtls-connection-id]. Connected operation is 
>>> strongly RECOMMENDED.
>>> 
>>> So I don't know if I looked to quickly at DTLS 1.3 and the dtls-connection-
>>> id 
>>> draft. However, I don't see any discussion of a connectionless operation.
>>> This 
>>> might be a terminology issue primarily. However, my understanding which
>>> might 
>>> be flawed are that the DTLS connection is created by the DTLS handshake.
>>> That 
>>> DTLS connection can either be identified by the 5-tuple or use this CID 
>>> extension.
>>> 
>>> The primary goal of the CID extension is to avoid need for a new DTLS 
>>> handshake and creating a new DTLS connection if the 5-tuple changes, for 
>>> example due to NAT port rebinding.
>>> 
>>> In addition my understanding is that [I-D.ietf-tls-dtls-connection-id] is 
>>> defining the extension for CID for DTLS 1.2. Section 9 in the DTLS1.3 
>>> specification imports that extension into DTSL 1.3. Thus, if you want to 
>>> recommend its usage it might be better to point to Section 9 and only use 
>>> [I-D.ietf-tls-dtls-connection-id] informationally.
>> 
>> Yes, I noticed that connection-id refers specifically to DTLS 1.2, but
>> assumed (erroneously) that it would also apply to DTLS 1.3. I didn't
>> think to look that the CID extension was already integrated into tls-dtls13.
>> 
>> I'll check into this further. It might be fine to simply drop the reference
>> to connection-id, replacing it as you suggest above.
> 
> I think the reference is rather simple to deal with. I think the real question
> is if it is motivated to recommend using CID or not. There is after all an
> overhead. And please remember that the first part of the CID value either needs
> to map to differnet lengths or a server proxy us a single length. So for a
> server UDP port that is used by many clients will have a large enough CID length
> to avoid a lack. Thus the CID likley are 4+ bytes. And describe that in a way
> that will not be missunderstood. 
> 
> But lets discuss this in today's interim meeting.

After reviewing Section 9 of tls-dtls37, IMO:

- the explicit reference to tls-dtls-connection-id can be removed
- the discussion of connectionless operation should be dropped
- the strong RECOMMENDATION to use connected operation should be dropped
- rpc-tls should REQUIRE the use of the CID extension for RPC-on-DTLS
- rpc-tls should provide implementation guidance to RPC server implementers
to use large CIDs for popular RPC services.

Does that sound right? If so I will propose replacement text here on list.

The other editorial items have already been fixed and pushed to github.

Tigran mentioned in the interim meeting chat room that the DESY RPC-on-TLS
implementation does indeed support DTLS. rpc-tls Section 6 needs to be
updated to reflect that. I've asked him for a pull request to take care of
it.

After that, I will submit a fresh revision.

--
Chuck Lever