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

[Chuck Lever <[e-mail]>]

> On Apr 28, 2020, at 7:23 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> On Mon, 2020-04-27 at 17:02 -0400, Chuck Lever wrote:
>>> 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.
>> 
> 
> Exactly, my understanding was that DTLS without connection IDs uses the 5-tuple
> and that needs to be reversed when replying. This is also definitely true in
> environments with NATs and Firewalls to hit the stateful pinholes. I understand
> that this is not the case in DC deployments. 
> 
> If it is common for RPC over UDP to not use reversed 5-tuples then I think using
> non-zero CIDs is a requirement.

It is not common, but it is not forbidden. In the field there have been
implementations that, when deployed on multi-homed hosts, do send Replies
via a different network path than the one on which Calls arrived.


> I think you should write that little motivation
> into the text to make people aware that this may not be the environment that
> people from outside of NFSv4 are used to. Because that clearly surprises me.

Well, NFSv4 is explicitly forbidden from running on connectionless transports
like UDP. It's other RPC programs that might fall into this trap. I'll see
if I can come up with a sentence or two that summarize this situation.


> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------

--
Chuck Lever