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

[Chuck Lever <[e-mail]>]

> On Apr 27, 2020, at 4:37 PM, Trond Myklebust <[e-mail]> wrote:
> 
> 
> 
> On Mon, 27 Apr 2020 at 11:45, Chuck Lever <[e-mail]> wrote:
> 
> 
>> > On Apr 27, 2020, at 11:11 AM, Trond Myklebust <[e-mail]> wrote:
>> > 
>> > 
>> > 
>> > On Mon, 27 Apr 2020 at 10:21, Chuck Lever <[e-mail]> wrote:
>> > Hi Magnus-
>> > 
>> > > On Apr 27, 2020, at 4:47 AM, Magnus Westerlund <[e-mail]> wrote:
>> > > 
>> > > Hi,
>> > > 
>> > > I think that text works. However, that now recommends using a non-zero
>> > > connection ID. From my perspective which have no implementation stake into this,
>> > > this is fine. However, I would note that this backtracks on what was said just a
>> > > few messages ago.
>> > 
>> > It's always possible I've gotten something wrong. However, I realized that RPC
>> > on UDP permits an RPC server to use a different network path to send a Reply
>> > than the path the client used to send the matching Call. IIUC a substantial CID
>> > is needed to deal correctly with that situation.
>> > 
>> > 
>> > I don't think that matters. The server should always authenticate to the client during the D/TLS handshake, so there should be no ambiguity about the source of the replies.
>> 
>> The server is free to reply via any of its network interfaces. In other
>> words, it can perform the handshake using one 5-tuple, then send replies
>> via another (or send them via a mix of 5-tuples).
>> 
>> A CID is needed to handle NAT rebinding in any case. But IIUC rebinding
>> would look like the client's 5-tuple changing, not the server's.
>> 
>> The question in mind is whether a DTLS session will be perturbed by the
>> server's or client's 5-tuple changing. Magnus, can you elaborate on your
>> earlier request for a clear statement about this in this section? Is this
>> no longer a concern now that the REQUIREMENT to drop an out-of-session
>> RPC Call?
>> 
>> 
>>   For RPC-on-DTLS, each DTLS handshake MUST include the connection_id
>>   extension described in Section 9 of [I-D.ietf-tls-dtls13].  RPC-on-
>>   DTLS peer endpoints SHOULD provide a ConnectionID with a non-zero
>>   length.  Endpoints implementing RPC programs that expect a
>>   significant number of concurrent clients should employ ConnectionIDs
>>   of at least 4 bytes in length.
>> 
>> Also, I'm not certain if SHOULD is correct here. Instead, "should" or
>> "MUST" might be less ambiguous. However, if we all agree the statement is
>> totally unnecessary, it can be replaced or dropped.
>> 
> 
> I'm saying that it doesn't matter from what network interface, or indeed which breed of carrier pigeon the server chooses, The client can still authenticate the reply as being genuine from the fact that the server authenticated to it at the start of the DTLS session. As long as this is still the same session, then the client can ignore any changes to the network topology.

My reading of draft-ietf-tls-dtls-connection-id suggests that is not
the case for DTLS 1.2 and later.

Abstract says:

   A CID is an identifier carried in the record layer header that gives
   the recipient additional information for selecting the appropriate
   security association.  In "classical" DTLS, selecting a security
   association of an incoming DTLS record is accomplished with the help
   of the 5-tuple.  If the source IP address and/or source port changes
   during the lifetime of an ongoing DTLS session then the receiver will
   be unable to locate the correct security context.

Further, the Introduction states:

   In the current version of DTLS, the IP address and port of the peer
   are used to identify the DTLS association.  Unfortunately, in some
   cases, such as NAT rebinding, these values are insufficient.  This is
   a particular issue in the Internet of Things when devices enter
   extended sleep periods to increase their battery lifetime.  The NAT
   rebinding leads to connection failure, with the resulting cost of a
   new handshake.

Unless I'm reading this wrong, if either peer sees a DTLS datagram from
a different IP address than was used during the DTLS handshake, it's not
going to be able to associate that with a previously established DTLS
session... unless there's a CID.

The DTLS handshake and the subsequent DTLS record exchanges are two
separate protocols. The CID is exactly the material that the peers need
to determine that the remote sender is the same peer that established
that DTLS session.


--
Chuck Lever