Subject: [Netconf] NETCONF message integrity

From: "David B Harrington" <[email-masked]>
Date: Wed, 18 Feb 2009 12:37:28 -0500

Hi, 

This discussion went to the "backroom" for various reasons. I have
chosen to bring this back to the netconf mailing list, since one of
the chairs questioned why it was backroom, and there are a few people
who I think should see the discussion, such as our Security Technical
Advisor.

">>" is from Bert, and ">" is from Juergen.
 
> > - the EOM issue is NOT specific to netconf over TLS
> 
> Not sure what your intention behind this statement is. Here is a
> statement I can easily agree with: The issue is specific to NETCONF
> over TLS and NETCONF over SSH and any other future transports that
> uses the EOM marker.

I checked the 4 netconf RFCs. Only the SSH document seems to use this
delimiter. Bert, do you think this is not specific to transports?

Transports that use other framing mechanisms to delimit messages do
not have a problem when the EOM marker occurs within the XML. Using
the EOM for transport framing means the transport "model" needs to be
concerned whether the XML contains the EOM anywhere other than end of
message. A transport should not need to worry about what is in the
message; the netconf message should simply be an opaque PDU that gets
sent via the transport. By using the EOM for transport message
framing, we introduce potential problems to the transport.

That issue can be solved quite simply by adding a framing mechanism to
any transport that currently uses the EOM marker, and not using it in
future transports. Syslog/tls had a similar problem, and we had the
transport model add a bytecount in the TLS payload. A syslog/tls
sender adds a bytecount; the syslog/tls receiver removes the
bytecount; syslog never sees the bytecount; the other transports never
see the bytecount. The transport never needs to know what the PDU
contains.

If you do not use a different message framing solution, then the
Security Considerations should discuss the potential impact of legal
XML PDUs carrying a transport framing marker in its content. Can this
cause messages to be discarded, since the EOM will cause messages to
be seen as non-well-formed? Can deliberately inserting an EOM marker
be used to create a DoS attack?

> 
> > - the message integrety problem is NOT only a EOM issue
> 
> Correct. But the EOM marker adds to it significantly and this is why
I
> believe it needs to be discussed in the security considerations.
>
> > - we (netconf WG) may need (or want) to investigate the complete
> >   message intregrity (and maybe that requires us to do something
> >   about access control as well)  and see what sort of 
> solution we can
> >   find for that problem

This thread has somehow conflated the unreliable EOM marker with
message integrity checking and access control. 

Transport framing does not solve the message integrity issue. For that
you need a security protocol that provides message integrity. I think
SSH and TLS and BEEP and SOAP mitigate your message integrity threats
already (assuming operators do not turn the integrity checking off). 

Neither framing nor message integrity checking solve the access
control issue. Andy's recent messages suggest that some people are
making bad assumptions that it does somehow. It does not. For that you
need an application level solution. That is a different problem than
on-the-wire transport framing and message integrity checking.

> >
> > As a result, I propose we do NOT try to solve the EOM issue in the

> > netconf-over-tls document, but let that document go to RFC instead
> > of holding it hostage to a much wider problem we seem to have.

The problem only exists in the Netconf over SSH and Netconf over TLS
documents. It is not a netconf-wide problem. It is transport-specific.

I recommend fixing the transport framing problem in netconf/tls now,
before it goes to Proposed Standard. I know of NO implementations of
netconf over TLS. Fixing it in that document now resolves it for that
transport, and impacts nobody. If we fix it now, we will keep the EOM
problem contained to only 1 of the 4 standards-track transports.

So the only "problem" transport is netconf over SSH, because that has
the EOM problem, and that has been implemented. I think the byte-count
fix should be easy to implement, although it is not backwards
compatible. I am not sure whether adding a byetcount+sp between
netconf messages would break existing netconf/SSH implementations.

> 
> I agree with that as long as we spell out the issues to make sure
> implementors understand that they MUST make sure the EOM is not part
> of a message they generate.

