Subject: Re: [Netconf] way forward on netconf EOM

From: "Andy Bierman" <[email-masked]>
Date: Tue, 16 Nov 2010 23:53:14 +0800

Why?
The base:1.1 is clear and unambiguous.  Netconf does not require PI processing.  We should keep it that way.

The base uri already has to be present.  There is no need for new hacks and dealing with the corner cases.  I do not want to let implementers choose the wrong framing.

----- Reply message -----
From: "Ladislav Lhotka" <[email-masked]>
Date: Tue, Nov 16, 2010 07:34
Subject: [Netconf] way forward on netconf EOM
To: "Andy Bierman" <[email-masked]>
Cc: "Martin Bjorklund" <[email-masked]>, <[email-masked]>, <[email-masked]>

On Út, 2010-11-16 at 23:28 +0800, Andy Bierman wrote:
> We do not need 2 ways to indicate the new framing. All peers would
> have to support all options.  There is no choice of eom allowed.  1.1
> means new framing.  No exceptions.

OK, then I am slightly in favor of the PI as the authoritative
indication of the new framing.

Lada

> 
> Andy
> 
> 
> ----- Reply message -----
> From: "Ladislav Lhotka" <[email-masked]>
> Date: Tue, Nov 16, 2010 02:03
> Subject: [Netconf] way forward on netconf EOM
> To: "Martin Bjorklund" <[email-masked]>, <[email-masked]>
> Cc: <[email-masked]>
> 
> 
> On Mon, 15 Nov 2010 15:39:16 +0100 (CET), Martin Bjorklund
> <[email-masked]> wrote:
> > Phil Shafer <[email-masked]> wrote:
> > > Martin Bjorklund writes:
> > > >> IMO, Phil's framing is the best choice from the security review
> POV.
> > > >It should be clear by now that Phil's solution does not solve the
> > > >injection problem.
> > > 
> > > I think he's referring to my original suggestion of a real, honest
> > > to goodness framing mechanism.
> > > 
> > > http://www.ietf.org/mail-archive/web/netconf/current/msg06216.html
> > > http://www.ietf.org/mail-archive/web/netconf/current/msg06219.html
> > 
> > I know.  And I referred to:
> > 
> > http://www.ietf.org/mail-archive/web/netconf/current/msg06556.html
> > 
> > If the attacker can insert something that modifies the current
> > edit-config so that e.g. the password for an admin user is changed,
> > then the attacker can do anything.
> 
> True, but this is no more an issue for the transport layer. I would
> support Juergen's switchover hack with Phil's framing, I only think it
> would be better to signal the new framing to the transport layer via a
> PI. What if we had both - the base:1.1 AND the PIs? An implementation
> then could decide what to use.
> 
> I guess this would be the best outcome of this whole affair,
> especially
> if it could be fixed now.
> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > Netconf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> -- 
> Ladislav Lhotka, CESNET
> PGP Key ID: E74E8C0C
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> 

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Nov 2010 17:03:36 +0100

On Út, 2010-11-16 at 23:53 +0800, Andy Bierman wrote:
> The base uri already has to be present.  There is no need for new
> hacks and dealing with the corner cases.  I do not want to let
> implementers choose the wrong framing.

The parsing of hello is done by the message layer for which this will be
a special case to signal the version to the SSH transport - it is not
needed for any other transport. It also means the message layer cannot
be transport-agnostic and use a generic transport layer API.

IMO, SSH transport should eat its own dog food.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Nov 2010 17:11:57 +0100

> be transport-agnostic and use a generic transport layer API.

Since there is no specific transport layer API, any arguments about
how such an API looks are somewhat amusing.
 
> IMO, SSH transport should eat its own dog food.

Strictly speaking, the parsing of the whole XML document is done by
the message layer - including any magic PIs. So the layering argument
is not a strong one anyway. That said, I do not care too much as long
as we do not need new subsystems or port numbers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Phil Shafer <[email-masked]>
Date: Tue, 16 Nov 2010 11:10:49 -0500

>IMO, SSH transport should eat its own dog food.

One goal is that the transport handling layer should not have
to parse XML for things to work right.  This is for both framing
of contents and for detection of the framing system.  In Juergen's
proposal, the NETCONF system detects the ability to use the new
framing mechanism and signals (via function call/IPC/whatever) that
the connection is now using the new mechanism.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Nov 2010 17:43:55 +0100

> how such an API looks are somewhat amusing.

For any implementation supporting multiple transports, such an
(internal) API seems quite logical. There is no such implementation so
far, right?

> as we do not need new subsystems or port numbers.

Martin proposed a procedure for "poor man's" parsing of the hello front
matter, which is supposed to be performed by the SSH transport layer.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C