RE: [Netconf] Consensus verification WAS:RE: AD review = fordraft-ietf-netconf-tls-06.txt

Please send me your comments if you have any strong objections.

Best regards,

Badra

1) Section 2.1

   "This document uses the same d= elimiter sequence ("]]>]]>") defined in
   [RF= C4742], which MUST be sent by both the client and the server after
= ; each XML document in the NETCONF exchange. Since this charact= er
   sequence can legally appear in plain XML in attribute values, = comments,
   and Processing Instructions, implementations of t= his document MUST
   ensure that this character sequence is ne= ver part of a NETCONF message."

2) Security Considerations

   "The security consi= derations described throughout [RFC5246] and
   [RFC4741] appl= y here as well.

   This document in its current version do= esn't support third party
   authentication due to the fact that TLS doesn't specify th= is way of
   authentication and that NETCONF depends on the tr= ansport protocol for
   the authentication service. If t= hird party authentication is needed,
   BEEP or SSH transport can be used.

   An atta= cker might be able to inject arbitrary NETCONF messages via some
&= nbsp; application that does not carefully check exchanged messages or
&n= bsp; deliberately insert the delimiter sequence in a Netconf message = to
   create a DoS attack. Hence, applications and NETCONF API= s must ensure
   that the delimiter sequence defined in sectio= n 2.1 never appears in
   NETCONF messages; otherwise, t= hose messages can be dropped, garbled or
   mis-interpreted. If it is found in an incoming NETCONF message= by the
   sender side, a robust implementation of this docume= nt should warn the
   user that illegal characters have been d= iscovered. If the delimiter
   sequence is found in a Netconf message by the receiver side (i= ncluding
   any XML attributes, XML comments or Processing Ins= tructions) a robust
   implementation of this document must si= lently discard the message
   without further processing and then stop the NETCONF session.<= br>
   Finally, this document does not introduce any new secur= ity
   considerations compared to [RFC4742]."

--000e0cd2474a50559a046349f290-- From mehmet.ersue@nsn.com Thu Feb 19 11:10:58 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781473A6A47 for ; Thu, 19 Feb 2009 11:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSh7B524OJpN for ; Thu, 19 Feb 2009 11:10:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 441A93A6A31 for ; Thu, 19 Feb 2009 11:10:56 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1JJB5x8030466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Feb 2009 20:11:05 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1JJB4oR000847; Thu, 19 Feb 2009 20:11:04 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 20:11:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C992C5.BE7997BE" Date: Thu, 19 Feb 2009 20:10:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Netconf] Consensus verification WAS:RE: AD reviewfordraft-ietf-netconf-tls-06.txt Thread-Index: AcmSxb4nqwKrRRA7RzqUjMHQVRP3Tg== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 19 Feb 2009 19:11:04.0201 (UTC) FILETIME=[CF5DBF90:01C992C5] Subject: Re: [Netconf] Consensus verification WAS:RE: AD reviewfordraft-ietf-netconf-tls-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 19:10:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C992C5.BE7997BE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG members, we the WG chairs think that:=20 =20 - the EOM issue is NOT specific to Netconf over TLS - a security thread based on the EOM issue can only be solved=20 sufficiently if it's done in conjunction with access control - Netconf WG may want to investigate a complete solution for message intregrity (and access control) after re-chartering and=20 see how we can address the problem - we don't think we need to elaborate on issues of any missing=20 access control in the base protocol. That is in our view NOT part=20 of Netconf over TLS but rather a pure NETCONF protocol issue. =20 As a result, we propose NOT to try to solve any EOM issues=20 beyond the introduced delimiter sequence and corresponding=20 security considerations in the NETCONF over TLS document. We further recommend to let this document go to RFC and get=20 published, so that people can start to implement against a stable=20 specification. The text proposals of Badra in the parallel mail now hopefully=20 address the issue Dan indicated and other concerns stated until=20 now. Since the IETF LC ends today please check again the two text=20 blocks provided by Badra for approval and speak up if you have=20 any objections by 5pm ET Feb 20. We will bring then an updated version of the draft to the next=20 step. Thank you all for going through the (sometimes painful) steps=20 of RFC development. =20 Bert & Mehmet ------_=_NextPart_001_01C992C5.BE7997BE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Netconf] Consensus verification WAS:RE: AD = reviewfordraft-ietf-netconf-tls-06.txt

Dear WG = members,

we the WG chairs = think that:

- the EOM issue is = NOT specific to Netconf over TLS
- a security = thread based on the EOM issue can only be solved
= sufficiently if it's done in conjunction with access = control
- Netconf WG may = want to investigate a complete solution for
message = intregrity (and access control) after re-chartering and
see how we = can address the problem
- we don't think = we need to elaborate on issues of any missing
access = control in the base protocol. That is in our view NOT part =
of Netconf = over TLS but rather a pure NETCONF protocol issue.

As a result, we = propose NOT to try to solve any EOM issues
beyond the = introduced delimiter sequence and corresponding
security = considerations in the NETCONF over TLS document.

We further = recommend to let this document go to RFC and get
published, so that = people can start to implement against a stable
specification.

The text proposals = of Badra in the parallel mail now hopefully
address the issue = Dan indicated and other concerns stated until
now.

Since the IETF LC = ends today please check again the two text
blocks provided by = Badra for approval and speak up if you have
any objections by = 5pm ET Feb 20.

We will bring then = an updated version of the draft to the next
step.

Thank you all for = going through the (sometimes painful) steps
of RFC = development.

Bert & = Mehmet

------_=_NextPart_001_01C992C5.BE7997BE-- From balazs.lengyel@ericsson.com Thu Feb 19 23:48:55 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BD93A697B for ; Thu, 19 Feb 2009 23:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0-QeOM-C1Qp for ; Thu, 19 Feb 2009 23:48:53 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 892693A6957 for ; Thu, 19 Feb 2009 23:48:53 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AA94221D58; Fri, 20 Feb 2009 08:47:28 +0100 (CET) X-AuditID: c1b4fb3e-aa8b8bb000001315-0e-499e60100301 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8E8492128C; Fri, 20 Feb 2009 08:47:28 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Feb 2009 08:46:21 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Feb 2009 08:46:20 +0100 Message-ID: <499E5FCC.6080105@ericsson.com> Date: Fri, 20 Feb 2009 08:46:20 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "tom.petch" References: <200902190532.n1J5Wg6V041554@idle.juniper.net><499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> In-Reply-To: <000201c992b8$7bd58b80$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2009 07:46:20.0895 (UTC) FILETIME=[52387EF0:01C9932F] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 07:48:55 -0000 I also vote for escaping the delimiter sequence. HDLC bit stuffing also came to my mind. I agree with TOM. Balazs tom.petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Per Hedeland" > Cc: > Sent: Thursday, February 19, 2009 8:28 AM > Subject: Re: [Netconf] NETCONF message integrity > > >> 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 >>> - this is the assumption that turned out to be wrong in the SSH case >>> (and TLS if it chooses the same EOM). >> 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. > > 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. > From cfinss@dial.pipex.com Fri Feb 20 06:28:24 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93133A6A1D for ; Fri, 20 Feb 2009 06:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RyBRiLz2Dba for ; Fri, 20 Feb 2009 06:28:24 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id C41DC3A6A82 for ; Fri, 20 Feb 2009 06:28:23 -0800 (PST) X-Trace: 187933486/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.29/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.29 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEEAINMnkk+vBEd/2dsb2JhbACDQUGKCcY2B4JLgT0G X-IronPort-AV: E=Sophos;i="4.38,241,1233532800"; d="scan'208";a="187933486" X-IP-Direction: IN Received: from 1cust29.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.29]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Feb 2009 14:28:36 +0000 Message-ID: <028501c9935e$f649a440$0601a8c0@allison> From: "tom.petch" To: "Badra" References: <20090218080456.GC8037@elstar.iuhb02.iu-bremen.de><20090218.125148.208604864.mbj@tail-f.com> Date: Fri, 20 Feb 2009 14:26:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Consensus verification WAS:RE: ADreviewfordraft-ietf-netconf-tls-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 14:28:25 -0000 ---- Original Message ----- From: "Badra" To: "Martin Bjorklund" Cc: Sent: Thursday, February 19, 2009 7:45 PM Subject: Re: [Netconf] Consensus verification WAS:RE: ADreviewfordraft-ietf-netconf-tls-06.txt > > I considered all concerns until now and prepared following text blocks for > the delimiter handling in section 2.1 and the security considerations > section. > > We are going to use these text blocks now for the update of the document for > the next step. > > Please send me your comments if you have any strong objections. > Best regards, > Badra > > 1) Section 2.1 > > "This document uses the same delimiter sequence ("]]>]]>") defined in > [RFC4742], which MUST be sent by both the client and the server after > each XML document in the NETCONF exchange. Since this character > sequence can legally appear in plain XML in attribute values, comments, > and Processing Instructions, implementations of this document MUST > ensure that this character sequence is never part of a NETCONF message." > > 2) Security Considerations > > "The security considerations described throughout [RFC5246] and > [RFC4741] apply here as well. > > This document in its current version doesn't support third party > authentication due to the fact that TLS doesn't specify this way of > authentication and that NETCONF depends on the transport protocol for > the authentication service. If third party authentication is needed, > BEEP or SSH transport can be used. > > An attacker might be able to inject arbitrary NETCONF messages via some > application that does not carefully check exchanged messages or > deliberately insert the delimiter sequence in a Netconf message to > create a DoS attack. Hence, applications and NETCONF APIs must ensure > that the delimiter sequence defined in section 2.1 never appears in > NETCONF messages; otherwise, those messages can be dropped, garbled or > mis-interpreted. If it is found in an incoming NETCONF message by the > sender side, a robust implementation of this document should warn the > user that illegal characters have been discovered. If the delimiter > sequence is found in a Netconf message by the receiver side (including > any XML attributes, XML comments or Processing Instructions) a robust > implementation of this document must silently discard the message > without further processing and then stop the NETCONF session. > > Finally, this document does not introduce any new security > considerations compared to [RFC4742]." > If we accept these semantics, I see a need for some editorial tweaks: NETCONF or Netconf? don't mind but would like consistency /NETCONF APIs must/NETCONF APIs MUST/ /If it is found/If the delimiter sequence is found/ 'incoming message by the sender side' um, I think of incoming to receivers, not senders, suggest dropping the word 'incoming' Tom Petch From mehmet.ersue@nsn.com Sun Feb 22 09:57:45 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259223A6898 for ; Sun, 22 Feb 2009 09:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnYsXtoVzsgE for ; Sun, 22 Feb 2009 09:57:44 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 68DDE3A6869 for ; Sun, 22 Feb 2009 09:57:42 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1MHvvSl022279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 22 Feb 2009 18:57:57 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1MHvvnX017004 for ; Sun, 22 Feb 2009 18:57:57 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 18:57:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Feb 2009 18:57:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Renumbering needs work version 02 Thread-Index: AcmToPGbIDnsOcnSTS60UHvsExVgxgAhwh8g From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 22 Feb 2009 17:57:57.0155 (UTC) FILETIME=[17B8E730:01C99517] Subject: [Netconf] FW: [OPS-AREA] Renumbering needs work version 02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 17:57:45 -0000 =20 Hi All, the draft below recommends to use Netconf. What do you think on this? Mehmet -----Original Message----- From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On Behalf Of ext Brian E Carpenter Sent: Friday, February 20, 2009 10:07 PM To: ops-area@ietf.org Cc: RJ Atkinson; Flinck, Hannu (NSN - FI/Espoo) Subject: [OPS-AREA] Renumbering needs work version 02 A draft on this topic has been updated: http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-02. txt Comments and discussion are invited on the OPS Area list, ops-area@ietf.org Brian Carpenter Ran Atkinson Hannu Flinck P.S. Apologies if you receive multiple copies, but that seems preferable to cross-posting to multiple lists. _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From lhotka@cesnet.cz Mon Feb 23 01:40:28 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918163A6A5A for ; Mon, 23 Feb 2009 01:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqH+Gb+Ql-mS for ; Mon, 23 Feb 2009 01:40:28 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D1BF83A68AF for ; Mon, 23 Feb 2009 01:40:27 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6B017D800C0 for ; Mon, 23 Feb 2009 10:40:40 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <499E5FCC.6080105@ericsson.com> References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 23 Feb 2009 10:40:40 +0100 Message-Id: <1235382040.6383.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:40:28 -0000 Balazs Lengyel píše v Pá 20. 02. 2009 v 08:46 +0100: > I also vote for escaping the delimiter sequence. HDLC bit stuffing > also came to my mind. If you mean escaping the delimiter sequence via > entities, it doesn't really help. The following two valid PIs are different and should remain so: ]]> ?> 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@ericsson.com Mon Feb 23 02:04:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7CD3A6AA5 for ; Mon, 23 Feb 2009 02:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbWrnfSx9vGd for ; Mon, 23 Feb 2009 02:04:36 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2B1153A6874 for ; Mon, 23 Feb 2009 02:04:36 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC89B2115C; Mon, 23 Feb 2009 11:04:52 +0100 (CET) X-AuditID: c1b4fb3c-a9281bb00000127c-89-49a2736182fa Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 07BCB21410; Mon, 23 Feb 2009 10:58:58 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 10:58:48 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 10:58:48 +0100 Message-ID: <49A27358.2000009@ericsson.com> Date: Mon, 23 Feb 2009 10:58:48 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> In-Reply-To: <1235382040.6383.27.camel@missotis> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Feb 2009 09:58:48.0356 (UTC) FILETIME=[52840E40:01C9959D] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:04:37 -0000 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 Ladislav Lhotka wrote: > Balazs Lengyel píše v Pá 20. 02. 2009 v 08:46 +0100: >> I also vote for escaping the delimiter sequence. HDLC bit stuffing >> also came to my mind. > > If you mean escaping the delimiter sequence via > entities, it > doesn't really help. The following two valid PIs are different and > should remain so: > > ]]> ?> > > > I think for now the delimiter sequence should be simply banned in the > PDU content. > > Lada > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From lhotka@cesnet.cz Mon Feb 23 02:13:03 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA383A6874 for ; Mon, 23 Feb 2009 02:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX+KDWkMdFyc for ; Mon, 23 Feb 2009 02:13:03 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EAA863A67C1 for ; Mon, 23 Feb 2009 02:13:02 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 861A0D800C8; Mon, 23 Feb 2009 11:13:20 +0100 (CET) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <49A27358.2000009@ericsson.com> References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 23 Feb 2009 11:13:20 +0100 Message-Id: <1235384000.6383.36.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:13:03 -0000 Balazs Lengyel píše v Po 23. 02. 2009 v 10:58 +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. Is it any different? My objection now applies to the following two PIs: ]]> ?> a]]> ?> Lada > Balazs > > Ladislav Lhotka wrote: > > Balazs Lengyel píše v Pá 20. 02. 2009 v 08:46 +0100: > >> I also vote for escaping the delimiter sequence. HDLC bit stuffing > >> also came to my mind. > > > > If you mean escaping the delimiter sequence via > entities, it > > doesn't really help. The following two valid PIs are different and > > should remain so: > > > > ]]> ?> > > > > > > I think for now the delimiter sequence should be simply banned in the > > PDU content. > > > > Lada > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From per@tail-f.com Mon Feb 23 02:23:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B223A6A41 for ; Mon, 23 Feb 2009 02:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4rwTZqSafAK for ; Mon, 23 Feb 2009 02:23:40 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3822C3A6874 for ; Mon, 23 Feb 2009 02:23:40 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AA59576C225; Mon, 23 Feb 2009 11:23:56 +0100 (CET) Message-ID: <49A2793C.308@tail-f.com> Date: Mon, 23 Feb 2009 11:23:56 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Ladislav Lhotka References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> <1235384000.6383.36.camel@missotis> In-Reply-To: <1235384000.6383.36.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:23:41 -0000 On 2009-02-23 11:13, Ladislav Lhotka wrote: > Balazs Lengyel píae v Po 23. 02. 2009 v 10:58 +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. > > Is it any different? My objection now applies to the following two PIs: > > ]]> ?> > a]]> ?> 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 lhotka@cesnet.cz Mon Feb 23 02:54:10 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E269B28C121 for ; Mon, 23 Feb 2009 02:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b06drY3zNhQw for ; Mon, 23 Feb 2009 02:54:10 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1DB0C28C10B for ; Mon, 23 Feb 2009 02:54:10 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 43642D800C5; Mon, 23 Feb 2009 11:54:25 +0100 (CET) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <49A2793C.308@tail-f.com> References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> <1235384000.6383.36.camel@missotis> <49A2793C.308@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 23 Feb 2009 11:54:25 +0100 Message-Id: <1235386465.6383.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:54:11 -0000 Per Hedeland píše v Po 23. 02. 2009 v 11:23 +0100: > 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. 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 "]]>]]]" and then the extra bracket won't get removed. Lada > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From per@tail-f.com Mon Feb 23 03:53:40 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842093A68AD for ; Mon, 23 Feb 2009 03:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rreMjCnCXd4P for ; Mon, 23 Feb 2009 03:53:39 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AE1353A6801 for ; Mon, 23 Feb 2009 03:53:39 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BA35176C225; Mon, 23 Feb 2009 12:53:55 +0100 (CET) Message-ID: <49A28E53.5010309@tail-f.com> Date: Mon, 23 Feb 2009 12:53:55 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Ladislav Lhotka References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> <1235384000.6383.36.camel@missotis> <49A2793C.308@tail-f.com> <1235386465.6383.58.camel@missotis> In-Reply-To: <1235386465.6383.58.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:53:40 -0000 On 2009-02-23 11:54, Ladislav Lhotka wrote: > Per Hedeland píae v Po 23. 02. 2009 v 11:23 +0100: >> 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. > > 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 "]]>]]]" and then the extra bracket won't get removed. 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@netconfcentral.com Mon Feb 23 10:12:58 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E447E3A684F for ; Mon, 23 Feb 2009 10:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um3axyTMZv8E for ; Mon, 23 Feb 2009 10:12:58 -0800 (PST) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id EE9D43A6870 for ; Mon, 23 Feb 2009 10:12:18 -0800 (PST) Received: from [209.191.108.97] by n14.bullet.mail.mud.yahoo.com with NNFMP; 23 Feb 2009 18:12:36 -0000 Received: from [68.142.201.250] by t4.bullet.mud.yahoo.com with NNFMP; 23 Feb 2009 18:12:36 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 23 Feb 2009 18:12:36 -0000 X-Yahoo-Newman-Id: 141561.36200.bm@omp411.mail.mud.yahoo.com Received: (qmail 85067 invoked from network); 23 Feb 2009 18:12:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.52 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 23 Feb 2009 18:12:35 -0000 X-YMail-OSG: QYKRcMQVM1lW0jPwG8X1GjKMKjXG7SgJ5AN2VdIhb1jjsdBL1NKLiIMfWd0MqvRbbg9Y_tavWc4msqbZjh85HxV0aEZ5Zr_3oeT7OCqbSVNXGy_hlYDEGFoe5.XC7B8wTihDUjVFQgQQbNLd1s2zK94ucLhcG4MR15ZzbvQ1W5K1PUSi2OyzpQJf X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A2E711.3000602@netconfcentral.com> Date: Mon, 23 Feb 2009 10:12:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Per Hedeland References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> <1235384000.6383.36.camel@missotis> <49A2793C.308@tail-f.com> <1235386465.6383.58.camel@missotis> <49A28E53.5010309@tail-f.com> In-Reply-To: <49A28E53.5010309@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:12:59 -0000 Per Hedeland wrote: > On 2009-02-23 11:54, Ladislav Lhotka wrote: >> Per Hedeland píae v Po 23. 02. 2009 v 11:23 +0100: >>> 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. >> 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 "]]>]]]" and then the extra bracket won't get removed. > > 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. > 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 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 , so it won't. So how will version 2 managers talk to version 1 agents? Try v2. It fails, then start over with v1? > --Per Andy From phil@juniper.net Mon Feb 23 10:43:17 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EE53A691F for ; Mon, 23 Feb 2009 10:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HgW+jJnFlB8 for ; Mon, 23 Feb 2009 10:43:16 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 8AA5E3A6872 for ; Mon, 23 Feb 2009 10:42:44 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSaLuNV6gIml3BGngrCkqIM4aJxW8tPO9@postini.com; Mon, 23 Feb 2009 10:43:34 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 23 Feb 2009 10:41:11 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 10:41:11 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 10:41:10 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 10:41:10 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1NIf9M73297; Mon, 23 Feb 2009 10:41:09 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n1NIYZoZ031833; Mon, 23 Feb 2009 18:34:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902231834.n1NIYZoZ031833@idle.juniper.net> To: Andy Bierman In-Reply-To: <49A2E711.3000602@netconfcentral.com> Date: Mon, 23 Feb 2009 13:34:35 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Feb 2009 18:41:10.0277 (UTC) FILETIME=[4BC1AB50:01C995E6] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:43:17 -0000 Andy Bierman writes: >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? 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 ">", 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 ]]>mumble?> ]]>ble?> 1 2 3 4 % xmllint /tmp/foo.xml ]]>mumble?> ]]>ble?> 1 2 3 4 From randy_presuhn@mindspring.com Mon Feb 23 10:45:24 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2ACE28C0DD for ; Mon, 23 Feb 2009 10:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLlq9tK8XnOb for ; Mon, 23 Feb 2009 10:45:23 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id B886028C0F6 for ; Mon, 23 Feb 2009 10:45:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FP27LHJE4PKruHBkIaPpZ5ihFkEfIzXw8O24tUwOJfkSsqI8ceE/V7g+2S2yEJ+L; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.28.69] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LbfoD-0003ij-MF for netconf@ietf.org; Mon, 23 Feb 2009 13:45:41 -0500 Message-ID: <004c01c995e6$fb92fa20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> <1235384000.6383.36.camel@missotis><49A2793C.308@tail-f.com> <1235386465.6383.58.camel@missotis><49A28E53.5010309@tail-f.com> <49A2E711.3000602@netconfcentral.com> Date: Mon, 23 Feb 2009 10:46:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173cce109ed584ce58574eb871a39c74893350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.69 Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:45:24 -0000 Hi - > From: "Andy Bierman" > To: "Per Hedeland" > Cc: > Sent: Monday, February 23, 2009 10:12 AM > Subject: Re: [Netconf] NETCONF message integrity ... > 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. ... 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@netconfcentral.com Mon Feb 23 11:04:27 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E5D3A6827 for ; Mon, 23 Feb 2009 11:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRmGCSO9Xd1M for ; Mon, 23 Feb 2009 11:04:26 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id A003B3A6784 for ; Mon, 23 Feb 2009 11:04:26 -0800 (PST) Received: (qmail 71932 invoked from network); 23 Feb 2009 19:04:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 23 Feb 2009 19:04:44 -0000 X-YMail-OSG: kQpIsxsVM1naxDOc0JPOqFjI9_UNys8EsV.Uo5bny7utqRgmaogJVtH7o_15xIFWcz61AR0cRvIZXyMVNsT62oziUY3thxPHyCUfhlK8053ssqC8uvSwIRsG.afdDzIRoC.eTQ4WYpbdJfbHe2B6lFwjYzJB92OvhR.TiB4inrCUzehd_hoGOOqi X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A2F34B.8050402@netconfcentral.com> Date: Mon, 23 Feb 2009 11:04:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Randy Presuhn References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> <1235384000.6383.36.camel@missotis><49A2793C.308@tail-f.com> <1235386465.6383.58.camel@missotis><49A28E53.5010309@tail-f.com> <49A2E711.3000602@netconfcentral.com> <004c01c995e6$fb92fa20$6801a8c0@oemcomputer> In-Reply-To: <004c01c995e6$fb92fa20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:04:27 -0000 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Per Hedeland" >> Cc: >> Sent: Monday, February 23, 2009 10:12 AM >> Subject: Re: [Netconf] NETCONF message integrity > ... >> 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. > ... > > 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. > +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 by an application only allowed to send . But inserting extra rows into a table that the user is already allowed to write with will not likely be stopped the ACM at all. > 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. > 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. > Randy > Andy From andy@netconfcentral.com Mon Feb 23 11:11:51 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8898B3A69B1 for ; Mon, 23 Feb 2009 11:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJBFiOCAd8gm for ; Mon, 23 Feb 2009 11:11:50 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id DCDE93A6872 for ; Mon, 23 Feb 2009 11:11:50 -0800 (PST) Received: (qmail 64889 invoked from network); 23 Feb 2009 19:12:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 23 Feb 2009 19:12:08 -0000 X-YMail-OSG: Gj29u1oVM1ldWTxZUC2Y.K1ola64GJSpOayCuI03xpKXhMQI.Mcl0OwQAbdqetV2_EvCjv136RA9J223ihqfiScyftLCMBvOUfwhTa7dc9UuuWyNeTP3dgBLL3bBLFJNCXhej3u1JOV06NWcKimTxCes X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A2F507.5000105@netconfcentral.com> Date: Mon, 23 Feb 2009 11:12:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200902231834.n1NIYZoZ031833@idle.juniper.net> In-Reply-To: <200902231834.n1NIYZoZ031833@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:11:51 -0000 Phil Shafer wrote: > Andy Bierman writes: >> 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? > > 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 ">", 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. > 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). > Thanks, > Phil Andy > > ----------- > > % cat /tmp/foo.xml > > ]]>mumble?> > > > > > ]]>ble?> > > > > 1 > 2 > 3 > 4 > > > > % xmllint /tmp/foo.xml > > ]]>mumble?> > > > > ]]>ble?> > > > 1 > 2 > 3 > 4 > > > > From cfinss@dial.pipex.com Tue Feb 24 04:20:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6951928C134 for ; Tue, 24 Feb 2009 04:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s88pwaQLR9nO for ; Tue, 24 Feb 2009 04:20:14 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 48A7E28C12C for ; Tue, 24 Feb 2009 04:20:14 -0800 (PST) X-Trace: 222864028/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.158/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.158 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIN0o0k+vBGe/2dsb2JhbACDQ0GKEMhQB4QKBg X-IronPort-AV: E=Sophos;i="4.38,259,1233532800"; d="scan'208";a="222864028" X-IP-Direction: IN Received: from 1cust158.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.158]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Feb 2009 12:20:29 +0000 Message-ID: <014801c99671$b6bbc680$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Per Hedeland" References: <200902190532.n1J5Wg6V041554@idle.juniper.net> <499CFFA4.9090004@tail-f.com> <20090219072830.GA11559@elstar.iuhb02.iu-bremen.de> <000201c992b8$7bd58b80$0601a8c0@allison> <499E5FCC.6080105@ericsson.com> <1235382040.6383.27.camel@missotis> <49A27358.2000009@ericsson.com> <1235384000.6383.36.camel@missotis><49A2793C.308@tail-f.com> <1235386465.6383.58.camel@missotis><49A28E53.5010309@tail-f.com> <49A2E711.3000602@netconfcentral.com> Date: Tue, 24 Feb 2009 12:12:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message integrity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 12:20:15 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Per Hedeland" Cc: Sent: Monday, February 23, 2009 7:12 PM Subject: Re: [Netconf] NETCONF message integrity > Per Hedeland wrote: > > On 2009-02-23 11:54, Ladislav Lhotka wrote: > >> Per Hedeland píae v Po 23. 02. 2009 v 11:23 +0100: > >>> 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. > >> 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 "]]>]]]" and then the extra bracket won't get removed. > > > > 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. > > > > 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. > 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 > 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 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 , so it won't. > So how will version 2 managers talk to version 1 agents? > Try v2. It fails, then start over with v1? > > > --Per > > Andy > From andy@netconfcentral.com Tue Feb 24 10:24:28 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C893A6A15 for ; Tue, 24 Feb 2009 10:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmfrZcw-o7lN for ; Tue, 24 Feb 2009 10:24:27 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id E75F83A69E3 for ; Tue, 24 Feb 2009 10:24:27 -0800 (PST) Received: (qmail 7513 invoked from network); 24 Feb 2009 18:24:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 24 Feb 2009 18:24:46 -0000 X-YMail-OSG: 9a.SC9UVM1nZM.zpyHbf6MzzZFq_mcEUagUWG48WvoEtQNMpa36f8rye2QyRG00wjrJUl.Qvz9aDal8q5kNpHKlUvQ1Fv9leST3RpesdlExaFKaJo7P2BIIflFWBS_wXh0Rxx5Qn3.x0mboxquguRshcfdXNFJA5OouwS_ibih6v7gjlSP7Jgto6irRO9Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A43B6D.7050308@netconfcentral.com> Date: Tue, 24 Feb 2009 10:24:45 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Content-Type: multipart/mixed; boundary="------------010506030400090503040903" Subject: [Netconf] with-defaults.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:24:28 -0000 This is a multi-part message in MIME format. --------------010506030400090503040903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I think the attached YANG module is closer to the syntax that Phil and others expected for the leaf, than the current draft. I prefer that the new leaf be defined in one specific XML namespace. The text about "if no namespace is used, then the agent MUST accept it anyway" contradicts the XML standard, which NETCONF must follow. (2.5, para 4) Andy --------------010506030400090503040903 Content-Type: text/plain; name="with-defaults.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="with-defaults.yang" module with-defaults { namespace "TBD-by-IANA-with-defaults"; prefix "wd"; import netconf { prefix nc; } organization "Network Configuration Working Group"; contact "WG Web: WG List: WG Chair: Bert Wijnen WG Chair: Mehmet Ersue Editor: Andy Bierman Editor: Balazs Lengyel "; description "YANG version of with-defaults data model."; revision 2009-02-24 { description "Initial version."; } grouping WithDefaults { leaf with-defaults { description "With default agent behavior: - false: default data SHOULD NOT be returned. - true: all default data MUST be returned. If not present, then the 'with-defaults' behavior is implementation-dependent."; type boolean; } } augment "/nc:get/nc:input" { uses WithDefaults; } augment "/nc:get-config/nc:input" { uses WithDefaults; } augment "/nc:copy-config/nc:input" { uses WithDefaults; } } --------------010506030400090503040903-- From phil@juniper.net Tue Feb 24 11:05:55 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04CE3A6B3C for ; Tue, 24 Feb 2009 11:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hiHhFjtubG6 for ; Tue, 24 Feb 2009 11:05:54 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 2B0B13A6927 for ; Tue, 24 Feb 2009 11:05:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSaRFIweGiO7b5Uzw1OeFuJ+dco1PmuOL@postini.com; Tue, 24 Feb 2009 11:06:14 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Feb 2009 11:02:59 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 11:02:59 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 11:02:19 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 11:02:18 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1OJ2IM96011; Tue, 24 Feb 2009 11:02:18 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n1OIthOk041051; Tue, 24 Feb 2009 18:55:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902241855.n1OIthOk041051@idle.juniper.net> To: Andy Bierman In-Reply-To: <49A43B6D.7050308@netconfcentral.com> Date: Tue, 24 Feb 2009 13:55:43 -0500 From: Phil Shafer X-OriginalArrivalTime: 24 Feb 2009 19:02:18.0695 (UTC) FILETIME=[6A34A570:01C996B2] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] with-defaults.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:05:55 -0000 Andy Bierman writes: > augment "/nc:copy-config/nc:input" { > uses WithDefaults; > } Does this conflict with the existing NETCONF idea that copy-config does a higher-level datastore-oriented copy, rather than one that inspects the configuration nodes? I can't find this idea called out strongly enough in the RFC to matter, but I recall the idea was that copy-config did a copy without regard for the content. Does this idea still exist? Thanks, Phil From andy@netconfcentral.com Tue Feb 24 11:24:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1818628C15B for ; Tue, 24 Feb 2009 11:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOHl7mwzulM1 for ; Tue, 24 Feb 2009 11:24:24 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 6F04728C113 for ; Tue, 24 Feb 2009 11:24:24 -0800 (PST) Received: (qmail 92027 invoked from network); 24 Feb 2009 19:24:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 24 Feb 2009 19:24:43 -0000 X-YMail-OSG: lmKFiigVM1l9qODvd7WfLSLaL8dDN6uraVHVLMQwC.tmgsJumHPmVLuuHQ5PqAd3Rtr0bME1ktZA90vLyTAGBN7At0uv0CmaQJoDOolp8jB1L50PXiW0SpU3XW1PjFPGb6Df.Ca5gDakE65kMm4D7K87 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A4497A.3080006@netconfcentral.com> Date: Tue, 24 Feb 2009 11:24:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200902241855.n1OIthOk041051@idle.juniper.net> In-Reply-To: <200902241855.n1OIthOk041051@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:24:25 -0000 Phil Shafer wrote: > Andy Bierman writes: >> augment "/nc:copy-config/nc:input" { >> uses WithDefaults; >> } > > Does this conflict with the existing NETCONF idea that copy-config > does a higher-level datastore-oriented copy, rather than one that > inspects the configuration nodes? I can't find this idea called > out strongly enough in the RFC to matter, but I recall the idea was > that copy-config did a copy without regard for the content. Does > this idea still exist? > AFAIK, the only mandatory copy-config operation is from to , if :startup is supported. I think with-defaults applies in that situation. I agree with you (in this case and in general) that 'feature-creep' seems to occur to NETCONF sometimes. It was never the intent the the target of a be a standard database, in any other use case except :startup. Without :url or :startup capabilities, there is nothing mandatory to support for . > Thanks, > Phil > > Andy From root@core3.amsl.com Tue Feb 24 11:30:01 2009 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F10763A68A7; Tue, 24 Feb 2009 11:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090224193001.F10763A68A7@core3.amsl.com> Date: Tue, 24 Feb 2009 11:30:01 -0800 (PST) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:30:02 -0000 --NextPart 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 : NETCONF Over Transport Layer Security (TLS) Author(s) : M. Badra Filename : draft-ietf-netconf-tls-07.txt Pages : 9 Date : 2009-02-24 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-tls-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-24112619.I-D@ietf.org> --NextPart-- From mbadra@gmail.com Tue Feb 24 11:30:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F7828C185 for ; Tue, 24 Feb 2009 11:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7+xZk2PkTIP for ; Tue, 24 Feb 2009 11:30:08 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 9BAF528C179 for ; Tue, 24 Feb 2009 11:30:07 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so132000fgb.41 for ; Tue, 24 Feb 2009 11:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=pcBwLrzLw0uATyRpQ1iayrauDVWpYoOKcvAoKfb9ksg=; b=JECmxjx/q5NgTmit+Cv8YiOzFdbJ1/jDJcx/2x3PNouZuMtHnV5xxrnPoEq6XbnCxP jI5HXP6QZJwmi2qtHbccBiKYuTJZ3Y4m5YcScVSo9918PGSC/IS8FgVOwSZpGj9QYVlZ V2I1XHx/xQo+a7/eFPYJy1MGRHSb2I19Z/j4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=bcxHkUwk9vY5R0N3CjjrJBI+rKmyimKd2FjtKh+9tVaVvCuWX2PgFtvdwx/LsGJ5lh wV8+kE9p8Z2vhFG2HSV09000A7mf4cFT95UvjNwMJz9jt8udvk4aKlV3HPFU2HXt6qwB h85UPDwG5p6yZ+ZkbgffVGpNLsUMpm8z0pjzo= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.83.1 with SMTP id g1mr1069fgb.20.1235503826415; Tue, 24 Feb 2009 11:30:26 -0800 (PST) In-Reply-To: <20090224192619.504DE28C1E5@core3.amsl.com> References: <20090224192619.504DE28C1E5@core3.amsl.com> Date: Tue, 24 Feb 2009 20:30:26 +0100 X-Google-Sender-Auth: 23c592ff7b642b0d Message-ID: From: Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=000e0cd250aab12fe70463af2616 Subject: [Netconf] New Version Notification for draft-ietf-netconf-tls-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:30:08 -0000 --000e0cd250aab12fe70463af2616 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, Please find an updated version as required by our AD Dan Romascanu, based on the WG discussion and consensus call. We are going to bring it to the next step. http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt Best regards Badra --000e0cd250aab12fe70463af2616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear all,

=A0

Please find an updated version as required by our AD Dan Ro= mascanu,=A0based on the WG discussion and consensus call.=A0We are going to= bring it to the next step.

http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt

Best regards

Badra

--000e0cd250aab12fe70463af2616-- From mehmet.ersue@nsn.com Wed Feb 25 07:55:51 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3539F3A6A95 for ; Wed, 25 Feb 2009 07:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw0KB31SQFvE for ; Wed, 25 Feb 2009 07:55:50 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C915C3A6805 for ; Wed, 25 Feb 2009 07:55:49 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1PFu5lt027835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Feb 2009 16:56:05 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1PFu5n1026639; Wed, 25 Feb 2009 16:56:05 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 16:56:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99761.8F91466E" Date: Wed, 25 Feb 2009 16:56:03 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bringing the TLS draft to the next step WAS:RE: [Netconf] New Version Notification for draft-ietf-netconf-tls-07 Thread-Index: AcmWtoQr7D94Ko9sSz69t7nEKUu3uwAqoQhQ References: <20090224192619.504DE28C1E5@core3.amsl.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 25 Feb 2009 15:56:04.0809 (UTC) FILETIME=[9076B390:01C99761] Subject: [Netconf] Bringing the TLS draft to the next step WAS:RE: New Version Notification for draft-ietf-netconf-tls-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:55:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99761.8F91466E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, =20 we had a chat with our AD Dan Romascanu on the message=20 integrity issue and how we should proceed with the TLS draft. Current version is draft-ietf-netconf-tls-07.txt. =20 Our conclusion from the feedback on the mailing list and our chat with the AD is that it would be the best if we bring the NETCONF=20 over TLS document to RFC and get it published. =20 We, the WG chairs, still think that the EOM or message integrity=20 issue is not specific to Netconf over TLS and a satisfying solution=20 (addressing also NETCONF base and SSH transport protocols)=20 can only be found if it's developed in conjunction with access=20 control. Therefor we don't see a TLS-only solution, which would=20 obviously differs from the current SSH transport, as appropriate.=20 =20 We would like to encourage a discussion on the message integrity=20 issue in San Francisco meeting and ask whether the WG members=20 are interested to work on a generic and complete solution. The=20 development of this issue can then be started after re-chartering. =20 For now, we will bring the updated version of the TLS draft to the next step, which is IESG review. If possible Dan will bring it to the=20 next IESG chat. =20 Thank you all again for supporting the TLS RFC development.=20 =20 Bert & Mehmet=20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Badra Sent: Tuesday, February 24, 2009 8:30 PM To: netconf@ietf.org Subject: [Netconf] New Version Notification for draft-ietf-netconf-tls-07 =09 =09 Dear all, Please find an updated version as required by our AD Dan Romascanu, based on the WG discussion and consensus call. We are going to bring it to the next step. =09 =09 http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt =09 Best regards =09 Badra ------_=_NextPart_001_01C99761.8F91466E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF=20 WG,

we had a chat with our AD Dan Romascanu on the message=20
integrity issue and how we should proceed with the TLS = draft.
Current=20 version is draft-ietf-netconf-tls-07.txt.

Our conclusion = from the=20 feedback on the mailing list and our chat
with the AD is that it = would be the=20 best if we bring the NETCONF

over TLS=20 document to RFC and get it=20 published.

We, the WG chairs, still think that the = EOM or=20 message integrity
issue is not specific to Netconf over TLS and a = satisfying=20 solution
(addressing also NETCONF base and SSH transport = protocols)
can only be found if it's = developed in=20 conjunction with access
control. Therefor we don't see a TLS-only = solution,=20 which would
obviously differs from the current SSH transport, as=20 appropriate.

We would like to encourage a discussion on = the=20 message integrity
issue in San Francisco meeting and ask whether the = WG=20 members
are interested to work on a generic and complete solution. = The=20
development of this issue can then be started after=20 re-chartering.

For now, we will bring the updated version = of the=20 TLS draft to the
next step, which is IESG review. If possible Dan = will bring=20 it to the
next IESG chat.

Thank you all again for = supporting=20 the TLS RFC development.

Bert & Mehmet =

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext=20 Badra
Sent: Tuesday, February 24, 2009 8:30 PM
To: = netconf@ietf.org
Subject: [Netconf] New Version Notification = for=20 draft-ietf-netconf-tls-07

Dear all,

Please find an updated version as required by our AD Dan=20 Romascanu, based on the WG discussion and consensus call. We = are=20 going to bring it to the next step.

http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt
Best=20 regards

Badra

------_=_NextPart_001_01C99761.8F91466E-- From andy@netconfcentral.com Wed Feb 25 09:34:47 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4902928C1A3 for ; Wed, 25 Feb 2009 09:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBEgTIYm4tM6 for ; Wed, 25 Feb 2009 09:34:46 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 7CBAD28C16F for ; Wed, 25 Feb 2009 09:34:46 -0800 (PST) Received: (qmail 70044 invoked from network); 25 Feb 2009 17:35:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 17:35:05 -0000 X-YMail-OSG: fGSr2PQVM1l4_PyxS3wSQ.CYYbg1mSYAxxe5plafFkTtkgSx4Qe0aXNzvFxTKhavv_96luaECv.bdMrrke5Q73xK.xfdyRdjTrYmIXXHOk0TSsI1hSLEDrATgAu6sABVeXGCpua8PwGrZG7hTy2cLRZL X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A58148.4070704@netconfcentral.com> Date: Wed, 25 Feb 2009 09:35:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] comments on netconf-monitoring-03 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:34:47 -0000 Hi, I have some initial comments, not sure if they are already resolved or not: 1) bug: top of pg 16, example start-tag paired with end-tag 2) netconf container What about renaming it to 'netconf-state'? IMO this sets a clear and workable precedent. Use 1 top-level element with the same name as the YANG module. It also solves the problem of a read-only vs. read-write /netconf container. 3) Should this element be the exact capabilities given in the or should the netconf namespace be changed to the netconf-state namespace (as the draft defines now)? IMO it is confusing and code which understands the cannot be reused to handle the netconf-state data-model. 4) static elements I assume there will be always be an entry for each of the 3 databases supported by the agent. I.e., at least one entry for . Adding and deleting these based on the current state of the locks would complicate things. 5) empty OK? It seems useful and convenient to be able to return an empty locks container, especially if there are lots of partial locks or a big database. An implementation should not need to search out all the partial locks twice (w/ added race condition) to make sure there really is at least 1 partial lock to report. 6) session drops a) The inBadHellos object should mention that sessions dropped because a was never received are also included in this counter. b) should there be an 'abnormalTerminations' counter to count any sessions terminated for an abnormal reason (i.e., other than close-session, kill-session, already counted in inBadHellos) c) should transport connection drops by the manager be counted in any way? 7) usage statistics There is no total bytes counters, only message counters. Is this on purpose? Were usage statistics rejected? 8) per-session statistics There are none. Is it worth it to add them, perhaps as an additional capability? Perhaps more than one session is active at the same time. The global counters will not give a clean view of the problem, and be useless. 9) get-schema RPC operation The positive and negative response parts of the template are missing. What errors are to be expected? Is it operation-failed if the module name/revision are not found? What if the requested format is not available? 10) User name This field is fairly vague, which matches the NETCONF architecture wrt/ this subject. What is the 'owner'? Should there be some more text here? This is going to show up later for access control work, so might as well get it correct now. 11) Documentation style I really like the 'info-model' style of documentation much better than the MIB style. It is easy to read and easy to find stuff. I hope all NETCONF data model drafts follow this style. Andy From balazs.lengyel@ericsson.com Thu Feb 26 00:52:22 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A661D28C19F for ; Thu, 26 Feb 2009 00:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJkL7pUcuYdO for ; Thu, 26 Feb 2009 00:52:21 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C9F2D28C1CD for ; Thu, 26 Feb 2009 00:52:21 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C896211C5; Thu, 26 Feb 2009 09:52:28 +0100 (CET) X-AuditID: c1b4fb3e-ac0bbbb000001315-6d-49a658216e87 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A08D1210A3; Thu, 26 Feb 2009 09:51:45 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 09:51:44 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 09:51:44 +0100 Message-ID: <49A6581F.4040808@ericsson.com> Date: Thu, 26 Feb 2009 09:51:43 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <49A43B6D.7050308@netconfcentral.com> In-Reply-To: <49A43B6D.7050308@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2009 08:51:44.0193 (UTC) FILETIME=[732AC310:01C997EF] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] with-defaults.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:52:22 -0000 Hello Andy, Andy Bierman wrote: > Hi, > > I think the attached YANG module is closer to the syntax > that Phil and others expected for the leaf, > than the current draft. > > I prefer that the new leaf be defined in one specific > XML namespace. The text about "if no namespace is used, > then the agent MUST accept it anyway" contradicts the > XML standard, which NETCONF must follow. (2.5, para 4) BALAZS: OK I will remove the sentence "if no namespace ..." Otherwise I think your YANG is the same as what the current text and the XSD describe. Do you see any difference? We could include the YANG as a non-normative appendix. The reason I would rather not do this is that there is no official/semi-official YAM for the Netconf XSD. Balazs From balazs.lengyel@ericsson.com Thu Feb 26 00:57:22 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5448928C1CD for ; Thu, 26 Feb 2009 00:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9ztXZ5bBoMG for ; Thu, 26 Feb 2009 00:57:21 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4AA9828C19F for ; Thu, 26 Feb 2009 00:57:21 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B51CC21506; Thu, 26 Feb 2009 09:54:32 +0100 (CET) X-AuditID: c1b4fb3e-ae8c0bb000001315-51-49a6589ba593 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 731A62150A; Thu, 26 Feb 2009 09:53:47 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 09:53:40 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 09:53:40 +0100 Message-ID: <49A65894.1060902@ericsson.com> Date: Thu, 26 Feb 2009 09:53:40 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200902241855.n1OIthOk041051@idle.juniper.net> In-Reply-To: <200902241855.n1OIthOk041051@idle.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2009 08:53:40.0424 (UTC) FILETIME=[B8723480:01C997EF] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] with-defaults.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:57:22 -0000 Hello Phil, Could you please give some examples where the datastore oriented and the node-inspecting copy-configs would lead to different results? Balazs Phil Shafer wrote: > Does this conflict with the existing NETCONF idea that copy-config > does a higher-level datastore-oriented copy, rather than one that > inspects the configuration nodes? I can't find this idea called > out strongly enough in the RFC to matter, but I recall the idea was > that copy-config did a copy without regard for the content. Does > this idea still exist? From bertietf@bwijnen.net Thu Feb 26 08:29:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0353928C0F7 for ; Thu, 26 Feb 2009 08:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.068 X-Spam-Level: X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSbMFWR2Glca for ; Thu, 26 Feb 2009 08:29:23 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 3A0883A6829 for ; Thu, 26 Feb 2009 08:29:23 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Lcj73-0002iG-LR; Thu, 26 Feb 2009 17:29:30 +0100 Message-ID: <08332EA1C1F240958EC552C561A9A4F1@BertLaptop> From: "Bert Wijnen $IETF$" To: "Netconf" Date: Thu, 26 Feb 2009 17:28:42 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1704_01C99837.ABBE2BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: Margaret Wasserman Subject: [Netconf] WG Last Call: Pls review proposed text change regarding: [Technical Errata Reported] RFC4742 (1628) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: