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

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

Dear Sean,

thank you for your support.

The RFC Editor's note is on the way.

Cheers, 
Mehmet 


> -----Original Message-----
> From: ext Sean Turner [mailto:[e-mail]]
> Sent: Wednesday, March 02, 2011 10:45 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
> 
> 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
> >>>
> >