Re: [Netconf] Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07

[Alexey Melnikov <[e-mail]>]

Sean Turner wrote:

> Mehemt,
>
> Normally, IESG members hold their discusses until either a) a new 
> draft is posted that incorporates the agreed changes or b) an RFC 
> editor's note is included in the IESG evaluation tab (by your AD).  If 
> either of these happen, then I'll clear.  It's most a double check 
> that you incorporate what you said you would (not picking on you we do 
> this to just about everybody).

+1. (Not speaking specifically of your case) And I've seen multiple 
occasions when some changes were agreed on and then not applied.

> spt
>
> On 3/2/11 3:21 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:
>
>> Dear Sean,
>>
>> I interpreted your answer that your DISCUSS have been addressed.
>> Is this correct?
>>
>> If yes, can you please clear your DISCUSS.
>> If no, what can I do more?
>>
>> Thank you.
>>
>> Cheers,
>> Mehmet
>>
>>
>>> -----Original Message-----
>>> From: ext Sean Turner [mailto:[e-mail]]
>>> Sent: Wednesday, March 02, 2011 3:56 PM
>>> To: Ersue, Mehmet (NSN - DE/Munich)
>>> Cc: The IESG; ext Romascanu, Dan (Dan); [e-mail]; draft-
>>> [e-mail]; draft-ietf-netconf-
>>> [e-mail]; Netconf
>>> Subject: Re: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-
>>> rfc4742bis-07
>>>
>>> Mehmet,
>>>
>>> Responses inline.
>>>
>>> spt
>>>
>>> On 3/2/11 9:38 AM, Ersue, Mehmet (NSN - DE/Munich) wrote:
>>>
>>>> Hi Sean,
>>>>
>>>> I detected your DISCUSS in the draft tracker (see below). However,
>>>>
>>>> we, the WG chairs, did not get any alarm email. We were wondering
>>>>
>>>> whether sending an alarm should be the default case for the IESG
>>>
>>> tool.
>>>
>>> I think the problem was on my end.  After we enter positions we can
>>
>> hit
>>
>>> save or save and send.  I guess I only hit save.
>>>
>>>> DISCUSS #1:
>>>>
>>>>>   #1) You state a max for chunk-size in 4.2 but I think you need a
>>>>
>>> MUST
>>>
>>>> for what
>>>>
>>>>>   to do if a client or server sends something out-of-range (<=0 or
>>>>
>>>>   >2^32-1).
>>>>
>>>>>   The idea is to get implementers not to leave buffer overrun
>>>>
>>>> vulnerabilities around.
>>>>
>>>>>   (Same thing for what to do if chunk-size does contain leading
>>>>
>>> zeros, or is
>>>
>>>>
>>>>>   negative perhaps.)
>>>>
>>>>
>>>> Concerning the errors during the decoding process, which for sure
>>>
>>> includes
>>>
>>>>
>>>> the case "chunk-size out-of-range", the draft says:
>>>>
>>>> OLD:
>>>>
>>>> "If an error occurs during the decoding process, the peer MUST
>>>>
>>>> terminate the NETCONF session by closing the corresponding SSH
>>>>
>>>> channel."
>>>>
>>>> I think it is OK toaddexplicitlythat the session is closed if an
>>>> invalid-chunk size or
>>>>
>>>> invalid chunk-size value is received.
>>>>
>>>> NEW:
>>>>
>>>> "If the chunk-sizeandthe chunk-size valuerespectively areinvalid or
>>>
>>> an error
>>>
>>>>
>>>> occurs during the decoding process, the peer MUST terminate the
>>>
>>> NETCONF
>>>
>>>>
>>>> session by closing the corresponding SSH channel."
>>>>
>>>>>   That may not be quite the same as saying "MUST terminate" at the
>>>>
>>> very
>>>
>>>> end of
>>>
>>>
>>> That would work for me.
>>>
>>>>>   4.2 if someone didn't consider the chunk-size part of the
>>>>
>>>>
>>>>>   decoding process.
>>>>
>>>>
>>>>>   Lastly, as a bit of a mad corner-case, if I send a chunk that's
>>>>
>>> 2^32-2
>>>
>>>> long (which
>>>>
>>>>>   is allowed) and then another chunk that's 10 bytes, but both are
>>>>
>>> the
>>>
>>>> same XML
>>>>
>>>>>   element, i.e. the "<rpc..." is in the 1st chunk and the 2nd chunk
>>>>
>>>> contains the closing
>>>>
>>>>>   "</rpc>" then is a server or client expected to be able to handle
>>>>
>>> the
>>>
>>>> overall<rpc>
>>>>
>>>>>   element that's 2^32+8 bytes long?
>>>>
>>>>
>>>>>   Maybe just add text that implementations SHOULD include an upper-
>>>>
>>> limit
>>>
>>>> that ensures
>>>>
>>>>>   they're not vulnerable to buffer overruns or something.
>>>>
>>>>
>>>> I think 4742bis document, as the NETCONF transport layer, shouldn't
>>>
>>> have
>>>
>>>> to handle
>>>>
>>>> with NETCONF message size (which is the size of the<rpc>  element).
>>>
>>> But
>>>
>>>> I agree
>>>>
>>>> that the document should state that the implementation needs to
>>>
>> check
>>
>>>> for it to
>>>>
>>>> "ensure they're not vulnerable to buffer overruns".
>>>>
>>>> (including the text for the first part above)
>>>>
>>>> OLD:
>>>>
>>>> If an error occurs during the decoding process, the peer MUST
>>>>
>>>> terminate the NETCONF session by closing the corresponding SSH
>>>>
>>>> channel.
>>>>
>>>> NEW:
>>>>
>>>> "If the chunk-size or the chunk-size value is invalid or an error
>>>>
>>>> occurs during the decoding process, the peer MUST terminate the
>>>>
>>>> NETCONF session by closing the corresponding SSH channel.
>>>>
>>>> Implementations MUST ensure they are not vulnerable for a buffer
>>>>
>>>> overrun."
>>>>
>>>> Would this be sufficient for you to clear your DISCUSS?
>>>
>>>
>>> Yes.
>>>
>>>> DISCUSS #2:
>>>>
>>>>>   #2) There's a mix of upper and lower case in the security
>>>>
>>>> considerations was
>>>>
>>>>>   this purposely done? Specifically, it says "should" only be used
>>>>
>>> with
>>>
>>>>
>>>>>   confidentiality. Maybe "SHOULD" is better there? Also why isn't
>>>>
>>> this a
>>>
>>>> MUST?
>>>>
>>>> This is actually just an explanation about the requirement for
>>>
>>> NETCONF.
>>>
>>>> The hard
>>>>
>>>> requirement statement is in 4741bis. However, you are right 4742bis
>>>> shouldn't
>>>>
>>>> downgrade the requirement in 4741bis and shoulduse"required"
>>>> orsomethingequal.
>>>>
>>>> OLD:
>>>>
>>>> "So, NETCONF should only be used overcommunications channels that
>>>
>>> provide
>>>
>>>>
>>>> strong encryption for data privacy."
>>>>
>>>> NEW:
>>>>
>>>> "So, NETCONFrequirescommunications channels that provide strong
>>>
>>> encryption
>>>
>>>>
>>>> for data privacy."
>>>>
>>>> Would this be sufficient for youto clear your DISCUSS?
>>>
>>>
>>> Yes
>>>
>>>> Comment #1:
>>>>
>>>>>   #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the
>>>>
>> first
>>
>>>> paragraph be
>>>>
>>>>>   a "MUST"?
>>>>
>>>>
>>>> This is in the area of and a MUST statement in 4741bis.
>>>>
>>>> Comment #2)
>>>>
>>>>>   Sec 4.2: Would any XML decoding error cause termination as stated
>>>>
>>> at
>>>
>>>>
>>>>>   the end of 4.2? E.g. some unknown xmlns value or something?
>>>>
>>>>
>>>> Interpreting the XML document content is not done in the transport
>>>
>>> layer
>>>
>>>> (4742bis).
>>>>
>>>> 4741bis deals with this. There are a number of different error
>>>
>>> responses
>>>
>>>> if the XML
>>>>
>>>> message can't be understood or the XML message is not well-formed.
>>>>
>>>> takes care of it.
>>>>
>>>> 4741bis says:
>>>>
>>>> "All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If
>>>
>> a
>>
>>>>
>>>> peer receives an<rpc>  message that is not well-formed XML or not
>>>>
>>>> encoded in UTF-8, it SHOULD reply with a "malformed-message" error.
>>>>
>>>> If a reply cannot be sent for any reason, the server MUST close the
>>>>
>>>> session."
>>>>
>>>> Regards,
>>>>
>>>> Mehmet
>>>>
>>>> (document shepherd)
>>>>
>>>> ------------------
>>>>
>>>> *******Discuss (2011-03-01)*Picture (Device Independent Bitmap)
>>>>
>>>> #1) You state a max for chunk-size in 4.2 but I think you need a
>>>
>> MUST
>>
>>>> for what
>>>>
>>>> to do if a client or server sends something out-of-range (<=0 or
>>>>   >2^32-1). The
>>>>
>>>> idea is to get implementers not to leave buffer overrun
>>>
>>> vulnerabilities
>>>
>>>> around.
>>>>
>>>> (Same thing for what to do if chunk-size does contain leading zeros,
>>>
>>> or is
>>>
>>>>
>>>> negative perhaps.) That may not be quite the same as saying "MUST
>>>> terminate" at
>>>>
>>>> the very end of 4.2 if someone didn't consider the chunk-size part
>>>
>> of
>>
>>> the
>>>
>>>>
>>>> decoding process. Lastly, as a bit of a mad corner-case, if I send a
>>>
>>> chunk
>>>
>>>>
>>>> that's 2^32-2 long (which is allowed) and then another chunk that's
>>>
>>> 10
>>>
>>>> bytes,
>>>>
>>>> but both are the same XML element, i.e. the "<rpc..." is in the 1st
>>>> chunk and
>>>>
>>>> the 2nd chunk contains the closing "</rpc>" then is a server or
>>>
>>> client
>>>
>>>> expected
>>>>
>>>> to be able to handle the overall<rpc>  element that's 2^32+8 bytes
>>>
>>> long?
>>>
>>>> Maybe
>>>>
>>>> just add text that implementations SHOULD include an upper-limit
>>>
>> that
>>
>>>> ensures
>>>>
>>>> they're not vulnerable to buffer overruns or something.
>>>>
>>>> #2) There's a mix of upper and lower case in the security
>>>
>>> considerations was
>>>
>>>>
>>>> this purposely done? Specifically, it says "should" only be used
>>>
>> with
>>
>>>>
>>>> confidentiality. Maybe "SHOULD" is better there? Also why isn't this
>>>
>>> a MUST?
>>>
>>>>
>>>> *******Comment (2011-03-01)*Picture (Device Independent Bitmap)
>>>>
>>>> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first
>>>> paragraph be
>>>>
>>>> a "MUST"?
>>>>
>>>> #2) Sec 4.2: Would any XML decoding error cause termination as
>>>
>> stated
>>
>>> at
>>>
>>>>
>>>> the end of 4.2? E.g. some unknown xmlns value or something?
>>>>
>>>> Cheers,
>>>> Mehmet
>>>>
>>


-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address