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

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

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