Re: [nfsv4] Erik Kline's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)

[Chuck Lever <[e-mail]>]

Hi Erik-

Thanks for your comments!

> On Jun 30, 2020, at 12:31 AM, Erik Kline via Datatracker <[e-mail]> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ questions ]]
> 
> * Can/should the same AUTH_TLS w/ NULL RPC check be done on the rpcbind
>  (portmapper) service as well?

Yes. It would work like any RPC program that uses a well-known destination
port.


> * What mechanism guarantees that (D)TLS traffic can always and easily be
>  distinguished from RPC traffic on the same port?

The document does not specify any mechanism for making that distinction
for UDP. The server would have to match ingress datagrams that appear to
be DTLS traffic to existing DTLS session state. The server treats datagrams
that fail to match as RPC messages.

For TCP, once a TLS session is established on a connection, the client is
forbidden from mixing TLS traffic with unprotected traffic on that
connection. To send unprotected traffic after establishing a session, a
client would have to establish a separate TCP connection that does not
have a TLS session.


> [[ nits ]]
> 
> [ section 5.1.1 ]
> 
> * "When operation is complete" ... In addition to a grammar tweak, you
>  might repeat a few choice words from section 7.2 about the ability to
>  send multiple requests over a connection.

I don't understand this comment. Section 7.2 is about user privilege
separation. What did you have in mind?


> [ section 7.4 ]
> 
> * s/RCPSEC_GSS/RPCSEC_GSS/

Thanks, will fix.

--
Chuck Lever