As long as the ']]>]]>' is used for framing, there is potential for
abuse that might enable security violations. If we continue to use it
for netconf/TLS, then the Security Considerations should spell out the
issues.

dbh

> 
> /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: Badra <[email-masked]>
Date: Wed, 18 Feb 2009 19:50:52 +0100

Dear David,

I have a short question

I don't well understand your comparison between Netconf and Syslog regarding
the bytecount. Netconf hasn't message length in its message.

Suppose that this bytecount appear in a Netconf message (XML element, XML
comment, or PIs), what will happen? We will not have the same special
sequence case? Syslog/tls may rely on the message length to avoid that but
not netconf/tls.

Best regards,
Badra

On Wed, Feb 18, 2009 at 6:37 PM, David B Harrington <
[email-masked]> wrote:

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Feb 2009 11:02:50 -0800

> Hi, 

Since I started the backroom thread, I'll throw in my 2 (OK, 6) pennies.

  1) the transport message framing does not have to be the
     same.  This seems obvious, but there have been
     some comments about the TLS framing must match the SSH framing.
     Why?  The message framing is never seen by the 'NETCONF layer'.

  2) Until there is a standard access control model for NETCONF,
     there will be no solution for injected content that the
     original application is not 'expected' to send.

  3) Relying on the 'fact' that a particular application
     only sends <get> or <foo>, but never <reboot>, is no
     security at all in the age of openSource code.

  4) Transport layer message integrity does not help at all if
     the application is full of holes.

  5) It is really useful to have the EOM marker in SSH
     because the agent code is much faster and simpler.
     The EOM marker helps implement simple database integrity,
     by preventing database instrumentation from blocking
     part way through an <edit-config>, waiting for the
     rest of the PDU.

  6) The SSH EOM framing mechanism should only be changed
     if a real solution is found.  An incompatible protocol
     change for a solution that is only 'less broken' than
     the current solution is not good enough.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Feb 2009 21:33:24 +0100 (CET)

Hi,

> netconf messages would break existing netconf/SSH implementations.

Adding a simple bytecount forces implementations to buffer.  So you
need something like chunked encoding.  And yes, adding this to the SSH
transport will break existing NETCONF/SSH implementations.

With the current SSH transport, you can ssh to the box and paste XML
files and receive XML; this will no longer be possible.  You will need
a NETCONF-specific transport application even for this simple task.

>     the current solution is not good enough.

/martin

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Thu, 19 Feb 2009 06:20:34 +0800

Sorry for being obtuse, but, how does the bytecount protect us ?
Some of the previous examples showing how to break the >]]>]]> apply
equally with a byte count.

[count]blahblahblahblah %s blahblahblah

can't I just insert for %s
blahblahblah[newcount]myblahmyblahmyblah

so I can still insert extra messages in the datastream if I wanted to.

James.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Bjorklund
> Sent: Thursday, February 19, 2009 7:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] NETCONF message integrity
> 
> Hi,
> 
> Adding a simple bytecount forces implementations to buffer.  
> So you need something like chunked encoding.  And yes, adding 
> this to the SSH transport will break existing NETCONF/SSH 
> implementations.
> 
> With the current SSH transport, you can ssh to the box and 
> paste XML files and receive XML; this will no longer be 
> possible.  You will need a NETCONF-specific transport 
> application even for this simple task.
>

---

From: Badra <[email-masked]>
Date: Wed, 18 Feb 2009 23:31:38 +0100

This is not related to the transport protocols, all transport protocols. And
it out out of scope of the transport layer. And the bytecounter doesn't
protect us, it only help to delimit the messages.

Best regards
Badr
On Wed, Feb 18, 2009 at 11:20 PM, James Balestriere (jbalestr) <

-- 
Badra

---

From: Per Hedeland <[email-masked]>
Date: Wed, 18 Feb 2009 23:44:50 +0100

> a NETCONF-specific transport application even for this simple task.

All true (of course). But... - I think David's message was useful in
making it very clear that this is all a transport issue. As far as I
know, there are basically only two ways for a "content-agnostic"
transport to implement framing - either a length at the front of the
frame or an EOM at the end. Chunking as mentioned by Martin is basically
an enhancement of "length at the front".

When using EOM, you *might* be able to choose one that can never appear
in the content - it was thought that this had been achieved for
NETCONF/SSH, but it turned out to be wrong. In the general case however,
this type of framing works by doing (reversible) escaping of the EOM
whenever it happens to appear in the content, e.g. dot-stuffing for
SMTP.

Isn't the solution simply to apply this standard technique here? I.e.
the SSH transport for NETCONF (which is the entity adding the EOM on
transmission and removing it on reception) must modify the EOM when it
appears in content about to be transmitted, and reverse that
modification in content that is received. It doesn't need to do any XML
parsing for this, far less know in which XML constructs the EOM can
appear.

To be concrete it could look like this (trying to follow the SMTP model
in the hope of not getting this wrong...):

1. Transmission of PDU:

a) Any occurrence of the sequence "]]>]]" is rewritten to "]]>]]]".

b) The sequence "]]>]]>" is appended to the PDU.

2. Reception of PDU:

a) The sequence "]]>]]>" indicates the end of the PDU.

b) Any occurrence of the sequence "]]>]]]" is rewritten to "]]>]]".

This is certainly not backwards-compatible either, but it's only
non-backwards-compatible in cases where the PDU actually includes the
sequence "]]>]]". And, just as you can telnet to a SMTP server and paste
in a message without concern for dot-stuffing as long as the message
doesn't have any lines with leading dots, you can ssh to a NETCONF
server and paste and receive XML (and EOMs) as long as that sequence
doesn't appear in the XML.

--Per Hedeland

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Feb 2009 00:06:16 +0100

> parsing for this, far less know in which XML constructs the EOM can

I think our problem is not that we are looking for a way to ship the
EOM marker. All we want to / have to make clear is that implementors
understand that they are responsible for checking that they really do
not ship EOMs other than where they should appear. [And I thought we
were pretty close to having concrete text for this.]

/js

---

From: Per Hedeland <[email-masked]>
Date: Thu, 19 Feb 2009 00:37:24 +0100

> were pretty close to having concrete text for this.]

OK... - so this would be a requirement/restriction on the NETCONF
protocol, but only when using some specific transports, and spelled out
in the respective transport specifications? And there will absolutely
never be a "valid" reason to have the EOM included verbatim in a PDU?

--Per Hedeland

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Feb 2009 17:18:14 -0800

> whenever it happens to appear in the content, e.g. dot-stuffing for

Don't we already have this for NETCONF?
Doesn't any decent NETCONF application look for '>' in XML content
(i.e., string nodes) and replace it with &gt; already?

If so, then it would be impossible to inject the EOM marker into
content.  The opposite peer does not need to do anything new,
since of course, the agent always looks to undo certain
character entities.  (Indeed, libxml2 replaces character entities
before delivering the packet to the parser.)

It seems to me that nothing new is required here,
since a manager needs to protect against '>' in the
content anyway.

An attacker hijacking an existing application would not be
able to inject new messages.  If they write a 'break-in' program
from scratch, then of course the '>' char is still a problem,
but in that case, gaining session authentication is 'game over'
anyways, so it doesn't matter.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Feb 2009 00:32:42 -0500

>never be a "valid" reason to have the EOM included verbatim in a PDU?

It's not a restriction on NETCONF, but a requirement on the SSH and
TLS transports to escape this EOM when used in real content (as
"]]&lt;]]&lt;").

Thanks,
 Phil

---

From: Per Hedeland <[email-masked]>
Date: Thu, 19 Feb 2009 07:43:48 +0100

