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

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 2 Mar 2011 15:38:50 +0100

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.

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 to add explicitly that the session is closed if an
invalid-chunk size or 
invalid chunk-size value is received. 

NEW:
   "If the chunk-size and the chunk-size value respectively are invalid
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 
> 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?

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 should use "required" or
something equal.

OLD: 
   "So, NETCONF should only be used over communications channels that
provide 
    strong encryption for data privacy."

NEW:
   "So, NETCONF requires communications channels that provide strong
encryption 
   for data privacy."

Would this be sufficient for you to clear your DISCUSS?

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

---

From: Sean Turner <[email-masked]>
Date: Wed, 02 Mar 2011 09:55:34 -0500

Mehmet,

Responses inline.

spt

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

>>  (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
>
> channel.”
> I think it is OK toaddexplicitlythat the session is closed if an
> invalid-chunk size or
>
> “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 would work for me.

> “ensure they're not vulnerable to buffer overruns”.
>

Yes.

> 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

> “All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a
>
> session.”
> *******Discuss (2011-03-01)*Picture (Device Independent Bitmap)
>
> (Same thing for what to do if chunk-size does contain leading zeros, or is
>
> 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
>
> #2) There's a mix of upper and lower case in the security considerations was
>
> confidentiality. Maybe "SHOULD" is better there? Also why isn't this a MUST?
>
> *******Comment (2011-03-01)*Picture (Device Independent Bitmap)
>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 2 Mar 2011 21:21:33 +0100

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:[email-masked]]
> Sent: Wednesday, March 02, 2011 3:56 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: The IESG; ext Romascanu, Dan (Dan); [email-masked]; draft-
> [email-masked]; draft-ietf-netconf-
> [email-masked]; Netconf
> Subject: Re: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-
> rfc4742bis-07
> 
> Mehmet,
> 
> Responses inline.
> 
> spt
> 
> > "If the chunk-sizeandthe chunk-size valuerespectively areinvalid or
> an error
> >
> > downgrade the requirement in 4741bis and shoulduse"required"
> > orsomethingequal.
> >
> > OLD:
> >
> > "So, NETCONF should only be used overcommunications channels that
> provide
> >
> > "So, NETCONFrequirescommunications channels that provide strong
> encryption
> >
> > for data privacy."
> >
> > "All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If
a
> > #2) Sec 4.2: Would any XML decoding error cause termination as
stated
> at

---

From: Sean Turner <[email-masked]>
Date: Wed, 02 Mar 2011 16:44:38 -0500

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:
>>> overall<rpc>
>>> with NETCONF message size (which is the size of the<rpc>  element).
>> But
>>> I agree
>>>
>>> peer receives an<rpc>  message that is not well-formed XML or not
>>>
>>> to be able to handle the overall<rpc>  element that's 2^32+8 bytes
>> long?
>>> Maybe
>>>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 2 Mar 2011 23:04:23 +0100

Dear Sean,

thank you for your support.

The RFC Editor's note is on the way.

Cheers, 
Mehmet 

> Sent: Wednesday, March 02, 2011 10:45 PM
> >>>>   #1) You state a max for chunk-size in 4.2 but I think you need
a
> >> MUST
> >>>>   That may not be quite the same as saying "MUST terminate" at
the
> >> very
> >>>>   is allowed) and then another chunk that's 10 bytes, but both
are
> >>>>   "</rpc>" then is a server or client expected to be able to
> handle
> >> the
> >>> overall<rpc>
> >>>
> >>>>   Maybe just add text that implementations SHOULD include an
> upper-
> >> limit
> >>> that ensures
> >>>
> >>> I think 4742bis document, as the NETCONF transport layer,
shouldn't
> >> have
> >>>>   this purposely done? Specifically, it says "should" only be
used
> >> with
> >>>>   Sec 4.2: Would any XML decoding error cause termination as
> stated
> >> at
> >>>
If
> >>> that's 2^32-2 long (which is allowed) and then another chunk
that's
> >> 10

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Mar 2011 11:09:50 +0000

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.

>>>> 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
>>
>>>>>   #1) You state a max for chunk-size in 4.2 but I think you need a
>>>>
>>> MUST
>>>
>>>> for what
>>>>
>>>>>   (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
>>>
>>>
>>> That would work for me.
>>>
>>>>>   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
>>>>
>>>>>   "</rpc>" then is a server or client expected to be able to handle
>>>>
>>> the
>>>
>>>> overall<rpc>
>>>>
>>>>>   Maybe just add text that implementations SHOULD include an upper-
>>>>
>>> limit
>>>
>>>> that ensures
>>>>
>>>> I think 4742bis document, as the NETCONF transport layer, shouldn't
>>>
>>> have
>>>
>>>> to handle
>>>>
>>>> that the document should state that the implementation needs to
>>>
>> check
>>
>>>> for it to
>>>>
>>>>>   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
>>>>
>>>>>   #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the
>>>>
>> first
>>
>>>> paragraph be
>>>>
>>>>>   a "MUST"?
>>>>
>>>>
>>>>>   Sec 4.2: Would any XML decoding error cause termination as stated
>>>>
>>> at
>>>
>>>>
>>>> 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
>>>>
>>>> #1) You state a max for chunk-size in 4.2 but I think you need a
>>>
>> MUST
>>
>>>> for what
>>>>
>>>> idea is to get implementers not to leave buffer overrun
>>>
>>> vulnerabilities
>>>
>>>> around.
>>>>
>>>> the very end of 4.2 if someone didn't consider the chunk-size part
>>>
>> of
>>
>>> the
>>>
>>>>
>>>> that's 2^32-2 long (which is allowed) and then another chunk that's
>>>
>>> 10
>>>
>>>> bytes,
>>>>
>>>> the 2nd chunk contains the closing "</rpc>" then is a server or
>>>
>>> client
>>>
>>>> expected
>>>>
>>>> just add text that implementations SHOULD include an upper-limit
>>>
>> that
>>
>>>> ensures
>>>>
>>>> this purposely done? Specifically, it says "should" only be used
>>>
>> with
>>
>>>>

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