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

[Juergen Schoenwaelder <[e-mail]>]

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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>