Re: [nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-rfc5666bis-10: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

Just one thing below...

On 02/03/17 20:06, Chuck Lever wrote:
> 
>> On Feb 28, 2017, at 3:49 PM, Stephen Farrell <[e-mail]> wrote:
>>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-nfsv4-rfc5666bis-10: 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-rfc5666bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> - 3.4.5: Can a requester DoS a responder by asking the
>> latter to read giga- or tera-bytes?
> 
> A storage server would be prepared to respond appropriately
> to requests for that much data in a way that manages the
> bandwidth of the connection, RNIC, and fabric.
> 
> The responder is free to reject requests with Read chunks
> of unreasonable size (RCOUS's ;-).
> 
> The transport protocol does not place a limit on chunk
> size. The Upper Layer Protocol may place a limit on the
> amount of data transferred by one RPC. That limit might
> be used as a chunk size sanity check by the transport.
> 
> 
>> And the same question
>> the other way about for 3.4.6.
> 
> In this case, the client provisions each Write chunk.
> If the server transmits more data than the client is
> prepared to receive in that chunk, the connection is
> dropped immediately.
> 
> The client would have to reconnect to send more RPCs.
> If any of them have Write chunks, and the server
> overruns one or more of them, the client would drop
> the connection again.
> 
> Other connections should be unaffected, depending on
> the RNIC implementation.
> 
> So, a rogue server could prevent forward progress on
> a connection.
> 
> 
>> - 4.4.1: not having access to memory allocated for
>> "cancelled RPCs" also seems like a potential DoS that ought
>> be noted. Is it?
> 
> IMO signaled RPCs would not prevent forward progress
> of other RPCs on each new connection, though it might
> slow them down.
> 
> 
>> - General: I was surprised see no mention of DoS. Is that
>> covered in some reference? Even if so, I'd have expected
>> some discussion of DoS attacks and mitigations.
> 
> As far as I am aware DoS is not covered in any of this
> document's references, and was not covered in the
> original text of RFC 5666.
> 
> I am open to suggestion about the addition of such
> discussion, as I'm sure my co-authors are.

So my suggestion is: Yes, please do think about DoS
and then add what you conclude is the right text:-)

That may involve you reaching out to some folks who
know about DoS and about nfs, but I'm sure such folks
do exist and you probably know 'em already or can
find 'em. (I'm not such a person btw.)

Cheers,
S.

> 
> 
>> - 8.2.1: "Protection below the RDMA layer is a more
>> appropriate security mechanism for RDMA transports in
>> performance-sensitive deployments." I think that's a bit
>> over-stated. A deployment could be performance-sensitive
>> but yet prioritise application layer crypto for various
>> reasons. As you're really just talking about trade-offs,
>> and I think that's sufficiently explained already, I figure
>> you could omit that sentence.
> 
> That sentence could be considered implementation
> advice. If my co-authors agree, I can remove it in the
> next revision.
> 
> 
> --
> Chuck Lever
> 
> 
>