Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt

[Andy Bierman <[e-mail]>]

I agree with this solution proposal from Juergen.


Andy


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, October 06, 2010 3:46 PM
To: Ladislav Lhotka
Cc: Netconf
Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt

On Wed, Oct 06, 2010 at 08:37:51PM +0200, Ladislav Lhotka wrote:
> On St, 2010-10-06 at 12:35 +0200, Juergen Schoenwaelder wrote:
> > On Wed, Oct 06, 2010 at 11:42:03AM +0200, Ladislav Lhotka wrote:
> > > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder <[e-mail]> wrote:
> > > > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> > > > > > > Section 9. Security Considerations
> > > > > > >
> > > > > > > I would suggest to add a few sentences for the EOM handling
> > > > > > > and the possible thread concerning section 3. It would be
> > > > > > > interesting to recommend a possible reaction if this happens
> > > > > > > frequently, e.g. to drop the NETCONF session.
> > > > > > 
> > > > > > 4741bis does not have an EOM marker - so how can we discuss it in
> > > > > > the security considerations?
> > > > > 
> > > > > EOM handling is for sure not part of NETCONF but the possible 
> > > > > thread concerning EOM handling is. I think security considerations 
> > > > > section should discuss the related security thread, as we did on 
> > > > > NETCONF ML with a long mail thread.
> > > > 
> > > > There is no EOM issue if you run NETCONF over BEEP. We should stick to
> > > > modularity and discuss things where they belong. Perhaps you want
> > > > different text than the one I currently image you want...
> > > 
> > > SSH is the *mandatory* transport, so any appearance of ']]>]]>' in the
> > > Messages, Operation or Content layer necessarily has an impact on
> > > operation and is a potential security hole. So I agree with Mehmet that
> > > 4741bis should not dismiss this issue completely. The protocol
> > > modularity has been damaged by the unfortunate EOM choice.
> > > 
> > > Apart from Security Considerations, text in Sec. 3 should be changed as
> > > follows:
> > > 
> > > OLD
> > > 
> > >   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.
> > > 
> > > NEW
> > > 
> > >   All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and
> > >   MUST NOT contain the character sequence ']]>]]>'.
> > 
> > Still I believe it is the transport that has to deal with this. If a
> > message contains ']]>]]>', a transport that can not handle this should
> > either not accept to transport that message or have a mechanism to
> > deal with it by quoting it or whatever. Pushing this issue up to the
> > content layer just on the ground that the mandatory SSH transport is
> > not totally robust seems odd from an architectural point of view.
> 
> OK, but according to section 2.4 the mandatory transport protocol is RFC
> 4742, which does not handle the EOM issue properly. So sec. 2.4 in fact
> says that every compliant implementation MUST have that security hole.
> 

I am willing to accept an addition to the security considerations that
says that readers should consult the security considerations of the
NETCONF transports in addition to the 4741bis security considerations
section since the 4741bis security considerations only covers the base
message layer and the base operations of NETCONF. A first quick
attempt:

	This section provides security considerations for the base
	NETCONF message layer and the base operations of the NETCONF
	protocol. Security considerations for the NETCONF transports
	are provided in the transport documents and security
	considerations for the content manipulated by NETCONF can be
	found in the document defining data models.

We could add this right at the beginning of section 9 and then it
should be clear even to the causal reader that just reading section 9
of 4741bis is not sufficient to understand all security aspects of
NETCONF.

Note that this approach allows to add/fix security problems in all our
transports without causing any text in 4741bis to become obsolete or
incomplete.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf