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

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

I agree and can go with this proposal too.

(You don't need a calendar mark ;)

Cheers,
Mehmet


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of ext Andy Bierman
> Sent: Thursday, October 07, 2010 1:13 AM
> To: Juergen Schoenwaelder; LadislavLhotka
> Cc: Netconf
> Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended
for:draft-
> ietf-netconf-4741bis-04.txt
> 
> 
> 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
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf