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

[Sean Turner <[e-mail]>]

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).

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
>>>
>