Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt

Hi Chuck,

I will try provide some text to address this issue.

Thanks,
   Tigran.

----- Original Message -----
> From: "Chuck Lever" <chuck.lever@oracle.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
> Cc: "NFSv4" <nfsv4@ietf.org>
> Sent: Saturday, February 15, 2020 5:02:43 PM
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt

> Hi Tigran-
> 
> Opened https://github.com/chucklever/i-d-rpc-tls/issues/8 to track
> this.
> 
>> On Feb 15, 2020, at 7:47 AM, Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
>> 
>> Hi Chuck,
>> 
>> Yesterday we were fixing in our (not nfs related) code a TLS bug.
>> The issue was that we were redirecting clients to another endpoint
>> by an IP address. As a result, the client side server certificate
>> validation was failing, as subject alternative name didn't match
>> endpoint client was connecting to - subject and and alternative
>> name were dns names.
>> 
>> This situation is very similar to what we will ger with pNFS, where
>> data servers are offered as combination of netid and uaddr.
> 
> I'm thinking fs_locations too, but agreed.
> 
> 
>> Though
>> there is no direct connection between your spec and pNFS over TLS,
>> you probably should have a paragraph describing TLS and certificate
>> handling when server address presented as netid+uaddr.
> 
> I was wondering if this should be in a later NFS-related document,
> but both netid and uaddr are RPC-layer data types.
> 
> Would you propose some text to get us started? Describe how you
> addressed the bug, for example. What do you think are the
> interoperability concerns?
> 
> 
>> Regards,
>>   Tigran.
>> 
>> 
>> ----- Original Message -----
>>> From: "Chuck Lever" <chuck.lever@oracle.com>
>>> To: "NFSv4" <nfsv4@ietf.org>
>>> Sent: Monday, February 3, 2020 4:44:11 PM
>>> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt
>> 
>>>> On Feb 3, 2020, at 10:41 AM, internet-drafts@ietf.org wrote:
>>>> 
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the Network File System Version 4 WG of the IETF.
>>>> 
>>>>       Title           : Towards Remote Procedure Call Encryption By Default
>>>>       Authors         : Trond Myklebust
>>>>                         Charles Lever
>>>> 	Filename        : draft-ietf-nfsv4-rpc-tls-06.txt
>>>> 	Pages           : 21
>>>> 	Date            : 2020-02-03
>>>> 
>>>> Abstract:
>>>>  This document describes a mechanism that, through the use of
>>>>  opportunistic Transport Layer Security (TLS), enables encryption of
>>>>  in-transit Remote Procedure Call (RPC) transactions while
>>>>  interoperating with ONC RPC implementations that do not support this
>>>>  mechanism.  This document updates RFC 5531.
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
>>>> 
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls-06
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-06
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpc-tls-06
>>>> 
>>>> 
>>>> Please note that it may take a couple of minutes from the time of submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>> 
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> I heard no objection to the changes proposed last week.
>>> This revision addresses recent comments from Rick Macklem.
>>> 
>>> 
>>> --
>>> Chuck Lever
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever