Subject: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 20 Oct 2010 18:27:26 +0200

Hi All,

same is with 4742bis WGLC discusion. We had only minor 
changes after IETF 78. Our impression is that we have 
consensus to see the draft as final.

Margaret submitted the draft today making it ready for
AD review. Please check the changes by 10/22 so that 
we have a chance to re-submit before deadline. Thanks.

Cheers,
Mehmet

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Bert Wijnen (IETF)
Sent: Wednesday, October 20, 2010 3:52 PM
To: Netconf
Subject: [Netconf] status WGLC RFC4741bis

It seems that the WGLC discussion has now died out on the mailing list.
>From re-reading all those comments, I also get the impression that 
there is consensus/agreement on the changes that need to be addressed.

The editors (specifically Martin) is preparing a new revision based
on the result of the discussions. Will probably show up later today.

Our plan as WG-chairs is to allow the WG a few days to quickly check
if the changes are OK. Then ask our Ad to bring it forward to IETF
Last Call and IESG review.

Thanks,
Bert and Mehmet
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 20 Oct 2010 17:00:02 +0200

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : Using the NETCONF Configuration Protocol over Secure Shell (SSH)
	Author(s)       : M. Wasserman, T. Goddard
	Filename        : draft-ietf-netconf-rfc4742bis-03.txt
	Pages           : 10
	Date            : 2010-10-20

This document describes a method for invoking and running the NETCONF
protocol within a Secure Shell (SSH) session as an SSH subsystem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Oct 2010 19:23:21 +0200

> we have a chance to re-submit before deadline. Thanks.

The justification for the EOM marker in sec. 3.1 is technically
incorrect - and I objected against it previously:
http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html

Here is the change I propose (there's also a typo in "unambiguously"):

OLD

This character sequence cannot legally appear outside of a comment in an
XML document, so it can be unambigiously used to identify the end of the
current document, allowing resynchronization of the NETCONF exchange in
the event of an XML syntax or parsing error.

NEW

This character sequence cannot legally appear outside of a comment,
processing instruction and attribute value in an XML document, so it can
be unambiguously used to identify the end of the current document,
allowing resynchronization of the NETCONF exchange in the event of an
XML syntax or parsing error. 

Lada

> e-mail message attachment
> > -------- Forwarded Message --------
> > From: [email-masked]
> > Reply-to: <[email-masked]>
> > To: [email-masked]
> > Cc: [email-masked]

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 21 Oct 2010 18:49:04 +0200

Hi Lada,

[speaking as a contributor]

if I understand you correctly you want to allow the EOM 
not only in comments but also in XML attributes and PIs.

In case the answer is no: I appear to misunderstand what 
you were saying. So pls explain.

In case the answer is yes:

Theoretically the EOM sequence can appear everywhere in 
an XML document.

However, the transport layer shouldn't do fine grained 
parsing of the XML document, to find out where the 
attributes or PIs are.
This is the reason why 4742 kept it simple and, as I 
think, appropriate for the transport layer. 

I don't see any difference between XML elements and 
[attributes or PI]. They all are XML data. And EOM can 
appear in XML data or at the end of the document.
If somebody wants to disrupt the rpc command he can 
do it no matter in elements or attributes. 

So, at the end I don't see any benefit in reducing the 
restriction and think:
To be on the safe side and to keep it simple for the 
implementer of 4742bis the sequence must not appear 
in the XML document (except outside of comments).

[now the chair hat on]:

Please keep in mind that we don't have the mandate 
for v2.0. We are just doing bug-fixing.

I agree with you that v2.0 should solve this issue
with a thorough solution. Would you like to prepare 
a few slides for the NETCONF session in Beijing for 
a solution, which could be put later into v2.0? 

Cheers,
Mehmet

> From: ext Ladislav Lhotka [mailto:[email-masked]]
> Sent: Wednesday, October 20, 2010 7:23 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: Netconf; ext Margaret Wasserman
> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC
> RFC4741bis
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Oct 2010 19:10:06 +0200

Hi Mehmet,

> you were saying. So pls explain.

I certainly don't want to allow anything that isn't already allowed. :-)

The current text says, as I understand it, that XML specification
doesn't allow the EOM marker to appear outside comments in an XML
document (and therefore it is a good choice). But this is not true: XML
documents having the sequence in PIs and attribute values are
well-formed as well. The only place where the sequence is really
forbidden is element text.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 21 Oct 2010 20:21:05 +0200

Hi Lada,

> forbidden is element text.

"This character sequence cannot legally appear in an XML document, so
it can be unambigiously used to indentify the end of the current
document in the event of an XML syntax or parsing error, allowing
resynchronization of the NETCONF exchange."

The sentence is actually since May 2004 (v01) in SSH document 
and did not change until today. I don't know exactly what the 
aim of the authors was to write it that way. 

One option is they wanted to state that the EOM "... MUST NOT 
appear outside of a comment in an XML document", which would 
be a consistent restriction.

The other option is how you understand it:
"XML specification doesn't allow the EOM marker to appear 
outside comments"

...which is obviously not correct and can be addressed as 
you suggest. But this would mean additional implementation 
effort for SSH transport.

Margaret, Ted, Andy: 
Can you please clarify what the original aim was?

What do others in the WG think?
Please state your opinion before Friday EOB.

Mehmet

> > > This character sequence cannot legally appear outside of a comment
> in
> > > an
> > > XML document, so it can be unambigiously used to identify the end
> of
> > > the
> > > processing instruction and attribute value in an XML document, so
> it
> > > can
> > > > > A New Internet-Draft is available from the on-line Internet-
> Drafts
> > > directories.
> > > > > 	Title           : Using the NETCONF Configuration Protocol
> over
> > > Secure Shell (SSH)
> > > > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-
> rfc4742bis-
> > > 03.txt
> > > > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 20:26:00 +0200

> forbidden is element text.

I think Lada has a valid point here. However, I do not like his
rewrite - the "so it can be unambiguously used" part. What about
this:

  This character sequence cannot legally appear outside of a comment,
  processing instruction and attribute value in an XML document.  If
  the XML content carried by NETCONF does not include comments,
  processing instructions, or attribute values, this character
  sequence can be used to resynchronize a NETCONF exchange in the
  event of an XML syntax or parsing error.

/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: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 21 Oct 2010 20:40:45 +0200

>   event of an XML syntax or parsing error.

I tend to agree. But we still need to define what happens if 
the XML content carried by NETCONF "does" include comments,
processing instructions, or attribute values.

Mehmet

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Oct 2010 20:42:30 +0200

> aim of the authors was to write it that way. 

Actually, RFC 4742 has this:

"This character sequence cannot legally appear in an XML document, ..."

So it really looks like slippery slope.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Oct 2010 20:51:28 +0200

> rewrite - the "so it can be unambiguously used" part. What about

I agree, the unambiguity now looks like a bad joke, but that has been my
point for quite some time, too.

>   event of an XML syntax or parsing error.

The Messages layer uses XML attributes by definition. For example, a
really nasty (but compliant) client may use "]]>]]>" as a message-id.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 11:51:34 -0700

Hi,

The original intent was to use a char sequence that was not legal in
an XML instance document.  Nobody in the WG at the time knew for sure,
so we asked the XML Directorate.  We worked under the assumption that
the ]]>]]> sequence was a suitable message boundary marker.

I would like to hear evidence that this EOM sequence is causing problems
for operators using NETCONF.  Is this really a concern to operators?
Would a significant protocol change to address this issue cause more
operational problems than it solves?

I do not agree that this must be fixed in NETCONF 2.0, whenever that is.
We should decide at the time, after some more deployment experience.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Thursday, October 21, 2010 11:21 AM
To: ext Ladislav Lhotka
Cc: ext Margaret Wasserman; Netconf
Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis

Hi Lada,

