Subject: [Netconf] way forward on netconf EOM

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Nov 2010 14:38:02 -0800

Hi,

Step 1: Problem
It is clear that the WG agrees there is a problem to be solved,
which is that the current EOM is permitted in NETCONF messages
even though it is used as the SSH and TLS EOM marker.

Step 2: Timeframe
There seems to be agreement that if we have a good solution now
then we should fix this now.  I can imagine the IESG sending the
document back to the WG until a solution is found.  We cannot
decide a security hole is not important because we don't agree
on a solution.  So we have to agree on a solution now.

Step 3: Process
I can imagine the IESG asking the Security Directorate if the NETCONF
message framing problem is fixed or not.  We know that changing one
magic pattern for another one does not fix the problem.
I really think getting help for the Security Directorate (or just
listen to Wes ;-) is a good idea.

Step 4: Solution
It is true that 0x4 is better than ]]>]]>.
It makes it harder than before to inject data, but still relies
on the client implementing the content layer validation correctly.
Consider also the availability of free test tools (e.g., yangcli)
that allow arbitrary XML to be easily injected in NETCONF packets
for testing purposes.  There is absolutely so safe magic pattern
if people write tools designed to exploit this protocol bug.
(This is why NACM is needed in addition to real framing.)

IMO, Phil's framing is the best choice from the security review POV.

Step 5: Deployment
Assuming a framing method is chosen it has to be deployed.
A flag day that breaks all existing 4741 deployments is not possible.
In order to keep supporting 4742 framing there needs to be a new subsystem
or a hack to switch framing methods after the first message chop.

I am now inclined to accept Juergen's solution.
I had thought about this before but rejected it as a hack.
It is a hack, but it saves an SSH session startup.

The key is that each chop is supposed to represent a single XML instance
document which means one top-level element.  The server is supposed to
check for extra top-level elements and reject the message if it is not
a valid XML instance document,  So it is relatively safe to expect exactly one
<hello> message followed by the old EOM, then zero or more [<rpc> new-eom] pairs.

(Of course a hacker could inject <rpc> followed by the new eom if a different
magic pattern is used for the framing solution.)

It is also OK to say that a new client SHOULD NOT begin using the session for <rpc>
until it processes the server <hello> and determines if base:1.0 or base:1.1
is being used. TCP will make the client wait if the server is not ready to
accept <rpc> messages due to some latency for the message layer to tell the transport
layer the framing to use.

If base:1.1 then new-eom is set.  If base:1.0, then old-eom is set.
No magic PIs or comments are needed.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Nov 2010 12:54:23 +0100 (CET)

> even though it is used as the SSH and TLS EOM marker.

This is one of the two problems, i.e. legal NETCONF messages can be
truncated by this transport protocol.  The other problem is the
security problem (the injection problem).

In the rest of your email, you talk about the injection problem.

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

Also note that the injection problem is a problem only when you have a
client that authenticates as some user, and then reads input from
another user, and inserts the inputted data without doing any checks.

> I am now inclined to accept Juergen's solution.

Juergen's solution to the versioning problem can be used with any of
the three "framing" solutions.  Did you mean Juergen's solution +
0x04?

[...]

> No magic PIs or comments are needed.

So you want to tie the base protocol version to the transport version?
I would prefer a separate indication (PI, comment, capability, ...).

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 15 Nov 2010 08:41:38 -0500

>It should be clear by now that Phil's solution does not solve the

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

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Nov 2010 15:39:16 +0100 (CET)

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

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Nov 2010 07:46:53 -0800

On 11/15/2010 06:39 AM, Martin Bjorklund wrote:
> Phil Shafer<[email-masked]>  wrote:
>> Martin Bjorklund writes:

This is only addressed by NACM.
If the framing relies on NETCONF content it is not real framing.  Period.
Or should I say, ]]>]]>.

There is no need whatsoever to mix-and-match framing with protocol ersions.
4741bis MUST use the new framing.  4741 MUST use the old framing.
This applies to SSH and TLS.

IMO, we should use Phil's framing proposal + Juergen's base:1.1 check
to change the framing after the hello.

Also, 4741bis should be changed so any loss of framing causes the
session to be dropped.  The server MUST send operation-failed and then MUST
drop the session.

Andy

---

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

> 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

---

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

> then could decide what to use.

Having two ways to do this is IMHO a bad idea; this allows
combinations that are not really fun to have.

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