[nfsv4] Sorin review of draft-ietf-nfsv4-rpc-tls

[[e-mail]]

Hi Chuck,

My review notes marked with [sf]

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.

[sf] I reviewed the latest draft and I have some questions and concerns related to section 7.2 it is defined the TLS management on clients:
"The RPC-on-TLS protocol by itself cannot protect against exposure of a user's RPC requests to other users on the same client.
Moreover, client implementations are free to transmit RPC requests for more than one RPC user using the same TLS session. Depending on the details of the client RPC implementation, this means that the client's TLS identity material is potentially visible to every RPC user that shares a TLS session."

I see two issues with this:
1. If there is a compromised user running on same client it is possible that the compromised user can "see" the identity material of the legitimate users.
2. It is possible that a compromised user initiate a DDoS attack on the server and the server will not detect the attack as it comes from a legitimate host and encrypted. This may expose a server to undetected DDoS attacks.

Also the question is do we allow a mix of users using TLS and others not using TLS on same client? I understand that we don't support multiple TLS on same connection but do we support a mix? Some explanation/clarification text will be useful.

./Sorin
--
Chuck Lever

_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4