> TLS transports to escape this EOM when used in real content (as

Having the transport escape the EOM was the suggestion that I made (the
details of how the escaping is implemented wasn't the significiant
part), but Juergen claimed that this was not the solution sought,
instead users of the transport should be required to make sure that the
EOM was never present in real content. This is what prompted my
questions above, which of course are completely pointless if the
transport can deal with the EOM being present (whether by escaping or
some other means that the transport user doesn't need to care about) -
i.e. there wouldn't be such a requirement at all.

Btw, I wouldn't describe escaping as a "requirement on the transport" -
it is the transport that introduces the EOM for the purpose of framing,
the requirement is simply the "be transparent" that any transport should
fulfill. If the transport can rely on its chosen EOM never being present
in content, it doesn't need escaping or any other means to deal with it
- this is the assumption that turned out to be wrong in the SSH case
(and TLS if it chooses the same EOM).

--Per Hedeland

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Feb 2009 08:28:30 +0100

On Thu, Feb 19, 2009 at 07:43:48AM +0100, Per Hedeland wrote:
 
> If the transport can rely on its chosen EOM never being present in
> content, it doesn't need escaping or any other means to deal with it

The assumption is wrong only if we assume NETCONF payload is arbitrary
XML. We have these options:

a) Define a new framing mechanism for the TLS and SSH transports so
   that arbitrary XML content works. This might require a version
   number change of NETCONF itself (since we do not have version
   numbers for the transports).

b) Restrict NETCONF content to XML that does not contain the EOM
   marker over the SSH/TLS transports. Does not require any changes to
   the protocol except clarification that EOMs are not allowed in
   NETCONF messages.

Note that b) does not preclude to do a) in the future. The third
option is:

c) Do b) for the SSH transport and a) for the TLS transport since the
   TLS transport is not yet deployed.

But then c) requires that we have a new framing proposal people can
agree with. Not sure we are there and what it takes to get there. So
for making progress, I think b) is a reasonable trade-off. When there
is work on NETCONF 2.0, the SSH/TLS framing issue can be reconsidered.

/js

---

From: Per Hedeland <[email-masked]>
Date: Thu, 19 Feb 2009 08:30:27 +0100

> (i.e., string nodes) and replace it with &gt; already?

Could be, and that would be useful info for choosing a solution to the
problem, but the standards specification obviously can't rely on what
decent applications do. It has apparently been established that the SSH
EOM can legally appear, unescaped, in valid XML content. I.e. what you
suggest is a requirement/restriction on the NETCONF protocol, when using
certain transports, to escape the EOM that has been chosen for these
transports?

> content.

Personally I find the speculation about what an attacker could or could
not do based on the existence of the problematic EOM to be mainly
distracting from the real problem, i.e. that the SSH (and apparently
TLS) transport isn't transparent.

--Per Hedeland

---

From: "tom.petch" <[email-masked]>
Date: Thu, 19 Feb 2009 18:27:32 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Per Hedeland" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 19, 2009 8:28 AM
Subject: Re: [Netconf] NETCONF message integrity

>    TLS transport is not yet deployed.

Much as I think that appeals to frameworks, architectures and the like are
overdone, I think that they have value here.  Option b) is saying make it -
security, integrity, whatever - the responsibility of the application, let the
secure transport get it wrong.  Options a) and c) say make the secure transport
provide security, allow the application a transparent secure transport to do
with as it will: for me, that is the only approach to consider.  It could be
called a Character Transfer Syntax - HDLC bit stuffing anyone? - and many of
those are available, I am easy as to which to use.

As for a) versus c), it has to be c) for the moment, and when the dust settles,
when IETF Last Call uncovers no problems, go back and reconsider Netconf over
SSH.

Tom Petch

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 20 Feb 2009 08:46:20 +0100

I also vote for escaping the delimiter sequence. HDLC bit stuffing also came to my mind.
I agree with TOM.
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Feb 2009 10:40:40 +0100

> I also vote for escaping the delimiter sequence. HDLC bit stuffing

If you mean escaping the delimiter sequence via &gt; entities, it
doesn't really help. The following two valid PIs are different and
should remain so:

<?foo ]]>]]> ?>
<?foo ]]&gt;]]&gt; ?>

I think for now the delimiter sequence should be simply banned in the
PDU content.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 23 Feb 2009 10:58:48 +0100

Hello Lada,
No what I mean is something like the HDLC bit stuffing.
Whenever you see ]]>]]> in the content, add a character to change the sequence to (e.g.) 
]]>a]]> on the transport sending end, and reverse this during reception on the receiving end.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Feb 2009 11:13:20 +0100

> ]]>a]]> on the transport sending end, and reverse this during reception on the receiving end.

Is it any different? My objection now applies to the following two PIs:

<?foo ]]>]]> ?>
<?foo ]]>a]]> ?>

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Per Hedeland <[email-masked]>
Date: Mon, 23 Feb 2009 11:23:56 +0100

On 2009-02-23 11:13, Ladislav Lhotka wrote:
> Balazs Lengyel píae v Po 23. 02. 2009 v 10:58 +0100:
>> Hello Lada,

Yes, I don't believe the scheme suggested by Balazs can work - but I do
believe the one I suggested in
http://www.ietf.org/mail-archive/web/netconf/current/msg04231.html
("bracket stuffing") can work - please try to shoot it down.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Feb 2009 11:54:25 +0100

> ("bracket stuffing") can work - please try to shoot it down.

Yes, sorry, I had holidays last week, so I could only read one screenful
from each message in my inbox. The bracket stuffing you suggested is
clever and should work. The only problem I can imagine is that some
other processing happens between adding the extra bracket and removing
it. For instance, xmllint would change the (valid) attribute value
"]]>]]]" to "]]&gt;]]]" and then the extra bracket won't get removed.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Per Hedeland <[email-masked]>
Date: Mon, 23 Feb 2009 12:53:55 +0100

On 2009-02-23 11:54, Ladislav Lhotka wrote:
> Per Hedeland píae v Po 23. 02. 2009 v 11:23 +0100:

Hm, well, it's not a very transparent transport if it applies xmllint
(or any other processing) to the PDU content... I.e. just like the EOM
addition/removal, the escaping/unescaping must be done immediately
before pushing the bits into the SSH pipe / immediately after pulling
them out - it would all be part of the transport spec.

--Per

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Feb 2009 10:12:33 -0800

> them out - it would all be part of the transport spec.

We have not been precise about the protocol layer
when discussing this attack vector (including me).
Clearly the transport layer must be limited to stuffing
and unstuffing the EOM sequence and ignoring everything else.

At the application layer, if an attacker injects the EOM marker
into some buffer that the application treats as XML content,
then it is likely to get altered by the time it gets to
the transport layer during PDU transmission.  It may not though,
so that protection is not good enough.

Before a new EOM msg is pursued, I would like to know the
details of the protocol deployment plan?  Will all 4741/4742
implementations be obsolete and ignored going forward?
Will the 4741-bis work still stick to a 'no-changes' policy?
How will the <hello> exchange be modified? Will the manager
advertise 2 'base' versions, and just use the 1 that the agent
advertises?  Gee, I wish that would work, but the manager needs
to send the EOM marker along with the <hello>, so it won't.
So how will version 2 managers talk to version 1 agents?
Try v2. It fails, then start over with v1?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 23 Feb 2009 13:34:35 -0500

>implementations be obsolete and ignored going forward?

These are reasons I'd strongly prefer to stay with the current EOM
marker.  The ssh and tls transports can be required to escape the
EOM using "&gt;", which solves the issues with attributes.  PIs are
more annoying, since they don't seem to handle character references
in the same way (see below).  For my money, I'd be happy to just
add "No PIS" to section 3 of rfc4741.  Worse case, the receiving
ssh and tls transports would be required to reverse this escaping
in order to make it transport to the netconf content being carried.

Thanks,
 Phil

-----------

% cat /tmp/foo.xml
<?xml version="1.0"?>
<?bad mumble]]>]]>mumble?>
<?badder mumble]]&gt;]]&gt;mumble?>
<?worse <?mumble?>
  <?worstest <!--yup?>

<?pig <?mum]]>]]>ble?>

<top val="]]>]]>">
  <foo val2="]]&gt;]]&gt;">
    <one>1</one>
    <two>2</two>
    <three>3</three>
    <four>4</four>
  </foo>
</top>

% xmllint /tmp/foo.xml
<?xml version="1.0"?>
<?bad mumble]]>]]>mumble?>
<?badder mumble]]&gt;]]&gt;mumble?>
<?worse <?mumble?>
<?worstest <!--yup?>
<?pig <?mum]]>]]>ble?>
<top val="]]&gt;]]&gt;">
  <foo val2="]]&gt;]]&gt;">
    <one>1</one>
    <two>2</two>
    <three>3</three>
    <four>4</four>
  </foo>
</top>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 23 Feb 2009 10:46:04 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> Sent: Monday, February 23, 2009 10:12 AM
...
> so that protection is not good enough.
...

I think this group needs to step back a little bit and think
through just what the threat model is supposed to be here.
If you have attackers injecting text into the stream, a mis-placed
EOM marker is hardly at the top of the list of worries.
We already have protocols that can provide reasonable protection
against such insertions, and should not be trying to re-invent
them here.

The EOM marker, as I recall, was an attempt to provide a measure
of robustness when communicating with a defective implementation.
It may be worth considering whether it even meets that basic goal.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Feb 2009 11:04:43 -0800

> against such insertions, and should not be trying to re-invent

+1.

I would worry much more about the injection of additional
table rows into a table (forgot who posted that great email)
than injecting new messages.  Obviously, a NETCONF-capable
ACM would catch <reboot> by an application only allowed
to send <get*>.  But inserting extra rows into a table
that the user is already allowed to write with <edit-config>
will not likely be stopped the ACM at all.

> It may be worth considering whether it even meets that basic goal.

I know it helps there. (I can produce buggy code
with the best of 'em.:-) The easiest bug to produce
also causes the most pain -- an unmatched start-tag.
Depending on your XML parser, this type of bad XML
might cause an 'end-of-file' error in the parser.
The agent can still send back an operation-failed error
and the session continues, but it doesn't know which
element caused the problem.

But without the EOM marker, the XML parser would wait forever
for the missing end-tag. (NETCONF has no std idle-timeout.)
The EOM marker lets the agent know right away there isn't
going to be any more data for this PDU, so stop waiting for it.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Feb 2009 11:12:07 -0800

> in order to make it transport to the netconf content being carried.

Is there a solution that will work even if the manager side
is using the 'new way', and talking to an old agent
that has no clue there even is a 'new way'?

BTW, are must/when expressions for /rpc/input, /rpc/output,
and /notification expected to support the processing-instruction()
node test?  If so, then IMO it should be punted.  NETCONF agents
should not be forced to keep those around.  I agree that agents
should be allowed to ignore PIs (and comments).

Andy

---

From: "tom.petch" <[email-masked]>
Date: Tue, 24 Feb 2009 12:12:01 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Per Hedeland" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 23, 2009 7:12 PM
Subject: Re: [Netconf] NETCONF message integrity

> and unstuffing the EOM sequence and ignoring everything else.

Very much so.  My take is that the transport should delimit the message into
PDUs and pass them to the upper layer.  The application gets a PDU and if it
finds EOM in it, then that is illegal, do what you do with it (see thread last
November about Handling invalid XML).

Netconf over TLS can introduce bit stuffing to the EOM without any change to RFC
4741 or RFC4742.  This makes the TLS transport better than, and different to,
the SSH transport; good news and bad news, but I think that that is the best way
forward.

At a later date, we may change RFC4742 but RFC4741 has no mention of EOM so why
change it?  S.2 thereof is silent about whether the transport is stream or
message oriented, although the mention of rpc conveys overtones of message.  It
is RFC4742 that makes it message.

Tom Petch