Margaret, Ted, Andy: 

Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 21 Oct 2010 21:10:51 +0200

OK. However, independently what happened earlier we should fix 
the misleading text now. 

Juergen wrote:
" If the XML content carried by NETCONF does not include comments,
  processing instructions, or attribute values, this character
  sequence can be used to resynchronize a NETCONF exchange in the
  event of an XML syntax or parsing error."

I have an issue with this text since it does not state what the 
implementer should do if the XML content carried by NETCONF does 
include comments, etc. 

After all, I tend to agree with Lada that it would be correct from 
XML specification pov. if we state:

"This character sequence cannot legally appear outside of a comment,
processing instruction and attribute value in an XML document, so it 
can be used to identify the end of the current document, allowing 
resynchronization of the NETCONF exchange in the event of an XML 
syntax or parsing error."

s/unambiguously//

Please propose concrete text if anybody thinks something is better
than the proposal from Lada.

Cheers,
Mehmet

> From: ext Andy Bierman [mailto:[email-masked]]
> Sent: Thursday, October 21, 2010 8:52 PM
> To: Ersue, Mehmet (NSN - DE/Munich); ext Ladislav Lhotka
> Subject: RE: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC
> RFC4741bis
> 
> Hi,
> 
> Behalf Of Ersue, Mehmet (NSN - DE/Munich)
> > I certainly don't want to allow anything that isn't already allowed.
> :-
> > )
> >
> > > > http://www.ietf.org/mail-
> archive/web/netconf/current/msg06277.html
> > > >
> > > > allowing resynchronization of the NETCONF exchange in the event
> of
> > an
> > > > > From: [email-masked] [mailto:netconf-
> [email-masked]]
> > On
> > > > > It seems that the WGLC discussion has now died out on the
> mailing
> > > > list.
> > > > > > This draft is a work item of the Network Configuration
> Working
> > > > Group of the IETF.
> > > > > >
> > > > > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 21:11:08 +0200

> We should decide at the time, after some more deployment experience.

Andy,

we are in a different discussion. We agreed to not fix it. Still, the
wording should be correct and appropriate. This is what we are
discussing. Do you have a proposal?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 21:14:47 +0200

> implementer should do if the XML content carried by NETCONF does 

But that problem won't be solved until 2.0.
 
> than the proposal from Lada.

So hiding the issue is better than being clear about it? I would
rather add text to my proposed wording that says that the transport
should drop the session in case a parsing error has been detected by
the NETCONF message layer if content can contain the magic sequence.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Oct 2010 21:24:58 +0200

> the NETCONF message layer if content can contain the magic sequence.

The problem is that the message layer won't detect a parsing error if
there isn't any. Other transports such as BEEP or TLS should work fine
even for message-id="]]>]]>".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 12:29:41 -0700

Hi,

I did not agree to push this to 2.0 and fix it then.

I liked the original text that Martin had.
I think the IESG is likely to want text that says what the server
does if invalid XML is encountered.  The current 4741bis text says
an operation-failed error MUST be generated.

If there is going to be text that says the server MUST drop the session
if invalid XML is encountered, then it needs to be for every transport,
and needs to be in 4741bis.  The transport layer should not need to know
the content is XML instead of text.   The protocol layer should not need
to know which transport was used to decide how to respond to a parse error.
The server should not assume it knows whether broken XML is due
to client programming error or by some data injection attack.

Andy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, October 21, 2010 12:11 PM
To: Andy Bierman
Cc: Ersue, Mehmet (NSN - DE/Munich); ext Ladislav Lhotka; ext Margaret Wasserman; Netconf
Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis

Andy,

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Oct 2010 21:39:35 +0200

> I liked the original text that Martin had.

Now I am confused. Martin's new text was intended for 4741bis, wasn't
it? We are now discussing the text from sec. 3.1 of 4742bis.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 21:41:32 +0200

> to client programming error or by some data injection attack.

Can the message layer be expected to tell the transport whether a
parsing error occured? This is all that is needed so that one can
do this:

SSH with weak framing:

	c = nc_msg_process_frame(...);
	if (c == NC_PARSE_ERROR) {
	   ssh_close_session();
        }

BEEP with robust framing:

	c = nc_msg_process_frame(...);
	if (c == NC_PARSE_ERROR) {
	   beep_resynchronize();
        }

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Oct 2010 21:58:21 +0200

> parsing error occured? This is all that is needed so that one can

What do you mean by parsing error? The most problematic messages are
well-formed XML and satisfy all other requirements of 4741bis.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 13:22:25 -0700

> 	if (c == NC_PARSE_ERROR) {

The protocol layer would have to code for all supported transports, not just 1.
I do not like introducing coupling between the layers here.  It seems too complicated.
It is extremely unlikely server implementations will parse XML in the SSH layer.
This code never knows if it is delivering valid NETCONF messages.
It resyncs on its own without any input from the upper layers.

Since invalid XML should be extremely rare, and certainly not a use-case,
it is not a big deal to shutdown the session whenever invalid XML is received,
whether assumed to be due to framing or not.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Oct 2010 22:35:03 +0200 (CEST)

> whether assumed to be due to framing or not.

So here's a concrete proposal, along these lines.

Add the text I proposed earlier to 4741bis:

         All NETCONF messages MUST be well-formed XML, encoded in UTF-8.  If
         a peer receives a message that is not well-formed XML, it MUST
         close the NETCONF session.

And remove this text from 4742bis:

   This
   character sequence cannot legally appear outside of a comment in an
   XML document, so it can be unambigiously used to identify the end of
   the current document, allowing resynchronization of the NETCONF
   exchange in the event of an XML syntax or parsing error.

And then we can revisit this issue when we do NETCONF 2.0.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 22:34:48 +0200

> well-formed XML and satisfy all other requirements of 4741bis.

4741bis says:

   [...] If a
   peer receives a message that is not well-formed XML, it MUST reply
   with an 'operation-failed' error.

This got added after long debates.

Well-formed XML messages are simply processed. If someone injects data
that properly closes the current message and opens another one that
then properly closes as well, we are simply out of luck. If this is a
valid concern, we should close the session immediately after opening
it. ;-)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 22:39:38 +0200

On Thu, Oct 21, 2010 at 01:22:25PM -0700, Andy Bierman wrote:
> The protocol layer would have to code for all supported transports,
> not just 1.  I do not like introducing coupling between the layers
> here.  It seems too complicated.

You did not get the idea. The code fragments sit in the transport
code.

> It is extremely unlikely server implementations will parse XML in

Nobody suggested this, we are in agreement.

> It resyncs on its own without any input from the upper layers.

Sure it knows - because the message layer tells.

> Since invalid XML should be extremely rare, and certainly not a
> use-case, it is not a big deal to shutdown the session whenever
> invalid XML is received, whether assumed to be due to framing or
> not.

So you agree to what I proposed. Thanks.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 13:44:48 -0700

On 10/21/2010 01:35 PM, Martin Bjorklund wrote:
> Andy Bierman<[email-masked]>  wrote:

Looks good to me.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Oct 2010 10:57:46 +0200

> This got added after long debates.

OK, but this issue is different from the EOM justification in 4742bis. I
missed the change in topics, sorry.

> valid concern, we should close the session immediately after opening

Agreed.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Oct 2010 11:13:41 +0200

>          close the NETCONF session.

I think it should also send an error message before closing, otherwise I
agree.

>    exchange in the event of an XML syntax or parsing error.

But this means sweeping the issue under the carpet. How about telling
the whole truth, i.e.

1. Originally it was believed the EOM sequence cannot appear in any XML
document.

2. This assumption turned out to be wrong but now this mistake cannot be
mitigated in a backwards compatible way.

3. As a result, the SSH transport is not 100% reliable and safe and may
lead to operational problems and open space for attacks. It is however
believed that the associated threat is not very high. On the other hand,
making incompatible changes would break existing clients.

4. NETCONF implementations using the SSH transport must exercise extra
care and make sure the EOM sequence is not present in NETCONF messages
before passing them to the Transport layer, even if they were
well-formed XML.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 22 Oct 2010 13:20:13 +0200

As a technical contributor.

My understanding was (and still is):

- at rfc4741 time, we thought that the sequence could NOT legally occur
    in an XML document.
- so we decided that the sequence serves as an EOM. Which I understand to mean
    that the SSH layer does not (at least does not need to) parse XML at all. It just
    searched in the stream for the EOM sequence, and then passes the data up
    to that point to the netconf layer.
- we learned later that the sequence may occur in comments and decided that
    we do not consider that as a problem, ans do we do (or should) advise
    users to NOT use the EOM sequence in XML comments
- then yet later we learned that it can occur in PI and attribute values, but we decided
    (or concluded based on experience) that we are not using/needing PI in NETCONF
    or NETCONF content, and that we also do not need it in attribute values.
    So, we figure it is still OK to use the EOM marker, at least untill someone shows us
    a good use case where our EOM marker is needed with NETCONF.

So, we want be correct/precise/honest in exactly specifying how the sequence can
theoretically and legally appear in an XML document.
We then want to state that we believe, based on our experience, that that sequence
is in practice not used/needed in NETCONF, and so that we still believe it is OK
to use that sequence as EOM marker, no matter where in the transport stream it
occurs.

We could add a question that if anyone ever sees a need to use the sequence that
they better inform us (netconf WG) asap with a good description of the scenario.

Bert

On 10/21/10 8:51 PM, Andy Bierman wrote:
>>>>>> Reply-to:<[email-masked]>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Oct 2010 13:38:08 +0200

>     a good use case where our EOM marker is needed with NETCONF.

It may not be needed but it is available to attackers who may try to
inject the marker in various places. This could be done indirectly, by
exploiting other holes such as stack overflow in the client code.

If this ever happens, all NETCONF implementations will have to be
patched very quickly. I think it is better to fix it NOW than in such an
emergency situation.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 22 Oct 2010 14:13:47 +0200

> patched very quickly. I think it is better to fix it NOW than in such an

Lada, that "fix it now" may be better in the view of some people, but we were unable to reach agreement
on fixing it now. So that "better fix it now" is no longer open for discussion.

We're discussing how to best document the situation we have created.

Bert (now speaking as a WG chair)

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 22 Oct 2010 14:34:54 +0200

Hi All,

>    exchange in the event of an XML syntax or parsing error.

I agree with Lada and Martin that this sentence caused more trouble 
than it helped. 

To avoid any kind of misunderstanding for the implementer of 4742bis 
I would write instead of the text above:

NEW:
"This character sequence MUST NOT appear in an XML document."

Good or bad, this is how SSH transport works in v1.0.

Lada wrote:
> How about telling the whole truth, i.e.
> 
> 1. Originally it was believed the EOM sequence cannot appear in any XML document.

Some of this should be written into the security considerations section.
E.g.

NEW:
"RFC 4742 assumes that the EOM sequence cannot appear in any XML document,
which turned out to be mistaken. The EOM sequence can cause operational 
problems and open space for attacks if sent deliberately in an XML document.
It is however believed that the associated threat is not very high. This 
document keeps using the EOM sequence to avoid incompatibility with existing 
clients.
NETCONF implementations using the SSH transport must exercise extra care 
and make sure the EOM sequence is not present in NETCONF messages before 
passing them to the Transport layer, even if they were well-formed XML."

With this (two) NEW-text proposals, can we see now the issue as closed 
for (v1.0) 4742bis?

And we can revisit this issue when we do NETCONF v2.0.

Cheers,
Mehmet

> From: ext Bert (IETF) Wijnen [mailto:[email-masked]]
> Sent: Friday, October 22, 2010 1:20 PM
> To: Andy Bierman

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 22 Oct 2010 14:39:35 +0200

Hi Lada,

can you provide a few slides for the NETCONF session
summarizing the solution proposals for the EOM issue 
for v2.0 we had so far on the ML?

I think we should discuss it in Beijing as long as it
is warm.

Cheers,
Mehmet

> Sent: Friday, October 22, 2010 11:14 AM
> To: Martin Bjorklund
> Cc: [email-masked]; [email-masked]; Ersue, Mehmet (NSN -
> DE/Munich); [email-masked]; [email-masked]
> use-case,

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Oct 2010 06:38:34 -0700

> I think we should discuss it in Beijing as long as it

Why?
There is no new information.
We are not working on NETCONF 2.0 yet, so why revisit the issue over and over now?

A client application could be compromised at any protocol layer, so no form
of framing is safe.

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 22 Oct 2010 15:55:06 +0200

This is by no means part of 4742bis or 4741bis discussion.
Both of which are going hopefully to AD review on Monday.

I proposed this as an open mike discussion. Though with a 
few slides to structure it. Let's see whether we can reach 
any common view.

Cheers,
Mehmet

> From: ext Andy Bierman [mailto:[email-masked]]
> Sent: Friday, October 22, 2010 3:39 PM
> Cc: ext Ladislav Lhotka; Martin Bjorklund; [email-masked];
> [email-masked]
> >> I think it should also send an error message before closing,
> otherwise
> >> I
> >> agree.
> >>
> >>>
> >>>     character sequence cannot legally appear outside of a comment
> in
> >> an
> >> 2. This assumption turned out to be wrong but now this mistake
> cannot
> >> be

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Oct 2010 16:36:48 +0200

> "This character sequence MUST NOT appear in an XML document."

Works for me.
 
> passing them to the Transport layer, even if they were well-formed XML."

So where does this go, into 4741bis or 4742bis? The last sentence more
sounds like 4741bis since it says something about what the NETCONF
message layer has to do.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Oct 2010 10:41:22 -0400

>> "This character sequence MUST NOT appear in an XML document."

This is a change to the NETCONF protocol, since it makes a previously
legal character sequence illegal.  If we're willing to change
NETCONF, why not just repair the SSH transport mapping, where the
problem really exists.

But if the WG really is following the "it's not a bug" line, then
I suggest:

(a) The draft should include an explanation of why this is illegal,
with the history, etc.

(b) The draft should include a description of the means to avoid
this sequence (amper escaping) and a list of places where that
escaping is not possible (processing instructions).

That is, the draft should give all the details as we know them so
an implementor can understand and properly address the issues.

Me, I think it's a bug.  A minor one, sure, but at least on par with
the other issues addressed with netconf-1.1.

Thanks,
 Phil

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 22 Oct 2010 18:20:18 +0200

>> document keeps using the EOM sequence to avoid incompatibility with
>> existing clients.

Agree it should rather be:

NEW (in security consideration section of 4742bis):

"RFC 4742 assumes that the EOM sequence cannot appear in any XML
document,
which turned out to be mistaken. The EOM sequence can cause operational
problems and open space for attacks if sent deliberately in an XML
document.
It is however believed that the associated threat is not very high. This
document keeps using the EOM sequence to avoid incompatibility with
existing clients.
Implementations of SSH transport should exercise extra care and make
sure 
the EOM sequence is not present in an XML document."

Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 22 Oct 2010 18:21:21 +0200

Hi Phil, All,

::>> NEW:
::>> "This character sequence MUST NOT appear in an XML document."

> the other issues addressed with netconf-1.1.

Yes, it is a bug. We found out it can only be addressed "thoroughly" 
in v2.0. We are now trying to fix the mistaken text in v1.0 of 4742bis.

SSH v1.0 is specified to recognize end of document with this character 
sequence. As we all were thinking, the character sequence cannot appear 
in an XML document, I don't think it is a change for the NETCONF
protocol
(this BTW was the case since May 2004, see v01 of SSH draft which leaded

to 4742).

If you think "MUST NOT" is too strict I can go also with "SHOULD NOT".
OTOH, if we know already it is bad, why not "MUST"?

The explanation text you are proposing should go into the security 
considerations section of 4742bis, e.g.:

NEW:

:: "RFC 4742 assumes that the EOM sequence cannot appear in any XML
document,
:: which turned out to be mistaken. The EOM sequence can cause
operational
:: problems and open space for attacks if sent deliberately in an XML
document.
:: It is however believed that the associated threat is not very high.
This
:: document keeps using the EOM sequence to avoid incompatibility with
:: existing clients.
:: Implementations of SSH transport must exercise extra care and make
sure 
:: the EOM sequence is not present in an XML document."

All:
: Knowing that this is only a (limited) bug fixing for v1.0, can we go 
: with the proposed two NEW text blocks in 4742bis?

We need a decision kind of soon to resubmit before deadline. Thank you.

Mehmet

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Oct 2010 18:21:40 +0200

> for v2.0 we had so far on the ML?

OK, I will.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Oct 2010 18:29:34 +0200

> on fixing it now. So that "better fix it now" is no longer open for discussion.

OK, I just don't agree with the logic that as long there are no use
cases for the EOM marker inside NETCONF messages the marker is good
enough. The problem are misuse cases, not use cases.

> We're discussing how to best document the situation we have created.

Yes, I understand and tried to work in that direction, too. I just
couldn't resist here. :-)

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Oct 2010 18:30:34 +0200

> an implementor can understand and properly address the issues.

Absolutely.

> the other issues addressed with netconf-1.1.

Same here.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Oct 2010 18:36:43 +0200

> document keeps using the EOM sequence to avoid incompatibility with

s/clients/implementations/

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Oct 2010 10:18:42 -0700

Hi,

We went through all this already at the last IETF.

In order to change the framing for SSH, a new subsystem or port number
needs to be used, so the new framing is used for every message,
even the <hello>. A hacker could possibly piggyback an <rpc> onto the <hello>,
so switching framing modes after the <hello> does not fix the problem.

Using multiple subsystems adds complexity to NMS applications,
and requires that a new NMS make 2 connection attempts to determine
if which protocol versions are supported on the server.
Using ability-to-connect-right-now is a bad way to manage version control.

These are the reasons the WG decided to wait until a major release
to change the framing.

Andy

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]]
Sent: Friday, October 22, 2010 9:30 AM
To: Bert (IETF) Wijnen
Cc: Andy Bierman; Ersue, Mehmet (NSN - DE/Munich); ext Margaret Wasserman; Netconf
Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 22 Oct 2010 21:16:36 +0200

Agree, the WG decided to do the framing change with v2.0.

Mehmet

> Sent: Friday, October 22, 2010 7:19 PM
> To: Ladislav Lhotka; Bert (IETF) Wijnen
> Cc: Ersue, Mehmet (NSN - DE/Munich); ext Margaret Wasserman; Netconf
> > >>> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
> > >>>> On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN -
> DE/Munich)
> > >>>> wrote:
> > >>>>> Hi Lada,
> > >>>>>
> > >>>> I certainly don't want to allow anything that isn't already
> allowed. :-
> > >>>> )
> > >>>>
> > >>>>>> On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN -
> DE/Munich)
> > >>>>>> wrote:
> > >>>>>>> Hi All,
> > >>>>>>>
> > >>>>>> allowing resynchronization of the NETCONF exchange in the
> event of
> > >>>> an
> > >>>>>>>    From re-reading all those comments, I also get the
> impression
> > >>>> that
> > >>>>>>> Our plan as WG-chairs is to allow the WG a few days to
> quickly
> > >>>> check
> > >>>>>>>> This document describes a method for invoking and running
> the
> > >>>>>> NETCONF
> > >>>>>>>> implementation to automatically retrieve the ASCII version
> of
> > >>>> the
> > >>>>>>>> Internet-Draft.