From j.schoenwaelder@jacobs-university.de Fri Nov 1 06:03:59 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2621E843D for ; Fri, 1 Nov 2013 06:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg0LuoLRwmNG for ; Fri, 1 Nov 2013 06:03:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDA621E83F0 for ; Fri, 1 Nov 2013 05:59:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F79C200BF; Fri, 1 Nov 2013 13:59:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7xaqE9KU53Bf; Fri, 1 Nov 2013 13:59:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E269200A8; Fri, 1 Nov 2013 13:59:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC87629236B1; Fri, 1 Nov 2013 13:58:59 +0100 (CET) Date: Fri, 1 Nov 2013 13:58:59 +0100 From: Juergen Schoenwaelder To: Joe Touch Message-ID: <20131101125859.GB63548@elstar.local> Mail-Followup-To: Joe Touch , Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org References: <5272975A.2030904@isi.edu> <20131031.191446.362075100.mbj@tail-f.com> <52729EC4.1050703@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52729EC4.1050703@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 13:04:00 -0000 On Thu, Oct 31, 2013 at 11:17:40AM -0700, Joe Touch wrote: > > > On 10/31/2013 11:14 AM, Martin Bjorklund wrote: > >Kent Watsen wrote: > >> > >> > >>On 10/31/13 1:46 PM, "Joe Touch" wrote: > >> > >>> > >>>Why would (should) that not happen in-band, as part of the message type? > >> > >>Because it would require updating both the SSH and TLS protocols to enable > >>reversal before the crypto tunnel is setup. This is not likely to garner > >>consensus given the Applicability Statements limiting the solution to just > >>NETCONF, especially given the option to use a port instead. > > > >Agreed. Also, I think these are fundamentally two different services; > >one is a NETCONF server (e.g. some managed device) and the other a > >NETCONF client (e.g. a NMS). > > First, can any of that be explained in this doc? > > In specific: > > - how the services differ > > - why reversing the existing netconf-ssh system > isn't a useful way forward > > - the specific use case where both a client and server > would sit on the same device, and why those would be independent > > All of these questions are begged by the name "reverse NETCONF". If > that's not what you're really doing, this needs a better, more > accurate description. Does this help: A NC client and a NC server provide two different services. The NC server executes RPC requests and manipulates local datastores while the NC client invokes RPC requests. It is possible to have both an NC server and an NC client running on the same node (e.g., the node runs a NC server and the NC client on the same node manages the node's configuration via NC). The port number xyz is used by NC servers. NC clients connect to the server on port xyz in order to execute RPC calls on the server. The port number abc is used by NC clients if they support call-home. An NC server using call-home will connect to an NC client in order to let the client subsequently initiate RPC calls. The NC client has the logic to manipulate configurations (e.g., executing network-wide configuration change transactions) while the NC server provides an interface to manage (edit) its local configuration maintained in configuration datastores. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From touch@isi.edu Fri Nov 1 07:18:18 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0321E8450 for ; Fri, 1 Nov 2013 07:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mqJTVYJBala for ; Fri, 1 Nov 2013 07:18:10 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5C21E83CC for ; Fri, 1 Nov 2013 07:17:57 -0700 (PDT) Received: from [128.9.176.210] (c2-vpn01.isi.edu [128.9.176.210]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA1EHR8E021416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Nov 2013 07:17:27 -0700 (PDT) Message-ID: <5273B7F7.1050406@isi.edu> Date: Fri, 01 Nov 2013 07:17:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org References: <5272975A.2030904@isi.edu> <20131031.191446.362075100.mbj@tail-f.com> <52729EC4.1050703@isi.edu> <20131101125859.GB63548@elstar.local> In-Reply-To: <20131101125859.GB63548@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:18:19 -0000 On 11/1/2013 5:58 AM, Juergen Schoenwaelder wrote: ... >> All of these questions are begged by the name "reverse NETCONF". If >> that's not what you're really doing, this needs a better, more >> accurate description. > > Does this help: > > A NC client and a NC server provide two different services. The NC > server executes RPC requests and manipulates local datastores while > the NC client invokes RPC requests. It is possible to have both an > NC server and an NC client running on the same node (e.g., the node > runs a NC server and the NC client on the same node manages the > node's configuration via NC). > > The port number xyz is used by NC servers. NC clients connect to the > server on port xyz in order to execute RPC calls on the server. The > port number abc is used by NC clients if they support call-home. An > NC server using call-home will connect to an NC client in order to > let the client subsequently initiate RPC calls. The NC client has > the logic to manipulate configurations (e.g., executing network-wide > configuration change transactions) while the NC server provides an > interface to manage (edit) its local configuration maintained in > configuration datastores. It confirms what I said - that this is just the reverse initiation of an existing service. If that is justification for an assignment, then we would need to potentially double the existing assignments and the rate of assignments - which is why this is problematic and very likely untenable. I'll continue this discussion with others off-list, but at the least the document needs to more clearly explain why a new port is being requested. Joe From mbj@tail-f.com Fri Nov 1 07:40:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53CD21E8288 for ; Fri, 1 Nov 2013 07:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO3UAVv-6bCC for ; Fri, 1 Nov 2013 07:40:30 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 59DC821E8383 for ; Fri, 1 Nov 2013 07:40:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 567D21200054; Fri, 1 Nov 2013 15:40:26 +0100 (CET) Date: Fri, 01 Nov 2013 15:40:26 +0100 (CET) Message-Id: <20131101.154026.166636043402427329.mbj@tail-f.com> To: touch@isi.edu From: Martin Bjorklund In-Reply-To: <5273B7F7.1050406@isi.edu> References: <52729EC4.1050703@isi.edu> <20131101125859.GB63548@elstar.local> <5273B7F7.1050406@isi.edu> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:40:36 -0000 Joe Touch wrote: > > > On 11/1/2013 5:58 AM, Juergen Schoenwaelder wrote: > ... > >> All of these questions are begged by the name "reverse NETCONF". If > >> that's not what you're really doing, this needs a better, more > >> accurate description. > > > > Does this help: > > > > A NC client and a NC server provide two different services. The NC > > server executes RPC requests and manipulates local datastores while > > the NC client invokes RPC requests. It is possible to have both an > > NC server and an NC client running on the same node (e.g., the node > > runs a NC server and the NC client on the same node manages the > > node's configuration via NC). > > > > The port number xyz is used by NC servers. NC clients connect to the > > server on port xyz in order to execute RPC calls on the server. The > > port number abc is used by NC clients if they support call-home. An > > NC server using call-home will connect to an NC client in order to > > let the client subsequently initiate RPC calls. The NC client has > > the logic to manipulate configurations (e.g., executing network-wide > > configuration change transactions) while the NC server provides an > > interface to manage (edit) its local configuration maintained in > > configuration datastores. > > It confirms what I said - that this is just the reverse initiation of > an existing service. If that is justification for an assignment, then > we would need to potentially double the existing assignments and the > rate of assignments - which is why this is problematic and very likely > untenable. I think we're going in circles. I think that you suggest that a single port is used, and that some signalling is used in-band before the SSH session is started. This would be fine, except that this is not how the existing protocol (on port 830) works. (I think there are other usability issues with this approach as well, but that's not important now). So this in-band signalling doesn't work; and we need a new port. If this is not what you propose, could you explain what you mean? /martin From andy@yumaworks.com Fri Nov 1 07:54:38 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D3621E8383 for ; Fri, 1 Nov 2013 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGODEOFIpbHh for ; Fri, 1 Nov 2013 07:54:34 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id B55B911E817D for ; Fri, 1 Nov 2013 07:54:34 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lf10so4137875pab.34 for ; Fri, 01 Nov 2013 07:54:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jbUEb2ej5hKOsYMUaPbX1GHM77URkjSysdjbMbs94F8=; b=T1W99sKkYjiuQADlgCoC8WEIwOEbb5vi1LY8f62Iv4obT7X8C0aQCxGpf/nmC0qA1M 8TIB7E0E2rYODAlq/0tUazEi16HPsG9ISKdg8yx7vnl8B6fXfGWTL4bSXt2VyQM2Gjwu jGaih16m6cV2q7oPJIdYTHFSkEMrhcO2Ihg6naoqMFWyIx8ZEGMwvCSnmjrhffvMI3hV vca7/T3Eq4M8WVSxR6rP69SgUBcBm0zao4hZZJQisVMN9bGHeaQ1cLycvnOLsbUbzypl FX3iAIZBTNOtnnhtw344CYbuvs9L//RtcpPvICMXzGFYkTl8iMBQDNT/Q5uREv0rF6De +N0w== X-Gm-Message-State: ALoCoQmbVFoSdwy5O0uDpsycHaud8EXPCAQEHmHZVXu4wWwosYEnBRvwTbohZH0SJdcWwnyIOKTx MIME-Version: 1.0 X-Received: by 10.66.139.38 with SMTP id qv6mr3636126pab.59.1383317674413; Fri, 01 Nov 2013 07:54:34 -0700 (PDT) Received: by 10.70.9.33 with HTTP; Fri, 1 Nov 2013 07:54:34 -0700 (PDT) In-Reply-To: <20131101.154026.166636043402427329.mbj@tail-f.com> References: <52729EC4.1050703@isi.edu> <20131101125859.GB63548@elstar.local> <5273B7F7.1050406@isi.edu> <20131101.154026.166636043402427329.mbj@tail-f.com> Date: Fri, 1 Nov 2013 07:54:34 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11331a8c988e2404ea1ebea8 Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:54:39 -0000 --001a11331a8c988e2404ea1ebea8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 1, 2013 at 7:40 AM, Martin Bjorklund wrote: > Joe Touch wrote: > > > > > > On 11/1/2013 5:58 AM, Juergen Schoenwaelder wrote: > > ... > > >> All of these questions are begged by the name "reverse NETCONF". If > > >> that's not what you're really doing, this needs a better, more > > >> accurate description. > > > > > > Does this help: > > > > > > A NC client and a NC server provide two different services. The NC > > > server executes RPC requests and manipulates local datastores while > > > the NC client invokes RPC requests. It is possible to have both an > > > NC server and an NC client running on the same node (e.g., the node > > > runs a NC server and the NC client on the same node manages the > > > node's configuration via NC). > > > > > > The port number xyz is used by NC servers. NC clients connect to the > > > server on port xyz in order to execute RPC calls on the server. The > > > port number abc is used by NC clients if they support call-home. An > > > NC server using call-home will connect to an NC client in order to > > > let the client subsequently initiate RPC calls. The NC client has > > > the logic to manipulate configurations (e.g., executing network-wide > > > configuration change transactions) while the NC server provides an > > > interface to manage (edit) its local configuration maintained in > > > configuration datastores. > > > > It confirms what I said - that this is just the reverse initiation of > > an existing service. If that is justification for an assignment, then > > we would need to potentially double the existing assignments and the > > rate of assignments - which is why this is problematic and very likely > > untenable. > > I think we're going in circles. > > Agreed > I think that you suggest that a single port is used, and that some > signalling is used in-band before the SSH session is started. This > would be fine, except that this is not how the existing protocol (on > port 830) works. (I think there are other usability issues with this > approach as well, but that's not important now). > > I think the usability issues are important. Let's say there was only 1 shared port. An "SSH dispatcher" would have to be rewritten so it could examine the NETCONF message to decide if the session was for the MLM or the server. But this is too late, because SSH has to be setup correctly first. It is also possible that an operator would want to block access on specific ports for 1 role but not the other. This is not possible if they use the same port number. So this in-band signalling doesn't work; and we need a new port. > > If this is not what you propose, could you explain what you mean? > > > /martin > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11331a8c988e2404ea1ebea8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 1, 2013 at 7:40 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Joe Touch <touch@isi.edu> wrote:
>
>
> On 11/1/2013 5:58 AM, Juergen Schoenwaelder wrote:
> ...
> >> All of these questions are begged by the name "reverse N= ETCONF". If
> >> that's not what you're really doing, this needs a bet= ter, more
> >> accurate description.
> >
> > Does this help:
> >
> > =A0 =A0A NC client and a NC server provide two different services= . The NC
> > =A0 =A0server executes RPC requests and manipulates local datasto= res while
> > =A0 =A0the NC client invokes RPC requests. It is possible to have= both an
> > =A0 =A0NC server and an NC client running on the same node (e.g.,= the node
> > =A0 =A0runs a NC server and the NC client on the same node manage= s the
> > =A0 =A0node's configuration via NC).
> >
> > =A0 =A0The port number xyz is used by NC servers. NC clients conn= ect to the
> > =A0 =A0server on port xyz in order to execute RPC calls on the se= rver. =A0The
> > =A0 =A0port number abc is used by NC clients if they support call= -home. =A0An
> > =A0 =A0NC server using call-home will connect to an NC client in = order to
> > =A0 =A0let the client subsequently initiate RPC calls. The NC cli= ent has
> > =A0 =A0the logic to manipulate configurations (e.g., executing ne= twork-wide
> > =A0 =A0configuration change transactions) while the NC server pro= vides an
> > =A0 =A0interface to manage (edit) its local configuration maintai= ned in
> > =A0 =A0configuration datastores.
>
> It confirms what I said - that this is just the reverse initiation of<= br> > an existing service. If that is justification for an assignment, then<= br> > we would need to potentially double the existing assignments and the > rate of assignments - which is why this is problematic and very likely=
> untenable.

I think we're going in circles.


Agreed
=A0
I think that you suggest that a single port is used, and that some
signalling is used in-band before the SSH session is started. =A0This
would be fine, except that this is not how the existing protocol (on
port 830) works. =A0 (I think there are other usability issues with this approach as well, but that's not important now).



I think the usability i= ssues are important.
Let's say there was only 1 shared port.<= /div>
An "SSH dispatcher" would have to be rewritten so it co= uld examine
the NETCONF <hello> message to decide if the session
w= as for the MLM or the server. =A0But this is too late, because SSH
has to be setup correctly first. =A0It is also possible that an operator = would
want to block access on specific ports for 1 role but not the other.
This is not possible if they use the same port number.
<= br>
So this in-band signalling doesn't work; and we need a new port.

If this is not what you propose, could you explain what you mean?


/martin



Andy
=A0
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a11331a8c988e2404ea1ebea8-- From touch@isi.edu Fri Nov 1 08:11:01 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D468D11E8162 for ; Fri, 1 Nov 2013 08:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.542 X-Spam-Level: X-Spam-Status: No, score=-105.542 tagged_above=-999 required=5 tests=[AWL=1.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkGkUCCIZDp3 for ; Fri, 1 Nov 2013 08:10:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D39D021F9C6A for ; Fri, 1 Nov 2013 08:10:55 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id rA1FA9Uf025712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Nov 2013 08:10:18 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: Date: Fri, 1 Nov 2013 08:10:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52729EC4.1050703@isi.edu> <20131101125859.GB63548@elstar.local> <5273B7F7.1050406@isi.edu> <20131101.154026.166636043402427329.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:11:02 -0000 On Nov 1, 2013, at 7:54 AM, Andy Bierman wrote: > ... > I think the usability issues are important. > Let's say there was only 1 shared port. > An "SSH dispatcher" would have to be rewritten so it could examine > the NETCONF message to decide if the session > was for the MLM or the server. But this is too late, because SSH > has to be setup correctly first. It is also possible that an operator = would > want to block access on specific ports for 1 role but not the other. > This is not possible if they use the same port number. >=20 > So this in-band signalling doesn't work; and we need a new port. >=20 > If this is not what you propose, could you explain what you mean? Here's the counterargument: - if that's true for netconf, is it not true for every other service? - would that not double the current allocation, and all future = allocations? - how would that impact the consumption of the port space? That's the problem. You're talking about difficulty of a software = implementation or complexity of management; I'm talking about burning = port numbers in a way that isn't sustainable. That's my concern. I'm not yet convinced that making an exception for = this case doesn't open the floodgates to a problem that might render the = port space full too quickly. Joe= From mbj@tail-f.com Fri Nov 1 08:17:21 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC93B11E8212 for ; Fri, 1 Nov 2013 08:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-HjciHEbecu for ; Fri, 1 Nov 2013 08:17:16 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5F11E8163 for ; Fri, 1 Nov 2013 08:17:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F6EF12000BF; Fri, 1 Nov 2013 16:17:13 +0100 (CET) Date: Fri, 01 Nov 2013 16:17:13 +0100 (CET) Message-Id: <20131101.161713.1148921964267486351.mbj@tail-f.com> To: touch@isi.edu From: Martin Bjorklund In-Reply-To: References: <20131101.154026.166636043402427329.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:17:21 -0000 Joe Touch wrote: > > On Nov 1, 2013, at 7:54 AM, Andy Bierman wrote: > > > ... > > I think the usability issues are important. > > Let's say there was only 1 shared port. > > An "SSH dispatcher" would have to be rewritten so it could examine > > the NETCONF message to decide if the session > > was for the MLM or the server. But this is too late, because SSH > > has to be setup correctly first. It is also possible that an operator > > would > > want to block access on specific ports for 1 role but not the other. > > This is not possible if they use the same port number. > > > > So this in-band signalling doesn't work; and we need a new port. > > > > If this is not what you propose, could you explain what you mean? > > Here's the counterargument: > > - if that's true for netconf, is it not true for every other service? > > - would that not double the current allocation, and all future > allocations? > > - how would that impact the consumption of the port space? > > That's the problem. You're talking about difficulty of a software > implementation or complexity of management; No, it is not an implementation problem, it is a specification problem. If you have a solution that lets us reuse a single port, that's great! Could you share this solution? /martin > I'm talking about burning > port numbers in a way that isn't sustainable. > > That's my concern. I'm not yet convinced that making an exception for > this case doesn't open the floodgates to a problem that might render > the port space full too quickly. > > Joe From kwatsen@juniper.net Fri Nov 1 08:22:44 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF64211E8212 for ; Fri, 1 Nov 2013 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6XQ8ZXkbb5U for ; Fri, 1 Nov 2013 08:22:38 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 32D4211E81C6 for ; Fri, 1 Nov 2013 08:22:38 -0700 (PDT) Received: from mail161-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.22; Fri, 1 Nov 2013 15:22:37 +0000 Received: from mail161-co1 (localhost [127.0.0.1]) by mail161-co1-R.bigfish.com (Postfix) with ESMTP id A9D97A80166; Fri, 1 Nov 2013 15:22:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail161-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(54316002)(56776001)(76482001)(77982001)(81542001)(79102001)(81342001)(80022001)(47446002)(74502001)(74662001)(31966008)(69226001)(46102001)(4396001)(50986001)(47736001)(47976001)(51856001)(83506001)(87266001)(49866001)(76176001)(65816001)(63696002)(59766001)(66066001)(80976001)(76796001)(74706001)(56816003)(76786001)(74876001)(77096001)(85306002)(54356001)(81686001)(81816001)(74366001)(53806001)(36756003)(83072001)(83322001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail161-co1 (localhost.localdomain [127.0.0.1]) by mail161-co1 (MessageSwitch) id 138331935656927_15886; Fri, 1 Nov 2013 15:22:36 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.229]) by mail161-co1.bigfish.com (Postfix) with ESMTP id 00E092004E; Fri, 1 Nov 2013 15:22:36 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 1 Nov 2013 15:22:34 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 1 Nov 2013 15:22:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 1 Nov 2013 15:22:32 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Fri, 1 Nov 2013 15:22:32 +0000 From: Kent Watsen To: Joe Touch , Andy Bierman Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogCAAHbQAIAAhZ+AgACnnQCAAAt7gIAAA6wA///CpoCAAEVhAIAAANAAgAE5S4CAABXsgIAABmwAgAAD8wCAAARdgP//wF4A Date: Fri, 1 Nov 2013 15:22:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.224.36] x-forefront-prvs: 00179089FD Content-Type: text/plain; charset="us-ascii" Content-ID: <71FF957082BCDD49B3057DAA047A0009@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:22:45 -0000 >- if that's true for netconf, is it not true for every other service? No, because we're talking about reversing the crypto layer and not every service has a crypto layer and, for those that do, none other has a need to reverse its crypto layer. This is currently a very unique situation we're discussing for NETCONF. >- would that not double the current allocation, and all future >allocations? If it were true, yes, but it's not true (see above) >- how would that impact the consumption of the port space? We're asking for a total of 2 new ports (one to reverse SSH and another to reverse TLS) >That's the problem. You're talking about difficulty of a software >implementation or complexity of management; I'm talking about burning >port numbers in a way that isn't sustainable. No sustainability issue - this is a one-off. >That's my concern. I'm not yet convinced that making an exception for >this case doesn't open the floodgates to a problem that might render the >port space full too quickly. I think this is unlikely to happen in our lifetimes. Thanks, Kent From touch@isi.edu Fri Nov 1 09:41:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900711E8221 for ; Fri, 1 Nov 2013 09:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HClygzziCjWV for ; Fri, 1 Nov 2013 09:41:30 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B8EED11E8226 for ; Fri, 1 Nov 2013 09:41:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA1GeT9t004914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Nov 2013 09:40:31 -0700 (PDT) Message-ID: <5273D9DB.2020008@isi.edu> Date: Fri, 01 Nov 2013 09:42:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kent Watsen , Andy Bierman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:41:36 -0000 ... >> - how would that impact the consumption of the port space? > > We're asking for a total of 2 new ports (one to reverse SSH and another to > reverse TLS) Why would that not apply to every other service over SSH or TLS? ... >> That's the problem. You're talking about difficulty of a software >> implementation or complexity of management; I'm talking about burning >> port numbers in a way that isn't sustainable. > > No sustainability issue - this is a one-off. For Netconf. I'm considering the impact in the broader context. Joe From kwatsen@juniper.net Fri Nov 1 10:08:44 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0597211E8210 for ; Fri, 1 Nov 2013 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSvxrRuSUO7S for ; Fri, 1 Nov 2013 10:08:23 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 56C0811E80DE for ; Fri, 1 Nov 2013 10:08:20 -0700 (PDT) Received: from mail221-DB9-R.bigfish.com (10.174.16.227) by DB9EHSOBE001.bigfish.com (10.174.14.64) with Microsoft SMTP Server id 14.1.225.22; Fri, 1 Nov 2013 17:08:19 +0000 Received: from mail221-DB9 (localhost [127.0.0.1]) by mail221-DB9-R.bigfish.com (Postfix) with ESMTP id 2E8702200CD; Fri, 1 Nov 2013 17:08:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail221-DB9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(164054003)(51704005)(76786001)(74876001)(56816003)(85306002)(77096001)(80976001)(76796001)(74706001)(83072001)(83322001)(74366001)(36756003)(53806001)(54356001)(81816001)(81686001)(47446002)(74502001)(74662001)(31966008)(56776001)(54316002)(76482001)(79102001)(80022001)(81342001)(81542001)(77982001)(69226001)(59766001)(63696002)(66066001)(65816001)(47736001)(50986001)(83506001)(51856001)(47976001)(46102001)(4396001)(76176001)(49866001)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail221-DB9 (localhost.localdomain [127.0.0.1]) by mail221-DB9 (MessageSwitch) id 1383325697129807_11130; Fri, 1 Nov 2013 17:08:17 +0000 (UTC) Received: from DB9EHSMHS032.bigfish.com (unknown [10.174.16.251]) by mail221-DB9.bigfish.com (Postfix) with ESMTP id 12D22200192; Fri, 1 Nov 2013 17:08:17 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS032.bigfish.com (10.174.14.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 1 Nov 2013 17:08:13 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 1 Nov 2013 17:08:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 1 Nov 2013 17:08:10 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Fri, 1 Nov 2013 17:08:09 +0000 From: Kent Watsen To: Joe Touch , Andy Bierman Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogCAAHbQAIAAhZ+AgACnnQCAAAt7gIAAA6wA///CpoCAAEVhAIAAANAAgAE5S4CAABXsgIAABmwAgAAD8wCAAARdgP//wF4AgABZTID//8Q6AA== Date: Fri, 1 Nov 2013 17:08:09 +0000 Message-ID: In-Reply-To: <5273D9DB.2020008@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.224.36] x-forefront-prvs: 00179089FD Content-Type: text/plain; charset="us-ascii" Content-ID: <60494786F80EF3419A8AFDB51ED4AF36@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 17:08:45 -0000 >>> - how would that impact the consumption of the port space? >> >> We're asking for a total of 2 new ports (one to reverse SSH and another >>to >> reverse TLS) > >Why would that not apply to every other service over SSH or TLS? For one, the Applicability Statements on these drafts limit the proposed solution to just NETCONF. But to your point, it's possible that someday another management protocol may need reversal, but I don't see why any protocol other than a management protocol would want to do this. FWIW, all SSH-based protocols that wanted to be reversed could share the same port. This is possible because the client could just as easily start their subsystem instead of the "netconf" subsystem. Only the applicability statement in the reverse-ssh draft would need to be changed to allow it. So, even in the worst case scenario, no more than one port would be needed to reverse SSH-based protocols. TLS lacks any form of a session protocol enabling to client to select which application-level protocol it wants to run, so a new port would be needed for each TLS-based protocol needing reversal. But as mentioned before, it's not understood why any non-management protocol would need reversal >>>No sustainability issue - this is a one-off. > >For Netconf. I'm considering the impact in the broader context. I understand. What I meant that that within all of the IETF this seems like a one-off. =20 Thanks, Kent From jclarke@cisco.com Fri Nov 1 10:58:28 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC8211E8230 for ; Fri, 1 Nov 2013 10:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEPOwRLkyaHw for ; Fri, 1 Nov 2013 10:58:23 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBCA11E8173 for ; Fri, 1 Nov 2013 10:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3398; q=dns/txt; s=iport; t=1383328703; x=1384538303; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=B/5rO0ZlcWzzDP5Ie9faCbKX6ElCvrmRyi8NgnwUXe8=; b=WwbJfA8fWYkL4hONjifh2wD5z9i3sGJBI7VP7JJHpAqlXL9lvEJPIl00 tvb4iEaIQ6ZGfSXyRo+1OJdPFPZ1wNtVabmj5wmY2fXM29rmUSWdxM2AX wrg3S50lYI4y7rFVSFsTHSu6oG/Cu5yiBfdOc+NOyCNMcA6F06oEiVt0m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAELrc1KrRDoJ/2dsb2JhbABWA4MHOMA3gR4WdIIlAQEBAwE4NQsBDgILDgoJFg8JAwIBAgEJPAYBDAEFAgEBh30FvVYEjguBORAHEYQdA5gKgS+QWoNCIIE1 X-IronPort-AV: E=Sophos;i="4.93,618,1378857600"; d="scan'208";a="93726013" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 01 Nov 2013 17:58:22 +0000 Received: from sjc-vpn5-1599.cisco.com (sjc-vpn5-1599.cisco.com [10.21.94.63]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA1HwJrQ020842; Fri, 1 Nov 2013 17:58:19 GMT Message-ID: <5273EBBB.3030706@cisco.com> Date: Fri, 01 Nov 2013 13:58:19 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Hanna Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 17:58:28 -0000 On 10/31/13, 8:41 AM, Kent Watsen wrote: > > Hi Joe, > >> why would the device need the FQDN of the vendor's DNS >> server? Couldn't it use the domain name with an NS query to get this? >> I'm trying to think of something that may be more scalable over time >> (i.e., if an older device is deployed that may have an old FQDN). > > Because we need to support devices connected to ISP networks (think > McDonalds, Radio Shack, etc.), we cannot assume the presence of any > locally-administered server (DHCP, DNS, LDAP, etc.) that a device could > extract deployment-specific information from. From the device's > perspective, its local DHCP and DNS servers are administered by the ISP, > who is disinclined to allow its customers to insert customer-specific > information into them. Sorry, I think I was unclear. I meant why can't we lookup the NS record in the ISP's DNS? Meaning, why should I statically configure "n1.cisco.com" in all my devices? Why not just configure cisco.com, and have the device do the equivalent "host -t NS cisco.com" to find the nameservers? > > >> What type of DNS queries will be used to get the NMS name and >> credentials? It would be helpful to see a query flow diagram in this >> draft. > > I guess it would be the 'A' record for the > . entry. As pointed out in the Open > Issues section, already we need to extend DNS to accommodate some data, so > including this data in that analysis as well makes sense. Being a -00 > with no implementation as of yet, we're really just fishing to see if the > IETF has interest. If so, then we'd be sure to lock down all the unknowns > at that time. Okay. >> In the security considerations, you mention the potential threat in a >> malicious party learning the NMS FQDN, but I think the NMS authn >> parameters are more sensitive. Additionally, there may be hesitance of >> customers to store authn parameters within a vendor database. One >> potential workaround of this might be an alternate DNS address that the >> new device can query in the customer's network that would provide these >> bits of info. This would maintain the ability to support >> customer-unconfigurable DHCP servers while still allowing things like >> the NMS parameters to be maintained within the customer's network. > > Regarding auth parameters, we'd only support storing public keys or hashed > passwords. As such, the concern for who has access to them is essentially > eliminated. With large enough keys lengths, even a brute force attack > would be acceptably unlikely. I still think we'd see some reluctance here. Even usernames might be revealing. But I get your point. Perhaps it's worth clarifying that in the document's text. One other comment comes to mind... Should the document state that a device can be put back into an initial state to reinitiate Zero-Touch? This may be obvious, but I think it's worth noting that this need not only apply to new devices. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From touch@isi.edu Fri Nov 1 11:21:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCD911E80DE for ; Fri, 1 Nov 2013 11:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cadYLDxVLaVf for ; Fri, 1 Nov 2013 11:21:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE3311E811D for ; Fri, 1 Nov 2013 11:21:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA1ILC5T007238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Nov 2013 11:21:12 -0700 (PDT) Message-ID: <5273F177.2030307@isi.edu> Date: Fri, 01 Nov 2013 11:22:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kent Watsen , Andy Bierman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:21:35 -0000 On 11/1/2013 10:08 AM, Kent Watsen wrote: > >>>> - how would that impact the consumption of the port space? >>> >>> We're asking for a total of 2 new ports (one to reverse SSH and another >>> to >>> reverse TLS) >> >> Why would that not apply to every other service over SSH or TLS? > > > For one, the Applicability Statements on these drafts limit the proposed > solution to just NETCONF. > > But to your point, it's possible that someday another management protocol > may need reversal, but I don't see why any protocol other than a > management protocol would want to do this. > > FWIW, all SSH-based protocols that wanted to be reversed could share the > same port. This is possible because the client could just as easily start > their subsystem instead of the "netconf" subsystem. Only the > applicability statement in the reverse-ssh draft would need to be changed > to allow it. So, even in the worst case scenario, no more than one port > would be needed to reverse SSH-based protocols. The same argument for Netconf-ssh reversal applies to all SSH extensions of services - none of which use SSH ports directly (they all have dedicated ports). > TLS lacks any form of a session protocol enabling to client to select > which application-level protocol it wants to run, so a new port would be > needed for each TLS-based protocol needing reversal. But as mentioned > before, it's not understood why any non-management protocol would need > reversal Sure, but all the "TLS"-suffixed ports are generally management services with this property. >>>> No sustainability issue - this is a one-off. >> >> For Netconf. I'm considering the impact in the broader context. > > I understand. What I meant that that within all of the IETF this seems > like a one-off. If there's a case for that, I'd be glad to hear it, but so far everything (incluging the above) applies to every SSH and TLS extended service. Joe From ietfc@btconnect.com Fri Nov 1 11:37:18 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7211E8177 for ; Fri, 1 Nov 2013 11:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.061 X-Spam-Level: X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NrnWNkVbFq0 for ; Fri, 1 Nov 2013 11:37:12 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 737F111E8170 for ; Fri, 1 Nov 2013 11:37:11 -0700 (PDT) Received: from mail61-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 1 Nov 2013 18:37:00 +0000 Received: from mail61-tx2 (localhost [127.0.0.1]) by mail61-tx2-R.bigfish.com (Postfix) with ESMTP id ED7CA42028E; Fri, 1 Nov 2013 18:36:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail61-tx2 (localhost.localdomain [127.0.0.1]) by mail61-tx2 (MessageSwitch) id 1383331018851182_959; Fri, 1 Nov 2013 18:36:58 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.228]) by mail61-tx2.bigfish.com (Postfix) with ESMTP id C0B544E0034; Fri, 1 Nov 2013 18:36:58 +0000 (UTC) Received: from DBXPRD0710HT002.eurprd07.prod.outlook.com (157.56.253.197) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 1 Nov 2013 18:36:58 +0000 Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.79.165) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 1 Nov 2013 18:36:51 +0000 Message-ID: <00b001ced731$03569ba0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Joe Touch References: Date: Fri, 1 Nov 2013 18:31:32 +0000 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 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:37:18 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Joe Touch" ; "Andy Bierman" Cc: "Netconf" Sent: Friday, November 01, 2013 5:08 PM > > >>> - how would that impact the consumption of the port space? > >> > >> We're asking for a total of 2 new ports (one to reverse SSH and another > >>to > >> reverse TLS) > > > >Why would that not apply to every other service over SSH or TLS? > > > For one, the Applicability Statements on these drafts limit the proposed > solution to just NETCONF. > > But to your point, it's possible that someday another management protocol > may need reversal, but I don't see why any protocol other than a > management protocol would want to do this. > > FWIW, all SSH-based protocols that wanted to be reversed could share the > same port. This is possible because the client could just as easily start > their subsystem instead of the "netconf" subsystem. Only the > applicability statement in the reverse-ssh draft would need to be changed > to allow it. So, even in the worst case scenario, no more than one port > would be needed to reverse SSH-based protocols. > > TLS lacks any form of a session protocol enabling to client to select > which application-level protocol it wants to run, so a new port would be > needed for each TLS-based protocol needing reversal. But as mentioned > before, it's not understood why any non-management protocol would need > reversal > Kent I think that that is a spurious argument. Just because TLS has not got a session layer (some would say SSH hasn't but I know what you are getting at) does not mean that there cannot be a session layer protocol negotiating what happens next - I have proposed just such a one in the past. And there are plenty of such protocols in the early days of the Internet (from where I got my inspiration). We would be using far fewer ports if such session layers were more widespread but I accept that they are not. I understand the other points you are making but I think it weakens your case to argue that because TLS has no session layer then there cannot be such a layer. Tom Petch From andy@yumaworks.com Fri Nov 1 11:57:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB211E81C6 for ; Fri, 1 Nov 2013 11:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWQ23KmX8Lzs for ; Fri, 1 Nov 2013 11:57:45 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id D005711E819D for ; Fri, 1 Nov 2013 11:57:44 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id r10so4221505pdi.18 for ; Fri, 01 Nov 2013 11:57:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OS8rMhddS0kpCaLvpYin0Q/0FzxBIQvPzhrzZkZy9yU=; b=XAhB8ho66GFbVaB781As8UoqFvZbmkqk3+24jGgTBgyM0YjbkLI/asVw2BjMlTWhkr pBnZOY5Mew2hTHWNyHMRHnLZ2bECbPR1AV7xdo7MGprFqRET1q/H2N9hB0KoNYeb5CMq o9Azf/JtYgC5R5jkMBnC6CYZbO9VigtHDF9gm8gbWbp5zTCYu6pkUKs2+lfeKn8GtctX u5JWGNYcckcLdN7535+eR4IjkzQzUX7IzgkpYARx3PB2rI3VaCkhI5QtelOXAF5TDKoH m2C7jraF5/VBceNSm4uwULXvBwcNzMYUDeYu45roa/r+HbJnccbS8tGJdWqgV9SjbrkO pbrg== X-Gm-Message-State: ALoCoQnlMlJQtW3MlZdIsarGbJJtSEtV3SpkEFhLIcUQM7sZ9EzrgrnjhD6xMxLEg63fvhrJ5kdJ MIME-Version: 1.0 X-Received: by 10.68.58.137 with SMTP id r9mr4624627pbq.148.1383332264175; Fri, 01 Nov 2013 11:57:44 -0700 (PDT) Received: by 10.70.9.33 with HTTP; Fri, 1 Nov 2013 11:57:44 -0700 (PDT) In-Reply-To: <00b001ced731$03569ba0$4001a8c0@gateway.2wire.net> References: <00b001ced731$03569ba0$4001a8c0@gateway.2wire.net> Date: Fri, 1 Nov 2013 11:57:44 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=bcaec544ef223682ef04ea22241b Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:57:57 -0000 --bcaec544ef223682ef04ea22241b Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, If a server trying to call-home actually connects to a real NETCONF server instead of a client, then (if the SSH session gets established) both NETCONF servers will ignore the in the other's message and both will sit there waiting for requests. I am also concerned about ACL configuration. It is very likely that an operator would block one role or the other, but not both, based on the location of the NMS, MLMs, and devices in the network. Andy On Fri, Nov 1, 2013 at 11:31 AM, t.petch wrote: > > ----- Original Message ----- > From: "Kent Watsen" > To: "Joe Touch" ; "Andy Bierman" > Cc: "Netconf" > Sent: Friday, November 01, 2013 5:08 PM > > > > >>> - how would that impact the consumption of the port space? > > >> > > >> We're asking for a total of 2 new ports (one to reverse SSH and > another > > >>to > > >> reverse TLS) > > > > > >Why would that not apply to every other service over SSH or TLS? > > > > > > For one, the Applicability Statements on these drafts limit the > proposed > > solution to just NETCONF. > > > > But to your point, it's possible that someday another management > protocol > > may need reversal, but I don't see why any protocol other than a > > management protocol would want to do this. > > > > FWIW, all SSH-based protocols that wanted to be reversed could share > the > > same port. This is possible because the client could just as easily > start > > their subsystem instead of the "netconf" subsystem. Only the > > applicability statement in the reverse-ssh draft would need to be > changed > > to allow it. So, even in the worst case scenario, no more than one > port > > would be needed to reverse SSH-based protocols. > > > > TLS lacks any form of a session protocol enabling to client to select > > which application-level protocol it wants to run, so a new port would > be > > needed for each TLS-based protocol needing reversal. But as mentioned > > before, it's not understood why any non-management protocol would need > > reversal > > > > Kent > > I think that that is a spurious argument. Just because TLS has not got > a session layer (some would say SSH hasn't but I know what you are > getting at) does not mean that there cannot be a session layer protocol > negotiating what happens next - I have proposed just such a one in the > past. And there are plenty of such protocols in the early days of the > Internet (from where I got my inspiration). We would be using far fewer > ports if such session layers were more widespread but I accept that they > are not. > > I understand the other points you are making but I think it weakens your > case to argue that because TLS has no session layer then there cannot be > such a layer. > > Tom Petch > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --bcaec544ef223682ef04ea22241b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom,

If a server trying to call-home= actually connects to a real NETCONF server
instead of a client, = then (if the SSH session gets established) both
NETCONF servers w= ill ignore the <session-id> in the other's <hello>
message and both will sit there waiting for <rpc> requests.

I am also concerned about ACL configuration.
It is very likely that an operator would block one role or the other,
but not both, based on the location of the NMS, MLMs, and devices
in the network.


Andy

On Fri, Nov 1, = 2013 at 11:31 AM, t.petch <ietfc@btconnect.com> wrote:

----- Original Message -----
From: "Kent Watsen" <kw= atsen@juniper.net>
To: "Joe Touch" <touch@isi.ed= u>; "Andy Bierman" <andy@yumaworks.com>
Cc: "Netconf" <netconf@iet= f.org>
Sent: Friday, November 01, 2013 5:08 PM
>
> >>> - how would that impact the consumption of the port space= ?
> >>
> >> We're asking for a total of 2 new ports (one to reverse S= SH and
another
> >>to
> >> reverse TLS)
> >
> >Why would that not apply to every other service over SSH or TLS? >
>
> For one, the Applicability Statements on these drafts limit the
proposed
> solution to just NETCONF.
>
> But to your point, it's possible that someday another management protocol
> may need reversal, but I don't see why any protocol other than a > management protocol would want to do this.
>
> FWIW, all SSH-based protocols that wanted to be reversed could share the
> same port. =A0This is possible because the client could just as easily=
start
> their subsystem instead of the "netconf" subsystem. =A0Only = the
> applicability statement in the reverse-ssh draft would need to be
changed
> to allow it. =A0So, even in the worst case scenario, no more than one<= br> port
> would be needed to reverse SSH-based protocols.
>
> TLS lacks any form of a session protocol enabling to client to select<= br> > which application-level protocol it wants to run, so a new port would<= br> be
> needed for each TLS-based protocol needing reversal. =A0But as mention= ed
> before, it's not understood why any non-management protocol would = need
> reversal
>

Kent

I think that that is a spurious argument. =A0Just because TLS has not got a session layer (some would say SSH hasn't but I know what you are
getting at) does not mean that there cannot be a session layer protocol
negotiating what happens next - I have proposed just such a one in the
past. =A0And there are plenty of such protocols in the early days of the Internet (from where I got my inspiration). =A0We would be using far fewer<= br> ports if such session layers were more widespread but I accept that they are not.

I understand the other points you are making but I think it weakens your case to argue that because TLS has no session layer then there cannot be such a layer.

Tom Petch


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--bcaec544ef223682ef04ea22241b-- From kwatsen@juniper.net Fri Nov 1 12:18:17 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3DC11E8123 for ; Fri, 1 Nov 2013 12:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eltFjLXiDEqU for ; Fri, 1 Nov 2013 12:18:04 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id D096E11E80DE for ; Fri, 1 Nov 2013 12:18:03 -0700 (PDT) Received: from mail127-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.22; Fri, 1 Nov 2013 19:18:03 +0000 Received: from mail127-co9 (localhost [127.0.0.1]) by mail127-co9-R.bigfish.com (Postfix) with ESMTP id 273A3BC0383; Fri, 1 Nov 2013 19:18:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I542I1432I1418I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail127-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(24454002)(164054003)(51444003)(479174003)(377454003)(51704005)(74876001)(76786001)(56816003)(77096001)(85306002)(80976001)(74706001)(76796001)(83072001)(2656002)(19580405001)(83322001)(19580395003)(54356001)(36756003)(53806001)(81816001)(74366001)(81686001)(47446002)(74502001)(74662001)(31966008)(56776001)(54316002)(76482001)(79102001)(80022001)(81342001)(69226001)(63696002)(59766001)(76176001)(4396001)(65816001)(66066001)(81542001)(47736001)(50986001)(51856001)(47976001)(83506001)(46102001)(49866001)(77982001)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail127-co9 (localhost.localdomain [127.0.0.1]) by mail127-co9 (MessageSwitch) id 1383333451995161_22091; Fri, 1 Nov 2013 19:17:31 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.236]) by mail127-co9.bigfish.com (Postfix) with ESMTP id 5CB8912005F; Fri, 1 Nov 2013 19:17:13 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 1 Nov 2013 19:17:13 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 1 Nov 2013 19:17:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 1 Nov 2013 19:17:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Fri, 1 Nov 2013 19:17:09 +0000 From: Kent Watsen To: t.petch , Joe Touch Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogCAAHbQAIAAhZ+AgACnnQCAAAt7gIAAA6wA///CpoCAAEVhAIAAANAAgAE5S4CAABXsgIAABmwAgAAD8wCAAARdgP//wF4AgABZTID//8Q6AAALgFoA///ICAA= Date: Fri, 1 Nov 2013 19:17:08 +0000 Message-ID: In-Reply-To: <00b001ced731$03569ba0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.12] x-forefront-prvs: 00179089FD Content-Type: text/plain; charset="us-ascii" Content-ID: <7A5772716B8481419A89CF1350E0EEBF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$btconnect.com%0%1%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%BTCONNECT.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:18:17 -0000 Good point, Tom. Even good old tcpmux (port 1) defined by Jon Postel... You're right that, if a session-layer were added between TLS and the app-protocol, then the necessary indirection would be in place to allow IETF to only use one port for all protocols. I recall Joe Touch mentioning working on such a thing as well. [technically, we'd need two ports, one for TLS and another for reverse-TLS] To be honest, I don't know why we're still clinging to ports, given that firewalls have long-past moved beyond port-based filtering. I would welcome IETF standardizing something in this area. In the meanwhile, we are where we are, hence the request for a port. Thanks, Kent On 11/1/13 2:31 PM, "t.petch" wrote: > >----- Original Message ----- >From: "Kent Watsen" >To: "Joe Touch" ; "Andy Bierman" >Cc: "Netconf" >Sent: Friday, November 01, 2013 5:08 PM >> >> >>> - how would that impact the consumption of the port space? >> >> >> >> We're asking for a total of 2 new ports (one to reverse SSH and >another >> >>to >> >> reverse TLS) >> > >> >Why would that not apply to every other service over SSH or TLS? >> >> >> For one, the Applicability Statements on these drafts limit the >proposed >> solution to just NETCONF. >> >> But to your point, it's possible that someday another management >protocol >> may need reversal, but I don't see why any protocol other than a >> management protocol would want to do this. >> >> FWIW, all SSH-based protocols that wanted to be reversed could share >the >> same port. This is possible because the client could just as easily >start >> their subsystem instead of the "netconf" subsystem. Only the >> applicability statement in the reverse-ssh draft would need to be >changed >> to allow it. So, even in the worst case scenario, no more than one >port >> would be needed to reverse SSH-based protocols. >> >> TLS lacks any form of a session protocol enabling to client to select >> which application-level protocol it wants to run, so a new port would >be >> needed for each TLS-based protocol needing reversal. But as mentioned >> before, it's not understood why any non-management protocol would need >> reversal >> > >Kent > >I think that that is a spurious argument. Just because TLS has not got >a session layer (some would say SSH hasn't but I know what you are >getting at) does not mean that there cannot be a session layer protocol >negotiating what happens next - I have proposed just such a one in the >past. And there are plenty of such protocols in the early days of the >Internet (from where I got my inspiration). We would be using far fewer >ports if such session layers were more widespread but I accept that they >are not. > >I understand the other points you are making but I think it weakens your >case to argue that because TLS has no session layer then there cannot be >such a layer. > >Tom Petch > > > > From kwatsen@juniper.net Fri Nov 1 12:47:13 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B74D11E8146 for ; Fri, 1 Nov 2013 12:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=1.398, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jwyyg0sf3w5 for ; Fri, 1 Nov 2013 12:47:08 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id DE62311E817A for ; Fri, 1 Nov 2013 12:46:56 -0700 (PDT) Received: from mail218-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Fri, 1 Nov 2013 19:46:56 +0000 Received: from mail218-tx2 (localhost [127.0.0.1]) by mail218-tx2-R.bigfish.com (Postfix) with ESMTP id 2EFE3C0175; Fri, 1 Nov 2013 19:46:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zzbb2dI98dI9371Id772h1dbaI1432I4015I1447Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail218-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51914003)(24454002)(199002)(189002)(377454003)(479174003)(51704005)(164054003)(77096001)(76796001)(56816003)(81342001)(74706001)(56776001)(81542001)(54316002)(74876001)(74662001)(74366001)(81816001)(19580395003)(83322001)(19580405001)(66066001)(74502001)(81686001)(79102001)(65816001)(2656002)(49866001)(63696002)(47446002)(31966008)(83072001)(50986001)(47976001)(76482001)(59766001)(47736001)(77982001)(80022001)(4396001)(53806001)(54356001)(87266001)(46102001)(85306002)(51856001)(76176001)(69226001)(76786001)(83506001)(551544002)(80976001)(36756003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB331; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail218-tx2 (localhost.localdomain [127.0.0.1]) by mail218-tx2 (MessageSwitch) id 1383335213889205_29383; Fri, 1 Nov 2013 19:46:53 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.243]) by mail218-tx2.bigfish.com (Postfix) with ESMTP id D579140064; Fri, 1 Nov 2013 19:46:53 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 1 Nov 2013 19:46:52 +0000 Received: from CO1PR05MB331.namprd05.prod.outlook.com (10.141.69.22) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 1 Nov 2013 19:46:52 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB331.namprd05.prod.outlook.com (10.141.69.22) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 1 Nov 2013 19:46:49 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Fri, 1 Nov 2013 19:46:49 +0000 From: Kent Watsen To: Joe Marcus Clarke , "netconf@ietf.org" Thread-Topic: [Netconf] draft-kwatsen-netconf-zerotouch Thread-Index: AQHO0dJuD3W8i4+gjkmkr6qjDN4wpZoOUMsAgAA1gwCAAi3xgP//2z6A Date: Fri, 1 Nov 2013 19:46:48 +0000 Message-ID: In-Reply-To: <5273EBBB.3030706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.12] x-forefront-prvs: 00179089FD Content-Type: text/plain; charset="us-ascii" Content-ID: <3D350FA6EC62094CACA7FDBC02868DE9@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephen Hanna Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:47:13 -0000 On 11/1/13 1:58 PM, "Joe Marcus Clarke" wrote: >Sorry, I think I was unclear. I meant why can't we lookup the NS record >in the ISP's DNS? Meaning, why should I statically configure >"n1.cisco.com" in all my devices? Why not just configure cisco.com, and >have the device do the equivalent "host -t NS cisco.com" to find the >nameservers? I see, thanks for the clarification. This approach sounds good. The only caution might be that Cisco might want to use a nameserver other than it's standard nameservers for this purpose, so the request might need to go to something other than what the NS record for "cisco.com" returns - what do you think? >>Regarding auth parameters, we'd only support storing public keys or >>hashed >> passwords. As such, the concern for who has access to them is >>essentially >> eliminated. With large enough keys lengths, even a brute force attack >> would be acceptably unlikely. > >I still think we'd see some reluctance here. Even usernames might be >revealing. But I get your point. Perhaps it's worth clarifying that in >the document's text. Absolutely needs to be cleaned up. We also have your idea to have the lookup in the vendor's DNS server be a redirection to a deployment-specific server. We should settle that first. Having a username in the clear may or may not be OK. A couple reasons for why it might be OK are 1) the username itself would likely be something generic (e.g. "admin"), not personally-identifiying and 2) security it's bound to the username, its the key that matters. We'll need to ask the Sec folks what they think about it. >One other comment comes to mind... > >Should the document state that a device can be put back into an initial >state to reinitiate Zero-Touch? This may be obvious, but I think it's >worth noting that this need not only apply to new devices. It should say something, but there is a disagreement as to which way it should go. At least one Security person mentioned that all bets are off on a resale of the device. That is, the previous owner could potentially compromise its crypto chip such that it could no longer be assured to be secure solution. I'm on the fence because 1) it seems unlikely and 2) it should be up to the customer to choose. Thanks, Kent From touch@isi.edu Fri Nov 1 13:31:23 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8297E21E80FA for ; Fri, 1 Nov 2013 13:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnHB59AcECTw for ; Fri, 1 Nov 2013 13:31:18 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C0E3621E8104 for ; Fri, 1 Nov 2013 13:31:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA1KUhcc017083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Nov 2013 13:30:43 -0700 (PDT) Message-ID: <52740FD3.3000901@isi.edu> Date: Fri, 01 Nov 2013 13:32:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kent Watsen , "t.petch" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 20:31:23 -0000 On 11/1/2013 12:17 PM, Kent Watsen wrote: > > Good point, Tom. > > Even good old tcpmux (port 1) defined by Jon Postel... > > You're right that, if a session-layer were added between TLS and the > app-protocol, then the necessary indirection would be in place to allow > IETF to only use one port for all protocols. I recall Joe Touch > mentioning working on such a thing as well. [technically, we'd need two > ports, one for TLS and another for reverse-TLS] Not quite; I was working on a way to decouple the service name from the port number. That would not involve using a single port for all services; that would constrain the number of concurrent connections more than now, rather than relieve those constraints. The original idea is here, though it's evolving and we should be issuing an update shortly, as we're implementing it in Linux and FreeBSD: http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt > To be honest, I don't know why we're still clinging to ports, given that > firewalls have long-past moved beyond port-based filtering. I would > welcome IETF standardizing something in this area. In the meanwhile, we > are where we are, hence the request for a port. To to be clear, I'm not talking about zeroconf, mDNS, tcpmux, or portnames as an alternative. Regardless of the utility of those mechanisms, there will always be requests for specific port numbers, e.g., to allow network administrators to (try to) identify services by port and manage access (e.g., firewalls) accordingly. I do see the goal here, and the reason for the request. I appreciate that the floodgates have not yet opened, but I'm concerned that if netconf over SSH or SSL needs separate port numbers for each service when connections are initiated in reverse, that the same will be true for dozens of other services over SSH or SSL. So this problem isn't going away, and I am hoping those involved here can at least: - appreciate the problem - address it more carefully in this doc - explore alternatives, and at least explain why they don't currently work At a minimum that would help us all figure out how to handle this for the next service that makes this request. Joe From mehmet.ersue@nsn.com Sat Nov 2 13:01:49 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B8E21E80E2 for ; Sat, 2 Nov 2013 13:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.857 X-Spam-Level: X-Spam-Status: No, score=-105.857 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxdvNb81vAg1 for ; Sat, 2 Nov 2013 13:01:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4106821E80DC for ; Sat, 2 Nov 2013 13:01:33 -0700 (PDT) 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 rA2K1Rpv030733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 2 Nov 2013 21:01:27 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA2K1QsW025768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Nov 2013 21:01:26 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 2 Nov 2013 21:01:26 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Sat, 2 Nov 2013 21:01:26 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Joe Touch , Kent Watsen , "t.petch" Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogCAAHbQAIAAhZ+AgACnnQCAAAt7gIAAA6wA///CpoCAAEVhAIAAANAAgAE5S4CAABXsgIAABmwAgAAD8wCAAARdgP//wF4AgABZTID//8Q6AAALgFoA///ICACAAEdOgP//nlkw Date: Sat, 2 Nov 2013 20:01:25 +0000 Message-ID: References: <52740FD3.3000901@isi.edu> In-Reply-To: <52740FD3.3000901@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3246 X-purgate-ID: 151667::1383422488-00005753-C73A3859/0-0/0-0 Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 20:01:49 -0000 Dear Joe, All, We indeed are going in circles. > and I am hoping those involved here can at least: > - appreciate the problem > - address it more carefully in this doc > - explore alternatives, and at least explain why > they don't currently work Thank you for your suggestions. We will. At the end the decision will be taken in the NETCONF session based on the o= ptions available. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Joe Touch > Sent: Friday, November 01, 2013 9:32 PM > To: Kent Watsen; t.petch > Cc: Netconf > Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt >=20 >=20 >=20 > On 11/1/2013 12:17 PM, Kent Watsen wrote: > > > > Good point, Tom. > > > > Even good old tcpmux (port 1) defined by Jon Postel... > > > > You're right that, if a session-layer were added between TLS and the > > app-protocol, then the necessary indirection would be in place to allow > > IETF to only use one port for all protocols. I recall Joe Touch > > mentioning working on such a thing as well. [technically, we'd need t= wo > > ports, one for TLS and another for reverse-TLS] >=20 > Not quite; I was working on a way to decouple the service name from the > port number. That would not involve using a single port for all > services; that would constrain the number of concurrent connections more > than now, rather than relieve those constraints. >=20 > The original idea is here, though it's evolving and we should be issuing > an update shortly, as we're implementing it in Linux and FreeBSD: > http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt >=20 > > To be honest, I don't know why we're still clinging to ports, given tha= t > > firewalls have long-past moved beyond port-based filtering. I would > > welcome IETF standardizing something in this area. In the meanwhile, w= e > > are where we are, hence the request for a port. >=20 > To to be clear, I'm not talking about zeroconf, mDNS, tcpmux, or > portnames as an alternative. Regardless of the utility of those > mechanisms, there will always be requests for specific port numbers, > e.g., to allow network administrators to (try to) identify services by > port and manage access (e.g., firewalls) accordingly. >=20 > I do see the goal here, and the reason for the request. I appreciate > that the floodgates have not yet opened, but I'm concerned that if > netconf over SSH or SSL needs separate port numbers for each service > when connections are initiated in reverse, that the same will be true > for dozens of other services over SSH or SSL. So this problem isn't > going away, and I am hoping those involved here can at least: >=20 > - appreciate the problem > - address it more carefully in this doc > - explore alternatives, and at least explain why > they don't currently work >=20 > At a minimum that would help us all figure out how to handle this for > the next service that makes this request. >=20 > Joe > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From jclarke@cisco.com Sat Nov 2 15:00:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C1921E80E7 for ; Sat, 2 Nov 2013 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfEJjfhwT6KY for ; Sat, 2 Nov 2013 15:00:36 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B77A521E80E6 for ; Sat, 2 Nov 2013 15:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2703; q=dns/txt; s=iport; t=1383429636; x=1384639236; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=H38QoVXb+ieM6t0u1ETXWF6//D4a6nbg+4r8YvD1QUM=; b=kqEx+ZnLSsBA6lJecVLighL94ISdAyLg+plE14gsCX6e3ghVdyMBlSBV 7Xh+kVtN1raIQ6Rn7goVNATUWnUgo664NOJOpV/ByoPcP7BKV6wkmLPwa LQwe60CklbwBL9/r5tKQabR8UkDkKXuU4UUfUkmUbj6xHQxOtl6wX0vQL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEd1dVKrRDoI/2dsb2JhbABVA4MHOMBQgR0WdIIlAQEBAwE4QAEFCQILDgoJFg8JAwIBAgEJPAYBDAEFAgEBF4dgBb0mBI4LgTkQBxGEHQOYCoEvkFqDQiCBNQ X-IronPort-AV: E=Sophos;i="4.93,624,1378857600"; d="scan'208";a="93165804" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 02 Nov 2013 22:00:36 +0000 Received: from sjc-vpn6-769.cisco.com (sjc-vpn6-769.cisco.com [10.21.123.1]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA2M0WEo025830; Sat, 2 Nov 2013 22:00:34 GMT Message-ID: <52757600.1050107@cisco.com> Date: Sat, 02 Nov 2013 18:00:32 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Hanna Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 22:00:42 -0000 On 11/1/13, 3:46 PM, Kent Watsen wrote: > > > On 11/1/13 1:58 PM, "Joe Marcus Clarke" wrote: > >> Sorry, I think I was unclear. I meant why can't we lookup the NS record >> in the ISP's DNS? Meaning, why should I statically configure >> "n1.cisco.com" in all my devices? Why not just configure cisco.com, and >> have the device do the equivalent "host -t NS cisco.com" to find the >> nameservers? > > I see, thanks for the clarification. This approach sounds good. The only > caution might be that Cisco might want to use a nameserver other than it's > standard nameservers for this purpose, so the request might need to go to > something other than what the NS record for "cisco.com" returns - what do > you think? That did occur to me, so perhaps this can be a vendor-selectable thing. It wouldn't matter much to the end consumer, and might scale better for vendors that might see a change to external NSes. > Absolutely needs to be cleaned up. We also have your idea to have the > lookup in the vendor's DNS server be a redirection to a > deployment-specific server. We should settle that first. > > Having a username in the clear may or may not be OK. A couple reasons for > why it might be OK are 1) the username itself would likely be something > generic (e.g. "admin"), not personally-identifiying and 2) security it's > bound to the username, its the key that matters. We'll need to ask the > Sec folks what they think about it. You're right there. My overall point was that the security considerations should mention the fact that the end consumer may not feel comfortable sharing these credentials with the vendor. Even with a hash, an attacker could get it and try and brute force the value. > It should say something, but there is a disagreement as to which way it > should go. At least one Security person mentioned that all bets are off > on a resale of the device. That is, the previous owner could potentially > compromise its crypto chip such that it could no longer be assured to be > secure solution. I'm on the fence because 1) it seems unlikely and 2) it > should be up to the customer to choose. I meant that I as a consumer (and owner) of the device might want to reset the device to factory default to trigger another Zero Touch bootstrap. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From ietfc@btconnect.com Sun Nov 3 03:41:52 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7B111E81DB for ; Sun, 3 Nov 2013 03:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=-2.775, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ohcb8uewu5G for ; Sun, 3 Nov 2013 03:41:47 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 13D6E11E81C8 for ; Sun, 3 Nov 2013 03:41:47 -0800 (PST) Received: from mail201-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE035.bigfish.com (10.174.4.98) with Microsoft SMTP Server id 14.1.225.22; Sun, 3 Nov 2013 11:41:46 +0000 Received: from mail201-db8 (localhost [127.0.0.1]) by mail201-db8-R.bigfish.com (Postfix) with ESMTP id C4F00BA00CC; Sun, 3 Nov 2013 11:41:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz98dI9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail201-db8 (localhost.localdomain [127.0.0.1]) by mail201-db8 (MessageSwitch) id 1383478903710473_6525; Sun, 3 Nov 2013 11:41:43 +0000 (UTC) Received: from DB8EHSMHS022.bigfish.com (unknown [10.174.8.235]) by mail201-db8.bigfish.com (Postfix) with ESMTP id A8069980092; Sun, 3 Nov 2013 11:41:43 +0000 (UTC) Received: from DBXPRD0710HT003.eurprd07.prod.outlook.com (157.56.253.197) by DB8EHSMHS022.bigfish.com (10.174.4.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 3 Nov 2013 11:41:43 +0000 Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.79.166) with Microsoft SMTP Server (TLS) id 14.16.371.2; Sun, 3 Nov 2013 11:41:42 +0000 Message-ID: <015b01ced889$57c6f960$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <00b001ced731$03569ba0$4001a8c0@gateway.2wire.net> Date: Sun, 3 Nov 2013 11:33:38 +0000 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 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 11:41:52 -0000 Andy I think I understand what is being requested, that the Netconf server is the SSH server but is the TCP client. I note however the first line of the I-D "This memo presents a technique for a NETCONF server to initiate a SSH connection to a NETCONF client." It appears to me that that could be clearer, perhaps saying "This memo presents a technique for a NETCONF server to request a NETCONF client to initiate a SSH connection to a NETCONF server." If I understand correctly, expressed thus, all is needed is a signal from NETCONF server to NETCONF client to get on with it, and that signal could be anything, any PDU, any option (a TCP Option? mmm perhaps not), any alarm, alert etc. Looking at it like that, I sympathise with those who think that this may not be the best use of a Port, a resource limited in scope which one day we will run out of. The signal could even be a SYN; if I get a SYN from an address I am configured to understand with a source port assigned for X over Y, then assume that that address wants me to start X over Y as a client. Works for all protocols X and all protocols Y. Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Cc: "Kent Watsen" ; "Joe Touch" ; "Netconf" Sent: Friday, November 01, 2013 6:57 PM Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt > Hi Tom, > > If a server trying to call-home actually connects to a real NETCONF server > instead of a client, then (if the SSH session gets established) both > NETCONF servers will ignore the in the other's > message and both will sit there waiting for requests. > > I am also concerned about ACL configuration. > It is very likely that an operator would block one role or the other, > but not both, based on the location of the NMS, MLMs, and devices > in the network. > > > Andy > > On Fri, Nov 1, 2013 at 11:31 AM, t.petch wrote: > > > > > ----- Original Message ----- > > From: "Kent Watsen" > > To: "Joe Touch" ; "Andy Bierman" > > Cc: "Netconf" > > Sent: Friday, November 01, 2013 5:08 PM > > > > > > >>> - how would that impact the consumption of the port space? > > > >> > > > >> We're asking for a total of 2 new ports (one to reverse SSH and > > another > > > >>to > > > >> reverse TLS) > > > > > > > >Why would that not apply to every other service over SSH or TLS? > > > > > > > > > For one, the Applicability Statements on these drafts limit the > > proposed > > > solution to just NETCONF. > > > > > > But to your point, it's possible that someday another management > > protocol > > > may need reversal, but I don't see why any protocol other than a > > > management protocol would want to do this. > > > > > > FWIW, all SSH-based protocols that wanted to be reversed could share > > the > > > same port. This is possible because the client could just as easily > > start > > > their subsystem instead of the "netconf" subsystem. Only the > > > applicability statement in the reverse-ssh draft would need to be > > changed > > > to allow it. So, even in the worst case scenario, no more than one > > port > > > would be needed to reverse SSH-based protocols. > > > > > > TLS lacks any form of a session protocol enabling to client to select > > > which application-level protocol it wants to run, so a new port would > > be > > > needed for each TLS-based protocol needing reversal. But as mentioned > > > before, it's not understood why any non-management protocol would need > > > reversal > > > > > > > Kent > > > > I think that that is a spurious argument. Just because TLS has not got > > a session layer (some would say SSH hasn't but I know what you are > > getting at) does not mean that there cannot be a session layer protocol > > negotiating what happens next - I have proposed just such a one in the > > past. And there are plenty of such protocols in the early days of the > > Internet (from where I got my inspiration). We would be using far fewer > > ports if such session layers were more widespread but I accept that they > > are not. > > > > I understand the other points you are making but I think it weakens your > > case to argue that because TLS has no session layer then there cannot be > > such a layer. > > > > Tom Petch > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > From j.schoenwaelder@jacobs-university.de Sun Nov 3 10:52:51 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F9821E80F5 for ; Sun, 3 Nov 2013 10:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jra-PiaIbvH for ; Sun, 3 Nov 2013 10:52:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0921E80FC for ; Sun, 3 Nov 2013 10:52:38 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AA1C2007C; Sun, 3 Nov 2013 19:52:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SIhoCX1wO33p; Sun, 3 Nov 2013 19:52:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BAAB2006F; Sun, 3 Nov 2013 19:52:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EBE6C2927ABB; Sun, 3 Nov 2013 19:52:30 +0100 (CET) Date: Sun, 3 Nov 2013 19:52:30 +0100 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20131103185230.GD74233@elstar.local> Mail-Followup-To: "t.petch" , Andy Bierman , Netconf References: <00b001ced731$03569ba0$4001a8c0@gateway.2wire.net> <015b01ced889$57c6f960$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015b01ced889$57c6f960$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:52:51 -0000 On Sun, Nov 03, 2013 at 11:33:38AM +0000, t.petch wrote: > Andy > > I think I understand what is being requested, that the Netconf server is > the SSH server but is the TCP client. I note however the first line of > the I-D > "This memo presents a technique for a NETCONF server to initiate a SSH > connection to a NETCONF client." > It appears to me that that could be clearer, perhaps saying > "This memo presents a technique for a NETCONF server to request a > NETCONF client to initiate a SSH connection to a NETCONF server." > > If I understand correctly, expressed thus, all is needed is a signal > from NETCONF server to NETCONF client to get on with it, and that signal > could be anything, any PDU, any option (a TCP Option? mmm perhaps not), > any alarm, alert etc. > > Looking at it like that, I sympathise with those who think that this may > not be the best use of a Port, a resource limited in scope which one day > we will run out of. > > The signal could even be a SYN; if I get a SYN from an address I am > configured to understand with a source port assigned for X over Y, then > assume that that address wants me to start X over Y as a client. Works > for all protocols X and all protocols Y. Sorry, this is really going into the very wrong direction from an architectural point of view. Such a negotiation needs to happen at the application layer and with NC as it defined today, this implies that it happens _after_ the secure transport has been established. Even with TLS (which uses certs on both sides), I learned at the last IETF that this does not work because even certs are not necessarily symmetric in their properties. With SSH, it is clear that the security association is not symmetric. As such, security people adviced us that the 'direction (who is client and who is server)' must already be clear before the secure transport is established. And this means we need separate ports. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From touch@isi.edu Mon Nov 4 11:25:13 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ABF21E8210 for ; Mon, 4 Nov 2013 11:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K99ncLXrPQO for ; Mon, 4 Nov 2013 11:25:08 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCB421E81D9 for ; Mon, 4 Nov 2013 11:25:08 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA4JOdmL018139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Nov 2013 11:24:40 -0800 (PST) Message-ID: <5277F4E7.2040503@isi.edu> Date: Mon, 04 Nov 2013 11:26:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "t.petch" , Andy Bierman References: <00b001ced731$03569ba0$4001a8c0@gateway.2wire.net> <015b01ced889$57c6f960$4001a8c0@gateway.2wire.net> In-Reply-To: <015b01ced889$57c6f960$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Netconf Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:25:13 -0000 FWIW, this seems like an excellent alternative, given the goal of doc. Joe On 11/3/2013 3:33 AM, t.petch wrote: > Andy > > I think I understand what is being requested, that the Netconf server is > the SSH server but is the TCP client. I note however the first line of > the I-D > "This memo presents a technique for a NETCONF server to initiate a SSH > connection to a NETCONF client." > It appears to me that that could be clearer, perhaps saying > "This memo presents a technique for a NETCONF server to request a > NETCONF client to initiate a SSH connection to a NETCONF server." > > If I understand correctly, expressed thus, all is needed is a signal > from NETCONF server to NETCONF client to get on with it, and that signal > could be anything, any PDU, any option (a TCP Option? mmm perhaps not), > any alarm, alert etc. > > Looking at it like that, I sympathise with those who think that this may > not be the best use of a Port, a resource limited in scope which one day > we will run out of. > > The signal could even be a SYN; if I get a SYN from an address I am > configured to understand with a source port assigned for X over Y, then > assume that that address wants me to start X over Y as a client. Works > for all protocols X and all protocols Y. > > Tom Petch > > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Cc: "Kent Watsen" ; "Joe Touch" ; > "Netconf" > Sent: Friday, November 01, 2013 6:57 PM > Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt > > >> Hi Tom, >> >> If a server trying to call-home actually connects to a real NETCONF > server >> instead of a client, then (if the SSH session gets established) both >> NETCONF servers will ignore the in the other's >> message and both will sit there waiting for requests. >> >> I am also concerned about ACL configuration. >> It is very likely that an operator would block one role or the other, >> but not both, based on the location of the NMS, MLMs, and devices >> in the network. >> >> >> Andy >> >> On Fri, Nov 1, 2013 at 11:31 AM, t.petch wrote: >> >>> >>> ----- Original Message ----- >>> From: "Kent Watsen" >>> To: "Joe Touch" ; "Andy Bierman" >>> Cc: "Netconf" >>> Sent: Friday, November 01, 2013 5:08 PM >>>> >>>>>>> - how would that impact the consumption of the port space? >>>>>> >>>>>> We're asking for a total of 2 new ports (one to reverse SSH and >>> another >>>>>> to >>>>>> reverse TLS) >>>>> >>>>> Why would that not apply to every other service over SSH or TLS? >>>> >>>> >>>> For one, the Applicability Statements on these drafts limit the >>> proposed >>>> solution to just NETCONF. >>>> >>>> But to your point, it's possible that someday another management >>> protocol >>>> may need reversal, but I don't see why any protocol other than a >>>> management protocol would want to do this. >>>> >>>> FWIW, all SSH-based protocols that wanted to be reversed could > share >>> the >>>> same port. This is possible because the client could just as > easily >>> start >>>> their subsystem instead of the "netconf" subsystem. Only the >>>> applicability statement in the reverse-ssh draft would need to be >>> changed >>>> to allow it. So, even in the worst case scenario, no more than > one >>> port >>>> would be needed to reverse SSH-based protocols. >>>> >>>> TLS lacks any form of a session protocol enabling to client to > select >>>> which application-level protocol it wants to run, so a new port > would >>> be >>>> needed for each TLS-based protocol needing reversal. But as > mentioned >>>> before, it's not understood why any non-management protocol would > need >>>> reversal >>>> >>> >>> Kent >>> >>> I think that that is a spurious argument. Just because TLS has not > got >>> a session layer (some would say SSH hasn't but I know what you are >>> getting at) does not mean that there cannot be a session layer > protocol >>> negotiating what happens next - I have proposed just such a one in > the >>> past. And there are plenty of such protocols in the early days of > the >>> Internet (from where I got my inspiration). We would be using far > fewer >>> ports if such session layers were more widespread but I accept that > they >>> are not. >>> >>> I understand the other points you are making but I think it weakens > your >>> case to argue that because TLS has no session layer then there > cannot be >>> such a layer. >>> >>> Tom Petch >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> > From jclarke@cisco.com Mon Nov 4 12:09:55 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2D11E814D for ; Mon, 4 Nov 2013 12:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxOJo0WQF0YB for ; Mon, 4 Nov 2013 12:09:49 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9194721F9F80 for ; Mon, 4 Nov 2013 12:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1749; q=dns/txt; s=iport; t=1383595762; x=1384805362; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=6EoJfITvezpXsT3jscB1eJg+TusbisoJ235uDt/2UiA=; b=E8QFiHh+upSPAuFMbpRYYtss0/SXERl49hNSECoc/F9OwJSKHW6pCZg5 I12eWL26Wzl0/YMKPhksJSQmjSlXEmEKE5nwVIJgUOrkfrX/bSJWF0M9h WBhTdVD591DyrLGasmqFdoozAkmYhVCvtdLuZb9KrYoqqXz5xmFWMFap4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkGALb9d1KrRDoI/2dsb2JhbABPBwODB8F2Fm0HgmRADy4WGAMCAQIBCUINBgIBAYd8nRyhOQSOCwaBW4QdA4lAjkqSCYNEHoE1 X-IronPort-AV: E=Sophos;i="4.93,634,1378857600"; d="scan'208";a="96587897" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 04 Nov 2013 20:09:22 +0000 Received: from sjc-vpn3-634.cisco.com (sjc-vpn3-634.cisco.com [10.21.66.122]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA4K9KaB029563 for ; Mon, 4 Nov 2013 20:09:20 GMT Message-ID: <5277FEF0.6030205@cisco.com> Date: Mon, 04 Nov 2013 15:09:20 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] Zero Touch and serial numbers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:09:55 -0000 At the WG meeting today a comment was made that we should not be requiring serial numbers to be used by the NMS to identify devices. Forgive me if I misunderstood. It sounded like the opinion of the asker and the author (Kent) was that serial numbers are recommended, but would not be required. Due to time, I didn't raise this in the meeting, but I want to air it. I feel that requiring serial numbers is a good thing as it will help the operator. Think of an operator that uses multiple vendors. They need to have some unique ID they can use to identify devices at the NMS (Kent called this making sure the NMS is aware of the devices that _should_ connect). I stipulate that the serial number if the easiest thing for the operator to get ahead of the device ship so that they can program the NMS. Additionally, if they miss the serial number ahead of device ship, serial numbers are printed on the chassis of devices, so a non-tech user could easily read that value to an operator over the phone (or send a picture). If different vendors are allowed to pick other things as the identifier, this might cause confusion and defeat some of the "brain-dead-easy" goals of the draft. I'd like to make sure that whatever if chosen that it meet the needs of being intuitive and obvious for non-technical people to obtain. To me, this means serial number. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From diego@tid.es Mon Nov 4 14:07:57 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD8C21E81DA for ; Mon, 4 Nov 2013 14:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgMO+hC3qsr7 for ; Mon, 4 Nov 2013 14:07:45 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEF221E805D for ; Mon, 4 Nov 2013 14:07:39 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MVR00GB8ESJUF@tid.hi.inet> for netconf@ietf.org; Mon, 04 Nov 2013 23:07:31 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 67.B9.03197.3AA18725; Mon, 04 Nov 2013 23:07:31 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MVR00GB4ESIUF@tid.hi.inet> for netconf@ietf.org; Mon, 04 Nov 2013 23:07:31 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Mon, 04 Nov 2013 23:07:30 +0100 Date: Mon, 04 Nov 2013 22:07:29 +0000 From: "Diego R. Lopez" In-reply-to: <5277FEF0.6030205@cisco.com> X-Originating-IP: [10.95.64.115] To: Joe Marcus Clarke Message-id: <72D1DBC6-9800-4CAF-8D0F-B048C09EA1EF@tid.es> Content-id: <8ED8B9A507BD354DACF3E5F4BF85703C@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [Netconf] Zero Touch and serial numbers Thread-index: AQHO2ZnafOpImEO30kOM9lhg7nHG6ZoVkIYA X-AuditID: 0a5f4068-b7f3e8e000000c7d-a5-52781aa38a5b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42Lhinfg0l0sVRFksGMBl8XUTbdZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0XHqJ3PBP4WKwxvvMTcwTlDoYuTkkBAwkbh26RYjhC0mceHe erYuRi4OIYEDjBJ9J78wQzg/GSUW31zJCuHMZJR4eXQFC0gLi4CqxMOGBWwgNhuQ/aj5N3sX IweHMNDYq7vVQMKcApoSu5dDlEsIKEj8OfcYzBYBirft7AJrZQay7y9Yxgxi8wpYShxYfZAR Im4m8f7+PSaIuKDEj8n3WEDGMwuoS0yZkgtRIi7R3HqTBcJWlJi2qAGslVFAVuLd/PmsEKtM JbqeXGeHsI0kjh7+AfWwgMSSPeeZIWxRiZeP/4HVCwloSByd85plAqPELCRXzEJyxSyEK2Yh uWIWkisWMLKuYhQrTirKTM8oyU3MzEk3MNTLyNTLzEst2cQIibmMHYzLd6ocYhTgYFTi4X1x pTxIiDWxrLgy9xCjBAezkgjvq3tAId6UxMqq1KL8+KLSnNTiQ4xMHJxSDYzJBYcKBTZf5/yt EfL+6ZICien5zosePF0VcSFh9ivZLycqfznfyVe1WvzG/VfwNIHE7uqDP1J1Nkovf9E57/Pj 1xX9pb8MZ6+0Ktgy9aniroQ3TW/F1EvqF+7ZnfaUV/pgFE97550fnWZPgjx+Oa723rIxqckw ZcJfuSc99nmn7pj6Nz72jBJVYinOSDTUYi4qTgQApfQWSpcCAAA= References: <5277FEF0.6030205@cisco.com> Cc: "netconf@ietf.org" Subject: Re: [Netconf] Zero Touch and serial numbers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:07:57 -0000 SGkgSm9lLA0KDQpMZXQgbWUgaW5zaXN0IGluIHRoYXQgKGFzIEkgc3RhdGVkIGF0IHRoZSBtaWtl KSBJIGZpbmQgdGhlIGlkZWEgb2YgdXNpbmcgdGhlIHNlcmlhbCBudW1iZXJzIGV4dHJlbWVseSB1 c2VmdWwgYW5kIGJ5IG5vIG1lYW5zIEkgd2FzIGFza2luZyBmb3Igbm90IHVzaW5nIHRoZW0uIE15 IHF1ZXN0aW9uIHdhcyBhZGRyZXNzZWQgaW4gdHdvIGRpcmVjdGlvbnM6IEZpcnN0LCBvbiB0aGUg ZmFjdCBvZiBpbmNsdWRpbmcgdGhpcyBzZXJpYWwgbnVtYmVyIGluIHRoZSBDb21tb24gTmFtZSBh c3NvY2lhdGVkIHdpdGggdGhlIGNlcnRpZmljYXRlICh0aGVyZSBjYW4gYmUgb3RoZXIgb3B0aW9u cyB0aGF0IGFkZHJlc3MgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluY2x1ZGVkIGluIHRo ZSBkb2N1bWVudCkgU2Vjb25kLCBvbiBqdXN0IGxlYXZpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIHBl cmZvcm1pbmcgYWRkaXRpb25hbCBjaGVja3Mgb24gdGhlIGNlcnRpZmljYXRlLg0KDQpCZSBnb29k ZSwNCg0KT24gNCBOb3YgMjAxMywgYXQgMTI6MDkgLCBKb2UgTWFyY3VzIENsYXJrZSB3cm90ZToN Cg0KPiBBdCB0aGUgV0cgbWVldGluZyB0b2RheSBhIGNvbW1lbnQgd2FzIG1hZGUgdGhhdCB3ZSBz aG91bGQgbm90IGJlIHJlcXVpcmluZyBzZXJpYWwgbnVtYmVycyB0byBiZSB1c2VkIGJ5IHRoZSBO TVMgdG8gaWRlbnRpZnkgZGV2aWNlcy4gRm9yZ2l2ZSBtZSBpZiBJIG1pc3VuZGVyc3Rvb2QuICBJ dCBzb3VuZGVkIGxpa2UgdGhlIG9waW5pb24gb2YgdGhlIGFza2VyIGFuZCB0aGUgYXV0aG9yIChL ZW50KSB3YXMgdGhhdCBzZXJpYWwgbnVtYmVycyBhcmUgcmVjb21tZW5kZWQsIGJ1dCB3b3VsZCBu b3QgYmUgcmVxdWlyZWQuDQo+DQo+IER1ZSB0byB0aW1lLCBJIGRpZG4ndCByYWlzZSB0aGlzIGlu IHRoZSBtZWV0aW5nLCBidXQgSSB3YW50IHRvIGFpciBpdC4gSSBmZWVsIHRoYXQgcmVxdWlyaW5n IHNlcmlhbCBudW1iZXJzIGlzIGEgZ29vZCB0aGluZyBhcyBpdCB3aWxsIGhlbHAgdGhlIG9wZXJh dG9yLiAgVGhpbmsgb2YgYW4gb3BlcmF0b3IgdGhhdCB1c2VzIG11bHRpcGxlIHZlbmRvcnMuICBU aGV5IG5lZWQgdG8gaGF2ZSBzb21lIHVuaXF1ZSBJRCB0aGV5IGNhbiB1c2UgdG8gaWRlbnRpZnkg ZGV2aWNlcyBhdCB0aGUgTk1TIChLZW50IGNhbGxlZCB0aGlzIG1ha2luZyBzdXJlIHRoZSBOTVMg aXMgYXdhcmUgb2YgdGhlIGRldmljZXMgdGhhdCBfc2hvdWxkXyBjb25uZWN0KS4gIEkgc3RpcHVs YXRlIHRoYXQgdGhlIHNlcmlhbCBudW1iZXIgaWYgdGhlIGVhc2llc3QgdGhpbmcgZm9yIHRoZSBv cGVyYXRvciB0byBnZXQgYWhlYWQgb2YgdGhlIGRldmljZSBzaGlwIHNvIHRoYXQgdGhleSBjYW4g cHJvZ3JhbSB0aGUgTk1TLg0KPg0KPiBBZGRpdGlvbmFsbHksIGlmIHRoZXkgbWlzcyB0aGUgc2Vy aWFsIG51bWJlciBhaGVhZCBvZiBkZXZpY2Ugc2hpcCwgc2VyaWFsIG51bWJlcnMgYXJlIHByaW50 ZWQgb24gdGhlIGNoYXNzaXMgb2YgZGV2aWNlcywgc28gYSBub24tdGVjaCB1c2VyIGNvdWxkIGVh c2lseSByZWFkIHRoYXQgdmFsdWUgdG8gYW4gb3BlcmF0b3Igb3ZlciB0aGUgcGhvbmUgKG9yIHNl bmQgYSBwaWN0dXJlKS4gIElmIGRpZmZlcmVudCB2ZW5kb3JzIGFyZSBhbGxvd2VkIHRvIHBpY2sg b3RoZXIgdGhpbmdzIGFzIHRoZSBpZGVudGlmaWVyLCB0aGlzIG1pZ2h0IGNhdXNlIGNvbmZ1c2lv biBhbmQgZGVmZWF0IHNvbWUgb2YgdGhlICJicmFpbi1kZWFkLWVhc3kiIGdvYWxzIG9mIHRoZSBk cmFmdC4NCj4NCj4gSSdkIGxpa2UgdG8gbWFrZSBzdXJlIHRoYXQgd2hhdGV2ZXIgaWYgY2hvc2Vu IHRoYXQgaXQgbWVldCB0aGUgbmVlZHMgb2YgYmVpbmcgaW50dWl0aXZlIGFuZCBvYnZpb3VzIGZv ciBub24tdGVjaG5pY2FsIHBlb3BsZSB0byBvYnRhaW4uICBUbyBtZSwgdGhpcyBtZWFucyBzZXJp YWwgbnVtYmVyLg0KPg0KPiBKb2UNCj4NCj4gLS0NCj4gSm9lIE1hcmN1cyBDbGFya2UsIENDSUUg IzUzODQsICAgICAgICAgfCAgICAgICAgICB8DQo+IFNDSlAsIFNDU0EsIFNDTkEsIFNDU0VDQSwg VkNQICAgICAgICB8fHx8fCAgICAgIHx8fHx8DQo+IERpc3Rpbmd1aXNoZWQgU2VydmljZXMgRW5n aW5lZXIgLi46fHx8fHx8fHx8Ojp8fHx8fHx8fHw6Li4NCj4gUGhvbmU6ICsxICg5MTkpIDM5Mi0y ODY3ICAgICAgICAgYyBpIHMgYyBvICBTIHkgcyB0IGUgbSBzDQo+IEVtYWlsOiBqY2xhcmtlQGNp c2NvLmNvbQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5l dGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8i DQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQu ZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMg MTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJp by4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nD s24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpv Lg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2Vl LiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFz cHgNCg== From mbj@tail-f.com Mon Nov 4 14:53:12 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A15721E80DF for ; Mon, 4 Nov 2013 14:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vpXbqRVthRU for ; Mon, 4 Nov 2013 14:53:06 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5359311E816D for ; Mon, 4 Nov 2013 14:52:39 -0800 (PST) Received: from localhost (dhcp-a398.meeting.ietf.org [31.133.163.152]) by mail.tail-f.com (Postfix) with ESMTPSA id 61B781200054; Mon, 4 Nov 2013 23:52:36 +0100 (CET) Date: Mon, 04 Nov 2013 14:52:34 -0800 (PST) Message-Id: <20131104.145234.496495406.mbj@tail-f.com> To: touch@isi.edu From: Martin Bjorklund In-Reply-To: <5277F4E7.2040503@isi.edu> References: <015b01ced889$57c6f960$4001a8c0@gateway.2wire.net> <5277F4E7.2040503@isi.edu> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:53:12 -0000 Hi, Joe Touch wrote: > FWIW, this seems like an excellent alternative, given the goal of doc. > > Joe > > On 11/3/2013 3:33 AM, t.petch wrote: > > Andy > > > > I think I understand what is being requested, that the Netconf server is > > the SSH server but is the TCP client. I note however the first line of > > the I-D > > "This memo presents a technique for a NETCONF server to initiate a SSH > > connection to a NETCONF client." > > It appears to me that that could be clearer, perhaps saying > > "This memo presents a technique for a NETCONF server to request a > > NETCONF client to initiate a SSH connection to a NETCONF server." > > > > If I understand correctly, expressed thus, all is needed is a signal > > from NETCONF server to NETCONF client to get on with it, and that signal > > could be anything, any PDU, any option (a TCP Option? mmm perhaps not), > > any alarm, alert etc. If the NETCONF server is behind a fw or nat, the NETCONF client might not be able to connect to the NETCONF server. > > Looking at it like that, I sympathise with those who think that this may > > not be the best use of a Port, a resource limited in scope which one day > > we will run out of. > > > > The signal could even be a SYN; if I get a SYN from an address I am > > configured to understand The NETCONF client does not know the address of the NETCONF server in advance. /martin From touch@isi.edu Mon Nov 4 15:02:54 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4914221E80D4 for ; Mon, 4 Nov 2013 15:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.09 X-Spam-Level: X-Spam-Status: No, score=-103.09 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLriyZ3qdNZ3 for ; Mon, 4 Nov 2013 15:02:48 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DA5CB21E81C6 for ; Mon, 4 Nov 2013 15:02:46 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA4N2Rbd026164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Nov 2013 15:02:27 -0800 (PST) Message-ID: <527827F3.4050506@isi.edu> Date: Mon, 04 Nov 2013 15:04:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Bjorklund References: <015b01ced889$57c6f960$4001a8c0@gateway.2wire.net> <5277F4E7.2040503@isi.edu> <20131104.145234.496495406.mbj@tail-f.com> In-Reply-To: <20131104.145234.496495406.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: netconf@ietf.org Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:02:54 -0000 On 11/4/2013 2:52 PM, Martin Bjorklund wrote: > Hi, > > Joe Touch wrote: >> FWIW, this seems like an excellent alternative, given the goal of doc. >> >> Joe >> >> On 11/3/2013 3:33 AM, t.petch wrote: >>> Andy >>> >>> I think I understand what is being requested, that the Netconf server is >>> the SSH server but is the TCP client. I note however the first line of >>> the I-D >>> "This memo presents a technique for a NETCONF server to initiate a SSH >>> connection to a NETCONF client." >>> It appears to me that that could be clearer, perhaps saying >>> "This memo presents a technique for a NETCONF server to request a >>> NETCONF client to initiate a SSH connection to a NETCONF server." >>> >>> If I understand correctly, expressed thus, all is needed is a signal >>> from NETCONF server to NETCONF client to get on with it, and that signal >>> could be anything, any PDU, any option (a TCP Option? mmm perhaps not), >>> any alarm, alert etc. > > If the NETCONF server is behind a fw or nat, the NETCONF client might > not be able to connect to the NETCONF server. That seems like an intended consequence of putting a server behind a firewall or NAT. >>> Looking at it like that, I sympathise with those who think that this may >>> not be the best use of a Port, a resource limited in scope which one day >>> we will run out of. >>> >>> The signal could even be a SYN; if I get a SYN from an address I am >>> configured to understand > > The NETCONF client does not know the address of the NETCONF server in > advance. I'm confused about the case where a client doesn't know the server but the converse is true. Seems like you're begging for mDNS, at which point you could record the relevant port information there. Joe From jclarke@cisco.com Mon Nov 4 17:26:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C499911E814B for ; Mon, 4 Nov 2013 17:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrHldFMdF7qN for ; Mon, 4 Nov 2013 17:26:22 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 21BCE11E8256 for ; Mon, 4 Nov 2013 17:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1383614780; x=1384824380; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oamInu5iVyIC3qejHE/ZxReX3Eu6xgLM2q4zcACwbn4=; b=R51L8nX3duagVSb9SrqEca80eKOYqy6Na7xzZ+Qhb2rRpfIf8zW0BS85 TEadTRv5PHOTA5J1i+hE4rulaRY2eIwL3h6NUjXuItfhgisymDNo+nfU9 B+AwrsYLlDRdmNl7WAY4KuxAPQLp43lgnp2wUE8MvOT3BUPWP3YFK36la 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAPJIeFKrRDoJ/2dsb2JhbABPBwODBziDW7toS4EnFnSCJQEBAQMBAQEBIA8BBTYKAQ4CCxgCAgUWCwICCQMCAQIBCQwWGgYNAQUCAQGHdwUOq32SQASBJYxZBgqBKRAHEYJagUMDiUCCCIxCgS+QWoNEHoE1 X-IronPort-AV: E=Sophos;i="4.93,636,1378857600"; d="scan'208";a="93329450" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 05 Nov 2013 01:26:16 +0000 Received: from prosciutto.local ([10.89.9.140]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA51QEP8015993; Tue, 5 Nov 2013 01:26:14 GMT Message-ID: <52784936.1010207@cisco.com> Date: Mon, 04 Nov 2013 20:26:14 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <5277FEF0.6030205@cisco.com> <72D1DBC6-9800-4CAF-8D0F-B048C09EA1EF@tid.es> In-Reply-To: <72D1DBC6-9800-4CAF-8D0F-B048C09EA1EF@tid.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Zero Touch and serial numbers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:26:26 -0000 On 11/4/13, 5:07 PM, Diego R. Lopez wrote: > Hi Joe, > > Let me insist in that (as I stated at the mike) I find the idea of using the serial numbers extremely useful and by no means I was asking for not using them. My question was addressed in two directions: First, on the fact of including this serial number in the Common Name associated with the certificate (there can be other options that address the security considerations included in the document) Second, on just leaving the possibility of performing additional checks on the certificate. Thanks for clarifying, Diego. Sorry if I misunderstood. Using the SN in the common name may also be something we want to do. The reason being is that I envision an end user going to a vendor portal and trying to find some easy way to map the device to the credentials. SN seems like a reasonable thing for those end users to know about. If something else is allowed to be used by a vendor, it would have to meet the same requirements to make this easily knowable/findable by both operators and those who might be less technical. Joe > > Be goode, > > On 4 Nov 2013, at 12:09 , Joe Marcus Clarke wrote: > >> At the WG meeting today a comment was made that we should not be requiring serial numbers to be used by the NMS to identify devices. Forgive me if I misunderstood. It sounded like the opinion of the asker and the author (Kent) was that serial numbers are recommended, but would not be required. >> >> Due to time, I didn't raise this in the meeting, but I want to air it. I feel that requiring serial numbers is a good thing as it will help the operator. Think of an operator that uses multiple vendors. They need to have some unique ID they can use to identify devices at the NMS (Kent called this making sure the NMS is aware of the devices that _should_ connect). I stipulate that the serial number if the easiest thing for the operator to get ahead of the device ship so that they can program the NMS. >> >> Additionally, if they miss the serial number ahead of device ship, serial numbers are printed on the chassis of devices, so a non-tech user could easily read that value to an operator over the phone (or send a picture). If different vendors are allowed to pick other things as the identifier, this might cause confusion and defeat some of the "brain-dead-easy" goals of the draft. >> >> I'd like to make sure that whatever if chosen that it meet the needs of being intuitive and obvious for non-technical people to obtain. To me, this means serial number. >> >> Joe >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From skyper@thc.org Tue Nov 5 11:09:16 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB9021E80BE for ; Tue, 5 Nov 2013 11:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9C5C3ieIslr for ; Tue, 5 Nov 2013 11:09:11 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DD30C21E80CC for ; Tue, 5 Nov 2013 11:09:08 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so15659808iet.18 for ; Tue, 05 Nov 2013 11:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=7RQgONcsPL3kGvdQyxHcikb7SxMugN0Ooee+NUV/DOI=; b=YlmdfxrlB3UrBtq/PUobwACdGt0ck88Yyo0UJdWm6lDaEF7c7+Q4B6z73+eite1Kl8 zlPePPeZbl3J9TK/MNBSWghw5ru6bhtb5IUD7N41r7JQmK8/kBxY9yXIPZWwvpjFP3qp J08LTxTawjrTc/+xnpAznYaUMdhidEOr0um5k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=7RQgONcsPL3kGvdQyxHcikb7SxMugN0Ooee+NUV/DOI=; b=QL6g2LWup0VCDSI0LWmXLoqGV/7tdgTtt2QoUsoQatw1TE5LuyK0zKiFfhvHbpJ3IX 9URpHEcEobP43TUTfj3fm+Lv/5c9ui2H46GXrSjGeQ7VljwzF7q6U111PYIkZAjoh5dj ni+/k6WIiy94JlP7c3Qk7hMZqvAyIlzSrxL2YOnXFUIhnf6ZHQ3OF684+bul/EiAcug0 OQiNeQe5wjzRUDep+nSBq99pUaaE1D7zQxTrwinNBIDP5Ma1SgPwMAITmqoH1tMy+76d hIjiElxsSpsP2Jl7V508gjzPjuB9yWxp5JRBFEUZ2muyb0gfQl05NI3t2RUAzW4k7bqK x0NA== X-Gm-Message-State: ALoCoQlpe6wp8Na82RZY/cZngCpH7wSXAd0H4OWC2qosEYVbineohTOgp2HWs5UshoBO5hIJP7Fk MIME-Version: 1.0 X-Received: by 10.50.106.20 with SMTP id gq20mr17166642igb.36.1383678547821; Tue, 05 Nov 2013 11:09:07 -0800 (PST) Received: by 10.64.231.100 with HTTP; Tue, 5 Nov 2013 11:09:07 -0800 (PST) X-Originating-IP: [87.106.82.87] Date: Tue, 5 Nov 2013 19:09:07 +0000 Message-ID: From: Ralf Skyper Kaiser To: netconf@ietf.org Content-Type: multipart/alternative; boundary=047d7bea3434545e0504ea72c450 Subject: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:09:16 -0000 --047d7bea3434545e0504ea72c450 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I=92ve only just joined the discussion. I was at the IETF88 netconf WG meeting yesterday morning and that was the first time I heard about netconf. I=92m a newbie here. Have nothing to contribute except some securi= ty concerns. Most (maybe all) have been discussed already. Security principal: Anything that does not improve security or functionality should be removed or disabled. The security vulnerabilities grow linearly with the size of the source code. Anything that is (unnecessarily) left inside a product weakens the security of a product: It is where an attacker can attack, it is extra code (binary or source) that has to be audited, it is extra complexity and it is developer=92s time wasted on things that do not improve security or functionality. DNSSEC does not add functionality. (Anything that can be done with DNSSEC can be done with DNS [but insecurely]). Does DNSSEC add security? If DNS is used an attacker can make the device to connect to a bogus NMS. The secure connection would fail because of SSH/TLS. Ultimately an attacker can trigger a DoS. That=92s it. Not more. There are many other ways for an attacker to make the device to connect to a bogus NMS and even more ways to DoS the device (preventing the device to connect to the NMS at all) =96 regardless if DNSSEC is used or not. So why bother with DNSSEC for ZeroTouch? (Removing DNSSEC also seems to solve other non-security related/compatibility issues and reduces the complexity for the manufacture as well. As easier security is as faster and wider it will get adopted). regards, ralf --047d7bea3434545e0504ea72c450 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,=A0


I=92ve only just joined the discussion. I was at the IETF88 netconf WG meeting yesterday morning and that was the first time I heard ab= out netconf. I=92m a newbie here. Have nothing to contribute except some securi= ty concerns. Most (maybe all) have been discussed already.

=A0

Security principal: Anything that does not improve security or functionality should be removed or disabled.

=A0

The security vulnerabilities grow linearly with the size of the source code. Anything that is (unnecessarily) left inside a product = weakens the security of a product: It is where an attacker can attack, it is extra = code (binary or source) that has to be audited, it is extra complexity and it is= developer=92s time wasted on things that do not improve security or functionality.

=A0

DNSSEC does not add functionality. (Anything that can be done with DNSSEC can be done with DNS [but insecurely]).

=A0

Does DNSSEC add security?

=A0

If DNS is used an attacker can make the device to connect to a bogus NMS. The secure connection would fail because of SSH/TLS. Ultima= tely an attacker can trigger a DoS. That=92s it. Not more.

=A0

There are many other ways for an attacker to make the device to connect to a bogus NMS and even more ways to DoS the device (prev= enting the device to connect to the NMS at all) =96 regardless if DNSSEC is used o= r not.

=A0

So why bother with DNSSEC for ZeroTouch?

=A0

(Removing DNSSEC also seems to solve other non-security relat= ed/compatibility issues and reduces the complexity for the manufacture as well. As easier security is as faster and wider it will get adopted).


regards,

ralf

--047d7bea3434545e0504ea72c450-- From skyper@thc.org Tue Nov 5 11:18:22 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B388D11E8110 for ; Tue, 5 Nov 2013 11:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ITyLGVKBTW0 for ; Tue, 5 Nov 2013 11:18:18 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49AE711E80E2 for ; Tue, 5 Nov 2013 11:18:15 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id at1so15957360iec.15 for ; Tue, 05 Nov 2013 11:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=tKLSGTM1Uf+SNQXhzFRzCUqHoNTDLjJgW2tel/7xD3w=; b=QbCD0NX7kSnGzzfjfcm9NvY3xsXxEmg4AOSdSQyTRcnpKmPAHr7lQeFx0+XcWovEsX 2CfQyxTsay+dAGPnbZN9hoEBFknZM5RgudxWc5KPLZd4eI11JSGb2Yku7ok9vFUu9803 AgOPS2a09riqhUi2GjG0xLVlrePNaNu7neUUM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=tKLSGTM1Uf+SNQXhzFRzCUqHoNTDLjJgW2tel/7xD3w=; b=IQ/gWCgq7kkAWe7m+xJgz30RN2zZJYbudI4S0vXz4mQ2mydO+swd15OhvEeLbi1voi Yqp7Ncd2FTxMlHb9n44mEtiHk7vBi46Im4MW5Rb3ugNJj4lU2Gs+fKzHi6n39ylipbAx b2XmwqD6DzLgZ7UaWnbsHJPmvYWL7KtsXv3QSTkPWO3I4qbsWisJ09F9B9j1NmuAcoc0 KKpNL7CN6ttWJpFJ8NzEBHaIKFEZY9evHhrx0GeitU+5lPN+F5NrTH3B2S8X8p2PuaFK yJedajQIDkIEiXQRPMnTzDhNEHot1nP06m9Esab/fi4z1umPkrxWRApgmaOisYnWi/+i BoXg== X-Gm-Message-State: ALoCoQl1jjbjlZr4EstlfV4cjpYytdKCOELgIxhmDSTKUyIuzja4o9YBfE5gVR6Ic7erqlO0MJ8T MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr16972678igb.36.1383679094417; Tue, 05 Nov 2013 11:18:14 -0800 (PST) Received: by 10.64.231.100 with HTTP; Tue, 5 Nov 2013 11:18:14 -0800 (PST) X-Originating-IP: [87.106.82.87] Date: Tue, 5 Nov 2013 19:18:14 +0000 Message-ID: From: Ralf Skyper Kaiser To: netconf@ietf.org Content-Type: multipart/alternative; boundary=047d7b10cf0de89dbb04ea72e427 Subject: [Netconf] Reverse TLS and reverse SSH: Why support both? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:18:22 -0000 --047d7b10cf0de89dbb04ea72e427 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Security principal: Anything that does not improve security or functionality should be removed or disabled. Why support SSH and TLS? Either protocol establishes a secure tunnel by exchanging 1=92s and 0=92s. Why leave the decision which protocol to use to the manufacture? If the WG can=92t decide if TLS or SSH is more secure then the manufacture won=92t be able to decide either. Removing one of them from the implementation halves the possibilities for an attacker to find vulnerabilities, enables the developer to spend 2x the time (and care) on one protocol and removes complexity in general. Focusing on one protocol and give that one protocol all attention (review, testing, audit ...) could have some advantages. Supporting multiple different protocols, bloating up the size of the code (binary or source), adding complexity and leaving the manufacture in charge to make security related decisions are all things that weaken the security. My gut feeling is that reverse SSH should be dropped unless there is a functionality or security benefit that cannot be achieved with reverse TLS. Trusting a manufacture to generate secure X.509 certificates, having a secure RNG and running a CA securely gives me a funny feeling. But hey, what can possibly go wrong....:> regards, ralf --047d7b10cf0de89dbb04ea72e427 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,


Security principal: Anything that does not improve security or functionality should be removed or disabled.

=A0

Why support SSH and TLS? Either protocol establishes a secure tunnel by exchanging 1=92s and 0=92s.

=A0

Why leave the decision which protocol to use to the manufacture? If the WG can=92t decide if TLS or SSH is more secure then the manufacture won=92t be able to decide either.

=A0

Removing one of them from the implementation halves the possibilities for an attacker to find vulnerabilities, enables the develope= r to spend 2x the time (and care) on one protocol and removes complexity in gene= ral.

=A0

Focusing on one protocol and give that one protocol all atten= tion (review, testing, audit ...) could have some advantages.

=A0

Supporting multiple different protocols, bloating up the size of the code (binary or source), adding complexity and leaving the manufacture in charge to make security related decisions are all things tha= t weaken the security.

=A0

My gut feeling is that reverse SSH should be dropped unless there is a functionality or security benefit that cannot be achieved with reverse TLS.

=A0

Trusting a manufacture to generate secure X.509 certificates, having a secure RNG and running a CA securely gives me a funn= y feeling. But hey, what can possibly go wrong....:>


regards,

ralf
--047d7b10cf0de89dbb04ea72e427-- From lhotka@nic.cz Tue Nov 5 11:28:02 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA44511E8119 for ; Tue, 5 Nov 2013 11:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARjrPftBAlu8 for ; Tue, 5 Nov 2013 11:28:02 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 14C4D11E80F6 for ; Tue, 5 Nov 2013 11:28:02 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:d031:d73f:eddd:dec8]) by mail.nic.cz (Postfix) with ESMTPSA id 3065113FA60; Tue, 5 Nov 2013 20:27:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383679681; bh=YcCvqf067Uxg8ibUmlsgIhNVs6w18l+hQ2eeKHPVYek=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=puRS3XEAeA1kV96m7YCWsPUQdJzw3cqq58uUEd7T6bEKbpCsa2ncXinc6fp1rDYv7 uxos5V+voDXkfgvto71Pdz4Or+51LGkaoq1Ia9oJLbU8lFBJb9n5GuhrqIrTEhf+3I aWWnpaBf8yBjSutGRs3tvI1ZtE7+ns++OXXNZ8nE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 11:27:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <50597C4A-04FA-47CD-A867-9A3A8E73CDAD@nic.cz> References: To: Ralf Skyper Kaiser X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:28:03 -0000 On 05 Nov 2013, at 11:09, Ralf Skyper Kaiser wrote: > Hi,=20 >=20 >=20 >=20 > I=92ve only just joined the discussion. I was at the IETF88 netconf WG = meeting yesterday morning and that was the first time I heard about = netconf. I=92m a newbie here. Have nothing to contribute except some = security concerns. Most (maybe all) have been discussed already. >=20 > =20 > Security principal: Anything that does not improve security or = functionality should be removed or disabled. >=20 > =20 > The security vulnerabilities grow linearly with the size of the source = code. Anything that is (unnecessarily) left inside a product weakens the = security of a product: It is where an attacker can attack, it is extra = code (binary or source) that has to be audited, it is extra complexity = and it is developer=92s time wasted on things that do not improve = security or functionality. >=20 > =20 > DNSSEC does not add functionality. (Anything that can be done with = DNSSEC can be done with DNS [but insecurely]). >=20 > =20 > Does DNSSEC add security? >=20 > =20 > If DNS is used an attacker can make the device to connect to a bogus = NMS. The secure connection would fail because of SSH/TLS. Ultimately an = attacker can trigger a DoS. That=92s it. Not more. I don=92t agree. The attacker has an open TCP session and can use it for = other attacks, not only DoS. Already the information about the existence = and address of the device might be a problem.=20 Other that that, DNSSEC can be useful in connection with DANE (RFC = 6698), so that a certificate of a DNSSEC root (public or private) is all = that=92s needed - NMS certificate can thrn be obtained from DNS. Lada >=20 > =20 > There are many other ways for an attacker to make the device to = connect to a bogus NMS and even more ways to DoS the device (preventing = the device to connect to the NMS at all) =96 regardless if DNSSEC is = used or not. >=20 > =20 > So why bother with DNSSEC for ZeroTouch? >=20 > =20 > (Removing DNSSEC also seems to solve other non-security = related/compatibility issues and reduces the complexity for the = manufacture as well. As easier security is as faster and wider it will = get adopted). >=20 >=20 > regards, >=20 > ralf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From skyper@thc.org Tue Nov 5 11:56:02 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951DC21E80E6 for ; Tue, 5 Nov 2013 11:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f+qmtVKOcQ8 for ; Tue, 5 Nov 2013 11:55:58 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 36F4721E80A6 for ; Tue, 5 Nov 2013 11:55:48 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id u16so15491533iet.21 for ; Tue, 05 Nov 2013 11:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GBWUgWyD0gXMI5iM/izK2153ldJDvQOdKEwcwEluK0Y=; b=KTaWnSlw2wTCfN6UAqOab5IcxrbnObaXwW+srD/PH9aDOz8XaTr5jC1Nk/jThP22td AQghwlzCjywoF0IFL9Sso2gd1ZG2dPggnyxQjnyOrV2/QbFpNCCWzU7nTEasquaDDbv4 gNUQXakRL8OJxFPvCDZvIRQYczzeR0CJo/mXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GBWUgWyD0gXMI5iM/izK2153ldJDvQOdKEwcwEluK0Y=; b=Q1JT8q/n5qu9Lk3D594UEptnlZrR9YnxuTxgS+FeOhpjDRw6l5v6stsFsdHNiCbma7 Z6vITAO1fWlQ5rGI9soCfPbwTg67vgvaqV/zeoD/MEXb+Y+3KhVxYurrM8A//71RXHFI jt6kWiqnDgNco6vmHGa/VcP+nTjyOLeVNxX2tsr8HNSsKhFKSgae8UA8ZIp/sG2huk9z 20KP5T7XDTU0miGS4z+0OfYX+uYZEv6HooYcaN6IpeSaJYsJ3w/vj9SU0hwRlMcEkmu5 H0xyy7slqOapdpOOw4ox5BT0Tt2A6V1lZMS0PL2vcUBfuhlhX5MAcXEKorRu9SlCSjnz vCKA== X-Gm-Message-State: ALoCoQmMjATL5CZdfgLFrRSxlOvdu7h7QP+VHeXO13WCujTsBWjRbpdAphC+O12+pVdwuzDJuC92 MIME-Version: 1.0 X-Received: by 10.50.30.229 with SMTP id v5mr17260341igh.27.1383681347408; Tue, 05 Nov 2013 11:55:47 -0800 (PST) Received: by 10.64.231.100 with HTTP; Tue, 5 Nov 2013 11:55:47 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: <50597C4A-04FA-47CD-A867-9A3A8E73CDAD@nic.cz> References: <50597C4A-04FA-47CD-A867-9A3A8E73CDAD@nic.cz> Date: Tue, 5 Nov 2013 19:55:47 +0000 Message-ID: From: Ralf Skyper Kaiser To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bacc30c32882504ea736be3 Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:56:02 -0000 --047d7bacc30c32882504ea736be3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, . On Tue, Nov 5, 2013 at 7:27 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 11:09, Ralf Skyper Kaiser wrote: > > I don=92t agree. The attacker has an open TCP session and can use it for > other attacks, not only DoS. Already the information about the existence > and address of the device might be a problem. > > Even with DNSSEC an attacker can make the device to connect to a bogus NMS and thus giving the attacker an open TCP session to the device...... > Other that that, DNSSEC can be useful in connection with DANE (RFC 6698), > so that a certificate of a DNSSEC root (public or private) is all that=92= s > needed - NMS certificate can thrn be obtained from DNS. > In ZeroTouch the CA bundle is pre-programmed into the device. So DANE is not required. (And it DANE would be required than the CA key to verify the DNSSEC request would need to be preprogrammed into the device - nothing is gained beside making it complex?). regards, ralf --047d7bacc30c32882504ea736be3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

.


On Tue, Nov 5, 2013 at 7:27 PM, Ladislav Lhotka <lhot= ka@nic.cz> wrote:

On 05 Nov 2013, at 11:09, Ralf Skyper Kaiser <skyper@thc.org> wrote:

I don=92t agree. The attacker has an open TCP session and can use it = for other attacks, not only DoS. Already the information about the existenc= e and address of the device might be a problem.


Even with DNSSEC an attacker can make = the device to connect to a bogus NMS and thus giving the attacker an open T= CP session to the device......
=A0
Other that that, DNSSEC can be useful in connection with DANE (RFC 6698), s= o that a certificate of a DNSSEC root (public or private) is all that=92s n= eeded - NMS certificate can thrn be obtained from DNS.

In ZeroTouch the CA bundle is pre-programmed into the device. So = DANE is not required. (And it DANE would be required than the CA key to ver= ify the DNSSEC request would need to be preprogrammed into the device - not= hing is gained beside making it complex?).

regards,

ralf

--047d7bacc30c32882504ea736be3-- From lhotka@nic.cz Tue Nov 5 12:10:41 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B8221E8092 for ; Tue, 5 Nov 2013 12:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAI9P1jdo+X5 for ; Tue, 5 Nov 2013 12:10:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8C45321F9DD6 for ; Tue, 5 Nov 2013 12:10:36 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:4557:a593:52fe:cdca]) by mail.nic.cz (Postfix) with ESMTPSA id AD67D13FA60; Tue, 5 Nov 2013 21:10:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383682235; bh=innccw+sR5w9OfAGFwZwXINCdsgWJAY6hdyOt8rVA3o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x6z5ACwiRCIscNeEo2tDrsMDZ2RvRyFGrngoJM/J5jREfDFsLqwa8C245xXmAY/WR PddTFRHFikW/Chw64PAirZz/bLe68g6qJ9XVmzODZzbEL/fNT1yVokFroMxcjDHPuU BdpIFMpLVHzue11PkTgaEW3aSKN6PMvxDGVYhGzc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 12:10:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50597C4A-04FA-47CD-A867-9A3A8E73CDAD@nic.cz> To: Ralf Skyper Kaiser X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:10:41 -0000 On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser wrote: > Hi, >=20 > . >=20 >=20 > On Tue, Nov 5, 2013 at 7:27 PM, Ladislav Lhotka wrote: >=20 > On 05 Nov 2013, at 11:09, Ralf Skyper Kaiser wrote: >=20 > I don=92t agree. The attacker has an open TCP session and can use it = for other attacks, not only DoS. Already the information about the = existence and address of the device might be a problem. >=20 >=20 > Even with DNSSEC an attacker can make the device to connect to a bogus = NMS and thus giving the attacker an open TCP session to the device=85=85 With DNSSEC this becomes considerably harder. > =20 > Other that that, DNSSEC can be useful in connection with DANE (RFC = 6698), so that a certificate of a DNSSEC root (public or private) is all = that=92s needed - NMS certificate can thrn be obtained from DNS. >=20 > In ZeroTouch the CA bundle is pre-programmed into the device. So DANE = is not required. (And it DANE would be required than the CA key to = verify the DNSSEC request would need to be preprogrammed into the device = - nothing is gained beside making it complex?). The device can only be pre-programmed with DNSSEC trust anchor, and = that=92s all. I don=92t call it complex. Lada >=20 > regards, >=20 > ralf >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From skyper@thc.org Tue Nov 5 12:19:01 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCA821E80B0 for ; Tue, 5 Nov 2013 12:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PKEDOwFf1SQ for ; Tue, 5 Nov 2013 12:18:56 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 642FD21E8085 for ; Tue, 5 Nov 2013 12:18:56 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so15726329ieb.5 for ; Tue, 05 Nov 2013 12:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9kxL0qd5bvbM/nB1mGk1O+uFUX9u8r82kKISk59QQCs=; b=S54cUgWO95CzGUNVJeycd+L82slps5fPO4CVxINmgvVlB1MizicL4g0RvNGt9br0dO 6Oe8cOAcu0AxtsS8c9ZehCI401a4RdTgAMCqYDyCxv2mgrFK0w2nXR6t7OaOheOs6Uzl 3iZXk+dNOipqAP1ehGfSeg4LU8oA2C0sR42Qk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9kxL0qd5bvbM/nB1mGk1O+uFUX9u8r82kKISk59QQCs=; b=P08Qg0+M9f/B4lIqs2xdEJXIcvgHfIEsvcJGJgNpDxYdoWkLBsc+AmaHG3Rsizhynw DY/Is2AAixveC/IjNMEUpZAfr+nYs0Nx4xYt/dIZrmIqaY43Yt3YHjnGVDePUqWa5+uC /UVNxRak9IOMUOcIdO6rwEBLz6xaAluKwXDP/2o3A8AUCj1oqPChvp17qifHif0sZ2ko yn8eLYfdnYs34Z6GbhOkLq5jUNzwY5AscslVz2rJUu4zXgFe5pI7E5iCPib9vkYqlHbi cA+x3FbYVb/Qx0F2FyIuEzv79m1QpKvDHbzyzAGWLTlL5Pi4tiFK+MkqRxW21tEn+B3k pTMw== X-Gm-Message-State: ALoCoQma55M7vUCOMzkQZCrr5e8PjC0IfLpK3pYuLrFw3NtFXaf43nOf24+R0a6psfWrC2DL7ZRH MIME-Version: 1.0 X-Received: by 10.42.250.148 with SMTP id mo20mr7958434icb.34.1383682735103; Tue, 05 Nov 2013 12:18:55 -0800 (PST) Received: by 10.64.231.100 with HTTP; Tue, 5 Nov 2013 12:18:55 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: References: <50597C4A-04FA-47CD-A867-9A3A8E73CDAD@nic.cz> Date: Tue, 5 Nov 2013 20:18:55 +0000 Message-ID: From: Ralf Skyper Kaiser To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf300e4e51e8b68304ea73bd22 Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:19:01 -0000 --20cf300e4e51e8b68304ea73bd22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser wrote: > > > > > Even with DNSSEC an attacker can make the device to connect to a bogus > NMS and thus giving the attacker an open TCP session to the device=85=85 > > With DNSSEC this becomes considerably harder. > > No it does not. DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SSH traffic: - arp poisoning - Switch/CAM table tricks - transparent proxy - router reconfiguration - directly tapping the physical wire - .. this list is not complete....pretty much anywhere and using any method between the client and the NMS. DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS poisoning. Not more. regards, ralf --20cf300e4e51e8b68304ea73bd22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,


On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka <lhotka@nic.= cz> wrote:

On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <skyper@thc.org> wrote:

>
> Even with DNSSEC an attacker can make the device to connect to a= bogus NMS and thus giving the attacker an open TCP session to the device= =85=85

With DNSSEC this becomes considerably harder.


No it does not= .
DNSSEC does not prevent any of these to redirect the reverse TLS/rever= se SSH traffic:
- arp poisoning
- Switch/CAM ta= ble tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list = is not complete....pretty much anywhere and using any method between the cl= ient and the NMS.

DNSSEC in ZeroTouch prevents one (of many!) redirection meth= ods: DNS poisoning. Not more.

regards,

ralf
--20cf300e4e51e8b68304ea73bd22-- From kwatsen@juniper.net Tue Nov 5 16:30:49 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3982311E81A7 for ; Tue, 5 Nov 2013 16:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.295 X-Spam-Level: X-Spam-Status: No, score=-5.295 tagged_above=-999 required=5 tests=[AWL=1.304, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDeJMwsiEfez for ; Tue, 5 Nov 2013 16:30:42 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1E21F9D2E for ; Tue, 5 Nov 2013 16:30:42 -0800 (PST) Received: from mail98-co9-R.bigfish.com (10.236.132.247) by CO9EHSOBE032.bigfish.com (10.236.130.95) with Microsoft SMTP Server id 14.1.225.22; Wed, 6 Nov 2013 00:30:29 +0000 Received: from mail98-co9 (localhost [127.0.0.1]) by mail98-co9-R.bigfish.com (Postfix) with ESMTP id D8C895203C4; Wed, 6 Nov 2013 00:30:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail98-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(189002)(199002)(74502001)(47446002)(81542001)(74662001)(31966008)(74366001)(87266001)(79102001)(83072001)(77982001)(83322001)(54316002)(56776001)(65816001)(80022001)(66066001)(63696002)(59766001)(76786001)(56816003)(76796001)(77096001)(76176001)(69226001)(85306002)(83506001)(81686001)(80976001)(46102001)(81342001)(74706001)(47736001)(76482001)(81816001)(4396001)(36756003)(53806001)(51856001)(50986001)(54356001)(74876001)(47976001)(49866001)(2656002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail98-co9 (localhost.localdomain [127.0.0.1]) by mail98-co9 (MessageSwitch) id 1383697827195268_18284; Wed, 6 Nov 2013 00:30:27 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.237]) by mail98-co9.bigfish.com (Postfix) with ESMTP id 21DF994003E; Wed, 6 Nov 2013 00:30:27 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 6 Nov 2013 00:30:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 6 Nov 2013 00:30:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.810.5; Wed, 6 Nov 2013 00:30:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Wed, 6 Nov 2013 00:30:21 +0000 From: Kent Watsen To: Joe Touch Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogCAAHbQAIAAhZ+AgACnnQCAAAt7gIAAA6wA///CpoCAAEVhAIAAANAAgAE5S4CAABXsgIAABmwAgAAD8wCAAARdgP//wF4AgABZTID//8Q6AAALgFoAAAC1oAAAVV9VNABCgdKAAAcyOwAAAGkOgAAkh1+A Date: Wed, 6 Nov 2013 00:30:21 +0000 Message-ID: In-Reply-To: <527827F3.4050506@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0022134A87 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:30:49 -0000 Hi Joe, This issue was discussed in the NETCONF WG meeting. Specifically, the choices of: - having a default port - not having a default port (port has to be explicitly configured) - try to update the TLS and SSH protocols to support reversal There was unanimous support in the room to have a default port (around 30 people). No one raised their hand to support any other option. Playing devil's advocate, I made a case for having NO default port. That is, for the ZeroTouch solution, the device is already learning so much NMS-specific information, learning a port number also is easy. Unfortunately, reverse-SSH and reverse-TLS can be used outside of ZeroTouch and, for those cases, the port would then need to be manually configured, which people didn't like. As a quick recap, we initially took Reverse SSH to the SSH list, but it died there due to this port issue. Reverse SSH was resurrected after receiving a lot of operator demand for it. We decided to bring Reverse SSH to NETCONF WG specifically to end the discussion of if it uses an in-band or out-of-band mechanism to trigger the reversal. The NETCONF WG consensus was at that time and is still to use a port. Thanks, Kent From kwatsen@juniper.net Tue Nov 5 17:14:37 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FF011E818C for ; Tue, 5 Nov 2013 17:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgwWSK-0KEFF for ; Tue, 5 Nov 2013 17:14:30 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9411E81F8 for ; Tue, 5 Nov 2013 17:14:26 -0800 (PST) Received: from mail118-db9-R.bigfish.com (10.174.16.234) by DB9EHSOBE018.bigfish.com (10.174.14.81) with Microsoft SMTP Server id 14.1.225.22; Wed, 6 Nov 2013 01:14:25 +0000 Received: from mail118-db9 (localhost [127.0.0.1]) by mail118-db9-R.bigfish.com (Postfix) with ESMTP id BD2102C0110; Wed, 6 Nov 2013 01:14:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371Ic85dh1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh18c673h1de097hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h1155h) Received-SPF: pass (mail118-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(24454002)(377454003)(164054003)(69226001)(74366001)(46102001)(85306002)(19580405001)(74876001)(56776001)(54316002)(81816001)(19580395003)(51856001)(81342001)(16236675002)(81542001)(83506001)(80976001)(59766001)(54356001)(81686001)(53806001)(76482001)(83322001)(2656002)(74706001)(47736001)(77982001)(65816001)(74502001)(47446002)(80022001)(74662001)(31966008)(66066001)(36756003)(83072001)(79102001)(50986001)(77096001)(4396001)(76796001)(76176001)(56816003)(76786001)(47976001)(87266001)(49866001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail118-db9 (localhost.localdomain [127.0.0.1]) by mail118-db9 (MessageSwitch) id 138370046386575_26013; Wed, 6 Nov 2013 01:14:23 +0000 (UTC) Received: from DB9EHSMHS003.bigfish.com (unknown [10.174.16.227]) by mail118-db9.bigfish.com (Postfix) with ESMTP id 0076F220052; Wed, 6 Nov 2013 01:14:23 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS003.bigfish.com (10.174.14.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 6 Nov 2013 01:14:22 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 6 Nov 2013 01:14:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.810.5; Wed, 6 Nov 2013 01:14:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Wed, 6 Nov 2013 01:14:19 +0000 From: Kent Watsen To: Ralf Skyper Kaiser , Ladislav Lhotka Thread-Topic: [Netconf] Why bother with DNSSEC for ZeroTouch? Thread-Index: AQHO2lqP61y37wIOjkOfX5Akrc9D8JoXBYuAgAAHyYCAAAQegIAAAlmA///MZgA= Date: Wed, 6 Nov 2013 01:14:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0022134A87 Content-Type: multipart/alternative; boundary="_000_CE9ECEC74B6A5kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:14:37 -0000 --_000_CE9ECEC74B6A5kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ralf, Please explain the specific attack you're envisioning. I agree that the de= vice's call-home connection could be steered to another system and I'll agr= ee that that system could blindly authenticate the device's public key. B= ut in order for security to be compromised, that system needs to be able to= authenticate itself to the device, which is where it will fail because it = will not know the real NMS's auth credentials (e.g. private key). Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to conf= igure the device with the NMS it's to connect to and 2) to configure the de= vice with information it can use to authenticate the NMS with. It is this = 2nd piece of information that prevents the spoofer from succeeding. Critic= al to this is that the device can verify the authenticity of the informatio= n it downloads from the network, which is where using DNSSEC plays a role. = Makes sense? PS: I also agree with your premise that unnecessary code leads to a larger = attack surface, but devices should already have support for DNSSEC. It is = not envisioned that this solution introduces new code to the device but, if= it does, it is a good thing. Thanks, Kent From: Ralf Skyper Kaiser > Date: Tuesday, November 5, 2013 12:18 PM To: Ladislav Lhotka > Cc: NetConf > Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? Hi, On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka > wrote: On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser > wrote: > > Even with DNSSEC an attacker can make the device to connect to a bogus NM= S and thus giving the attacker an open TCP session to the device...... With DNSSEC this becomes considerably harder. No it does not. DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SS= H traffic: - arp poisoning - Switch/CAM table tricks - transparent proxy - router reconfiguration - directly tapping the physical wire - .. this list is not complete....pretty much anywhere and using any method= between the client and the NMS. DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS poison= ing. Not more. regards, ralf --_000_CE9ECEC74B6A5kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <588127B636277D42B6170F51B243BABB@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi Ralf,

Please explain the specific attack you're envisioning.  I agree t= hat the device's call-home connection could be steered to another system an= d I'll agree that that system could blindly authenticate the device's publi= c key.   But in order for security to be compromised, that system needs to be able to authenticate itself t= o the device, which is where it will fail because it will not know the real= NMS's auth credentials (e.g. private key).  

Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to= configure the device with the NMS it's to connect to and 2) to configure t= he device with information it can use to authenticate the NMS with.  I= t is this 2nd piece of information that prevents the spoofer from succeeding.  Critical to this is that the d= evice can verify the authenticity of the information it downloads from the = network, which is where using DNSSEC plays a role.  Makes sense?

PS: I also agree with your premise that unnecessary code leads to a la= rger attack surface, but devices should already have support for DNSSEC. &n= bsp;It is not envisioned that this solution introduces new code to the devi= ce but, if it does, it is a good thing.

Thanks,
Kent


From: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tuesday, November 5, 2013 12:= 18 PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] Why bother w= ith DNSSEC for ZeroTouch?

Hi,


On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <skyper@thc.org> wrote:

>
> Even with DNSSEC an attacker can make the device to connect to a bogus= NMS and thus giving the attacker an open TCP session to the device…&= #8230;

With DNSSEC this becomes considerably harder.


No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SS= H traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any m= ethod between the client and the NMS.

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS p= oisoning. Not more.

regards,

ralf

 --_000_CE9ECEC74B6A5kwatsenjunipernet_-- From kwatsen@juniper.net Tue Nov 5 17:53:00 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4FD21E8131 for ; Tue, 5 Nov 2013 17:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.83 X-Spam-Level: X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrFvo9xH4CPI for ; Tue, 5 Nov 2013 17:52:53 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id AF8B411E8199 for ; Tue, 5 Nov 2013 17:52:38 -0800 (PST) Received: from mail205-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.22; Wed, 6 Nov 2013 01:51:54 +0000 Received: from mail205-co1 (localhost [127.0.0.1]) by mail205-co1-R.bigfish.com (Postfix) with ESMTP id 369F9D80378; Wed, 6 Nov 2013 01:51:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzdb82h4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail205-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(76482001)(79102001)(54316002)(56776001)(81542001)(77982001)(59766001)(69226001)(80022001)(81342001)(47446002)(74502001)(31966008)(74662001)(66066001)(4396001)(76176001)(51856001)(47976001)(83506001)(46102001)(50986001)(87266001)(49866001)(63696002)(65816001)(47736001)(76796001)(74706001)(56816003)(76786001)(74876001)(77096001)(561944002)(85306002)(81686001)(81816001)(54356001)(74366001)(80976001)(36756003)(83322001)(83072001)(53806001)(2656002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail205-co1 (localhost.localdomain [127.0.0.1]) by mail205-co1 (MessageSwitch) id 1383702711971958_25509; Wed, 6 Nov 2013 01:51:51 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.246]) by mail205-co1.bigfish.com (Postfix) with ESMTP id E96B55C005B; Wed, 6 Nov 2013 01:51:51 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 6 Nov 2013 01:51:51 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 6 Nov 2013 01:51:51 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.810.5; Wed, 6 Nov 2013 01:51:48 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Wed, 6 Nov 2013 01:51:48 +0000 From: Kent Watsen To: Ralf Skyper Kaiser , "netconf@ietf.org" Thread-Topic: [Netconf] Reverse TLS and reverse SSH: Why support both? Thread-Index: AQHO2lviZVwpxEIqe0WURj3NP7ciqJoW6qkA Date: Wed, 6 Nov 2013 01:51:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0022134A87 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6C4CF321009C70429679AD01525FA38A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Netconf] Reverse TLS and reverse SSH: Why support both? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:53:00 -0000 > Why support SSH and TLS? Either protocol establishes a secure tunnel by >exchanging 1=B9s and 0=B9s. NETCONF supports both transports for good reasons. > Why leave the decision which protocol to use to the manufacture? If the >WG can=B9t decide if TLS or SSH is more secure then the manufacture won=B9= t >be able to decide either. It isn't left to the manufacturer, each specific deployment chooses it for themselves. > Removing one of them from the implementation halves the possibilities >for an attacker to find vulnerabilities, enables the developer to spend >2x the time (and care) on one protocol and removes complexity in general. > Focusing on one protocol and give that one protocol all attention >(review, testing, audit ...) could have some advantages. Noted. Each manufacturer can choose what they want to implement and support. > My gut feeling is that reverse SSH should be dropped unless there is a >functionality or security benefit that cannot be achieved with reverse >TLS. SSH is NETCONF's mandatory transport, as such, supporting Call Home with SSH is a given. =20 =20 > Trusting a manufacture to generate secure X.509 certificates, having a >secure RNG and running a CA securely gives me a funny feeling. But hey, >what can possibly go wrong....:> Your concern is unwarranted. The spec clearly states that the manufacturer should use a TPM. These chips are typically awarded the highest security certifications (FIPS, CC, etc.). Also, this proposal has been reviewed by multiple security experts with no concern raised. But, really, what option is there, given the use-cases ZeroTouch tries to solve? Thanks, Kent From yiya@cisco.com Wed Nov 6 10:11:15 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF3421E815F for ; Wed, 6 Nov 2013 10:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIY6K-nZdFsk for ; Wed, 6 Nov 2013 10:11:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE021E8142 for ; Wed, 6 Nov 2013 10:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1239; q=dns/txt; s=iport; t=1383761470; x=1384971070; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OfH4nL+nQlJIT11kybauetR4vpb6aJST1GdVGEQKpmI=; b=C40sps0lvoD5cnkhO4JKFmX41D559hgFlwZOJUgIVeuxQK8WDXse8W4Q BwUDuIiQx7YeZbxcaTxkz2KfirMtwf3seZD9V8NZ31sZcfVNFNbXXkoSA x1fjn4IYsLJDpilIdf9WTDBY8IOfpGitdmbscVcW1jqVixV9xpn/nyc5i s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAJeFelKtJV2Z/2dsb2JhbABaDoJ5gQu/NoElFnSCLDozDBIBCA4oQiUCBAENBRuHZr8oj1kHhDADmAySCoJnP4Iq X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="281534924" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2013 18:11:06 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA6IB6cl019131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 18:11:06 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 12:11:06 -0600 From: "Yi Yang (yiya)" To: Kent Watsen , Joe Touch Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO2ZOZizx73xJsUkq9CmwCXb8g/poWEocAgAADSYCAAapegIAA1IsA Date: Wed, 6 Nov 2013 18:11:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.82.255.132] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:11:15 -0000 Hi Kent, On 11/5/13 7:30 PM, "Kent Watsen" wrote: > >Hi Joe, > >This issue was discussed in the NETCONF WG meeting. Specifically, the >choices of: > > - having a default port > - not having a default port (port has to be explicitly configured) > - try to update the TLS and SSH protocols to support reversal > >There was unanimous support in the room to have a default port (around 30 >people). No one raised their hand to support any other option. > >Playing devil's advocate, I made a case for having NO default port. That >is, for the ZeroTouch solution, the device is already learning so much >NMS-specific information, learning a port number also is easy. >Unfortunately, reverse-SSH and reverse-TLS can be used outside of >ZeroTouch and, for those cases, the port would then need to be manually >configured, which people didn't like. Is there any reason that reverse-SSH cannot use the default SSH port 22? And even if a default port is assigned for reverse-SSH/reverse-TLS, ZeroTouch should allow a non-default port be provisioned, which seems missed in current draft -- Actually, the mechanism to offer the port is already built in the DNS with using SRV record. Yi From skyper@thc.org Wed Nov 6 12:25:30 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F242821E8175 for ; Wed, 6 Nov 2013 12:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxYdbLgDZO6W for ; Wed, 6 Nov 2013 12:25:25 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A48EA11E80D9 for ; Wed, 6 Nov 2013 12:25:25 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id at1so34319iec.29 for ; Wed, 06 Nov 2013 12:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jHaNu77W6arJLeFDlLCWiCcQZDmhq4NNpH6fWsYlxR0=; b=csMezI46slQHgiofFqFRpc4SbmwM0IWFuTkFzo3RXotFQnMQDGFE4gUoXrGBFce7Qz pDC9KFEue9hYAs9Ii9+FgQqW57hl5fDpfxvPEQCqMXzZpgBbbMwrEkY9ijiODGwyGq8x gMrp3HsF+nceDy4ol1R5rgTBmpL30dQbMH0pY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jHaNu77W6arJLeFDlLCWiCcQZDmhq4NNpH6fWsYlxR0=; b=cXbhq7bqeEsXQIvSJ01mA0EtUmCPxhzZFN/ZZJvfMNCIFJGaY0AnlN9wYcykA7LW3f B2V0CW1IBjxjq4gxjcI3b/UJ7LqdihZUeOnuDSZksxNQ8K560q9G+83TCsiUhtZ/B7p/ j4yTkyJXy7LaGqWUsYBlPnCYeak1Kuox/fHOaDyRks1ft6FdXs6TORngnqVIwij+6A7T 9I/0eigzur4v5vunoAgU6GxjZiXoFck7wxzYFp7UvUB/84N0zktZAWFFDAiYPZBF1LZ8 nSrUoBJDS/zhiD5jANg0bqwXRAZxQPHUGR4m2YMaKwd4g2heJQ/z6WECj+Tnw4y27504 5gew== X-Gm-Message-State: ALoCoQnyGgfiplDeOBl7qKyvkqRkiaFWBGm/JDQCqqCkBLCbs8oCmPw2DivPwoXQXYhpLQVGNCF1 MIME-Version: 1.0 X-Received: by 10.51.16.35 with SMTP id ft3mr3855588igd.46.1383769522627; Wed, 06 Nov 2013 12:25:22 -0800 (PST) Received: by 10.64.231.100 with HTTP; Wed, 6 Nov 2013 12:25:22 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: References: Date: Wed, 6 Nov 2013 20:25:22 +0000 Message-ID: From: Ralf Skyper Kaiser To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1134bc1ed9aa6604ea87f2c8 Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:25:30 -0000 --001a1134bc1ed9aa6604ea87f2c8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kent, The only thing that I can find in the ZeroTouch draft is that DNSSEC is used to retrieve information that are public and if wrong (by an attacker) end up in a DoS: - IP of NMS - username for NMS - if reverse TLS or reverse SSL should be used. A scenario where an attacker can change/modify either of those ends up in a DoS. What other attack vector does DNSSEC solve beside DoS against the device? If DNSSEC in this scenario only solves a DoS then why bother with DNSSEC considering that the attacker can already mount a DoS attack with far less resources at a far lower cost. DNSSEC does not solve this DoS problem (and you should not try to solve it either as the attacker will always have the upper hand _in this scenario_ of device DoS). regards, ralf On Wed, Nov 6, 2013 at 1:14 AM, Kent Watsen wrote: > > Hi Ralf, > > Please explain the specific attack you're envisioning. I agree that the > device's call-home connection could be steered to another system and I'll > agree that that system could blindly authenticate the device's public key= . > But in order for security to be compromised, that system needs to be ab= le > to authenticate itself to the device, which is where it will fail because > it will not know the real NMS's auth credentials (e.g. private key). > > Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to > configure the device with the NMS it's to connect to and 2) to configure > the device with information it can use to authenticate the NMS with. It = is > this 2nd piece of information that prevents the spoofer from succeeding. > Critical to this is that the device can verify the authenticity of the > information it downloads from the network, which is where using DNSSEC > plays a role. Makes sense? > > PS: I also agree with your premise that unnecessary code leads to a > larger attack surface, but devices should already have support for DNSSEC= . > It is not envisioned that this solution introduces new code to the devic= e > but, if it does, it is a good thing. > > Thanks, > Kent > > > From: Ralf Skyper Kaiser > Date: Tuesday, November 5, 2013 12:18 PM > To: Ladislav Lhotka > Cc: NetConf > Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? > > Hi, > > > On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka wrote: > >> >> On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser wrote: >> >> > >> > Even with DNSSEC an attacker can make the device to connect to a bogu= s >> NMS and thus giving the attacker an open TCP session to the device=85=85 >> >> With DNSSEC this becomes considerably harder. >> >> > No it does not. > DNSSEC does not prevent any of these to redirect the reverse TLS/reverse > SSH traffic: > - arp poisoning > - Switch/CAM table tricks > - transparent proxy > - router reconfiguration > - directly tapping the physical wire > - .. this list is not complete....pretty much anywhere and using any > method between the client and the NMS. > > DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS > poisoning. Not more. > > regards, > > ralf > > --001a1134bc1ed9aa6604ea87f2c8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Kent,

The onl= y thing that I can find in the ZeroTouch draft is that DNSSEC is used to re= trieve information that are public and if wrong (by an attacker) end up in = a DoS:

- IP of NMS
- username for NMS
- if reverse TLS= or reverse SSL should be used.

A scenario where an attacker c= an change/modify either of those ends up in a DoS. What other attack vector= does DNSSEC solve beside DoS against the device?

If DNSSEC in this scenario only solves a DoS then why bother with= DNSSEC considering that the attacker can already mount a DoS attack with f= ar less resources at a far lower cost.

DNSSEC does not solve t= his DoS problem (and you should not try to solve it either as the attacker = will always have the upper hand _in this scenario_ of device DoS).

regards,

ralf




On Wed, Nov 6, 201= 3 at 1:14 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Hi Ralf,

Please explain the specific attack you're envisioning. =A0I agree = that the device's call-home connection could be steered to another syst= em and I'll agree that that system could blindly authenticate the devic= e's public key. =A0 But in order for security to be=A0compromised, that system needs to be able to authenticate itself to t= he device, which is where it will fail because it will not know the real NM= S's auth credentials (e.g. private key). =A0

Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to= configure the device with the NMS it's to connect to and 2) to configu= re the device with information it can use to authenticate the NMS with. =A0= It is this 2nd piece of information that prevents the spoofer from succeeding. =A0Critical to this is that the devi= ce can verify the authenticity of the information it downloads from the net= work, which is where using DNSSEC plays a role. =A0Makes sense?

PS: I also agree with your premise that unnecessary code leads to a la= rger attack surface, but devices should already have support for DNSSEC. = =A0It is not envisioned that this solution introduces new code to the devic= e but, if it does, it is a good thing.

Thanks,
Kent


From: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tuesday, November 5, 2013 12:= 18 PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] Why bother w= ith DNSSEC for ZeroTouch?

Hi,


On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <skyper@thc.org> wrote:

>
> Even with DNSSEC an attacker can make the device to connect to a bogus= NMS and thus giving the attacker an open TCP session to the device=85=85
With DNSSEC this becomes considerably harder.


No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SS= H traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any m= ethod between the client and the NMS.

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS p= oisoning. Not more.

regards,

ralf

--001a1134bc1ed9aa6604ea87f2c8-- From skyper@thc.org Wed Nov 6 12:35:10 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8148E11E8190 for ; Wed, 6 Nov 2013 12:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qCfg8KeMQwe for ; Wed, 6 Nov 2013 12:35:05 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD5521E818A for ; Wed, 6 Nov 2013 12:35:00 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id aq17so48708iec.38 for ; Wed, 06 Nov 2013 12:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QC9SnqFeaLLSJeJtHRtOfyALh7FzE8XrnJHqRtFJ/hw=; b=ABo2YM5q9oQWKHCDypGxXqc1FQxEswGh6jFlsBBhgBr99b7is9tzS+bT8zL4Zcn+24 KuZOfO0F1G3kGFlB/RjsiOOdzzExc2G9IulDtjfndhT84qzKcpfzJWSmFrG5w0WF6U5f cgSOuFUWFAg31joohg930GWzVc/ty9X7HzQuk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QC9SnqFeaLLSJeJtHRtOfyALh7FzE8XrnJHqRtFJ/hw=; b=ilAFhmh7aOTfFzuVxgwoHVQUDdBnHYzQadZwpuc4bERuBXEHQXRW/ksMrkf8hG6sjj N4JgetbpYzXgJBLQ/HBXl9mfoNnMbtC530rZfbiEAcGmpYkltUhdH2V2AvHYSy100Cq6 TjIohksNFnlEMETAi22Ra02FC8i2QYI/+CqLxfkP2TIluNpwgmiLMYdR34uqq8R9sJyK RoVigSR+F9FW2WPl0WlNosPkIzFXzQQfEbNT8lB3u0HN5EFJrtcpcIgfCu/yS88LpBCt 08m4R+eDU6oMlIX1Udk5dl3DF4C9RHWTdOwisdFsEre0a3bWwlCaZZtZxtFsF++7ifc6 T+Ug== X-Gm-Message-State: ALoCoQkklEUd3yfXfuAZbN1NKYgcE1pMDEH0cgVZooETbCiA+sf8hJfB/a1zO28+RvfIGdwsoqyN MIME-Version: 1.0 X-Received: by 10.42.190.142 with SMTP id di14mr3239801icb.45.1383770099448; Wed, 06 Nov 2013 12:34:59 -0800 (PST) Received: by 10.64.231.100 with HTTP; Wed, 6 Nov 2013 12:34:59 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: References: Date: Wed, 6 Nov 2013 20:34:59 +0000 Message-ID: From: Ralf Skyper Kaiser To: Kent Watsen Content-Type: multipart/alternative; boundary=20cf303ea4b83b526604ea88154e Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reverse TLS and reverse SSH: Why support both? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:35:10 -0000 --20cf303ea4b83b526604ea88154e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2013 at 1:51 AM, Kent Watsen wrote: > > > Why support SSH and TLS? Either protocol establishes a secure tunnel by > >exchanging 1=B9s and 0=B9s. > > NETCONF supports both transports for good reasons. > What are these good reasons to support two transports which achieve the same thing? > Why leave the decision which protocol to use to the manufacture? If the > >WG can=B9t decide if TLS or SSH is more secure then the manufacture won= =B9t > >be able to decide either. > > It isn't left to the manufacturer, each specific deployment chooses it fo= r > themselves. > It was iterated again in today's Plenary Session: The less options you give to the user/admin the more secure it will be. Just from a security point of view I can not see why support both protocols is more secure than just supporting one of them. > My gut feeling is that reverse SSH should be dropped unless there is a > >functionality or security benefit that cannot be achieved with reverse > >TLS. > > SSH is NETCONF's mandatory transport, as such, supporting Call Home with > SSH is a given. > Why was SSH chosen instead of TLS? (just curious from a security point of view). > > > > > Trusting a manufacture to generate secure X.509 certificates, having a > >secure RNG and running a CA securely gives me a funny feeling. But hey, > >what can possibly go wrong....:> > > Your concern is unwarranted. The spec clearly states that the > manufacturer should use a TPM. These chips are typically awarded the > highest security certifications (FIPS, CC, etc.). Also, this proposal > has been reviewed by multiple security experts with no concern raised. > But, really, what option is there, given the use-cases ZeroTouch tries to > solve? > I've pushed a product through FIPS140-2 and CC and reviewed many others. Some are broken beyond recognition and still get FIPS certified. FIPS does not guarantee security. FIPS only shows that the product complies with some (often outdated) policies. It would not be the first FIPS device that gets broken. Anyway, there is no alternative to the TPM. It's as good as it gets I guess. Let's see what happens... regards, ralf > > > Thanks, > Kent > > > > --20cf303ea4b83b526604ea88154e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 6, 2013 at 1:51 AM, Kent Watsen <<= a href=3D"mailto:kwatsen@juniper.net" target=3D"_blank">kwatsen@juniper.net= > wrote:

> Why support SSH and TLS? Either protocol establishes a secure tunnel b= y
>exchanging 1=B9s and 0=B9s.

NETCONF supports both transports for good reasons.

What are these good reasons to support two transports whi= ch achieve the same thing?


> Why leave the decision which protocol to use to the manufacture? If th= e
>WG can=B9t decide if TLS or SSH is more secure then the manufacture won= =B9t
>be able to decide either.

It isn't left to the manufacturer, each specific deployment choos= es it for
themselves.

It was iterated again in to= day's Plenary Session: The less options you give to the user/admin the = more secure it will be.

Just from a security point of vie= w I can not see why support both protocols is more secure than just support= ing one of them.

> My gut feeling is that reverse SSH should be dropped unless there is a=
>functionality or security benefit that cannot be achieved with reverse<= br> >TLS.

SSH is NETCONF's mandatory transport, as such, supporting Call Ho= me with
SSH is a given.

Why was SSH chosen inst= ead of TLS? (just curious from a security point of view).
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">



> Trusting a manufacture to generate secure X.509 certificates, having a=
>secure RNG and running a CA securely gives me a funny feeling. But hey,=
>what can possibly go wrong....:>

Your concern is unwarranted. =A0The spec clearly states that the
manufacturer should use a TPM. =A0These chips are typically awarded the
highest security certifications (FIPS, CC, etc.). =A0 Also, this proposal has been reviewed by multiple security experts with no concern raised.
But, really, what option is there, given the use-cases ZeroTouch tries to solve?

I've pushed a product throug= h FIPS140-2 and CC and reviewed many others. Some are broken beyond recogni= tion and still get FIPS certified. FIPS does not guarantee security. FIPS o= nly shows that the product complies with some (often outdated) policies.
It would not be the first FIPS device that gets broken. Anyw= ay, there is no alternative to the TPM. It's as good as it gets I guess= . Let's see what happens...

regards,

ralf

=A0


Thanks,
Kent




--20cf303ea4b83b526604ea88154e-- From kwatsen@juniper.net Wed Nov 6 17:03:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E60911E81CE for ; Wed, 6 Nov 2013 17:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.817 X-Spam-Level: X-Spam-Status: No, score=-3.817 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lweaDZGkQBuR for ; Wed, 6 Nov 2013 17:03:19 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id E945821E81AE for ; Wed, 6 Nov 2013 17:02:49 -0800 (PST) Received: from mail73-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 01:02:48 +0000 Received: from mail73-ch1 (localhost [127.0.0.1]) by mail73-ch1-R.bigfish.com (Postfix) with ESMTP id BD60F401D0; Thu, 7 Nov 2013 01:02:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz148cI4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail73-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(52604005)(164054003)(47446002)(47976001)(49866001)(50986001)(47736001)(74366001)(81342001)(51856001)(36756003)(81816001)(77982001)(59766001)(53806001)(46102001)(54316002)(56776001)(76176001)(54356001)(81686001)(56816003)(79102001)(74876001)(74706001)(83506001)(76786001)(74662001)(31966008)(76482001)(74502001)(76796001)(4396001)(63696002)(77096001)(65816001)(87266001)(81542001)(80022001)(66066001)(83072001)(80976001)(85306002)(2656002)(87936001)(83322001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail73-ch1 (localhost.localdomain [127.0.0.1]) by mail73-ch1 (MessageSwitch) id 1383786150911310_29780; Thu, 7 Nov 2013 01:02:30 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail73-ch1.bigfish.com (Postfix) with ESMTP id D11DB140296; Thu, 7 Nov 2013 01:02:30 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 01:02:29 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 01:02:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 7 Nov 2013 01:02:27 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Thu, 7 Nov 2013 01:02:27 +0000 From: Kent Watsen To: "Yi Yang (yiya)" , Joe Touch Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogCAAHbQAIAAhZ+AgACnnQCAAAt7gIAAA6wA///CpoCAAEVhAIAAANAAgAE5S4CAABXsgIAABmwAgAAD8wCAAARdgP//wF4AgABZTID//8Q6AAALgFoAAAC1oAAAVV9VNABCgdKAAAcyOwAAAGkOgAAkh1+AADXQIID//+zPAA== Date: Thu, 7 Nov 2013 01:02:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.224.36] x-forefront-prvs: 00235A1EEF Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:03:26 -0000 >Is there any reason that reverse-SSH cannot use the default SSH port 22? The only way we could use port 22 would be to update the SSH protocol enabling in-band negotiation for reversal. This may be technically possible, but there is little support for this approach. >And even if a default port is assigned for reverse-SSH/reverse-TLS, >ZeroTouch should allow a non-default port be provisioned, which seems >missed in current draft That is an omission. The configuration model described in the Reverse SSH draft enables a port to be specified and we would, of course, want it to be configurable via ZeroTouch as well. Thanks for pointing it out. > Actually, the mechanism to offer the port is >already built in the DNS with using SRV record. Which DNS records ZeroConf uses is TBD, but this sounds viable. Thanks, Kent From kwatsen@juniper.net Wed Nov 6 17:13:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959F121F96ED for ; Wed, 6 Nov 2013 17:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.806 X-Spam-Level: X-Spam-Status: No, score=-3.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWzfgUolfGUw for ; Wed, 6 Nov 2013 17:13:29 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id E463211E81C0 for ; Wed, 6 Nov 2013 17:13:13 -0800 (PST) Received: from mail22-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE016.bigfish.com (10.3.207.138) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 01:13:12 +0000 Received: from mail22-am1 (localhost [127.0.0.1]) by mail22-am1-R.bigfish.com (Postfix) with ESMTP id 89BD7E012B; Thu, 7 Nov 2013 01:13:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail22-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(164054003)(81542001)(77096001)(83506001)(69226001)(53806001)(63696002)(80976001)(56816003)(83322001)(83072001)(47736001)(49866001)(47976001)(50986001)(54356001)(87936001)(80022001)(66066001)(65816001)(54316002)(74706001)(2656002)(56776001)(81686001)(81342001)(81816001)(76482001)(79102001)(87266001)(76786001)(59766001)(77982001)(74366001)(74876001)(74502001)(47446002)(46102001)(31966008)(74662001)(36756003)(85306002)(76176001)(76796001)(4396001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.50; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail22-am1 (localhost.localdomain [127.0.0.1]) by mail22-am1 (MessageSwitch) id 1383786790381983_26220; Thu, 7 Nov 2013 01:13:10 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.246]) by mail22-am1.bigfish.com (Postfix) with ESMTP id 59E64C009D; Thu, 7 Nov 2013 01:13:10 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 01:13:09 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 01:13:08 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 7 Nov 2013 01:13:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.108]) with mapi id 15.00.0810.005; Thu, 7 Nov 2013 01:13:06 +0000 From: Kent Watsen To: Ralf Skyper Kaiser Thread-Topic: [Netconf] Why bother with DNSSEC for ZeroTouch? Thread-Index: AQHO2lqP61y37wIOjkOfX5Akrc9D8JoXBYuAgAAHyYCAAAQegIAAAlmA///MZgCAAce8AP//ykWA Date: Thu, 7 Nov 2013 01:13:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.224.50] x-forefront-prvs: 00235A1EEF Content-Type: text/plain; charset="us-ascii" Content-ID: <416202FB1CD482419F171B5A5A2C0225@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:13:35 -0000 > A scenario where an attacker can change/modify either of those ends up >in a DoS. What other attack vector does DNSSEC solve beside DoS against >the device? I don't understand, how could an attacker change/modify the call home data in DNS without invalidating a DNSSEC signature? Using DNSSEC is more about preventing MITM than DoS. > If DNSSEC in this scenario only solves a DoS then why bother with DNSSEC >considering that the attacker can already mount a DoS attack with far >less resources at a far lower cost. Because a MITM (not-detectable) is worse than a DoS (detectable) - makes sense? Thanks, Kent From mehmet.ersue@nsn.com Wed Nov 6 19:08:39 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6500F21E80EE for ; Wed, 6 Nov 2013 19:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBqRxzhIZ3kV for ; Wed, 6 Nov 2013 19:08:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 42DD621E810A for ; Wed, 6 Nov 2013 19:08:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA738UUd005642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2013 04:08:30 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA738UVJ002229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 04:08:30 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 04:08:30 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Benoit Claise , Netconf Thread-Topic: Summary of the Netconf Session at IETF #88 Thread-Index: Ac7bZqFUoHi+yGZLT/ubQKOgn5pofA== Date: Thu, 7 Nov 2013 03:08:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81EDD41DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 15691 X-purgate-ID: 151667::1383793711-00004A43-D16B6F7E/0-0/0-0 Subject: [Netconf] Summary of the Netconf Session at IETF #88 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 03:08:39 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81EDD41DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, NETCONF WG, below is a summary and action items from the NETCONF WG session on November= 4, 2013 in Vancouver, Canada. A short version of the summary is also available at: http://trac.tools.ietf= .org/area/ops/trac/wiki/IETF88summary - We had approx. 60 participants in the 2.5 hour NETCONF session, - We reviewed the status of the WG, - We went through the chartered WG items and had a discussion also on three= non-chartered documents. - Note takers were: Lada Lhotka and Balazs Lengyel. The Jabber scribe was J= uergen Schoenwaelder. The session agenda is available at: http://www.ietf.org/proceedings/88/agen= da/agenda-88-netconf NETCONF Over TLS update - RFC 5539bis http://www.ietf.org/proceedings/88/slides/slides-88-netconf-0.pdf We went through last changes and issues. The discussion on new port has bee= n taken again. Opinion poll of the WG showed that many people were in favor= of a new port and nobody against. The WG also decided to separate the YANG module in a new document, align wi= th the module in Reverse SSH draft and use it for both WG items. Reverse Secure Shell (Reverse SSH) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-1.pptx Text on ZeroConfig has been put into ZeroTouch draft with some extensions. There is an IPR on this draft. The chairs and the author informed the WG on= the details. Zero Touch Provisioning for NETCONF Call Home http://www.ietf.org/proceedings/88/slides/slides-88-netconf-1.pptx The WG has still interest in the document to develop. There was not much co= mments on the maillist. Discussion on whether we need different solutions i= n one draft or the WG should select one. Also discussed whether the draft s= hould be merged with DHCPv6 option draft. The discussion has been taken to = the maillist. RESTCONF Protocol http://www.ietf.org/proceedings/88/slides/slides-88-netconf-3.pdf Andy Bierman went through the last changes, the RESTCONF protocol summary a= nd applicability. The chair explained why it is proposed to develop in Netconf WG. The author= s do not want to create a protocol which competes with Netconf. And it is s= een as beneficial if Netconf and Restconf are developed in parallel and ali= gned with each other. There are obviously different projects outside of IET= F (e.g. OpenDaylight) which use or plan to use Restconf. The opinion poll s= howed that there is a huge interest in this draft and nobody against. As a = result of the discussion with the AD the WG chairs will prepare a charter u= pdate and adopt Restconf as the new WG item. NETCONF Efficiency Extensions http://www.ietf.org/proceedings/88/slides/slides-88-netconf-4.pdf The draft proposes different extensions to Netconf, which have been partly = discussed already earlier. Approx. 15 hands in favor nobody against. There is more discussion necessar= y on the maillist. The WG participants are requested to provide comments on= the extensions and highlight the importance for each of them. NETCONF DHCPv6 Option http://www.ietf.org/proceedings/88/slides/slides-88-netconf-5.pdf Providing a bootstrapping option the draft has been supported. 10 hands in = favor and 1 hand against. The authors will discuss with the ZeroTouch author whether the two drafts c= an be merged. OpenDaylight Update http://www.ietf.org/proceedings/88/slides/slides-88-netconf-6.pptx Jan Medwed presented on the OpenDaylight project status and how they use Ne= tconf/Restconf and YANG. The presentation also highlighted which extensions the project would like t= o propose Netconf and YANG. OpenDaylight has a Restconf implementation and is interested to use such a = RESTful solution. Addendum: After seeing that 6tisch WG discusses a draft, which plans to transport YAN= G modules with CoAP, Netconf chair proposed a discussion on Restconf. The 6= tisch chairs found the idea good and the 6tisch, 6lo, Netconf chairs and th= e Restconf coauthors will meet on Thursday to discuss the use of Restconf i= n these WGs. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F81EDD41DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Benoit, NETCONF WG,
&nbs= p;
below is a summary and action items from the NETCONF WG session on Nov= ember 4, 2013 in Vancouver, Canada.
A short version of the summary is also available at: http://trac.tools.ietf.org/area/ops/trac/wiki/IETF88summary<= /a>
 
- We had approx. 60 participants in the 2.5 hour NETCONF session,
- We reviewed the status of the WG,
- We went through the chartered WG items and had a discussion also on = three non-chartered documents.
- Note takers were: Lada Lhotka and Balazs Lengyel. The Jabber scribe = was Juergen Schoenwaelder.
&nbs= p;
 
We went through last changes and issues. The discussion on new port ha= s been taken again. Opinion poll of the WG showed that many people were in = favor of a new port and nobody against.
The WG also decided to separate the YANG module in a new document, ali= gn with the module in Reverse SSH draft and use it for both WG items.
Text on ZeroConfig has been put into ZeroTouch draft with some extensi= ons.
There is an IPR on this draft. The chairs and the author informed the = WG on the details.
The WG has still interest in the document to develop. There was not mu= ch comments on the maillist. Discussion on whether we need different soluti= ons in one draft or the WG should select one. Also discussed whether the dr= aft should be merged with DHCPv6 option draft. The discussion has been taken to the maillist.
Andy Bierman went through the last changes, the RESTCONF protocol summ= ary and applicability.
The chair explained why it is proposed to develop in Netconf WG. The a= uthors do not want to create a protocol which competes with Netconf. And it= is seen as beneficial if Netconf and Restconf are developed in parallel an= d aligned with each other. There are obviously different projects outside of IETF (e.g. OpenDaylight) which = use or plan to use Restconf. The opinion poll showed that there is a huge i= nterest in this draft and nobody against. As a result of the discussion wit= h the AD the WG chairs will prepare a charter update and adopt Restconf as the new WG item.
The draft proposes different extensions to Netconf, which have been pa= rtly discussed already earlier.
Approx. 15 hands in favor nobody against. There is more discussion nec= essary on the maillist. The WG participants are requested to provide commen= ts on the extensions and highlight the importance for each of them.
&nbs= p;
Providing a bootstrapping option the draft has been supported. 10 hand= s in favor and 1 hand against.
The authors will discuss with the ZeroTouch author whether the two dra= fts can be merged.
Jan Medwed presented on the OpenDaylight project status and how they u= se Netconf/Restconf and YANG.
The presentation also highlighted which extensions the project would l= ike to propose Netconf and YANG.
OpenDaylight has a Restconf implementation and is interested to use su= ch a RESTful solution.
&nbs= p;
Addendum:
After seeing that 6tisch WG discusses a draft, which plans to transpor= t YANG modules with CoAP, Netconf chair proposed a discussion on Restconf. = The 6tisch chairs found the idea good and the 6tisch, 6lo, Netconf chairs a= nd the Restconf coauthors will meet on Thursday to discuss the use of Restconf in these WGs.
&nbs= p;
Cheers,
Mehmet
&nbs= p;
&nbs= p;
&nbs= p;
--_000_E4DE949E6CE3E34993A2FF8AE79131F81EDD41DEMUMBX005nsnintr_-- From skyper@thc.org Thu Nov 7 03:55:55 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8749C21E8131 for ; Thu, 7 Nov 2013 03:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.725 X-Spam-Level: X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_DOSE=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q6rUoNV7dKo for ; Thu, 7 Nov 2013 03:55:49 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 344E721E8159 for ; Thu, 7 Nov 2013 03:55:48 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so609131iec.41 for ; Thu, 07 Nov 2013 03:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xg9cQ+b89ASZ6/4S0wJETxwRWLTKuotxlX7F4Oz2mfc=; b=Ob0v4mzC/RIcNCsQvCo9pmx6av8vj+dkh4bSwNG1y8SXftTEO5BuHzfj1JusTAfwqi zP7xzn0+iPJj+3ujqA/g/C5dzN2pUK8+W8Z1HN2j/8mLHDchy5Xf/ukFUoH7rYjLOEpH bw3TyaF++svEaNbzXC1nK5CDOyfrqiRYAVgtM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xg9cQ+b89ASZ6/4S0wJETxwRWLTKuotxlX7F4Oz2mfc=; b=dOF29EhH27Bjw/GGxRNfJPFnLBC9gXklm7gyRvK7NMozGaLRCk1e6umhm37EdfME1p ylIWDkyfWVG5RdKYVXT9ci8wTOGkA5PAaDT8xvUTxLx+0N4QDO7HG08F7lNtD/nkpV2w YcJ1WXecG1bLMNLj8WX+QYRxvzLPKcH5jNs8PFiH3SYqwrZv2XUJ62T7VyQARSJPKeZ0 58o/E8Kg5WEcTySHf5R5G6Oh4Hh28sMDalPzAb+9U0oDnqz+zNp3O/97LyCvF3we30cz pKwvh/5T/7+oUoAz5OvRqqJ9jkZ/w+GlWPEl/TFmjAzkdGyWL1TcN7v4xU+hRzGjk2tc agtg== X-Gm-Message-State: ALoCoQkCPpzINu0gGN9H2Jz0BDdQTOw2HDtWyOkuaStMehB0/LHemOilS0cNNAC/hB2w+M17e568 MIME-Version: 1.0 X-Received: by 10.51.16.35 with SMTP id ft3mr1641554igd.46.1383825348113; Thu, 07 Nov 2013 03:55:48 -0800 (PST) Received: by 10.64.231.100 with HTTP; Thu, 7 Nov 2013 03:55:47 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: References: Date: Thu, 7 Nov 2013 11:55:47 +0000 Message-ID: From: Ralf Skyper Kaiser To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1134bc1e4ee6e104ea94f25b Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 11:55:55 -0000 --001a1134bc1e4ee6e104ea94f25b Content-Type: text/plain; charset=ISO-8859-1 Hi On Thu, Nov 7, 2013 at 1:13 AM, Kent Watsen wrote: > > > A scenario where an attacker can change/modify either of those ends up > >in a DoS. What other attack vector does DNSSEC solve beside DoS against > >the device? > > I don't understand, how could an attacker change/modify the call home data > in DNS without invalidating a DNSSEC signature? Using DNSSEC is more > about preventing MITM than DoS. > > Misunderstanding. I'm using the word 'DNS' when I'm talking about traditional DNS (RFC1034). I'm using 'DNSSEC' (and DNSSEC-request) to refer to a secure DNS (RFC3833). Your are saying "DNSSEC is more about preventing MITM than DoS". Which is correct. I'm not proposing any new magical trick against the security of DNSSEC. My point is that in ZeroTouch the DNSSEC is used to protect information which if transmitted by DNS do not stop DoS (in general) against ZeroTouch devices. Assuming ZeroTouch would use DNS (not DNSSEC) the attacker can send wrong information to the ZeroTouch device which ultimately ends in a DoS (e.g. the ZeroTouch device will attempt but fail to establish a secure connection (TLS/SSH) to the wrong NMS). The sole and only use for DNSSEC in ZeroTouch (not in general) is to prevent (or detect) a DoS-by-MITM. DNSSEC does not prevent an attacker (in general) to perform a DoS (by MITM or other means). You can not stop an attacker to DoS the ZeroTouch device regardless if ZeroTouch uses DNSSEC or not. In fact performing a DoS where the ZeroTouch device connects to the wrong NMS even when DNSSEC is used is possible with far less effort and without breaking DNSSEC (see my previous email with the list of other MITM attacks). ZeroTouch has to deal with the problem that a ZeroTouch device might connect to the wrong NMS even when DNSSEC is used. ZeroTouch deals with this in a correct and secure way: It uses TLS/SSH. The TCP connection to the wrong NMS will succeed but the secure connection will fail. It appears that DNSSEC is used in an attempt to prevent one (of many) ways to DoS the ZeroTouch device. An attack will laugh at this attempt and say "Well, if I can not DoS ZeroTouch device by DNS poisoning I just use any of my other 10 MITM tricks [see previous email for a list] against which ZeroTouch currently does not protect". An attacker gets what he wants (DoS) even if DNSSEC is used. So why bother with DNSSEC? It just adds code and complexity. (This would be all different if DNSSEC were to be used to transfer information which have to be authentic - like public key material). > > If DNSSEC in this scenario only solves a DoS then why bother with DNSSEC > >considering that the attacker can already mount a DoS attack with far > >less resources at a far lower cost. > > Because a MITM (not-detectable) is worse than a DoS (detectable) - makes > sense? > No, because you do not protect (or detect) any of the other DoS either (and you should not try to). Maybe a real life fairy tale scenario helps (sorry, that's the best I can up with at 3am in the morning): 10 gates to enter a castle. You put one guard (DNSSEC) at just 1 of the 10 gates saying that you will now detect DoS (at that gate). DoS still gets in to any of the 9 other gates. You can not protect all 10 gates. Might as well use the guard (e.g. resources) to do something else. DNSSEC in ZeroTouch adds unnecessary complexity. (The guard at 1 of the 10 gates does not solve your problem). thanks & regards, ralf > > > Thanks, > Kent > > > --001a1134bc1e4ee6e104ea94f25b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi

On Thu, Nov 7, 2013 at 1:13 AM, Kent Watsen &l= t;kwatsen@juniper.= net> wrote:

> A scenario where an attacker can change/modify either of those ends up=
>in a DoS. What other attack vector does DNSSEC solve beside DoS against=
>the device?

I don't understand, how could an attacker change/modify the call = home data
in DNS without invalidating a DNSSEC signature? =A0Using DNSSEC is more
about preventing MITM than DoS.


Misunderstandi= ng.

I'm using the word 'DNS' when I'm tal= king about traditional DNS (RFC1034). I'm using
=A0'DNSSEC' = (and DNSSEC-request) to refer to a secure DNS (RFC3833).

Your are saying "DNSSEC is more about preventing MITM t= han DoS".

Which is correct. I'm not proposing an= y new magical trick against
the security of DNSSEC.

My point is that in ZeroTouch the DNSSEC is used to pro= tect information which
if transmitted by DNS do not stop DoS (in general= ) against ZeroTouch devices.

Assuming ZeroTouch would use DNS (not D= NSSEC) the attacker can send wrong
information to the ZeroTouch device which ultimately ends in a DoS (e.g. th= e
ZeroTouch device will attempt but fail to establish a secur= e connection (TLS/SSH)
to the wrong NMS).

The sole and= only use for DNSSEC in ZeroTouch (not in general) is to
prevent (or detect) a DoS-by-MITM.

DNSSEC does not preve= nt an attacker (in general) to perform a DoS (by MITM or
other means).
You can not stop an attacker to DoS the ZeroTouch device regardless i= f ZeroTouch
uses DNSSEC or not.

In fact performing a DoS where the ZeroTouch dev= ice connects to the wrong NMS
even when DNSSEC is used is pos= sible with far less effort and without breaking
DNSSEC (see my previous = email with the list of other MITM attacks).

ZeroTouch has to deal with the p= roblem that a ZeroTouch device might connect to the
wrong NMS even when = DNSSEC is used.

ZeroTouch deals wit= h this in a correct and secure way: It uses TLS/SSH. The
TCP connection to the wrong NMS will succeed but the secure connection will= fail.

It appears that DNSSEC is us= ed in an attempt to prevent one (of many) ways to
DoS the ZeroTouch device.

An attack= will laugh at this attempt and say "Well, if I can not DoS ZeroTouch = device
by DNS poisoning I just use any of my other 10 MITM tricks [see p= revious email for
a list] against which ZeroTouch currently = does not protect".

An attacker= gets what he wants (DoS) even if DNSSEC is used.

So why bother with DNSSEC? It just add= s code and complexity.

(This would = be all different if DNSSEC were to be used to transfer information which ha= ve
to be authentic - like public key material).



> If DNSSEC in this scenario only solves a DoS then why bother with DNSS= EC
>considering that the attacker can already mount a DoS attack with far >less resources at a far lower cost.

Because a MITM (not-detectable) is worse than a DoS (detectable) - ma= kes
sense?

No, because you do not protect (= or detect) any of the other DoS either (and you should
not tr= y to).

Maybe a real life fairy tale scenario helps (sorr= y, that's the best I can up
with at 3am in the morning):

10 gates to enter a castle. = You put one guard (DNSSEC) at just 1 of the 10 gates
saying that you wil= l now detect DoS (at that gate).

DoS still gets in to any= of the 9 other gates.

You can not protect all 10 gates. Might as well use the guar= d (e.g. resources) to do
something else.

DNSSEC in Zer= oTouch adds unnecessary complexity. (The guard at 1 of the 10 gates does
not solve your problem).

thanks &am= p; regards,

ralf
=A0


Thanks,
Kent



--001a1134bc1e4ee6e104ea94f25b-- From yiya@cisco.com Thu Nov 7 10:50:40 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BAC11E8222 for ; Thu, 7 Nov 2013 10:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPioc8XBezbB for ; Thu, 7 Nov 2013 10:50:14 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6525621E8144 for ; Thu, 7 Nov 2013 10:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4353; q=dns/txt; s=iport; t=1383850199; x=1385059799; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=nllXCHf+mgHNYbEgQBmMrAmK/+LxjRc2UNRAM4Hdhu8=; b=L6INKjqjZpRwrOg6YSahFUTNd1Fz2LIIHefIypwa/Uan+oXDsJXgMAs4 AUHrwnFlhoEzjfBYSUBB1qZE+JzAkETX46e3qBc+VZ5UusMDy4OWx5UfT XUzhepesLnXv70ykL4JhS3XsEjM3hvC7sjr9rJwbMqMQ9fVajbnHiWRJz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAPffe1KtJXHA/2dsb2JhbABagkNEgQu/D4ElFnSCJQECBHkSAQgEDQMBAig5FAkIAgQBDQWIAbxoj0gRB4QwA5gMkgqDJoIq X-IronPort-AV: E=Sophos;i="4.93,653,1378857600"; d="scan'208,217";a="282071387" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 07 Nov 2013 18:49:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA7InwPA025376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 18:49:58 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 12:49:58 -0600 From: "Yi Yang (yiya)" To: Ralf Skyper Kaiser , Ladislav Lhotka Thread-Topic: [Netconf] Why bother with DNSSEC for ZeroTouch? Thread-Index: AQHO2lqHZjgeYJOjb0GqFPuDTKqctpoXaiCAgAAHyoCAAAQdgIAAAlmAgAK3/YA= Date: Thu, 7 Nov 2013 18:49:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.82.236.29] Content-Type: multipart/alternative; boundary="_000_CEA1480C1B73Byiyaciscocom_" MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:50:40 -0000 --_000_CEA1480C1B73Byiyaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline with [Yi] From: Ralf Skyper Kaiser > Date: Tuesday, November 5, 2013 3:18 PM To: Ladislav Lhotka > Cc: Netconf > Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? No it does not. DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SS= H traffic: - arp poisoning - Switch/CAM table tricks - transparent proxy - router reconfiguration - directly tapping the physical wire - .. this list is not complete....pretty much anywhere and using any method= between the client and the NMS. [Yi]: In the above cases, they have to be launched in the path between the= client and NMS, or around the clients. But without DNSSEC, the attacker ca= n be anywhere. [Yi]: In addition, the threat scope is different. Those aforementioned thre= ats will influence a subnet of clients which are closed to the subverted de= vices. But without DNSSEC, all clients across network will be impacted. DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS poison= ing. Not more. regards, ralf --_000_CEA1480C1B73Byiyaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Inline with [Yi]

From: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tuesday, November 5, 2013 3:1= 8 PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Why bother w= ith DNSSEC for ZeroTouch?

<snip>

No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SS= H traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any m= ethod between the client and the NMS.

[Yi]: In the above cases, they have to be launched in  the path b= etween the client and NMS, or around the clients. But without DNSSEC, the a= ttacker can be anywhere. 

[Yi]: In addition, the threat scope is different. Those aforementioned= threats will influence a subnet of clients which are closed to the subvert= ed devices. But without DNSSEC, all clients across network will be impacted= .

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS p= oisoning. Not more.

regards,

ralf

 --_000_CEA1480C1B73Byiyaciscocom_-- From ibrahim_g01867@utp.edu.my Fri Nov 8 02:25:04 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8915F21E80AA for ; Fri, 8 Nov 2013 02:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.545 X-Spam-Level: X-Spam-Status: No, score=0.545 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MY=0.35, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26Xfioa0lKUq for ; Fri, 8 Nov 2013 02:24:59 -0800 (PST) Received: from mailbeta.utp.edu.my (mail.utp.edu.my [203.135.191.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4946321E8090 for ; Fri, 8 Nov 2013 02:24:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailbeta.utp.edu.my (Postfix) with ESMTP id A7DAFAE3196 for ; Fri, 8 Nov 2013 14:44:52 +0800 (MYT) Received: from mailbeta.utp.edu.my ([127.0.0.1]) by localhost (mailbeta.utp.edu.my [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PF0ZudxSDdqf for ; Fri, 8 Nov 2013 14:44:40 +0800 (MYT) Received: from localhost (localhost [127.0.0.1]) by mailbeta.utp.edu.my (Postfix) with ESMTP id 7B7DCAE3197 for ; Fri, 8 Nov 2013 14:44:40 +0800 (MYT) X-Virus-Scanned: amavisd-new at mailbeta.utp.edu.my Received: from mailbeta.utp.edu.my ([127.0.0.1]) by localhost (mailbeta.utp.edu.my [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C1XmuDKKFaXq for ; Fri, 8 Nov 2013 14:44:40 +0800 (MYT) Received: from mailbeta.utp.edu.my (mailbeta.utp.edu.my [192.168.1.89]) by mailbeta.utp.edu.my (Postfix) with ESMTP id 56EC2AE3196 for ; Fri, 8 Nov 2013 14:44:40 +0800 (MYT) Date: Fri, 8 Nov 2013 14:44:40 +0800 (MYT) From: "Ibrahim A. Lawal" To: netconf@ietf.org Message-ID: <1681634166.492179.1383893080264.JavaMail.zimbra@utp.edu.my> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [203.135.190.111] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - IE9 (Win)/8.0.4_GA_5737) Thread-Topic: Netconf Digest, Vol 69, Issue 9 Thread-Index: xU6yPNGqV3TBKUrZk2+3E/YvTbA8sg== Subject: Re: [Netconf] Netconf Digest, Vol 69, Issue 9 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 10:25:04 -0000 Thanks ----- Original Message ----- From: netconf-request@ietf.org To: netconf@ietf.org Sent: Wednesday, November 6, 2013 9:53:01 AM Subject: Netconf Digest, Vol 69, Issue 9 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/netconf Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Netconf mailing list submissions to netconf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/netconf or, via email, send a message with subject or body 'help' to netconf-request@ietf.org You can reach the person managing the list at netconf-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Netconf digest..." Today's Topics: 1. Re: Why bother with DNSSEC for ZeroTouch? (Ladislav Lhotka) 2. Re: Why bother with DNSSEC for ZeroTouch? (Ralf Skyper Kaiser) 3. Re: I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt (Kent Watsen) 4. Re: Why bother with DNSSEC for ZeroTouch? (Kent Watsen) 5. Re: Reverse TLS and reverse SSH: Why support both? (Kent Watsen) ---------------------------------------------------------------------- Message: 1 Date: Tue, 5 Nov 2013 12:10:31 -0800 From: Ladislav Lhotka To: Ralf Skyper Kaiser Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? Message-ID: Content-Type: text/plain; charset=windows-1252 On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser wrote: > Hi, > > . > > > On Tue, Nov 5, 2013 at 7:27 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 11:09, Ralf Skyper Kaiser wrote: > > I don?t agree. The attacker has an open TCP session and can use it for other attacks, not only DoS. Already the information about the existence and address of the device might be a problem. > > > Even with DNSSEC an attacker can make the device to connect to a bogus NMS and thus giving the attacker an open TCP session to the device?? With DNSSEC this becomes considerably harder. > > Other that that, DNSSEC can be useful in connection with DANE (RFC 6698), so that a certificate of a DNSSEC root (public or private) is all that?s needed - NMS certificate can thrn be obtained from DNS. > > In ZeroTouch the CA bundle is pre-programmed into the device. So DANE is not required. (And it DANE would be required than the CA key to verify the DNSSEC request would need to be preprogrammed into the device - nothing is gained beside making it complex?). The device can only be pre-programmed with DNSSEC trust anchor, and that?s all. I don?t call it complex. Lada > > regards, > > ralf > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ------------------------------ Message: 2 Date: Tue, 5 Nov 2013 20:18:55 +0000 From: Ralf Skyper Kaiser To: Ladislav Lhotka Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? Message-ID: Content-Type: text/plain; charset="windows-1252" Hi, On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser wrote: > > > > > Even with DNSSEC an attacker can make the device to connect to a bogus > NMS and thus giving the attacker an open TCP session to the device?? > > With DNSSEC this becomes considerably harder. > > No it does not. DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SSH traffic: - arp poisoning - Switch/CAM table tricks - transparent proxy - router reconfiguration - directly tapping the physical wire - .. this list is not complete....pretty much anywhere and using any method between the client and the NMS. DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS poisoning. Not more. regards, ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Wed, 6 Nov 2013 00:30:21 +0000 From: Kent Watsen To: Joe Touch Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Message-ID: Content-Type: text/plain; charset="us-ascii" Hi Joe, This issue was discussed in the NETCONF WG meeting. Specifically, the choices of: - having a default port - not having a default port (port has to be explicitly configured) - try to update the TLS and SSH protocols to support reversal There was unanimous support in the room to have a default port (around 30 people). No one raised their hand to support any other option. Playing devil's advocate, I made a case for having NO default port. That is, for the ZeroTouch solution, the device is already learning so much NMS-specific information, learning a port number also is easy. Unfortunately, reverse-SSH and reverse-TLS can be used outside of ZeroTouch and, for those cases, the port would then need to be manually configured, which people didn't like. As a quick recap, we initially took Reverse SSH to the SSH list, but it died there due to this port issue. Reverse SSH was resurrected after receiving a lot of operator demand for it. We decided to bring Reverse SSH to NETCONF WG specifically to end the discussion of if it uses an in-band or out-of-band mechanism to trigger the reversal. The NETCONF WG consensus was at that time and is still to use a port. Thanks, Kent ------------------------------ Message: 4 Date: Wed, 6 Nov 2013 01:14:18 +0000 From: Kent Watsen To: Ralf Skyper Kaiser , Ladislav Lhotka Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi Ralf, Please explain the specific attack you're envisioning. I agree that the device's call-home connection could be steered to another system and I'll agree that that system could blindly authenticate the device's public key. But in order for security to be compromised, that system needs to be able to authenticate itself to the device, which is where it will fail because it will not know the real NMS's auth credentials (e.g. private key). Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to configure the device with the NMS it's to connect to and 2) to configure the device with information it can use to authenticate the NMS with. It is this 2nd piece of information that prevents the spoofer from succeeding. Critical to this is that the device can verify the authenticity of the information it downloads from the network, which is where using DNSSEC plays a role. Makes sense? PS: I also agree with your premise that unnecessary code leads to a larger attack surface, but devices should already have support for DNSSEC. It is not envisioned that this solution introduces new code to the device but, if it does, it is a good thing. Thanks, Kent From: Ralf Skyper Kaiser > Date: Tuesday, November 5, 2013 12:18 PM To: Ladislav Lhotka > Cc: NetConf > Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? Hi, On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka > wrote: On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser > wrote: > > Even with DNSSEC an attacker can make the device to connect to a bogus NMS and thus giving the attacker an open TCP session to the device...... With DNSSEC this becomes considerably harder. No it does not. DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SSH traffic: - arp poisoning - Switch/CAM table tricks - transparent proxy - router reconfiguration - directly tapping the physical wire - .. this list is not complete....pretty much anywhere and using any method between the client and the NMS. DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS poisoning. Not more. regards, ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Wed, 6 Nov 2013 01:51:48 +0000 From: Kent Watsen To: Ralf Skyper Kaiser , "netconf@ietf.org" Subject: Re: [Netconf] Reverse TLS and reverse SSH: Why support both? Message-ID: Content-Type: text/plain; charset="iso-8859-1" > Why support SSH and TLS? Either protocol establishes a secure tunnel by >exchanging 1?s and 0?s. NETCONF supports both transports for good reasons. > Why leave the decision which protocol to use to the manufacture? If the >WG can?t decide if TLS or SSH is more secure then the manufacture won?t >be able to decide either. It isn't left to the manufacturer, each specific deployment chooses it for themselves. > Removing one of them from the implementation halves the possibilities >for an attacker to find vulnerabilities, enables the developer to spend >2x the time (and care) on one protocol and removes complexity in general. > Focusing on one protocol and give that one protocol all attention >(review, testing, audit ...) could have some advantages. Noted. Each manufacturer can choose what they want to implement and support. > My gut feeling is that reverse SSH should be dropped unless there is a >functionality or security benefit that cannot be achieved with reverse >TLS. SSH is NETCONF's mandatory transport, as such, supporting Call Home with SSH is a given. > Trusting a manufacture to generate secure X.509 certificates, having a >secure RNG and running a CA securely gives me a funny feeling. But hey, >what can possibly go wrong....:> Your concern is unwarranted. The spec clearly states that the manufacturer should use a TPM. These chips are typically awarded the highest security certifications (FIPS, CC, etc.). Also, this proposal has been reviewed by multiple security experts with no concern raised. But, really, what option is there, given the use-cases ZeroTouch tries to solve? Thanks, Kent ------------------------------ _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf End of Netconf Digest, Vol 69, Issue 9 ************************************** From mehmet.ersue@nsn.com Mon Nov 18 13:58:54 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6332C1AE5A5 for ; Mon, 18 Nov 2013 13:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9257JwCrc_xr for ; Mon, 18 Nov 2013 13:58:52 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E13CE1AD9B8 for ; Mon, 18 Nov 2013 13:58:51 -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 rAILwfFa009711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 22:58:41 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAILwevL024228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 22:58:40 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 18 Nov 2013 22:58:40 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 22:58:40 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Draft Minutes for the IETF 88 NETCONF Session Thread-Index: AQHO5KlWimaLTm8iwUyDK++ke56e/g== Date: Mon, 18 Nov 2013 21:58:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.124] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81F9365DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6002 X-purgate-ID: 151667::1384811922-00005753-331539DB/0-0/0-0 Subject: [Netconf] Draft Minutes for the IETF 88 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:58:54 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81F9365DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, below is the link to the draft minutes of the NETCONF session in IETF 88. Pls send your comments to the co-chairs by November 29, 2013. http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf If somebody can resolve the missing names pls send a note. Many thanks to the minute takers Lada Lhotka, Balazs Lengyel and the Jabber scribe Juergen Schoenwaelder. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F81F9365DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF WG,

 

below is the link to the draft minutes = of the NETCONF session in IETF 88.

Pls send your comments to the co-chairs= by November 29, 2013.

 

If somebody can resolve the missing nam= es pls send a note.

Many thanks to the minute takers Lada L= hotka, Balazs Lengyel and

the Jabber scribe Juergen Schoenwaelder= .

 

Cheers,

Mehmet

 

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F81F9365DEMUMBX005nsnintr_-- From skyper@thc.org Tue Nov 19 04:22:49 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9C1ADF57 for ; Tue, 19 Nov 2013 04:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSnlXGcCXQVT for ; Tue, 19 Nov 2013 04:22:47 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 578FC1ADBD2 for ; Tue, 19 Nov 2013 04:22:47 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so2875953iec.9 for ; Tue, 19 Nov 2013 04:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Q2sPTrH6kp227RJXuvzxp/j2YGMjuFi4kfy2Rvt8uY=; b=ZQGDY9ObO2cKHuCwmCHAoSzr3Qig0n6yo0lBMV2PpgcttmMTTSOLVLWVxDrXdEt78B PmQG3BP/AjdoIzVhrXU7BjQxeIX4VXmn2r5nkZvc6a/YQuteRetfmFDVjUg6OfLFRBTy H7mc6kSkwHdgR/xVGiZJs5xtCeSI7WP3iU96M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5Q2sPTrH6kp227RJXuvzxp/j2YGMjuFi4kfy2Rvt8uY=; b=No8U0QhHITc0JEVcEd0568aUCXKuXW/wQEOea3xBnk9pAWfWVI5HCmm+p/sslfhz3M TPXeuiyqt8I/B4DAzU9v1jCnv74UEjQeJ5Ut5OsO/wbKM+wcoOW5V9Og0/5LsCG3Aa0W kHmgepddx7s/cB41m1qoUKLGq1l3M080v72adaH+W/7VAzKBr3Glx0EeuVJsGekVv6or JaoMzTptcmlxX/QD70McY05Og4CU9ibIrvT3kehHogiXTozGY3aYEiKBQ43A0v9hvT/j JhUuMtvvIW6iRZBjx+BJQbiLmlokBd8STCRYlmuZNQxUL8WGk5DpQjHFiKbUb2quuIN3 Mj2w== X-Gm-Message-State: ALoCoQnlg+WEhCSz8fTqbME29U8Zh9OPeXIpu3IFZ2X2PMnkhNlEwmv3DCqdQHgdCto7axz8dI0y MIME-Version: 1.0 X-Received: by 10.50.131.163 with SMTP id on3mr18512944igb.46.1384863761315; Tue, 19 Nov 2013 04:22:41 -0800 (PST) Received: by 10.64.9.41 with HTTP; Tue, 19 Nov 2013 04:22:41 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: References: Date: Tue, 19 Nov 2013 12:22:41 +0000 Message-ID: From: Ralf Skyper Kaiser To: "Yi Yang (yiya)" Content-Type: multipart/alternative; boundary=047d7b2e0d1f8e5fb004eb86b8d7 Cc: Netconf Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:22:49 -0000 --047d7b2e0d1f8e5fb004eb86b8d7 Content-Type: text/plain; charset=ISO-8859-1 Yi, DNSSEC in netconf is used to prevent one particular DoS attack. That's it. Not more. Not less. (It does not protect against other DoS attacks. So netconf anyway has to deal with DoS [and it does so very well - ultimately with TLS/SSH authentication]). DNSSEC is not use to prevent wrong netconf-configuration to be send to the device (That's done by TLS/SSH - not DNSSEC). DNSSEC protect against this 1 DoS that has no practical gain for the attacker (e.g. the DoS does not enable the attacker to send wrong netconf configuration to the device). (A DoS also means that the attacks risks detection - something that most attacks do not want.) I appreciate the effort to protect netconf against this 1 DoS. From my experience will this reduce the security of netcont. I said this before: DNSSEC is a complex beast. The source/program code does contain remote vulnerabilities (we have just not found them yet - believing that it is vulnerability free would be naive). Netconf enabled devices are mostly embedded. Those device have a long shelf-life time before deployment. A vulnerability in DNSSEC/netconf will be found and you wont have any chance of fixing them beside recalling hardware - which wont happen. That's the cost of protecting against 1 DoS. It's out of balance. (and same argument goes for supporting TLS and SSH. You are doubling the amount of source/programm code vulnerabilities...). regards, ralf On Thu, Nov 7, 2013 at 6:49 PM, Yi Yang (yiya) wrote: > Inline with [Yi] > > From: Ralf Skyper Kaiser > Date: Tuesday, November 5, 2013 3:18 PM > To: Ladislav Lhotka > Cc: Netconf > > Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch? > > > > No it does not. > DNSSEC does not prevent any of these to redirect the reverse TLS/reverse > SSH traffic: > - arp poisoning > - Switch/CAM table tricks > - transparent proxy > - router reconfiguration > - directly tapping the physical wire > - .. this list is not complete....pretty much anywhere and using any > method between the client and the NMS. > > [Yi]: In the above cases, they have to be launched in the path between > the client and NMS, or around the clients. But without DNSSEC, the attacker > can be anywhere. > > [Yi]: In addition, the threat scope is different. Those aforementioned > threats will influence a subnet of clients which are closed to the > subverted devices. But without DNSSEC, all clients across network will be > impacted. > > DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS > poisoning. Not more. > > regards, > > ralf > > --047d7b2e0d1f8e5fb004eb86b8d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yi,

DNSSEC in netconf is used to prevent = one particular DoS attack. That's it. Not more. Not less.
(It = does not protect against other DoS attacks. So netconf anyway has to deal w= ith DoS [and it
does so very well - ultimately with TLS/SSH authentication]).

D= NSSEC is not use to prevent wrong netconf-configuration to be send to the d= evice (That's done
by TLS/SSH - not DNSSEC).

DNSSE= C protect against this 1 DoS that has no practical gain for the attacker (e= .g. the DoS does not enable
the attacker to send wrong netconf configuration to the device). (A DoS als= o means that the attacks risks
detection - something that most attacks d= o not want.)

I appreciate the effort to protec= t netconf against this 1 DoS. From my experience will this reduce the
security of netcont. I said this before:

DNSSEC is a comp= lex beast. The source/program code does contain remote vulnerabilities (we = have just
not found them yet - believing that it is vulnerability free w= ould be naive).

Netconf enabled devices are mostly embedded. Those device ha= ve a long shelf-life time before deployment.
A vulnerability in DNSSEC/n= etconf will be found and you wont have any chance of fixing them beside
recalling hardware - which wont happen.

That's the co= st of protecting against 1 DoS. It's out of balance.

= (and same argument goes for supporting TLS and SSH. You are doubling the am= ount of source/programm code vulnerabilities...).

regards,

ralf


=



On Thu, Nov 7, 2013 at 6:49 PM, Yi = Yang (yiya) <yiya@cisco.com> wrote:
Inline with [Yi]

From: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tuesday, November 5, 20= 13 3:18 PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Netconf <netconf@ietf.org>

Subject: Re: [Netconf] Why bother w= ith DNSSEC for ZeroTouch?

<snip>

No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SS= H traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any m= ethod between the client and the NMS.

[Yi]: In the above cases, they have to be launched in =A0the path betw= een the client and NMS, or around the clients. But without DNSSEC, the atta= cker can be anywhere.=A0

[Yi]: In addition, the threat scope is different. Those aforementioned= threats will influence a subnet of clients which are closed to the subvert= ed devices. But without DNSSEC, all clients across network will be impacted= .

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS p= oisoning. Not more.

regards,

ralf

--047d7b2e0d1f8e5fb004eb86b8d7-- From kwatsen@juniper.net Tue Nov 19 12:01:14 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9D1AE240 for ; Tue, 19 Nov 2013 12:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf6grFrcApD9 for ; Tue, 19 Nov 2013 12:01:13 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 53DC31AE252 for ; Tue, 19 Nov 2013 12:00:53 -0800 (PST) Received: from mail164-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Nov 2013 20:00:47 +0000 Received: from mail164-va3 (localhost [127.0.0.1]) by mail164-va3-R.bigfish.com (Postfix) with ESMTP id 0F91E380232 for ; Tue, 19 Nov 2013 20:00:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz119bI1dbaI4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h1155h) Received-SPF: pass (mail164-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(45074003)(164054003)(54356001)(74876001)(76796001)(76786001)(74706001)(76176001)(56816003)(77982001)(51856001)(79102001)(63696002)(59766001)(83506001)(77096001)(69226001)(85306002)(53806001)(76482001)(83072001)(65816001)(47446002)(74502001)(50986001)(47976001)(87936001)(81342001)(54316002)(2656002)(31966008)(83322001)(80022001)(46102001)(74662001)(66066001)(56776001)(81542001)(4396001)(36756003)(87266001)(74366001)(81686001)(80976001)(47736001)(49866001)(81816001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail164-va3 (localhost.localdomain [127.0.0.1]) by mail164-va3 (MessageSwitch) id 1384891245379267_19896; Tue, 19 Nov 2013 20:00:45 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.250]) by mail164-va3.bigfish.com (Postfix) with ESMTP id 49102200B8 for ; Tue, 19 Nov 2013 20:00:45 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 19 Nov 2013 20:00:39 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 19 Nov 2013 20:00:38 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 20:00:36 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.188]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.181]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 20:00:36 +0000 From: Kent Watsen To: Netconf Thread-Topic: regarding combining reverse-tls and reverse-ssh Thread-Index: AQHO5WIDegXxIGAwEEiJ+TMD1y2hkg== Date: Tue, 19 Nov 2013 20:00:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.10] x-forefront-prvs: 0035B15214 Content-Type: text/plain; charset="us-ascii" Content-ID: <5F32AEA266F7EB44990AFA5AAD320A06@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 20:01:15 -0000 There was consensus in the Vancouver meeting to combine the YANG modules for reverse-ssh and reverse-tls. I want to suggest a few options. Current Status: RFC5539bis RFC6242 (call-home + YANG module) ^ | | Draft reverse-ssh (call-home + YANG module) Option #1: RFC5539bis RFC6242 (call-home) ^ ^ | \ | \ draft-reverse-ssh \ (call-home) \ ^ \ / \ / \ / draft-call-home-config (just YANG module) Option #2: RFC5539bis RFC6242bis (call-home) (call-home text added) ^ ^ \ / \ / \ / \ / draft-call-home-config (just YANG module) Option #3: RFC5539bis RFC6242 (call-home text removed) (no call-home) ^ ^ \ / \ / \ / \ / draft-netconf-call-home (call-home + YANG module) Thoughts: - Both #2 or #3 achieve symmetry (symmetry good, yes?) - Only #3 provides a complete-solution, defining both protocol and config, for both SSH & TLS. - Thinking about possible further transports, any option seems OK, assuming config will always need to be revisioned... What do you think? Thanks, Kent From mehmet.ersue@nsn.com Tue Nov 19 12:21:14 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C34C1AE252 for ; Tue, 19 Nov 2013 12:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRhL9sfkQYZi for ; Tue, 19 Nov 2013 12:21:12 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DB06C1AE251 for ; Tue, 19 Nov 2013 12:21:11 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAJKL22p016709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Nov 2013 21:21:02 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAJKL2d3006049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 21:21:02 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Nov 2013 21:21:02 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 21:21:01 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Kent Watsen , Netconf Thread-Topic: regarding combining reverse-tls and reverse-ssh Thread-Index: AQHO5WIDegXxIGAwEEiJ+TMD1y2hkpos/vBA Date: Tue, 19 Nov 2013 20:21:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2707 X-purgate-ID: 151667::1384892463-00005753-369CB094/0-0/0-0 Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 20:21:14 -0000 #3 Cheers,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Kent Wat= sen > Sent: Tuesday, November 19, 2013 9:01 PM > To: Netconf > Subject: [Netconf] regarding combining reverse-tls and reverse-ssh >=20 >=20 > There was consensus in the Vancouver meeting to combine the YANG modules > for reverse-ssh and reverse-tls. I want to suggest a few options. >=20 > Current Status: >=20 > RFC5539bis RFC6242 > (call-home + YANG module) ^ > | > | > Draft reverse-ssh > (call-home + YANG module) >=20 >=20 >=20 > Option #1: >=20 > RFC5539bis RFC6242 > (call-home) ^ > ^ | > \ | > \ draft-reverse-ssh > \ (call-home) >=20 >=20 > \ ^ > \ / > \ / > \ / > draft-call-home-config > (just YANG module) >=20 >=20 >=20 > Option #2: >=20 > RFC5539bis RFC6242bis > (call-home) (call-home text added) > ^ ^ > \ / > \ / > \ / > \ / > draft-call-home-config > (just YANG module) >=20 >=20 >=20 >=20 >=20 > Option #3: >=20 > RFC5539bis RFC6242 > (call-home text removed) (no call-home) > ^ ^ > \ / > \ / > \ / > \ / > draft-netconf-call-home > (call-home + YANG module) >=20 >=20 >=20 >=20 > Thoughts: > - Both #2 or #3 achieve symmetry (symmetry good, yes?) > - Only #3 provides a complete-solution, defining both > protocol and config, for both SSH & TLS. > - Thinking about possible further transports, any option seems > OK, assuming config will always need to be revisioned... >=20 > What do you think? >=20 >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Tue Nov 19 12:33:07 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3EC1AE140 for ; Tue, 19 Nov 2013 12:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAqT5C4fsohk for ; Tue, 19 Nov 2013 12:33:05 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 671AC1AE123 for ; Tue, 19 Nov 2013 12:33:05 -0800 (PST) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 0688812002EE; Tue, 19 Nov 2013 21:32:58 +0100 (CET) Date: Tue, 19 Nov 2013 21:32:57 +0100 (CET) Message-Id: <20131119.213257.57729216.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 20:33:07 -0000 Hi Kent, I prefer #2. I think it makes sense to keep all transport-specific details in one document, and have a separate document to configure them. I can think of option #4 as well, but I think it is overkill: RFC5539bis RFC6242bis (call-home) (call-home text added) augment model augment model w/ tls-stuff w/ ssh-stuff \ / \ / \ / \ / V V draft-netconf-server-config (YANG module w/ netconf-server specific config, including call-home) Actually, maybe option #2+ would be a netconf-server specific data model with more things than just call home, specifically normal listen address + port and timeouts etc. /martin Kent Watsen wrote: > > There was consensus in the Vancouver meeting to combine the YANG modules > for reverse-ssh and reverse-tls. I want to suggest a few options. > > Current Status: > > RFC5539bis RFC6242 > (call-home + YANG module) ^ > | > | > Draft reverse-ssh > (call-home + YANG module) > > > > Option #1: > > RFC5539bis RFC6242 > (call-home) ^ > ^ | > \ | > \ draft-reverse-ssh > \ (call-home) > > > \ ^ > \ / > \ / > \ / > draft-call-home-config > (just YANG module) > > > > Option #2: > > RFC5539bis RFC6242bis > (call-home) (call-home text added) > ^ ^ > \ / > \ / > \ / > \ / > draft-call-home-config > (just YANG module) > > > > > > Option #3: > > RFC5539bis RFC6242 > (call-home text removed) (no call-home) > ^ ^ > \ / > \ / > \ / > \ / > draft-netconf-call-home > (call-home + YANG module) > > > > > Thoughts: > - Both #2 or #3 achieve symmetry (symmetry good, yes?) > - Only #3 provides a complete-solution, defining both > protocol and config, for both SSH & TLS. > - Thinking about possible further transports, any option seems > OK, assuming config will always need to be revisioned... > > What do you think? > > > Thanks, > Kent > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From kwatsen@juniper.net Tue Nov 19 12:53:12 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E961AE1A7 for ; Tue, 19 Nov 2013 12:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZlyqYMJVWCa for ; Tue, 19 Nov 2013 12:53:10 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C91A1F7C for ; Tue, 19 Nov 2013 12:53:10 -0800 (PST) Received: from mail103-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Tue, 19 Nov 2013 20:53:03 +0000 Received: from mail103-ch1 (localhost [127.0.0.1]) by mail103-ch1-R.bigfish.com (Postfix) with ESMTP id E2B811E07B9 for ; Tue, 19 Nov 2013 20:53:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz1dbaI4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h1155h) Received-SPF: pass (mail103-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(76786001)(76796001)(65816001)(77096001)(66066001)(85306002)(69226001)(53806001)(51856001)(4396001)(46102001)(47976001)(54356001)(47736001)(50986001)(49866001)(83506001)(80976001)(2656002)(63696002)(56816003)(81542001)(74706001)(74662001)(87936001)(81686001)(87266001)(83322001)(81816001)(81342001)(31966008)(56776001)(80022001)(76482001)(36756003)(74876001)(47446002)(54316002)(74366001)(74502001)(83072001)(59766001)(79102001)(76176001)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail103-ch1 (localhost.localdomain [127.0.0.1]) by mail103-ch1 (MessageSwitch) id 1384894382183125_31215; Tue, 19 Nov 2013 20:53:02 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail103-ch1.bigfish.com (Postfix) with ESMTP id 1EE0440014B for ; Tue, 19 Nov 2013 20:53:02 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 19 Nov 2013 20:53:01 +0000 Received: from BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 19 Nov 2013 20:53:01 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 20:53:00 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.188]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.181]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 20:52:59 +0000 From: Kent Watsen To: Netconf Thread-Topic: regarding reducing number of future call-home ports Thread-Index: AQHO5WlUFaABO7w2xkSckRd3uotuhw== Date: Tue, 19 Nov 2013 20:52:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.10] x-forefront-prvs: 0035B15214 Content-Type: text/plain; charset="us-ascii" Content-ID: <8B1E3E0D504E284287744CCE16AAD408@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Netconf] regarding reducing number of future call-home ports X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 20:53:12 -0000 Here's an idea addressing Joe Touch's concern for port-proliferation: 1. Assume there is a defined TCP-port called the "call-home" port 2. The NMS accepts TCP connections from devices on this port 3. As soon as a TCP connection is established, the device sends a cleartext message indicated which protocol it wants to run in reverse (e.g. START_REVERSE_TLS, START_REVERSE_SSH, etc) 4. The NMS immediately starts the client-side of the protocol, the device immediately starts the server-side of the protocol 5. We ensure all protocols have a "connection" layer. SSH already has one defined (rfc4254) that allows the NMS to start any subsystem it wants. For instance, instead of starting the "netconf" subsystem, the NMS could just as easily start an "snmp" or any other subsystem. 6. Thus, only one port would ever be needed regardless the number of TCP-based transports or transport-tunneled protocols. Discussing putting the SSH connection protocol on top of TLS with the Joe Saloway, co-chair of the TLS WG, he said: 1) the idea has come up in the past, 2) no has has done it yet because they always fall back to using a port, and 3) if they were doing TLS from scratch, they would do it this way. OK, so that's that idea, the primary issues are: - do we have enough of a driver to make it happen? - to define a connection protocol on top of TLS? (mostly just repurposing rfc4254) - the NMS may be running more than one application and hence need more than call-home port. This seems like a corner-case and solvable by the NMS by using explicitly assigned ports (so let's not worry about it) What do you think? PS: I also think using ports is OK, but I wanted to throw out this option before we get any further... Thanks, Kent From j.schoenwaelder@jacobs-university.de Tue Nov 19 14:33:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDBD1AE065 for ; Tue, 19 Nov 2013 14:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EchdNLYx1Pk for ; Tue, 19 Nov 2013 14:33:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 333961AE163 for ; Tue, 19 Nov 2013 14:33:23 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4DFA2006D; Tue, 19 Nov 2013 23:33:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fsxErTNkHQB9; Tue, 19 Nov 2013 23:33:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B66B20070; Tue, 19 Nov 2013 23:33:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 135F229788CB; Tue, 19 Nov 2013 23:33:10 +0100 (CET) Date: Tue, 19 Nov 2013 23:33:10 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20131119223309.GA43421@elstar.local> Mail-Followup-To: Kent Watsen , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 22:33:27 -0000 On Tue, Nov 19, 2013 at 08:00:36PM +0000, Kent Watsen wrote: > > There was consensus in the Vancouver meeting to combine the YANG modules > for reverse-ssh and reverse-tls. I want to suggest a few options. > > Current Status: > > RFC5539bis RFC6242 > (call-home + YANG module) ^ > | > | > Draft reverse-ssh > (call-home + YANG module) > > > > Option #1: > > RFC5539bis RFC6242 > (call-home) ^ > ^ | > \ | > \ draft-reverse-ssh > \ (call-home) > > > \ ^ > \ / > \ / > \ / > draft-call-home-config > (just YANG module) > > > > Option #2: > > RFC5539bis RFC6242bis > (call-home) (call-home text added) > ^ ^ > \ / > \ / > \ / > \ / > draft-call-home-config > (just YANG module) > > > > > > Option #3: > > RFC5539bis RFC6242 > (call-home text removed) (no call-home) > ^ ^ > \ / > \ / > \ / > \ / > draft-netconf-call-home > (call-home + YANG module) > > > > > Thoughts: > - Both #2 or #3 achieve symmetry (symmetry good, yes?) > - Only #3 provides a complete-solution, defining both > protocol and config, for both SSH & TLS. > - Thinking about possible further transports, any option seems > OK, assuming config will always need to be revisioned... > The config in RFC5539bis is more than just call home hence the options all seem somewhat problematic. For me, the easiest and most sensible to do is to do RFC5539bis including the call home mechanism and separately the call home mechanism for SSH (this might later be merged into RFC6242bis but I do not think it is necessary to revise RFC6242 just because of this). In addition to this, we should create a NETCONF configuration module: RFC5539bis (NC over TLS and NC over TLS call home) RFCXXXX (NC over SSH call home) RFCYYYY (NC configuration data model) This slightly expands the scope of the YANG module but also puts all NC configuration parameters into a simple single YANG module (not everybody liked the submodule setup currently in the RFC5539bis draft). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Nov 19 15:05:06 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DC11AE185 for ; Tue, 19 Nov 2013 15:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjnLKFF44EzM for ; Tue, 19 Nov 2013 15:05:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 844F31AE17C for ; Tue, 19 Nov 2013 15:05:02 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3255D2005B; Wed, 20 Nov 2013 00:04:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mPVMXaU_T5El; Wed, 20 Nov 2013 00:04:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACB862009F; Wed, 20 Nov 2013 00:04:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E42882978C97; Wed, 20 Nov 2013 00:04:50 +0100 (CET) Date: Wed, 20 Nov 2013 00:04:50 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20131119230450.GD43421@elstar.local> Mail-Followup-To: Kent Watsen , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] regarding reducing number of future call-home ports X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:05:06 -0000 On Tue, Nov 19, 2013 at 08:52:58PM +0000, Kent Watsen wrote: > > Discussing putting the SSH connection protocol on top of TLS with the Joe > Saloway, co-chair of the TLS WG, he said: 1) the idea has come up in the > past, 2) no has has done it yet because they always fall back to using a > port, and 3) if they were doing TLS from scratch, they would do it this > way. > > OK, so that's that idea, the primary issues are: > > - do we have enough of a driver to make it happen? - to define > a connection protocol on top of TLS? (mostly just repurposing > rfc4254) > > - the NMS may be running more than one application and hence > need more than call-home port. This seems like a corner-case > and solvable by the NMS by using explicitly assigned ports > (so let's not worry about it) If you want to redo TLS, you likely have to do it in the TLS working group. My understanding is that NETCONF is _using_ TLS and SSH and not supposed to change or reinvent these security protocols. At some point in time, you will need to clarify what 'application' means. The RFCs I think only know NETCONF clients and servers. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Nov 20 04:58:38 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D841ADE86 for ; Wed, 20 Nov 2013 04:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2hpgzn7dQQY for ; Wed, 20 Nov 2013 04:58:37 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 27EA01ADE85 for ; Wed, 20 Nov 2013 04:58:37 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E968D12004E3; Wed, 20 Nov 2013 13:58:29 +0100 (CET) Date: Wed, 20 Nov 2013 13:58:29 +0100 (CET) Message-Id: <20131120.135829.310742572729539689.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20131119223309.GA43421@elstar.local> References: <20131119223309.GA43421@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:58:38 -0000 Juergen Schoenwaelder wrote: > On Tue, Nov 19, 2013 at 08:00:36PM +0000, Kent Watsen wrote: > > > > There was consensus in the Vancouver meeting to combine the YANG modules > > for reverse-ssh and reverse-tls. I want to suggest a few options. > > > > Current Status: > > > > RFC5539bis RFC6242 > > (call-home + YANG module) ^ > > | > > | > > Draft reverse-ssh > > (call-home + YANG module) > > > > > > > > Option #1: > > > > RFC5539bis RFC6242 > > (call-home) ^ > > ^ | > > \ | > > \ draft-reverse-ssh > > \ (call-home) > > > > > > \ ^ > > \ / > > \ / > > \ / > > draft-call-home-config > > (just YANG module) > > > > > > > > Option #2: > > > > RFC5539bis RFC6242bis > > (call-home) (call-home text added) > > ^ ^ > > \ / > > \ / > > \ / > > \ / > > draft-call-home-config > > (just YANG module) > > > > > > > > > > > > Option #3: > > > > RFC5539bis RFC6242 > > (call-home text removed) (no call-home) > > ^ ^ > > \ / > > \ / > > \ / > > \ / > > draft-netconf-call-home > > (call-home + YANG module) > > > > > > > > > > Thoughts: > > - Both #2 or #3 achieve symmetry (symmetry good, yes?) > > - Only #3 provides a complete-solution, defining both > > protocol and config, for both SSH & TLS. > > - Thinking about possible further transports, any option seems > > OK, assuming config will always need to be revisioned... > > > > The config in RFC5539bis is more than just call home hence the options > all seem somewhat problematic. For me, the easiest and most sensible > to do is to do RFC5539bis including the call home mechanism and > separately the call home mechanism for SSH (this might later be merged > into RFC6242bis but I do not think it is necessary to revise RFC6242 > just because of this). In addition to this, we should create a NETCONF > configuration module: > > RFC5539bis (NC over TLS and NC over TLS call home) > RFCXXXX (NC over SSH call home) > RFCYYYY (NC configuration data model) This is essentially my option #2+, but using a separate document for SSH call home. This suggestion is fine with me, although I am not sure why 6242bis would be problematic. /martin From andy@yumaworks.com Wed Nov 20 17:20:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6C21AC43E for ; Wed, 20 Nov 2013 17:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0Sxqu4Vyknx for ; Wed, 20 Nov 2013 17:20:18 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6661A802B for ; Wed, 20 Nov 2013 17:20:18 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id r5so2522963qcx.19 for ; Wed, 20 Nov 2013 17:20:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=z4i0fn1TNgfTqJ/Ft/LZijviuUzf2yRIMat/FBxOOXI=; b=bEjqThmWnKvd0GiLLoMIamiv7Tv8YQLgyhIKZsXkDKErfGynKoSxU3aDW7ZITkUxxT elve3ixJ9pIWGgwDw9pucnlLgZ5RZ8hGPS8wMe4j/6WI1eFoVat8q35xF+LewotxTRcx J/XdfE8CA5sZZbYeukcKnJj63MiINF4EGSqI9Jq+h3pPvHu9dC6UhJeQGSrE7WRQCljk WStyE38HW/+XnyVMCehF3miUKeDILle89BjeCMjLNJ/zlVvyGmoXiuPyX9VewrI+STsd GyctpRm+bmiA7LSX+SAAib10OPnDUoLavP6ypnfPRFINM78IRnjle89UTHHuFpqSf0vN ZaTQ== X-Gm-Message-State: ALoCoQlMs2zteniW3vaP+7hlZkEjbBCJHMmwEM+QsWopVxceNv9s4swC4g26hrQ6c63Kfxo5gMBw MIME-Version: 1.0 X-Received: by 10.224.60.193 with SMTP id q1mr6536306qah.99.1384996811101; Wed, 20 Nov 2013 17:20:11 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 20 Nov 2013 17:20:11 -0800 (PST) In-Reply-To: <20131119223309.GA43421@elstar.local> References: <20131119223309.GA43421@elstar.local> Date: Wed, 20 Nov 2013 17:20:11 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary=001a1133dee6f1f8f204eba5b267 Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:20:19 -0000 --001a1133dee6f1f8f204eba5b267 Content-Type: text/plain; charset=ISO-8859-1 Hi, > ... > The config in RFC5539bis is more than just call home hence the options > all seem somewhat problematic. For me, the easiest and most sensible > to do is to do RFC5539bis including the call home mechanism and > separately the call home mechanism for SSH (this might later be merged > into RFC6242bis but I do not think it is necessary to revise RFC6242 > just because of this). In addition to this, we should create a NETCONF > configuration module: > > RFC5539bis (NC over TLS and NC over TLS call home) > RFCXXXX (NC over SSH call home) > RFCYYYY (NC configuration data model) > > This slightly expands the scope of the YANG module but also puts all > NC configuration parameters into a simple single YANG module (not > everybody liked the submodule setup currently in the RFC5539bis > draft). > > I do not have strong preferences for 1 option over another but I strongly support RFCYYYY. I don't like submodules but I like the idea of organizing all the NETCONF configuration under the /netconf container. If all the YANG is in 1 RFC, even better. It is all in 1 namespace and it is clear to everyone where to find the NETCONF protocol configuration YANG module. /js > Andy --001a1133dee6f1f8f204eba5b267 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

=A0
... The config in RFC5539bis is more than just call home hence the options
all seem somewhat problematic. For me, the easiest and most sensible
to do is to do RFC5539bis including the call home mechanism and
separately the call home mechanism for SSH (this might later be merged
into RFC6242bis but I do not think it is necessary to revise RFC6242
just because of this). In addition to this, we should create a NETCONF
configuration module:

RFC5539bis (NC over TLS and NC over TLS call home)
RFCXXXX =A0 =A0(NC over SSH call home)
RFCYYYY =A0 =A0(NC configuration data model)

This slightly expands the scope of the YANG module but also puts all
NC configuration parameters into a simple single YANG module (not
everybody liked the submodule setup currently in the RFC5539bis
draft).


I do not have strong preferences for 1 option over a= nother but
I strongly support RFCYYYY. =A0I don't like submod= ules but I like
the idea of organizing all the NETCONF configuration under the
/netconf container. =A0If all the YANG is in 1 RFC, even better.
It is all in 1 namespace and it is clear to everyone where to
find the NETCONF protocol configuration YANG module.=A0


/js

=A0
Andy

--001a1133dee6f1f8f204eba5b267-- From lhotka@nic.cz Thu Nov 21 00:04:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DDC1AE08B for ; Thu, 21 Nov 2013 00:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KZLke51llgC for ; Thu, 21 Nov 2013 00:04:33 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6351AE07C for ; Thu, 21 Nov 2013 00:04:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A4D8754039F; Thu, 21 Nov 2013 09:04:24 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6spwnlz7Yde; Thu, 21 Nov 2013 09:04:21 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 777A95401C2; Thu, 21 Nov 2013 09:04:17 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20131120.135829.310742572729539689.mbj@tail-f.com> References: <20131119223309.GA43421@elstar.local> <20131120.135829.310742572729539689.mbj@tail-f.com> User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Thu, 21 Nov 2013 09:04:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 08:04:35 -0000 Martin Bjorklund writes: >> >> RFC5539bis (NC over TLS and NC over TLS call home) >> RFCXXXX (NC over SSH call home) >> RFCYYYY (NC configuration data model) > > This is essentially my option #2+, but using a separate document for > SSH call home. This suggestion is fine with me, although I am not > sure why 6242bis would be problematic. +1 I'd also support 5539bis, 6242bis and YYYY. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Nov 21 00:16:08 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96B31AC499 for ; Thu, 21 Nov 2013 00:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cduZ9W2YVptx for ; Thu, 21 Nov 2013 00:16:07 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 81F541AC448 for ; Thu, 21 Nov 2013 00:16:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6166554039F; Thu, 21 Nov 2013 09:16:00 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzfOMeRiyOqV; Thu, 21 Nov 2013 09:15:56 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 83CC25401C2; Thu, 21 Nov 2013 09:15:52 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Netconf In-Reply-To: References: User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Thu, 21 Nov 2013 09:15:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Netconf] regarding reducing number of future call-home ports X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 08:16:09 -0000 Hi Kent, this might open another can of worms. I'd suggest to go forward without registering a well-known port. After all, a port number is just one extra item in the device's initial configuration. Lada Kent Watsen writes: > Here's an idea addressing Joe Touch's concern for port-proliferation: > > > 1. Assume there is a defined TCP-port called the "call-home" port > > 2. The NMS accepts TCP connections from devices on this port > > 3. As soon as a TCP connection is established, the device sends a > cleartext message indicated which protocol it wants to run in reverse > (e.g. START_REVERSE_TLS, START_REVERSE_SSH, etc) > > 4. The NMS immediately starts the client-side of the protocol, the device > immediately starts the server-side of the protocol > > 5. We ensure all protocols have a "connection" layer. SSH already has one > defined (rfc4254) that allows the NMS to start any subsystem it wants. > For instance, instead of starting the "netconf" subsystem, the NMS could > just as easily start an "snmp" or any other subsystem. > > 6. Thus, only one port would ever be needed regardless the number of > TCP-based transports or transport-tunneled protocols. > > > > Discussing putting the SSH connection protocol on top of TLS with the Joe > Saloway, co-chair of the TLS WG, he said: 1) the idea has come up in the > past, 2) no has has done it yet because they always fall back to using a > port, and 3) if they were doing TLS from scratch, they would do it this > way. > > OK, so that's that idea, the primary issues are: > > - do we have enough of a driver to make it happen? - to define > > a connection protocol on top of TLS? (mostly just repurposing > rfc4254) > > - the NMS may be running more than one application and hence > need more than call-home port. This seems like a corner-case > and solvable by the NMS by using explicitly assigned ports > (so let's not worry about it) > > > > What do you think? > > > PS: I also think using ports is OK, but I wanted to throw out this option > before we get any further... > > Thanks, > Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jclarke@cisco.com Thu Nov 21 08:14:53 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1B81AE00F for ; Thu, 21 Nov 2013 08:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ32IEqjRwGH for ; Thu, 21 Nov 2013 08:14:51 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 908B31ADFF6 for ; Thu, 21 Nov 2013 08:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2860; q=dns/txt; s=iport; t=1385050485; x=1386260085; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=XaahNsYGLKS+KDNEywT78cdDv8qXgQkKw6q86HOzRQQ=; b=YegH+VJOpRSfsprFiRHbhaUMpMGAunPZ1vo2XH1WAzvv7+emwcZ/EHZO CYl0xbhYzDs2C2nuUERd34eA9Dzm1z5Swrp3pHCqZEcXlHouPlq+JDZnW SBpnZOo5yeUMxsQWmCkVGHNflc/bV9RIHrKJ+mO798bUNq4NwwAjTEHWl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAAkxjlKtJV2Y/2dsb2JhbABWA4MHOLxbToEkFnSCJQEBAQMBAQEBNTYZAgsOCgklDwIKDBYaBgEMBgIBAReHYAYNwQ8TBASOGxEBgSoXEYQhA4lCjlCSEINGHoE1 X-IronPort-AV: E=Sophos;i="4.93,745,1378857600"; d="scan'208";a="1240315" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 21 Nov 2013 16:14:44 +0000 Received: from prosciutto.local ([10.154.200.57]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rALGEix8019569; Thu, 21 Nov 2013 16:14:44 GMT Message-ID: <528E3174.60401@cisco.com> Date: Thu, 21 Nov 2013 11:14:44 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kent Watsen , Netconf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:14:53 -0000 On 11/19/13, 3:00 PM, Kent Watsen wrote: > > There was consensus in the Vancouver meeting to combine the YANG modules > for reverse-ssh and reverse-tls. I want to suggest a few options. I like Option #2. I think it presents a decent evolution of what is there today. Joe > > Current Status: > > RFC5539bis RFC6242 > (call-home + YANG module) ^ > | > | > Draft reverse-ssh > (call-home + YANG module) > > > > Option #1: > > RFC5539bis RFC6242 > (call-home) ^ > ^ | > \ | > \ draft-reverse-ssh > \ (call-home) > > > \ ^ > \ / > \ / > \ / > draft-call-home-config > (just YANG module) > > > > Option #2: > > RFC5539bis RFC6242bis > (call-home) (call-home text added) > ^ ^ > \ / > \ / > \ / > \ / > draft-call-home-config > (just YANG module) > > > > > > Option #3: > > RFC5539bis RFC6242 > (call-home text removed) (no call-home) > ^ ^ > \ / > \ / > \ / > \ / > draft-netconf-call-home > (call-home + YANG module) > > > > > Thoughts: > - Both #2 or #3 achieve symmetry (symmetry good, yes?) > - Only #3 provides a complete-solution, defining both > protocol and config, for both SSH & TLS. > - Thinking about possible further transports, any option seems > OK, assuming config will always need to be revisioned... > > What do you think? > > > Thanks, > Kent > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From skyper@thc.org Thu Nov 21 13:43:13 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1481A1AE32B for ; Thu, 21 Nov 2013 13:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C18crZ3PqsYQ for ; Thu, 21 Nov 2013 13:43:10 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C99831AE384 for ; Thu, 21 Nov 2013 13:43:10 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so639454ieb.25 for ; Thu, 21 Nov 2013 13:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VRb0iBzJAhTWgvMgiLx6vhXs/I2ZmR1U5httVRMdLLI=; b=GhU22xV3Yqs3sbOqYm7roUOHJtR8ZXtzG+J/x7awt/waRkhEZoKKOaSWG6OZ4uTIkY tNu3gb6VGOFNeO6fKeCQRvNZUkAchk9nJNNp46F4KCI/KpJQsltNpZc9SQLD2R9b7v2g fsAPD/4rno0YH8ZJYEoFai3hvxUxzb6c9dmyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VRb0iBzJAhTWgvMgiLx6vhXs/I2ZmR1U5httVRMdLLI=; b=c/LBiiZaEX6jnqshRGdsO34zdXJbPuB958DbrquKRcvXCNy1gadjJwrVmtfpmiclI4 qybe4obnsxkxxXdiEEdN07PPlkiTGamCWAAhletghAa7k5IcH9T4XWPD6Y3Rm0MmnLgJ Xu5P4pw3PxP5JJwDa+UycVm4yWJWhPuGctt2/ugLDt8R7BwE80MvxLya7/TUM7r8eweY Aop34MS85/8RM87okZwGhEeZNW4pyGF2+seCZY2fWpdlgexvPTiV5CaHrITuWlNqmxFd sd0z9uQ4Z47NM02Od0ilBeslq9+DAkpOTxFkiHfx+q15Qj39pVlDQjrMmakPqdRZebwg KzKw== X-Gm-Message-State: ALoCoQlIrzrxmw/PzZvN4T1GDD1M+eIW66w1AfAoEWQ31eAV1wc6lr81RMKBGwrMwfIpYJnZi0PJ MIME-Version: 1.0 X-Received: by 10.42.82.196 with SMTP id e4mr2300998icl.58.1385070182605; Thu, 21 Nov 2013 13:43:02 -0800 (PST) Received: by 10.64.9.41 with HTTP; Thu, 21 Nov 2013 13:43:02 -0800 (PST) X-Originating-IP: [80.195.189.45] In-Reply-To: <528E3174.60401@cisco.com> References: <528E3174.60401@cisco.com> Date: Thu, 21 Nov 2013 21:43:02 +0000 Message-ID: From: Ralf Skyper Kaiser To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=20cf30363fa139406e04ebb6c875 Cc: Netconf Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 21:43:13 -0000 --20cf30363fa139406e04ebb6c875 Content-Type: text/plain; charset=ISO-8859-1 I prefer to remove ssh and just use TLS. Simplifies everything and voids this discussion. I had the "why do we need ssh and TLS, if we can remove complexity and increase security by just using TLS" discussion before but beside Kent nobody voiced an opinion. regards, ralf On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke wrote: > On 11/19/13, 3:00 PM, Kent Watsen wrote: > >> >> There was consensus in the Vancouver meeting to combine the YANG modules >> for reverse-ssh and reverse-tls. I want to suggest a few options. >> > > I like Option #2. I think it presents a decent evolution of what is there > today. > > Joe > > > >> Current Status: >> >> RFC5539bis RFC6242 >> (call-home + YANG module) ^ >> | >> | >> Draft reverse-ssh >> (call-home + YANG module) >> >> >> >> Option #1: >> >> RFC5539bis RFC6242 >> (call-home) ^ >> ^ | >> \ | >> \ draft-reverse-ssh >> \ (call-home) >> >> >> \ ^ >> \ / >> \ / >> \ / >> draft-call-home-config >> (just YANG module) >> >> >> >> Option #2: >> >> RFC5539bis RFC6242bis >> (call-home) (call-home text added) >> ^ ^ >> \ / >> \ / >> \ / >> \ / >> draft-call-home-config >> (just YANG module) >> >> >> >> >> >> Option #3: >> >> RFC5539bis RFC6242 >> (call-home text removed) (no call-home) >> ^ ^ >> \ / >> \ / >> \ / >> \ / >> draft-netconf-call-home >> (call-home + YANG module) >> >> >> >> >> Thoughts: >> - Both #2 or #3 achieve symmetry (symmetry good, yes?) >> - Only #3 provides a complete-solution, defining both >> protocol and config, for both SSH & TLS. >> - Thinking about possible further transports, any option seems >> OK, assuming config will always need to be revisioned... >> >> What do you think? >> >> >> Thanks, >> Kent >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > ------------------------------------------------------------ > ---------------- > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --20cf30363fa139406e04ebb6c875 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I prefer to remove ssh and just use TLS. Si= mplifies everything and voids this discussion.

I had the "= ;why do we need ssh and TLS, if we can remove complexity and increase secur= ity by just using TLS" discussion before but beside Kent nobody voiced= an opinion.

regards,

ralf



On Thu, Nov 21, 2013 at 4:14 PM, Joe M= arcus Clarke <jclarke@cisco.com> wrote:
On 11/19/13, 3:00 PM, Kent= Watsen wrote:

There was consensus in the Vancouver meeting to combine the YANG modules for reverse-ssh and reverse-tls. =A0I want to suggest a few options.

I like Option #2. =A0I think it presents a decent evolution of what is ther= e today.

Joe



Current Status:

=A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 =A0 =A0RFC6242
=A0 =A0 (call-home + YANG module) =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Draft revers= e-ssh
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(call-home + YANG mo= dule)



Option #1:

=A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 =A0 =A0RFC6242
=A0 =A0 =A0 =A0 =A0 =A0(call-home) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 draft-reverse-ssh=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 (call-home= )


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-call-home-config
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(just YANG module)



Option #2:

=A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 RFC6242bis
=A0 =A0 =A0 =A0 =A0 =A0(call-home) =A0 =A0(call-home text added)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-call-home-config
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (just YANG module)





Option #3:

=A0 =A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 =A0 RFC6242
=A0 =A0 =A0 (call-home text removed) =A0 (no call-home)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-netconf-call-home
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (call-home + YANG module)




Thoughts:
=A0 =A0- Both #2 or #3 achieve symmetry (symmetry good, yes?)
=A0 =A0- Only #3 provides a complete-solution, defining both
=A0 =A0 =A0protocol and config, for both SSH & TLS.
=A0 =A0- Thinking about possible further transports, any option seems
=A0 =A0 =A0OK, assuming config will always need to be revisioned...

What do you think?


Thanks,
Kent




_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf



--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t= e m s
Email: jclarke@cisco= .com

-------------------------------------------------------------= ---------------

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--20cf30363fa139406e04ebb6c875-- From ietfdbh@comcast.net Thu Nov 21 21:24:21 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A131AE226 for ; Thu, 21 Nov 2013 21:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH3RFpVOIf_B for ; Thu, 21 Nov 2013 21:24:19 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id EA4A61AE010 for ; Thu, 21 Nov 2013 21:24:18 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta06.westchester.pa.mail.comcast.net with comcast id sVQ61m00227AodY56VQBTS; Fri, 22 Nov 2013 05:24:11 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta19.westchester.pa.mail.comcast.net with comcast id sVQB1m0032yZEBF3fVQB9p; Fri, 22 Nov 2013 05:24:11 +0000 From: "ietfdbh" To: "'Ralf Skyper Kaiser'" , "'Joe Marcus Clarke'" References: <528E3174.60401@cisco.com> In-Reply-To: Date: Fri, 22 Nov 2013 00:24:17 -0500 Message-ID: <061c01cee743$17717660$46546320$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_061D_01CEE719.2E9D9140" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHDTcr2VF9aPgfjP2wZ31yDvIklrAB1gvwnAs/MxA2aLb92sA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385097851; bh=3cD3ymNZ8hYgZKxSHvgxSCLvLYhE0I06GTbXOMjuYiM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=gnOw79DRVwPEJbgW/VD1IL2hi1YhJd9Lgg712KiY/iilXmw6x2jutrbleu+g+soXw QWg9cg/BkW1IOcmuc8en/Cru69qqYqH8kFlleZ6WVj8srQUqSKZV1Wre+RBB5ZdTM3 +gF1DkL3FoE3hEw43yjg7j/z1wOoicqJho9H/ir2QCPJFzvXp6n55ljwlFp2sLAEgR /0fl3dPVWr1x6mcG3pOuWZMtkElpyqPqr3C0dLDx4s8Lxfn12OsnqSedZwERgi/wwL uZ1QBI+AnR5b1wRFYzWScJ88A4et8h4IwYdUPM6vhVI/TuBOUh+5MmUn9XK7p1avxs x0W1PE+7ObbTw== Cc: 'Netconf' Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 05:24:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_061D_01CEE719.2E9D9140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SSH was the preferred protocol expressed in a poll of operators (by a wide margin as I recall). I think offering both SSH and TLS addresses the needs of interactive and programmatic approaches well. I support keeping both. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ralf Skyper Kaiser Sent: Thursday, November 21, 2013 4:43 PM To: Joe Marcus Clarke Cc: Netconf Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh I prefer to remove ssh and just use TLS. Simplifies everything and voids this discussion. I had the "why do we need ssh and TLS, if we can remove complexity and increase security by just using TLS" discussion before but beside Kent nobody voiced an opinion. regards, ralf On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke wrote: On 11/19/13, 3:00 PM, Kent Watsen wrote: There was consensus in the Vancouver meeting to combine the YANG modules for reverse-ssh and reverse-tls. I want to suggest a few options. I like Option #2. I think it presents a decent evolution of what is there today. Joe Current Status: RFC5539bis RFC6242 (call-home + YANG module) ^ | | Draft reverse-ssh (call-home + YANG module) Option #1: RFC5539bis RFC6242 (call-home) ^ ^ | \ | \ draft-reverse-ssh \ (call-home) \ ^ \ / \ / \ / draft-call-home-config (just YANG module) Option #2: RFC5539bis RFC6242bis (call-home) (call-home text added) ^ ^ \ / \ / \ / \ / draft-call-home-config (just YANG module) Option #3: RFC5539bis RFC6242 (call-home text removed) (no call-home) ^ ^ \ / \ / \ / \ / draft-netconf-call-home (call-home + YANG module) Thoughts: - Both #2 or #3 achieve symmetry (symmetry good, yes?) - Only #3 provides a complete-solution, defining both protocol and config, for both SSH & TLS. - Thinking about possible further transports, any option seems OK, assuming config will always need to be revisioned... What do you think? Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_061D_01CEE719.2E9D9140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SSH was the preferred protocol expressed in a poll of operators (by a = wide margin as I recall).

I think offering both SSH and TLS addresses the needs of interactive = and programmatic approaches well.

I support keeping both.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ralf = Skyper Kaiser
Sent: Thursday, November 21, 2013 4:43 = PM
To: Joe Marcus Clarke
Cc: = Netconf
Subject: Re: [Netconf] regarding combining reverse-tls = and reverse-ssh

 

I prefer to remove ssh = and just use TLS. Simplifies everything and voids this = discussion.

I had the "why do we need ssh and = TLS, if we can remove complexity and increase security by just using = TLS" discussion before but beside Kent nobody voiced an = opinion.

regards,

ralf

 

On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke = <jclarke@cisco.com> wrote:

On 11/19/13, 3:00 PM, Kent Watsen = wrote:


There was consensus in the = Vancouver meeting to combine the YANG modules
for reverse-ssh and = reverse-tls.  I want to suggest a few options.

 

I like = Option #2.  I think it presents a decent evolution of what is there = today.

Joe

 


Current Status:

    =        RFC5539bis           =    RFC6242
    (call-home + YANG module)   =       ^
            =                     =       |
            =                     =       |
            =                   =  Draft reverse-ssh
            =                (call-home + YANG = module)



Option #1:

        =    RFC5539bis             =  RFC6242
           (call-home) =                ^
  =               ^       =               |
    =              \       =              |
    =               \       =     draft-reverse-ssh
          =          \           =   (call-home)


            =         \             =     ^
              =        \             =   /
                =       \             = /
                  =      \           /
  =                 =  draft-call-home-config
          =            (just YANG = module)



Option #2:

        =    RFC5539bis           = RFC6242bis
           (call-home) =    (call-home text added)
        =         ^             =       ^
            =      \               =   /
                =   \               /
  =                  \   =           /
        =             \         =   /
                = draft-call-home-config
            =       (just YANG module)





Option = #3:

             RFC5539bis =             RFC6242
    =   (call-home text removed)   (no call-home)
    =               ^       =             ^
      =              \       =           /
        =             \         =       /
            =          \           =   /
                =       \           /
  =               =  draft-netconf-call-home
          =       (call-home + YANG = module)




Thoughts:
   - Both #2 or #3 = achieve symmetry (symmetry good, yes?)
   - Only #3 = provides a complete-solution, defining both
    =  protocol and config, for both SSH & TLS.
   - = Thinking about possible further transports, any option seems
  =    OK, assuming config will always need to be = revisioned...

What do you = think?


Thanks,
Kent




____________________= ___________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= /o:p>

 

-- =
Joe = Marcus Clarke, CCIE #5384,         |     =      |
SCJP, SCSA, SCNA, = SCSECA, VCP        |||||     =  |||||
Distinguished Services = Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i = s c o  S y s t e m s
Email: jclarke@cisco.com

----------------------------------------------------------= ------------------


_______________________________________________
= Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= /o:p>

 

------=_NextPart_000_061D_01CEE719.2E9D9140-- From swmike@swm.pp.se Thu Nov 21 23:09:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B911AE01D for ; Thu, 21 Nov 2013 23:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.376 X-Spam-Level: X-Spam-Status: No, score=-4.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTwbIUQBifjS for ; Thu, 21 Nov 2013 23:09:25 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4631ADFDC for ; Thu, 21 Nov 2013 23:09:25 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E2ECC9C; Fri, 22 Nov 2013 08:09:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D14CD9A; Fri, 22 Nov 2013 08:09:16 +0100 (CET) Date: Fri, 22 Nov 2013 08:09:16 +0100 (CET) From: Mikael Abrahamsson To: ietfdbh In-Reply-To: <061c01cee743$17717660$46546320$@comcast.net> Message-ID: References: <528E3174.60401@cisco.com> <061c01cee743$17717660$46546320$@comcast.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'Netconf' Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 07:09:28 -0000 On Fri, 22 Nov 2013, ietfdbh wrote: > SSH was the preferred protocol expressed in a poll of operators (by a wide > margin as I recall). > > I think offering both SSH and TLS addresses the needs of interactive and > programmatic approaches well. > > I support keeping both. I also support keeping both. -- Mikael Abrahamsson email: swmike@swm.pp.se From andy@yumaworks.com Fri Nov 22 08:27:53 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D031AE153 for ; Fri, 22 Nov 2013 08:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZXGrKvMC0GV for ; Fri, 22 Nov 2013 08:27:51 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 02B7E1AE0EA for ; Fri, 22 Nov 2013 08:27:50 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id t7so1104534qeb.34 for ; Fri, 22 Nov 2013 08:27:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HoCOmKGghuGg44adQQMZ7Ohg9MwNi4NUPHO7oL3irPo=; b=jtdkahhZSTUEX4hCxR2WpuqopHQAKielbfL2jj3XvPlwq3IGgFgSmxRQdiiHHJF7hc BDftbzDrxa0Wr2GyEy79ZnORIkGPlWxRgywv1rjRdwbTxUd1Esfj9pzMoF244Wx/J/+X 4eKUUX4C3mE12HXuEdULZvvJkP8xFhYuMxOJXbDY56UbtJF5UpYSrJFldQTFWq4VyClF DJgnb1JGKxJLXQ5vQxUYDCUjDd9gdQ4zCoFZR3oPR0p2bwC7IBhJNvi3QZ9/dRyWre30 FyemqwZ5OHsFeyHBGCX8WFI6kxhUgoBcpxjVcb0YjxG6gtUMeMPqpIrs4SoPOshbUJBv /1xA== X-Gm-Message-State: ALoCoQnRkPfVTIyk5FGXSOhEChTWIyi/HCm7Kyd2m3a5UUvoqolDgylsySg7ToQ7X/DyXXcRDEHT MIME-Version: 1.0 X-Received: by 10.224.43.206 with SMTP id x14mr22848685qae.7.1385137663685; Fri, 22 Nov 2013 08:27:43 -0800 (PST) Received: by 10.140.86.200 with HTTP; Fri, 22 Nov 2013 08:27:43 -0800 (PST) In-Reply-To: References: <528E3174.60401@cisco.com> Date: Fri, 22 Nov 2013 08:27:43 -0800 Message-ID: From: Andy Bierman To: Ralf Skyper Kaiser Content-Type: multipart/alternative; boundary=047d7bdc78a868c7f104ebc67e02 Cc: Netconf Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:27:53 -0000 --047d7bdc78a868c7f104ebc67e02 Content-Type: text/plain; charset=ISO-8859-1 Hi, The WG charter explicitly states the call-home mechanism will be developed for both SSH and TLS. For various reasons, SSH is the mandatory-to-implement transport for NETCONF. Perhaps if we were starting from scratch today, TLS would be the only transport, but we started around 2004, not today. Andy On Thu, Nov 21, 2013 at 1:43 PM, Ralf Skyper Kaiser wrote: > I prefer to remove ssh and just use TLS. Simplifies everything and voids > this discussion. > > I had the "why do we need ssh and TLS, if we can remove complexity and > increase security by just using TLS" discussion before but beside Kent > nobody voiced an opinion. > > regards, > > ralf > > > > On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke wrote: > >> On 11/19/13, 3:00 PM, Kent Watsen wrote: >> >>> >>> There was consensus in the Vancouver meeting to combine the YANG modules >>> for reverse-ssh and reverse-tls. I want to suggest a few options. >>> >> >> I like Option #2. I think it presents a decent evolution of what is >> there today. >> >> Joe >> >> >> >>> Current Status: >>> >>> RFC5539bis RFC6242 >>> (call-home + YANG module) ^ >>> | >>> | >>> Draft reverse-ssh >>> (call-home + YANG module) >>> >>> >>> >>> Option #1: >>> >>> RFC5539bis RFC6242 >>> (call-home) ^ >>> ^ | >>> \ | >>> \ draft-reverse-ssh >>> \ (call-home) >>> >>> >>> \ ^ >>> \ / >>> \ / >>> \ / >>> draft-call-home-config >>> (just YANG module) >>> >>> >>> >>> Option #2: >>> >>> RFC5539bis RFC6242bis >>> (call-home) (call-home text added) >>> ^ ^ >>> \ / >>> \ / >>> \ / >>> \ / >>> draft-call-home-config >>> (just YANG module) >>> >>> >>> >>> >>> >>> Option #3: >>> >>> RFC5539bis RFC6242 >>> (call-home text removed) (no call-home) >>> ^ ^ >>> \ / >>> \ / >>> \ / >>> \ / >>> draft-netconf-call-home >>> (call-home + YANG module) >>> >>> >>> >>> >>> Thoughts: >>> - Both #2 or #3 achieve symmetry (symmetry good, yes?) >>> - Only #3 provides a complete-solution, defining both >>> protocol and config, for both SSH & TLS. >>> - Thinking about possible further transports, any option seems >>> OK, assuming config will always need to be revisioned... >>> >>> What do you think? >>> >>> >>> Thanks, >>> Kent >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ------------------------------------------------------------ >> ---------------- >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --047d7bdc78a868c7f104ebc67e02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The WG charter explicitly states th= e call-home mechanism will
be developed for both SSH and TLS. For= various reasons, SSH is
the mandatory-to-implement transport for= NETCONF. Perhaps if we
were starting from scratch today, TLS would be the only transport,
but we started around 2004, not today.


=
Andy



On Thu, Nov 21, 2013 at 1:43 PM, Ralf Skyper Kaiser <<= a href=3D"mailto:skyper@thc.org" target=3D"_blank">skyper@thc.org> wrote:
I prefer to remove ssh and just use TLS. Si= mplifies everything and voids this discussion.

I had the "= ;why do we need ssh and TLS, if we can remove complexity and increase secur= ity by just using TLS" discussion before but beside Kent nobody voiced= an opinion.

regards,

ralf



On Thu, Nov 21, 2013 at 4:14 PM, Joe M= arcus Clarke <jclarke@cisco.com> wrote:
On 11/19/13, 3:00 PM, Kent Watsen wrote= :

There was consensus in the Vancouver meeting to combine the YANG modules for reverse-ssh and reverse-tls. =A0I want to suggest a few options.

I like Option #2. =A0I think it presents a decent evolution of what is ther= e today.

Joe



Current Status:

=A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 =A0 =A0RFC6242
=A0 =A0 (call-home + YANG module) =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Draft revers= e-ssh
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(call-home + YANG mo= dule)



Option #1:

=A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 =A0 =A0RFC6242
=A0 =A0 =A0 =A0 =A0 =A0(call-home) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 draft-reverse-ssh=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 (call-home= )


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-call-home-config
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(just YANG module)



Option #2:

=A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 RFC6242bis
=A0 =A0 =A0 =A0 =A0 =A0(call-home) =A0 =A0(call-home text added)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-call-home-config
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (just YANG module)





Option #3:

=A0 =A0 =A0 =A0 =A0 =A0 =A0RFC5539bis =A0 =A0 =A0 =A0 =A0 =A0 RFC6242
=A0 =A0 =A0 (call-home text removed) =A0 (no call-home)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-netconf-call-home
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (call-home + YANG module)




Thoughts:
=A0 =A0- Both #2 or #3 achieve symmetry (symmetry good, yes?)
=A0 =A0- Only #3 provides a complete-solution, defining both
=A0 =A0 =A0protocol and config, for both SSH & TLS.
=A0 =A0- Thinking about possible further transports, any option seems
=A0 =A0 =A0OK, assuming config will always need to be revisioned...

What do you think?


Thanks,
Kent




_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf



--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t= e m s
Email: jclarke@cisco= .com

-------------------------------------------------------------= ---------------

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--047d7bdc78a868c7f104ebc67e02-- From calle@tail-f.com Fri Nov 22 08:47:01 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0EC1AE39A for ; Fri, 22 Nov 2013 08:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sIMu7B8n4DP for ; Fri, 22 Nov 2013 08:46:59 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 32BEF1AE3E1 for ; Fri, 22 Nov 2013 08:46:50 -0800 (PST) Received: from [192.168.1.3] (c-67-164-14-13.hsd1.ca.comcast.net [67.164.14.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EAC712002C7; Fri, 22 Nov 2013 17:46:40 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Carl Moberg In-Reply-To: Date: Fri, 22 Nov 2013 08:46:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5AE6D25B-AA9C-4727-8194-7CE257D5258F@tail-f.com> References: <528E3174.60401@cisco.com> To: Ralf Skyper Kaiser X-Mailer: Apple Mail (2.1822) Cc: Netconf Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:47:01 -0000 NETCONF over SSH is in very wide commercial deployment and is in at = least 20+ implementations of networking equipment.=20 I don=92t know of a single NETCONF over TLS implementation that is in = use. My opinion is that SSH is required and TLS would be a great addition. On 21 Nov 2013, at 13:43 pm, Ralf Skyper Kaiser wrote: > I prefer to remove ssh and just use TLS. Simplifies everything and = voids this discussion. >=20 > I had the "why do we need ssh and TLS, if we can remove complexity and = increase security by just using TLS" discussion before but beside Kent = nobody voiced an opinion. >=20 > regards, >=20 > ralf >=20 >=20 >=20 > On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke = wrote: > On 11/19/13, 3:00 PM, Kent Watsen wrote: >=20 > There was consensus in the Vancouver meeting to combine the YANG = modules > for reverse-ssh and reverse-tls. I want to suggest a few options. >=20 > I like Option #2. I think it presents a decent evolution of what is = there today. >=20 > Joe >=20 >=20 >=20 > Current Status: >=20 > RFC5539bis RFC6242 > (call-home + YANG module) ^ > | > | > Draft reverse-ssh > (call-home + YANG module) >=20 >=20 >=20 > Option #1: >=20 > RFC5539bis RFC6242 > (call-home) ^ > ^ | > \ | > \ draft-reverse-ssh > \ (call-home) >=20 >=20 > \ ^ > \ / > \ / > \ / > draft-call-home-config > (just YANG module) >=20 >=20 >=20 > Option #2: >=20 > RFC5539bis RFC6242bis > (call-home) (call-home text added) > ^ ^ > \ / > \ / > \ / > \ / > draft-call-home-config > (just YANG module) >=20 >=20 >=20 >=20 >=20 > Option #3: >=20 > RFC5539bis RFC6242 > (call-home text removed) (no call-home) > ^ ^ > \ / > \ / > \ / > \ / > draft-netconf-call-home > (call-home + YANG module) >=20 >=20 >=20 >=20 > Thoughts: > - Both #2 or #3 achieve symmetry (symmetry good, yes?) > - Only #3 provides a complete-solution, defining both > protocol and config, for both SSH & TLS. > - Thinking about possible further transports, any option seems > OK, assuming config will always need to be revisioned... >=20 > What do you think? >=20 >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Carl Moberg VP Technology twitter: @cmoberg http://www.tail-f.com/ From kwatsen@juniper.net Fri Nov 22 11:42:52 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A581AE277 for ; Fri, 22 Nov 2013 11:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1-QAK_VuxFy for ; Fri, 22 Nov 2013 11:42:50 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9576E1AE26C for ; Fri, 22 Nov 2013 11:42:50 -0800 (PST) Received: from mail103-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Fri, 22 Nov 2013 19:42:42 +0000 Received: from mail103-ch1 (localhost [127.0.0.1]) by mail103-ch1-R.bigfish.com (Postfix) with ESMTP id E7F391E08C0; Fri, 22 Nov 2013 19:42:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bhz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h1155h) Received-SPF: pass (mail103-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(377454003)(479174003)(189002)(199002)(74502001)(65816001)(74662001)(66066001)(79102001)(81542001)(54316002)(87266001)(54356001)(49866001)(4396001)(80022001)(31966008)(46102001)(81342001)(51856001)(87936001)(63696002)(83506001)(56776001)(74366001)(76482001)(53806001)(2656002)(77982001)(59766001)(81686001)(74706001)(47976001)(76796001)(80976001)(76786001)(50986001)(77096001)(56816003)(74876001)(76176001)(47736001)(83322001)(36756003)(47446002)(19580405001)(69226001)(85306002)(81816001)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail103-ch1 (localhost.localdomain [127.0.0.1]) by mail103-ch1 (MessageSwitch) id 1385149361541703_29542; Fri, 22 Nov 2013 19:42:41 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail103-ch1.bigfish.com (Postfix) with ESMTP id 7F9BB400031; Fri, 22 Nov 2013 19:42:41 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 22 Nov 2013 19:42:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Fri, 22 Nov 2013 19:42:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 22 Nov 2013 19:42:35 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.22]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.110]) with mapi id 15.00.0810.005; Fri, 22 Nov 2013 19:42:35 +0000 From: Kent Watsen To: Carl Moberg , Ralf Skyper Kaiser Thread-Topic: [Netconf] regarding combining reverse-tls and reverse-ssh Thread-Index: AQHO5WIDegXxIGAwEEiJ+TMD1y2hkpov3tAAgABbugCAAT+DgP//3VcA Date: Fri, 22 Nov 2013 19:42:34 +0000 Message-ID: In-Reply-To: <5AE6D25B-AA9C-4727-8194-7CE257D5258F@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.15] x-forefront-prvs: 0038DE95A2 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0099D52557B9F048BB72F58CE1C347EB@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:42:52 -0000 I also don't know of any NC over TLS deployments. Juniper doesn't even support it. =20 The SSH transport is very intuitive with regards to mapping the user. The TLS transport requires special configuration to map the client cert, which relegates it to special use-cases (e.g. constrained devices) K. On 11/22/13 11:46 AM, "Carl Moberg" wrote: > > NETCONF over SSH is in very wide commercial deployment and is in at >least 20+ implementations of networking equipment. > > I don=B9t know of a single NETCONF over TLS implementation that is in use= . > > My opinion is that SSH is required and TLS would be a great addition. From kwatsen@juniper.net Fri Nov 22 14:09:29 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6161AE15B for ; Fri, 22 Nov 2013 14:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVgP4-WGrrtH for ; Fri, 22 Nov 2013 14:09:27 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 81EB31AE34D for ; Fri, 22 Nov 2013 14:09:23 -0800 (PST) Received: from mail33-db9-R.bigfish.com (10.174.16.253) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Fri, 22 Nov 2013 22:09:15 +0000 Received: from mail33-db9 (localhost [127.0.0.1]) by mail33-db9-R.bigfish.com (Postfix) with ESMTP id 8F7CF60AF8; Fri, 22 Nov 2013 22:09:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzdb82h4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h1155h) Received-SPF: pass (mail33-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(189002)(199002)(74502001)(65816001)(66066001)(79102001)(561944002)(81542001)(54316002)(54356001)(87266001)(49866001)(4396001)(74662001)(80022001)(31966008)(46102001)(81342001)(51856001)(63696002)(87936001)(83506001)(56776001)(74366001)(76482001)(53806001)(2656002)(77982001)(59766001)(81686001)(74706001)(47976001)(76796001)(80976001)(76786001)(50986001)(77096001)(56816003)(74876001)(76176001)(47736001)(83322001)(36756003)(47446002)(69226001)(85306002)(81816001)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail33-db9 (localhost.localdomain [127.0.0.1]) by mail33-db9 (MessageSwitch) id 1385158154236527_13407; Fri, 22 Nov 2013 22:09:14 +0000 (UTC) Received: from DB9EHSMHS031.bigfish.com (unknown [10.174.16.232]) by mail33-db9.bigfish.com (Postfix) with ESMTP id 34D553E004C; Fri, 22 Nov 2013 22:09:14 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS031.bigfish.com (10.174.14.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 22 Nov 2013 22:09:14 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.383.1; Fri, 22 Nov 2013 22:09:04 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 22 Nov 2013 22:09:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.22]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.162]) with mapi id 15.00.0810.005; Fri, 22 Nov 2013 22:09:01 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] regarding reducing number of future call-home ports Thread-Index: AQHO5WlUFaABO7w2xkSckRd3uotuh5otLKwAgARTjwA= Date: Fri, 22 Nov 2013 22:09:00 +0000 Message-ID: In-Reply-To: <20131119230450.GD43421@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.15] x-forefront-prvs: 0038DE95A2 Content-Type: text/plain; charset="us-ascii" Content-ID: <59E37B22A087F3498889F143FE03C72E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] regarding reducing number of future call-home ports X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 22:09:29 -0000 >If you want to redo TLS, you likely have to do it in the TLS working >group. My understanding is that NETCONF is _using_ TLS and SSH and not >supposed to change or reinvent these security protocols. I'm unclear if it would be a built into TLS or a layer on top of it. Either way, I agree that it wouldn't be for this WG to do. Overall, there doesn't seem to be much interest in this proposal, so I guess that we'll proceed without it - requesting 2 ports, one each for TLS and SSH Thanks, Kent From mehmet.ersue@nsn.com Sun Nov 24 06:16:51 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA091AE2A2 for ; Sun, 24 Nov 2013 06:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI69nsTCgPWQ for ; Sun, 24 Nov 2013 06:16:48 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 990691AE29A for ; Sun, 24 Nov 2013 06:16:47 -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 rAOEGcX4008918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 24 Nov 2013 15:16:38 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAOEGbJq005013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 24 Nov 2013 15:16:38 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 24 Nov 2013 15:16:37 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Sun, 24 Nov 2013 15:16:36 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Verifing session consensus on RESTCONF as WG item with the maillist Thread-Index: Ac7ocFsZdTW+Dcs3QRWqtmjne84RSwAr1t1A Date: Sun, 24 Nov 2013 14:16:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2BADEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4800 X-purgate-ID: 151667::1385302598-000022AE-D44230F8/0-0/0-0 Subject: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 14:16:51 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2BADEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Netconf WG, in the Netconf session during IETF #88 we discussed the RESTCONF protocol a= nd whether it should be developed in the Netconf WG. There were around 60 p= articipants in the room. The authors of the RESTCONF draft do not want to create a protocol which co= mpetes with NETCONF and it is seen as beneficial if NETCONF and RESTCONF ar= e developed in parallel and aligned with each other. There are obviously di= fferent projects outside of IETF (e.g. OpenDaylight and other MANET oriente= d projects) which use RESTCONF. The opinion poll showed that there is a hug= e support of the people in the room (and nobody against) to develop the RES= TCONF protocol in the Netconf WG. As a result of the discussion with the AD= , the WG chairs got the action to prepare a charter update and adopt RESTCO= NF as the new WG item. Though before we do this, the chairs need to verify the consensus in the se= ssion with the maillist. Following text is proposed to use for the charter update: " 3. Develop a RESTful protocol (RESTCONF) that provides a programmatic in= terface for accessing data defined in YANG, using the datastores defined in= NETCONF. The three parts concerning RESTCONF protocol, the transport bindi= ng over HTTP and the YANG patch operation will be prepared modular and in s= eparate drafts. This enables to add a new transport binding at a later stag= e." Please state your opinion on this step forward. If you have strong objections against please state your substantial and con= vincing arguments. This consensus call will close on December 4, 2013 EOB PT. Mehmet & Bert --_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2BADEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Netconf WG,
 
in the Netconf session during IETF #88 we discussed the RESTCONF proto= col and whether it should be developed in the Netconf WG. There were around= 60 participants in the room.
The authors of the RESTCONF draft do not want to create a protocol whi= ch competes with NETCONF and it is seen as beneficial if NETCONF and RESTCO= NF are developed in parallel and aligned with each other. There are obvious= ly different projects outside of IETF (e.g. OpenDaylight and other MANET oriented projects) which use RESTCO= NF. The opinion poll showed that there is a huge support of the people in t= he room (and nobody against) to develop the RESTCONF protocol in the Netcon= f WG. As a result of the discussion with the AD, the WG chairs got the action to prepare a charter update and a= dopt RESTCONF as the new WG item.
&nbs= p;
Though before we do this, the chairs need to verify the consensus in t= he session with the maillist.
 
Following text is proposed to use for the charter update:
“  3. Develop a RESTful protocol (RESTCONF) that provides a= programmatic interface for accessing data defined in YANG, using the datas= tores defined in NETCONF. The three parts concerning RESTCONF protocol, the= transport binding over HTTP and the YANG patch operation will be prepared modular and in separate drafts. This enables to = add a new transport binding at a later stage.”
 
Please state your opinion on this step forward.
If you have strong objections against please state your substantial an= d convincing arguments.
 
This consensus call will close on December 4, 2013 EOB PT.
&nbs= p;
Mehmet & Bert
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2BADEMUMBX005nsnintr_-- From mehmet.ersue@nsn.com Sun Nov 24 06:19:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9231AE2A2 for ; Sun, 24 Nov 2013 06:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEsmRNeaNxwO for ; Sun, 24 Nov 2013 06:19:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3F1ADE88 for ; Sun, 24 Nov 2013 06:19:53 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAOEJjSN012779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 24 Nov 2013 15:19:45 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAOEJjjJ007736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 24 Nov 2013 15:19:45 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 24 Nov 2013 15:19:44 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Sun, 24 Nov 2013 15:19:44 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Verifing session consensus with the maillist on RFC5539bis new port and YANG module separation Thread-Index: Ac7oc7r9FFZrYtb/RTGhEIothqUEzgArBJlA Date: Sun, 24 Nov 2013 14:19:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2D2DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4626 X-purgate-ID: 151667::1385302785-00006154-78DA6E72/0-0/0-0 Subject: [Netconf] Verifing session consensus with the maillist on RFC5539bis new port and YANG module separation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 14:19:56 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2D2DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Netconf WG, in the Netconf session during IETF #88 we discussed the draft NETCONF Over = TLS update - RFC5539bis. Opinion poll of the WG concerning the use of a new port showed that many pe= ople were in favor of a new port and nobody against. The WG also decided to separate the YANG module in a new document, align wi= th the module in Reverse SSH draft and use it for both WG items. This mail is a verification of the consensus in the session with the mailli= st. Please state your opinion on the use of a new port as well as separation of= the YANG module in a new document. Please state your substantial and convincing arguments, if you have strong = objections against. In case of the YANG module separation there is the discussion started to se= lect between module organization options in: http://www.ietf.org/mail-archive/web/netconf/current/msg08429.html The assumption in the session was simply aligning the YANG modules from RFC= 5539bis and Reverse SSH, and putting in a new draft. Please state whether you prefer such a simple module separation (i.e. optio= n #1 without any changes to RFC6242) or any other option for the module org= anization in the mail pointed above. This consensus call will close on December 4, 2013 EOB PT. Mehmet & Bert --_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2D2DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Netconf WG,
 
in the Netconf session during IETF #88 we discussed the draft NETCONF = Over TLS update - RFC5539bis.
 
Opinion poll of the WG concerning the use of a new port showed that ma= ny people were in favor of a new port and nobody against.
The WG also decided to separate the YANG module in a new document, ali= gn with the module in Reverse SSH draft and use it for both WG items.
&nbs= p;
This mail is a verification of the consensus in the session with the m= aillist.
&nbs= p;
Please state your opinion on the use of a new port as well as separati= on of the YANG module in a new document.
Please state your substantial and convincing arguments, if you have st= rong objections against.
 
In case of the YANG module separation there is the discussion started = to select between module organization options in:
 
The assumption in the session was simply aligning the YANG modules fro= m RFC5539bis and Reverse SSH, and putting in a new draft.
Please state whether you prefer such a simple module separation (i.e. = option #1 without any changes to RFC6242) or any other option for the modul= e organization in the mail pointed above.
 
This consensus call will close on December 4, 2013 EOB PT.
&nbs= p;
Mehmet & Bert
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81FE2D2DEMUMBX005nsnintr_-- From repenno@cisco.com Sun Nov 24 11:04:31 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE70F1AE0C8 for ; Sun, 24 Nov 2013 11:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7JvAIfagHAR for ; Sun, 24 Nov 2013 11:04:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E95A01AE06F for ; Sun, 24 Nov 2013 11:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6451; q=dns/txt; s=iport; t=1385319862; x=1386529462; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=zx47nJs42k0gHBvKE6W7Anu7D0q69GmOoxpFycEL9ek=; b=Zd3VDQ71ubaOJfY+p1wwX1VevPNsOY8jipx0FjIDaaEcCNKeJVIuISzA Xl3RwB0M1vlTaNxO1Y+a/Hg5azYGzV7aorCtXsE9++wUdsEAjGXYbg6xe l2K2kHjWwSlnmXRfaYE0lQjJh+DxhFzOGCRqqyhha5/ibqU1BxGhWeSNd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADxNklKtJXG8/2dsb2JhbABZgkNEOFO8HIEdFnSCJQECBC1HFwEIEQMBAig5FAkIAgQBEogBvDIXjhtIExiEMwOYFJISgWqBPoFxOQ X-IronPort-AV: E=Sophos;i="4.93,763,1378857600"; d="scan'208,217";a="287199952" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 24 Nov 2013 19:04:21 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAOJ4KQh015403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Nov 2013 19:04:20 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Sun, 24 Nov 2013 13:04:20 -0600 From: "Reinaldo Penno (repenno)" To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf Thread-Topic: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist Thread-Index: AQHO6Uf64yjl83FiwUODLuRQC0w+bw== Date: Sun, 24 Nov 2013 19:04:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.87.85] Content-Type: multipart/alternative; boundary="_000_CEB78C0D69F3repennociscocom_" MIME-Version: 1.0 Subject: Re: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:04:31 -0000 --_000_CEB78C0D69F3repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support RESTCONF as a new deliverable. RESTCONF is an very important par= t of Opendaylight Northbound Interface. From: , "Mehmet (NSN - DE/Munich)" > Date: Sunday, November 24, 2013 at 6:16 AM To: Netconf > Subject: [Netconf] Verifing session consensus on RESTCONF as WG item with t= he maillist Dear Netconf WG, in the Netconf session during IETF #88 we discussed the RESTCONF protocol a= nd whether it should be developed in the Netconf WG. There were around 60 p= articipants in the room. The authors of the RESTCONF draft do not want to create a protocol which co= mpetes with NETCONF and it is seen as beneficial if NETCONF and RESTCONF ar= e developed in parallel and aligned with each other. There are obviously di= fferent projects outside of IETF (e.g. OpenDaylight and other MANET oriente= d projects) which use RESTCONF. The opinion poll showed that there is a hug= e support of the people in the room (and nobody against) to develop the RES= TCONF protocol in the Netconf WG. As a result of the discussion with the AD= , the WG chairs got the action to prepare a charter update and adopt RESTCO= NF as the new WG item. Though before we do this, the chairs need to verify the consensus in the se= ssion with the maillist. Following text is proposed to use for the charter update: =93 3. Develop a RESTful protocol (RESTCONF) that provides a programmatic = interface for accessing data defined in YANG, using the datastores defined = in NETCONF. The three parts concerning RESTCONF protocol, the transport bin= ding over HTTP and the YANG patch operation will be prepared modular and in= separate drafts. This enables to add a new transport binding at a later st= age.=94 Please state your opinion on this step forward. If you have strong objections against please state your substantial and con= vincing arguments. This consensus call will close on December 4, 2013 EOB PT. Mehmet & Bert --_000_CEB78C0D69F3repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I support RESTCONF as a new deliverable.  RESTCONF is an very imp= ortant part of Opendaylight Northbound Interface. 

From: <Ersue>, "Mehmet (= NSN - DE/Munich)" <mehmet.e= rsue@nsn.com>
Date: Sunday, November 24, 2013 at = 6:16 AM
To: Netconf <netconf@ietf.org>
Subject: [Netconf] Verifing session= consensus on RESTCONF as WG item with the maillist

Dear Netconf WG,
 
in the Netconf session during IETF #88 we discussed the RESTCONF proto= col and whether it should be developed in the Netconf WG. There were around= 60 participants in the room.
The authors of the RESTCONF draft do not want to create a protocol whi= ch competes with NETCONF and it is seen as beneficial if NETCONF and RESTCO= NF are developed in parallel and aligned with each other. There are obvious= ly different projects outside of IETF (e.g. OpenDaylight and other MANET oriented projects) which use RESTC= ONF. The opinion poll showed that there is a huge support of the people in = the room (and nobody against) to develop the RESTCONF protocol in the Netco= nf WG. As a result of the discussion with the AD, the WG chairs got the action to prepare a charter update and = adopt RESTCONF as the new WG item.
&nbs= p;
Though before we do this, the chairs need to verify the consensus in t= he session with the maillist.
 
Following text is proposed to use for the charter update:
=93  3. Develop a RESTful protocol (RESTCONF) that provides a pro= grammatic interface for accessing data defined in YANG, using the datastore= s defined in NETCONF. The three parts concerning RESTCONF protocol, the tra= nsport binding over HTTP and the YANG patch operation will be prepared modular and in separate drafts. This enables to= add a new transport binding at a later stage.=94
 
Please state your opinion on this step forward.
If you have strong objections against please state your substantial an= d convincing arguments.
 
This consensus call will close on December 4, 2013 EOB PT.
&nbs= p;
Mehmet & Bert
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_CEB78C0D69F3repennociscocom_-- From jmh@joelhalpern.com Sun Nov 24 11:54:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3499A1AE1B9 for ; Sun, 24 Nov 2013 11:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxOK1k1FvuW5 for ; Sun, 24 Nov 2013 11:54:54 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E2D031ADFF5 for ; Sun, 24 Nov 2013 11:54:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 461BB1D2263; Sun, 24 Nov 2013 11:54:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 3A4C81D20C3; Sun, 24 Nov 2013 11:54:46 -0800 (PST) Message-ID: <52925984.5010407@joelhalpern.com> Date: Sun, 24 Nov 2013 14:54:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:54:56 -0000 Is there somewhere I can read a description of what problems with using NetConf are addressed by using RestConf? It would be helpful to understand the problem beyond "some folks are doing this" before supporting or opposing the work item. Thank you, Joel On 11/24/13 2:04 PM, Reinaldo Penno (repenno) wrote: > I support RESTCONF as a new deliverable. RESTCONF is an very important > part of Opendaylight Northbound Interface. > > From: , "Mehmet (NSN - DE/Munich)" > > Date: Sunday, November 24, 2013 at 6:16 AM > To: Netconf > > Subject: [Netconf] Verifing session consensus on RESTCONF as WG item > with the maillist > > Dear Netconf WG, > in the Netconf session during IETF #88 we discussed the RESTCONF > protocol and whether it should be developed in the Netconf WG. There > were around 60 participants in the room. > The authors of the RESTCONF draft do not want to create a protocol which > competes with NETCONF and it is seen as beneficial if NETCONF and > RESTCONF are developed in parallel and aligned with each other. There > are obviously different projects outside of IETF (e.g. OpenDaylight and > other MANET oriented projects) which use RESTCONF. The opinion poll > showed that there is a huge support of the people in the room (and > nobody against) to develop the RESTCONF protocol in the Netconf WG. As a > result of the discussion with the AD, the WG chairs got the action to > prepare a charter update and adopt RESTCONF as the new WG item. > Though before we do this, the chairs need to verify the consensus in the > session with the maillist. > Following text is proposed to use for the charter update: > “ 3. Develop a RESTful protocol (RESTCONF) that provides a programmatic > interface for accessing data defined in YANG, using the datastores > defined in NETCONF. The three parts concerning RESTCONF protocol, the > transport binding over HTTP and the YANG patch operation will be > prepared modular and in separate drafts. This enables to add a new > transport binding at a later stage.” > Please state your opinion on this step forward. > If you have strong objections against please state your substantial and > convincing arguments. > This consensus call will close on December 4, 2013 EOB PT. > Mehmet & Bert > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Sun Nov 24 12:39:51 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23051AE172 for ; Sun, 24 Nov 2013 12:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEDztb32ilDx for ; Sun, 24 Nov 2013 12:39:49 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id F258F1AE1DB for ; Sun, 24 Nov 2013 12:39:48 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id t7so2961162qeb.6 for ; Sun, 24 Nov 2013 12:39:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AhUoip9knU+gg945TxKmYs3Jd6HSZlvfpyHbwgHpurc=; b=TJsRgiZszoXBF/vomPxK2UlqN42atTGWzgZko7ET0im7HDROOjGc9e6Z/7XAwa8pSv YZuqJy6Bzi5zBGV+U1awzYSo24xGZC8BAv54t6SJM+MAQa8iDjoAGO6zWUUkQznZCQ6s cl+xNwlLGoe0SSJvK5DLMncA267ew5ZV35cga477ietu6KSW3laMEfA37aEM25WGVWt0 7C/0GeMlNnn9qhk/+z8CivcszozaXCRAgX/LcGLr1KzKvcLXl17/DTBPVMBTnuocN4jp 1LG8gs+7wrkobUwQ/80EnReRnGHrSaU+8CDZ1sFFNqKdBwWkkEYDxu07WqTa/1vlBpQY oHng== X-Gm-Message-State: ALoCoQntdEQfoQbZktPtgA0lbzlrPMTNfdYT87JmUMWjWOFVnH/1Vt56JrOANHglIjkLRd2Vilwc MIME-Version: 1.0 X-Received: by 10.49.116.210 with SMTP id jy18mr40732667qeb.65.1385325580829; Sun, 24 Nov 2013 12:39:40 -0800 (PST) Received: by 10.140.86.200 with HTTP; Sun, 24 Nov 2013 12:39:40 -0800 (PST) In-Reply-To: <52925984.5010407@joelhalpern.com> References: <52925984.5010407@joelhalpern.com> Date: Sun, 24 Nov 2013 12:39:40 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b5dbfc824d7c504ebf23fde Cc: Netconf Subject: Re: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 20:39:51 -0000 --047d7b5dbfc824d7c504ebf23fde Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Sec. 1.1 of draft-bierman-netconf-restconf-02.txt has some text. I will start a list to throw darts at: - NETCONF does not have a resource management model - NETCONF is session-based, and even some simple management tasks require several request/response pairs to complete - NETCONF allows a lot of server variance instead of a unified abstractio= n of the local configuration. This complicates management code. - Many more client tools are available for HTTP/REST than NETCONF/SSH - JSON is widely deployed and more efficient than XML Andy On Sun, Nov 24, 2013 at 11:54 AM, Joel M. Halpern wrot= e: > Is there somewhere I can read a description of what problems with using > NetConf are addressed by using RestConf? It would be helpful to understa= nd > the problem beyond "some folks are doing this" before supporting or > opposing the work item. > > Thank you, > Joel > > On 11/24/13 2:04 PM, Reinaldo Penno (repenno) wrote: > >> I support RESTCONF as a new deliverable. RESTCONF is an very important >> part of Opendaylight Northbound Interface. >> >> From: , "Mehmet (NSN - DE/Munich)" > > >> Date: Sunday, November 24, 2013 at 6:16 AM >> To: Netconf > >> Subject: [Netconf] Verifing session consensus on RESTCONF as WG item >> with the maillist >> >> Dear Netconf WG, >> in the Netconf session during IETF #88 we discussed the RESTCONF >> protocol and whether it should be developed in the Netconf WG. There >> were around 60 participants in the room. >> The authors of the RESTCONF draft do not want to create a protocol which >> competes with NETCONF and it is seen as beneficial if NETCONF and >> RESTCONF are developed in parallel and aligned with each other. There >> are obviously different projects outside of IETF (e.g. OpenDaylight and >> other MANET oriented projects) which use RESTCONF. The opinion poll >> showed that there is a huge support of the people in the room (and >> nobody against) to develop the RESTCONF protocol in the Netconf WG. As a >> result of the discussion with the AD, the WG chairs got the action to >> prepare a charter update and adopt RESTCONF as the new WG item. >> Though before we do this, the chairs need to verify the consensus in the >> session with the maillist. >> Following text is proposed to use for the charter update: >> =93 3. Develop a RESTful protocol (RESTCONF) that provides a programmat= ic >> interface for accessing data defined in YANG, using the datastores >> defined in NETCONF. The three parts concerning RESTCONF protocol, the >> transport binding over HTTP and the YANG patch operation will be >> prepared modular and in separate drafts. This enables to add a new >> transport binding at a later stage.=94 >> Please state your opinion on this step forward. >> If you have strong objections against please state your substantial and >> convincing arguments. >> This consensus call will close on December 4, 2013 EOB PT. >> Mehmet & Bert >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --047d7b5dbfc824d7c504ebf23fde Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

Sec. 1.1 of draft-bierman-netconf-r= estconf-02.txt has some text.

I will start a list = to throw darts at:
=A0 - NETCONF does not have a resource managem= ent model
=A0 - NETCONF is session-based, and even some simple management tasks = require
=A0 =A0 several request/response pairs to complete
<= div>=A0 - NETCONF allows a lot of server variance instead of a unified abst= raction
=A0 =A0 of the local configuration. This complicates management code.<= /div>
=A0 - Many more client tools are available for HTTP/REST than NET= CONF/SSH
=A0 - JSON is widely deployed and more efficient than XM= L


Andy

On Sun, Nov 24, 2013= at 11:54 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:=
Is there somewhere I can read a description = of what problems with using NetConf are addressed by using RestConf? =A0It = would be helpful to understand the problem beyond "some folks are doin= g this" before supporting or opposing the work item.

Thank you,
Joel

On 11/24/13 2:04 PM, Reinaldo Penno (repenno) wrote:
I support RESTCONF as a new deliverable. =A0RESTCONF is an very important part of Opendaylight Northbound Interface.

From: <Ersue>, "Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com
<mailto:mehmet= .ersue@nsn.com>>
Date: Sunday, November 24, 2013 at 6:16 AM
To: Netconf <netco= nf@ietf.org <mailto:netconf@ietf.org>>
Subject: [Netconf] Verifing session consensus on RESTCONF as WG item
with the maillist

Dear Netconf WG,
in the Netconf session during IETF #88 we discussed the RESTCONF
protocol and whether it should be developed in the Netconf WG. There
were around 60 participants in the room.
The authors of the RESTCONF draft do not want to create a protocol which competes with NETCONF and it is seen as beneficial if NETCONF and
RESTCONF are developed in parallel and aligned with each other. There
are obviously different projects outside of IETF (e.g. OpenDaylight and
other MANET oriented projects) which use RESTCONF. The opinion poll
showed that there is a huge support of the people in the room (and
nobody against) to develop the RESTCONF protocol in the Netconf WG. As a result of the discussion with the AD, the WG chairs got the action to
prepare a charter update and adopt RESTCONF as the new WG item.
Though before we do this, the chairs need to verify the consensus in the session with the maillist.
Following text is proposed to use for the charter update:
=93 =A03. Develop a RESTful protocol (RESTCONF) that provides a programmati= c
interface for accessing data defined in YANG, using the datastores
defined in NETCONF. The three parts concerning RESTCONF protocol, the
transport binding over HTTP and the YANG patch operation will be
prepared modular and in separate drafts. This enables to add a new
transport binding at a later stage.=94
Please state your opinion on this step forward.
If you have strong objections against please state your substantial and
convincing arguments.
This consensus call will close on December 4, 2013 EOB PT.
Mehmet & Bert


_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--047d7b5dbfc824d7c504ebf23fde-- From j.schoenwaelder@jacobs-university.de Mon Nov 25 01:15:21 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476371ACCDA for ; Mon, 25 Nov 2013 01:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q_IzuEo3BPy for ; Mon, 25 Nov 2013 01:15:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9D1ACCFF for ; Mon, 25 Nov 2013 01:15:16 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4A6820052; Mon, 25 Nov 2013 10:15:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CZrVgOH52KhL; Mon, 25 Nov 2013 10:15:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55F8D20040; Mon, 25 Nov 2013 10:15:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AB2322981DB9; Mon, 25 Nov 2013 10:15:10 +0100 (CET) Date: Mon, 25 Nov 2013 10:15:10 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20131125091510.GB58602@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 09:15:21 -0000 On Sun, Nov 24, 2013 at 02:16:36PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Following text is proposed to use for the charter update: > " 3. Develop a RESTful protocol (RESTCONF) that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The three parts concerning RESTCONF protocol, the transport binding over HTTP and the YANG patch operation will be prepared modular and in separate drafts. This enables to add a new transport binding at a later stage." > Technical question: I do wonder how you can separate the HTTP transport binding out of a RESTful protocol without making the specification rather complicated to read and understand. After all, you will make assumptions about what HTTP provides in many places (e.g. what is carried in HTTP message headers or HTTP mechanisms like etags are used). Is there an example somewhere I can look at to understand what this separation is going to look like? And which problem are we solving by separating this out? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Nov 25 01:33:30 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8321ACCF4 for ; Mon, 25 Nov 2013 01:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG5KjptUnjCL for ; Mon, 25 Nov 2013 01:33:28 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 556771ACCDF for ; Mon, 25 Nov 2013 01:33:28 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E6B9014093F; Mon, 25 Nov 2013 10:33:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1385372008; bh=5E9asv7J/+pWWsXvf4umCniw6fJHOjGfoblB9fEGL8s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kiEY1VUQFPlOMuuHSso0Y0RspPkDbV9+axGyd8Scn8n7uXUroCw9LDwXaFqygMkZF IKLEV/8ssQLRhGPScDIBBKh5SNscs87J3usZLeidhfS/qEnAqHoDSKR8COfJIfu1hL jq0X5Y3uPykwV3kApiPoL+Om1lxvCpwfzk/60i9E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: <20131125091510.GB58602@elstar.local> Date: Mon, 25 Nov 2013 10:33:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <757CAD24-CFC6-4EBC-99A9-7C53FC37B96D@nic.cz> References: <20131125091510.GB58602@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 09:33:30 -0000 On 25 Nov 2013, at 10:15, Juergen Schoenwaelder = wrote: > On Sun, Nov 24, 2013 at 02:16:36PM +0000, Ersue, Mehmet (NSN - = DE/Munich) wrote: >>=20 >> Following text is proposed to use for the charter update: >> " 3. Develop a RESTful protocol (RESTCONF) that provides a = programmatic interface for accessing data defined in YANG, using the = datastores defined in NETCONF. The three parts concerning RESTCONF = protocol, the transport binding over HTTP and the YANG patch operation = will be prepared modular and in separate drafts. This enables to add a = new transport binding at a later stage." >>=20 >=20 > Technical question: >=20 > I do wonder how you can separate the HTTP transport binding out of a > RESTful protocol without making the specification rather complicated > to read and understand. After all, you will make assumptions about > what HTTP provides in many places (e.g. what is carried in HTTP > message headers or HTTP mechanisms like etags are used). Is there an > example somewhere I can look at to understand what this separation is > going to look like? And which problem are we solving by separating > this out? Indeed, and also the use of HTTP methods is crucial. IMO, what makes sense is to factor out YANG Patch because, in principle, = other patch formats (media types) may be supported instead/in parallel. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Nov 25 01:45:52 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297411AD66E for ; Mon, 25 Nov 2013 01:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhV4L0uIOyNw for ; Mon, 25 Nov 2013 01:45:45 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id E29AA1AD2EC for ; Mon, 25 Nov 2013 01:45:44 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id gc15so3548958qeb.35 for ; Mon, 25 Nov 2013 01:45:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R210YKOzql9juiJTnJE/KHbokjgcRGP0ADocx/qcW8E=; b=LVPb2w8V984J9vcX0WSUJ0VRgXHiLlAXIXTA0jatc2tN9nDMC71RqQzQFxpPCqwnTI MEnoVNRw0hnhx9wlTQ2CKQlFubA32NVxR9dWx/1nOUFyn98iaVs99ilNp9sPtME+Mdrn 7Ze0OnyYExxjaVAYBoeHUzu+/12K3zHvKAVkOokA99WpN5eaRwka5IVV/k42hO5uOk1h 1d2HHUvaW7CsJmhxuAHexvAS5sEuTQJR3XU2zY7Dt4PoANL8rL2Crqa3aronIQ+gJi0m WkBdhiOWiHAKQCvY2BH5lVR9U+JPMzc/J4r70yr7z+A8M2GHDN58LvlZc/gCiwjmwOrN 32YA== X-Gm-Message-State: ALoCoQkqyE+mU7M6MiLuwiegMO76D7buzfIe5SOh7XcvFMi54rrLpSz6/6zrkGkrlzfar73BwL/E MIME-Version: 1.0 X-Received: by 10.224.51.196 with SMTP id e4mr25510700qag.16.1385372745053; Mon, 25 Nov 2013 01:45:45 -0800 (PST) Received: by 10.140.86.200 with HTTP; Mon, 25 Nov 2013 01:45:44 -0800 (PST) In-Reply-To: <757CAD24-CFC6-4EBC-99A9-7C53FC37B96D@nic.cz> References: <20131125091510.GB58602@elstar.local> <757CAD24-CFC6-4EBC-99A9-7C53FC37B96D@nic.cz> Date: Mon, 25 Nov 2013 01:45:44 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c29e5059d64404ebfd3acd Cc: Netconf Subject: Re: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 09:45:52 -0000 --001a11c29e5059d64404ebfd3acd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 25, 2013 at 1:33 AM, Ladislav Lhotka wrote: > > On 25 Nov 2013, at 10:15, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Sun, Nov 24, 2013 at 02:16:36PM +0000, Ersue, Mehmet (NSN - > DE/Munich) wrote: > >> > >> Following text is proposed to use for the charter update: > >> " 3. Develop a RESTful protocol (RESTCONF) that provides a > programmatic interface for accessing data defined in YANG, using the > datastores defined in NETCONF. The three parts concerning RESTCONF > protocol, the transport binding over HTTP and the YANG patch operation will > be prepared modular and in separate drafts. This enables to add a new > transport binding at a later stage." > >> > > > > Technical question: > > > > I do wonder how you can separate the HTTP transport binding out of a > > RESTful protocol without making the specification rather complicated > > to read and understand. After all, you will make assumptions about > > what HTTP provides in many places (e.g. what is carried in HTTP > > message headers or HTTP mechanisms like etags are used). Is there an > > example somewhere I can look at to understand what this separation is > > going to look like? And which problem are we solving by separating > > this out? > > Indeed, and also the use of HTTP methods is crucial. > > I agree. Just emailed Martin about this -- splitting out the HTTP bits may not be practical or required. More likely, the set of mandatory-to-implement features would be smaller for constrained devices. > IMO, what makes sense is to factor out YANG Patch because, in principle, > other patch formats (media types) may be supported instead/in parallel. > > Lada > > > > > /js > Andy > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c29e5059d64404ebfd3acd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 25, 2013 at 1:33 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 25 Nov 2013, at 10:15, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&g= t; wrote:

> On Sun, Nov 24, 2013 at 02:16:36PM +0000, Ersue, Mehmet (NSN - DE/Muni= ch) wrote:
>>
>> Following text is proposed to use for the charter update:
>> " =A03. Develop a RESTful protocol (RESTCONF) that provides a= programmatic interface for accessing data defined in YANG, using the datas= tores defined in NETCONF. The three parts concerning RESTCONF protocol, the= transport binding over HTTP and the YANG patch operation will be prepared = modular and in separate drafts. This enables to add a new transport binding= at a later stage."
>>
>
> Technical question:
>
> I do wonder how you can separate the HTTP transport binding out of a > RESTful protocol without making the specification rather complicated > to read and understand. After all, you will make assumptions about
> what HTTP provides in many places (e.g. what is carried in HTTP
> message headers or HTTP mechanisms like etags are used). Is there an > example somewhere I can look at to understand what this separation is<= br> > going to look like? And which problem are we solving by separating
> this out?

Indeed, and also the use of HTTP methods is crucial.


I agree.
Just emailed Martin= about this -- splitting out the HTTP bits may
not be practical o= r required. =A0More likely, the set of mandatory-to-implement
features would be smaller for constrained devices.

=A0
IMO, what makes sense is to factor out YANG Patch because, in principle, ot= her patch formats (media types) may be supported instead/in parallel.

Lada

>
> /js


Andy
= =A0
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a11c29e5059d64404ebfd3acd-- From j.schoenwaelder@jacobs-university.de Tue Nov 26 06:06:13 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB76F1AE1F4 for ; Tue, 26 Nov 2013 06:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQG2RzCgdWVE for ; Tue, 26 Nov 2013 06:06:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 297621AE21E for ; Tue, 26 Nov 2013 06:06:07 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9860F20078; Tue, 26 Nov 2013 15:06:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rdMKpUIatK5E; Tue, 26 Nov 2013 15:06:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FA1A20076; Tue, 26 Nov 2013 15:06:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A3853298539B; Tue, 26 Nov 2013 15:05:57 +0100 (CET) Date: Tue, 26 Nov 2013 15:05:57 +0100 From: Juergen Schoenwaelder To: Wojciech Dec Message-ID: <20131126140557.GA63168@elstar.local> Mail-Followup-To: Wojciech Dec , draft-bierman-netconf-restconf@tools.ietf.org, netconf@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org, draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] [netmod] Restconf - config and operational data sets X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 14:06:13 -0000 Hi, I think the current home for restconf discussions is the NETCONF WG mailing list and not the NETMOD WG mailing list. /js On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote: > Hello Restconf authors, > > (retrying) > > got a question regarding your latest Restconf draft. This features the split > between /config and /operational URIs . > > The text in section 5.1.1 and 5.1.2 indicates that the data in these URIs > use > data-stores that are effectively dis-joint sets, i.e. Rw data is in /config > and > ro data is in /operational. > Is that the intent, correct interpretation? > > If so, then the following example also in the draft indicates something > else: > > The jukebox data model is: > > | +--ro artist-count? uint32 > | +--ro album-count? uint32 > | +--rw song-count? uint32 > > > (p102) > > While on p52 we see the following returned from the operational store: > > GET /restconf/operational/example-jukebox:jukebox/library > HTTP/1.1 > Host: example.com > Accept: application/yang.data+json > > The server might respond: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:30 GMT > Server: example-server > Cache-Control: no-cache > Pragma: no-cache > Content-Type: application/yang.data+json > > { > "example-jukebox:library" : { > "artist-count" : 42, > "album-count" : 59, > "song-count" : 374 > } > } > > Which interpretation is correct? > > That said, personally I find this URI "fork" undesirable, and not > something a Rest-like interface ought to provide. If anything, the > example, even if it turns out to be due to a typo, offers a better > alternative; ie have a resource that provides "all" info, config and > operational, and another that delivers an oper or config only set. Some > better even better options can also be thought of. Anyway, before going > there, it would be great to understand whether my interpretation is > correct. > > Regards, > Wojciech. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Tue Nov 26 08:43:20 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7E1ADEC1 for ; Tue, 26 Nov 2013 08:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AhTIhJgZABB for ; Tue, 26 Nov 2013 08:43:18 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC971A1F55 for ; Tue, 26 Nov 2013 08:43:18 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id f11so4600879qae.5 for ; Tue, 26 Nov 2013 08:43:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jXCVOD34oOt232zGmrIDnLpFPp0vS+CMKVdCrdCY1Cs=; b=dvdhRRCxqwUsYl6Vre0qcCqZ9UfCTFWd6Ka3HJ3c+C+BcLGX78Ewy2kUnvwGyz1rFE ufSNLW0yKwqQbpq2eks6yt7o3e84aQ9j2Sk9jXPhXKCtWRh7tUnmmnrJomHn6D3Rfnrh TFo+ZEaIbySKRRz6luUrkwV0TNC/Lf5bejRhp16LNDYPU6VnzB08tQJ9CTnk4o52S0uY 52cYeSiQCMu87Y6fdXm1yE5D7V3FjJF581946TAOsGLkxMhVExf03m4MGVXPYt4yiIJQ XeYzLmE1z7MAU2sbYGH5mwOOX70/aThx+hCs2EbqGjXGN9AppkK8JJ8+2V5WSLsI1ykV /EAw== X-Gm-Message-State: ALoCoQlwodVAoimh+LrOngMSun2EC19tXK/ywRDiv0Hz7u5MdjdfTfrt9vIYxjySJU3Cmbq/afhn MIME-Version: 1.0 X-Received: by 10.224.60.193 with SMTP id q1mr14889972qah.99.1385484198032; Tue, 26 Nov 2013 08:43:18 -0800 (PST) Received: by 10.140.86.200 with HTTP; Tue, 26 Nov 2013 08:43:17 -0800 (PST) In-Reply-To: <20131126140557.GA63168@elstar.local> References: <20131126140557.GA63168@elstar.local> Date: Tue, 26 Nov 2013 08:43:17 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Wojciech Dec , draft-bierman-netconf-restconf@tools.ietf.org, Netconf Content-Type: multipart/alternative; boundary=001a1133dee677487204ec172d61 Subject: Re: [Netconf] [netmod] Restconf - config and operational data sets X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 16:43:20 -0000 --001a1133dee677487204ec172d61 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I think the current home for restconf discussions is the NETCONF WG > mailing list and not the NETMOD WG mailing list. > > /js > > On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote: > > Hello Restconf authors, > > > > (retrying) > > > > got a question regarding your latest Restconf draft. This features the > split > > between /config and /operational URIs . > > > > The text in section 5.1.1 and 5.1.2 indicates that the data in these URIs > > use > > data-stores that are effectively dis-joint sets, i.e. Rw data is in > /config > > and > > ro data is in /operational. > > Is that the intent, correct interpretation? > > > This is a conceptual API so the split is an implementation detail. The operational data includes ancestor list+keys and containers. > > If so, then the following example also in the draft indicates something > > else: > > > > The jukebox data model is: > > > > | +--ro artist-count? uint32 > > | +--ro album-count? uint32 > > | +--rw song-count? uint32 > > > Thanks for finding this bug (song-count is supposed to be config false in the example-jukebox YANG module. > > > > (p102) > > > > While on p52 we see the following returned from the operational store: > > > > GET /restconf/operational/example-jukebox:jukebox/library > > HTTP/1.1 > > Host: example.com > > Accept: application/yang.data+json > > > > The server might respond: > > > > HTTP/1.1 200 OK > > Date: Mon, 23 Apr 2012 17:01:30 GMT > > Server: example-server > > Cache-Control: no-cache > > Pragma: no-cache > > Content-Type: application/yang.data+json > > > > { > > "example-jukebox:library" : { > > "artist-count" : 42, > > "album-count" : 59, > > "song-count" : 374 > > } > > } > > > > Which interpretation is correct? > > > The retrieval is correct. The YANG example will be fixed. > > That said, personally I find this URI "fork" undesirable, and not > > something a Rest-like interface ought to provide. If anything, the > > example, even if it turns out to be due to a typo, offers a better > > alternative; ie have a resource that provides "all" info, config and > > operational, and another that delivers an oper or config only set. Some > > better even better options can also be thought of. Anyway, before going > > there, it would be great to understand whether my interpretation is > > correct. > > > I thought about this idea some more and it doesn't really work because the entity tags and last-modified timestamps for config=true data nodes would be affected by changes to descendant operational data nodes. >From and HTTP caching POV, the ETag and Last-Modified headers need to be updated if the resource changes at all. From a RESTCONF POV, only the configuration data nodes can affect these headers or else they are useless for If-Match testing for editing operations. > Regards, > > Wojciech. > > Andy > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a1133dee677487204ec172d61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

I think the current home for restconf discussions is the NETCONF WG
mailing list and not the NETMOD WG mailing list.

/js

On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote:
> Hello Restconf authors,
>
> (retrying)
>
> got a question regarding your latest Restconf draft. This features the= split
> between /config and /operational URIs .
>
> The text in section 5.1.1 and 5.1.2 indicates that the data in these U= RIs
> use
> data-stores that are effectively dis-joint sets, i.e. Rw data is in /c= onfig
> and
> ro data is in /operational.
> Is that the intent, correct interpretation?
>

This is a conceptual API so the sp= lit is an implementation detail.
The operational data includes an= cestor list+keys and containers.
=A0
> If so, then the following example also in the draft indicates somethin= g
> else:
>
> The jukebox data model is:
>
> =A0 =A0 =A0 =A0 =A0| =A0+--ro artist-count? =A0 uint32
> =A0 =A0 =A0 =A0 | =A0+--ro album-count? =A0 =A0uint32
> =A0 =A0 =A0 =A0 | =A0+--rw song-count? =A0 =A0 uint32
>

Thanks for finding this bug (song-= count is supposed to be config false
in the example-jukebox YANG = module.

=A0
>
> (p102)
>
> While on p52 we see the following returned from the operational store:=
>
> GET /restconf/operational/example-jukebox:jukebox/library
> =A0 =A0 =A0 =A0 HTTP/1.1
> =A0 =A0 =A0Host: exam= ple.com <http://ex= ample.com/>
> =A0 =A0 =A0Accept: application/yang.data+json
>
> =A0 The server might respond:
>
> =A0 =A0 =A0HTTP/1.1 200 OK
> =A0 =A0 =A0Date: Mon, 23 Apr 2012 17:01:30 GMT
> =A0 =A0 =A0Server: example-server
> =A0 =A0 =A0Cache-Control: no-cache
> =A0 =A0 =A0Pragma: no-cache
> =A0 =A0 =A0Content-Type: application/yang.data+json
>
> =A0 =A0 =A0{
> =A0 =A0 =A0 =A0"example-jukebox:library" : {
> =A0 =A0 =A0 =A0 =A0 "artist-count" : 42,
> =A0 =A0 =A0 =A0 =A0 "album-count" : 59,
> =A0 =A0 =A0 =A0 =A0 "song-count" : 374
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0}
>
> Which interpretation is correct?
>

The retrieval is correct.
The YANG example will be fixed.

=A0
> That said, personally I find this URI "fork" undesirable, an= d not
> something a Rest-like interface ought to provide. If anything, the
> example, even if it turns out to be due to a typo, offers a better
> alternative; ie have a resource that provides "all" info, co= nfig and
> operational, and another that delivers an oper or config only set. Som= e
> better even better options can also be thought of. Anyway, before goin= g
> there, it would be great to understand whether my interpretation is > correct.
>


I thought about thi= s idea some more and it doesn't really work
because the entit= y tags and last-modified timestamps for
config=3Dtrue data nodes = would be affected by changes to
descendant operational data nodes.=A0

From an= d HTTP caching POV, the ETag and Last-Modified headers
need to be= updated if the resource changes at all. From a RESTCONF POV,
onl= y the configuration data nodes can affect these headers or else they
are useless for If-Match testing for editing operations.

> Regards,
> Wojciech.


Andy
=A0
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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

--001a1133dee677487204ec172d61-- From wdec.ietf@gmail.com Wed Nov 27 11:33:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496A81ADF7B for ; Wed, 27 Nov 2013 11:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ByLI_eZeJ0W for ; Wed, 27 Nov 2013 11:33:24 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4964C1AD8DA for ; Wed, 27 Nov 2013 11:29:05 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id r10so10524308pdi.38 for ; Wed, 27 Nov 2013 11:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cl8oCI1T668G2noUeKfmMcxJUeEUWxrYG9Le8hVMdcU=; b=VoFca2RT9dsTycpDVJmpN5HuOIuLBxoGhdG0H1cM0uZ9WRFmTDg5Q1ZEXQXwxPtK9m S0aL4yMxH7y0F917uBkU+7ibPrzB/WxXKiUUBRSPx7Vo9gTXAx+KHLRghum7E3QUOv1m Gxn4oqO1OF4oqC57fOwjKzjLqWJDq7nTMAdK7q7MYWEBzgmB4VHntMHEX+ggWQNB8x/F wmJ3jhKatDqO0enP/Zm+1U9DZWMCAixkDzLew/f0nXZRGi+Ei8hfQopocAIwr1XfrHtt G+Agc1HzfDPD06Sufj68O+rk2Ua931wDeoJEuVw7KR2FYao8lIYWgkh6OyqxS/Cc2hnC QTcA== MIME-Version: 1.0 X-Received: by 10.68.172.65 with SMTP id ba1mr6774099pbc.18.1385580544834; Wed, 27 Nov 2013 11:29:04 -0800 (PST) Received: by 10.70.57.163 with HTTP; Wed, 27 Nov 2013 11:29:04 -0800 (PST) In-Reply-To: References: <20131126140557.GA63168@elstar.local> Date: Wed, 27 Nov 2013 20:29:04 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b10cc852ec25f04ec2d9c63 Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] [netmod] Restconf - config and operational data sets X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:33:42 -0000 X-List-Received-Date: Wed, 27 Nov 2013 19:33:42 -0000 --047d7b10cc852ec25f04ec2d9c63 Content-Type: text/plain; charset=ISO-8859-1 Hi Andy, thanks for the reply. Continued inline... On 26 November 2013 17:43, Andy Bierman wrote: > > > > On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> Hi, >> >> I think the current home for restconf discussions is the NETCONF WG >> mailing list and not the NETMOD WG mailing list. >> >> /js >> >> On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote: >> > Hello Restconf authors, >> > >> > (retrying) >> > >> > got a question regarding your latest Restconf draft. This features the >> split >> > between /config and /operational URIs . >> > >> > The text in section 5.1.1 and 5.1.2 indicates that the data in these >> URIs >> > use >> > data-stores that are effectively dis-joint sets, i.e. Rw data is in >> /config >> > and >> > ro data is in /operational. >> > Is that the intent, correct interpretation? >> > >> > > This is a conceptual API so the split is an implementation detail. > The operational data includes ancestor list+keys and containers. > Well, not sure I understand. The /config and /operational "resources" would appear to be anything but conceptual. I.e. Any restconf API implementation would expose these two top level resources, irrespective of the data-store implementation used. Any client following the Restconf API would use these URIs as absolutes. What am I missing? > > >> > If so, then the following example also in the draft indicates something >> > else: >> > >> > The jukebox data model is: >> > >> > | +--ro artist-count? uint32 >> > | +--ro album-count? uint32 >> > | +--rw song-count? uint32 >> > >> > > Thanks for finding this bug (song-count is supposed to be config false > in the example-jukebox YANG module. > > > >> > >> > (p102) >> > >> > While on p52 we see the following returned from the operational store: >> > >> > GET /restconf/operational/example-jukebox:jukebox/library >> > HTTP/1.1 >> > Host: example.com >> > Accept: application/yang.data+json >> > >> > The server might respond: >> > >> > HTTP/1.1 200 OK >> > Date: Mon, 23 Apr 2012 17:01:30 GMT >> > Server: example-server >> > Cache-Control: no-cache >> > Pragma: no-cache >> > Content-Type: application/yang.data+json >> > >> > { >> > "example-jukebox:library" : { >> > "artist-count" : 42, >> > "album-count" : 59, >> > "song-count" : 374 >> > } >> > } >> > >> > Which interpretation is correct? >> > >> > > The retrieval is correct. > The YANG example will be fixed. > Cool. > > > >> > That said, personally I find this URI "fork" undesirable, and not >> > something a Rest-like interface ought to provide. If anything, the >> > example, even if it turns out to be due to a typo, offers a better >> > alternative; ie have a resource that provides "all" info, config and >> > operational, and another that delivers an oper or config only set. Some >> > better even better options can also be thought of. Anyway, before going >> > there, it would be great to understand whether my interpretation is >> > correct. >> > >> > > > I thought about this idea some more and it doesn't really work > because the entity tags and last-modified timestamps for > config=true data nodes would be affected by changes to > descendant operational data nodes. > Well, the big downside of the current approach is that, for a client to get a "complete view" of the state of some resource, it needs to do two API calls to two rather distinct URIs. Now, perhaps I should have explained better above, but the following would still appear to offer the ETag and timestamps behaviour that you appear to be indicating as a concern: - the operational "tree" shows everything (config and run time state). No one can assume that last-modified timestamps have to do with "last time some config was changed" - the config "tree" shows just the config and there one can assume that last-modified timestamps have to do with "last time some config was changed". Clients could pick which one they want to use, or both. Regards, Wojciech. > > From and HTTP caching POV, the ETag and Last-Modified headers > need to be updated if the resource changes at all. From a RESTCONF POV, > only the configuration data nodes can affect these headers or else they > are useless for If-Match testing for editing operations. > > > > Regards, >> > Wojciech. >> >> > Andy > > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > > --047d7b10cc852ec25f04ec2d9c63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andy,

thanks for the reply. Continued inline...<= br>


On 26= November 2013 17:43, Andy Bierman <andy@yumaworks.com> wro= te:



On Tue, Nov = 26, 2013 at 6:05 AM, Juergen Schoenwaelder <j.schoenwae= lder@jacobs-university.de> wrote:
Hi,

I think the current home for restconf discussions is the NETCONF WG
mailing list and not the NETMOD WG mailing list.

/js

On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote:
> Hello Restconf authors,
>
> (retrying)
>
> got a question regarding your latest Restconf draft. This features the= split
> between /config and /operational URIs .
>
> The text in section 5.1.1 and 5.1.2 indicates that the data in these U= RIs
> use
> data-stores that are effectively dis-joint sets, i.e. Rw data is in /c= onfig
> and
> ro data is in /operational.
> Is that the intent, correct interpretation?
>

This is a conceptual API so = the split is an implementation detail.
The operational data inclu= des ancestor list+keys and containers.

Well, not sure I understand. The /config and /operation= al "resources" would appear to be anything but conceptual. I.e. A= ny restconf API implementation would expose these two top level resources, = irrespective of the data-store implementation used.=A0 Any client following= the Restconf API would use these URIs as absolutes. What am I missing?
=A0
> If so, then the following example also in the draft indicates somethin= g
> else:
>
> The jukebox data model is:
>
> =A0 =A0 =A0 =A0 =A0| =A0+--ro artist-count? =A0 uint32
> =A0 =A0 =A0 =A0 | =A0+--ro album-count? =A0 =A0uint32
> =A0 =A0 =A0 =A0 | =A0+--rw song-count? =A0 =A0 uint32
>

Thanks for finding this bug = (song-count is supposed to be config false
in the example-jukebox= YANG module.

=A0
>
> (p102)
>
> While on p52 we see the following returned from the operational store:=
>
> GET /restconf/operational/example-jukebox:jukebox/library
> =A0 =A0 =A0 =A0 HTTP/1.1
> =A0 =A0 =A0Host: exam= ple.com <http://ex= ample.com/>
> =A0 =A0 =A0Accept: application/yang.data+json
>
> =A0 The server might respond:
>
> =A0 =A0 =A0HTTP/1.1 200 OK
> =A0 =A0 =A0Date: Mon, 23 Apr 2012 17:01:30 GMT
> =A0 =A0 =A0Server: example-server
> =A0 =A0 =A0Cache-Control: no-cache
> =A0 =A0 =A0Pragma: no-cache
> =A0 =A0 =A0Content-Type: application/yang.data+json
>
> =A0 =A0 =A0{
> =A0 =A0 =A0 =A0"example-jukebox:library" : {
> =A0 =A0 =A0 =A0 =A0 "artist-count" : 42,
> =A0 =A0 =A0 =A0 =A0 "album-count" : 59,
> =A0 =A0 =A0 =A0 =A0 "song-count" : 374
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0}
>
> Which interpretation is correct?
>

The retrieval is correct.
The YANG example will be fixed.

Cool.

=A0
> That said, personally I find this URI "fork" undesirable, an= d not
> something a Rest-like interface ought to provide. If anything, the
> example, even if it turns out to be due to a typo, offers a better
> alternative; ie have a resource that provides "all" info, co= nfig and
> operational, and another that delivers an oper or config only set. Som= e
> better even better options can also be thought of. Anyway, before goin= g
> there, it would be great to understand whether my interpretation is > correct.
>


I thought abo= ut this idea some more and it doesn't really work
because the= entity tags and last-modified timestamps for
config=3Dtrue data = nodes would be affected by changes to
descendant operational data nodes.=A0

Well, the big downside of the current approach is t= hat, for a client to get a "complete view" of the state of some r= esource, it needs to do two API calls to two rather distinct URIs.
Now, perhaps I should have explained better above, but the following would = still appear to offer the ETag and timestamps behaviour that you appear to = be indicating as a concern:
- the operational "tree" shows ev= erything (config and run time state). No one can assume that last-modified = timestamps have to do with "last time some config was changed" - the config "tree" shows just the config=A0 and there=A0 one can= assume that last-modified timestamps have to do with "last time some = config was changed".

Clients could pick which one th= ey want to use, or both.

Regards,
Wojciech.
=A0

From and = HTTP caching POV, the ETag and Last-Modified headers
need to be updated if the resource changes at all. From a RESTCONF POV= ,
only the configuration data nodes can affect these headers or e= lse they
are useless for If-Match testing for editing operations.

> Regards,
> Wojciech.


Andy
=A0
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


--047d7b10cc852ec25f04ec2d9c63-- From andy@yumaworks.com Wed Nov 27 16:16:49 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783A81AE048 for ; Wed, 27 Nov 2013 16:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FXxx1SaeACv for ; Wed, 27 Nov 2013 16:16:47 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1257F1AE045 for ; Wed, 27 Nov 2013 16:16:45 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id t7so8432454qeb.34 for ; Wed, 27 Nov 2013 16:16:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CdMkHprx9cGZgj1nSkYUdSwIVJFinEs1ekegBEmLzDw=; b=TmQnOQCXLmlgRQYVALdlY3xpn+1xnXdqZ3WsfRS+hjMJVCD1M4SiW0/MDdSN/D9+rP 4+OiMzZOLmDIhGBgImmEi1Knx8DMSx92KXPG+HkJI23HEZawLadZGia5Xw9Dvm3TU1tg vEozs/ohn0XX8704ypbZKTrQgBq28KLbZdEGTS2tvfXlwrh3VLbGrdNMk4t5Fgtd29OH 7NQZR1rL/61CUwGDoJuudvPoCEqsJKfXa5TcGEZQnm/J85TJLS+cC4jJQM3ItejNsFCz 2aaqYbmWgBkQCKPA5sRE/4eeLXZURO5dxLnzb6ly+UDM7eFAYiogPNDpI2n5loZX/CBv QPmQ== X-Gm-Message-State: ALoCoQlE6O1nOt3TmLbplE/N+JP1vRPwKwsi5izCkY6ronP7lcEUkElt7A9W4wGmNx3yf+gpao+K MIME-Version: 1.0 X-Received: by 10.49.84.105 with SMTP id x9mr18993023qey.65.1385597805231; Wed, 27 Nov 2013 16:16:45 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 27 Nov 2013 16:16:45 -0800 (PST) In-Reply-To: References: <20131126140557.GA63168@elstar.local> Date: Wed, 27 Nov 2013 16:16:45 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7bdc0ef0fbb05304ec31a07b Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] [netmod] Restconf - config and operational data sets X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 00:16:49 -0000 --047d7bdc0ef0fbb05304ec31a07b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 27, 2013 at 11:29 AM, Wojciech Dec wrote: > Hi Andy, > > thanks for the reply. Continued inline... > > > On 26 November 2013 17:43, Andy Bierman wrote: > >> >> >> >> On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> Hi, >>> >>> I think the current home for restconf discussions is the NETCONF WG >>> mailing list and not the NETMOD WG mailing list. >>> >>> /js >>> >>> On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote: >>> > Hello Restconf authors, >>> > >>> > (retrying) >>> > >>> > got a question regarding your latest Restconf draft. This features the >>> split >>> > between /config and /operational URIs . >>> > >>> > The text in section 5.1.1 and 5.1.2 indicates that the data in these >>> URIs >>> > use >>> > data-stores that are effectively dis-joint sets, i.e. Rw data is in >>> /config >>> > and >>> > ro data is in /operational. >>> > Is that the intent, correct interpretation? >>> > >>> >> >> This is a conceptual API so the split is an implementation detail. >> The operational data includes ancestor list+keys and containers. >> > > Well, not sure I understand. The /config and /operational "resources" > would appear to be anything but conceptual. I.e. Any restconf API > implementation would expose these two top level resources, irrespective of > the data-store implementation used. Any client following the Restconf API > would use these URIs as absolutes. What am I missing? > Yes they would use these APIs, but it doesn't mean the server maintains the data in a way that resembles the API. That's what I mean by conceptual. > >> >>> > If so, then the following example also in the draft indicates something >>> > else: >>> > >>> > The jukebox data model is: >>> > >>> > | +--ro artist-count? uint32 >>> > | +--ro album-count? uint32 >>> > | +--rw song-count? uint32 >>> > >>> >> >> Thanks for finding this bug (song-count is supposed to be config false >> in the example-jukebox YANG module. >> >> >> >>> > >>> > (p102) >>> > >>> > While on p52 we see the following returned from the operational store: >>> > >>> > GET /restconf/operational/example-jukebox:jukebox/library >>> > HTTP/1.1 >>> > Host: example.com >>> > Accept: application/yang.data+json >>> > >>> > The server might respond: >>> > >>> > HTTP/1.1 200 OK >>> > Date: Mon, 23 Apr 2012 17:01:30 GMT >>> > Server: example-server >>> > Cache-Control: no-cache >>> > Pragma: no-cache >>> > Content-Type: application/yang.data+json >>> > >>> > { >>> > "example-jukebox:library" : { >>> > "artist-count" : 42, >>> > "album-count" : 59, >>> > "song-count" : 374 >>> > } >>> > } >>> > >>> > Which interpretation is correct? >>> > >>> >> >> The retrieval is correct. >> The YANG example will be fixed. >> > > Cool. > >> >> >> >>> > That said, personally I find this URI "fork" undesirable, and not >>> > something a Rest-like interface ought to provide. If anything, the >>> > example, even if it turns out to be due to a typo, offers a better >>> > alternative; ie have a resource that provides "all" info, config and >>> > operational, and another that delivers an oper or config only set. Some >>> > better even better options can also be thought of. Anyway, before going >>> > there, it would be great to understand whether my interpretation is >>> > correct. >>> > >>> >> >> >> I thought about this idea some more and it doesn't really work >> because the entity tags and last-modified timestamps for >> config=true data nodes would be affected by changes to >> descendant operational data nodes. >> > > Well, the big downside of the current approach is that, for a client to > get a "complete view" of the state of some resource, it needs to do two API > calls to two rather distinct URIs. > Now, perhaps I should have explained better above, but the following would > still appear to offer the ETag and timestamps behaviour that you appear to > be indicating as a concern: > - the operational "tree" shows everything (config and run time state). No > one can assume that last-modified timestamps have to do with "last time > some config was changed" > - the config "tree" shows just the config and there one can assume that > last-modified timestamps have to do with "last time some config was > changed". > > Clients could pick which one they want to use, or both. > > Yes -- I think that's what we discussed offline.... /restconf/config == config=true only config parameter ignored /restconf/data == operational data or all config=true ==> all config == false ==> operational data only > Regards, > Wojciech. > Andy > > >> >> From and HTTP caching POV, the ETag and Last-Modified headers >> need to be updated if the resource changes at all. From a RESTCONF POV, >> only the configuration data nodes can affect these headers or else they >> are useless for If-Match testing for editing operations. >> >> >> > Regards, >>> > Wojciech. >>> >>> >> Andy >> >> >>> > _______________________________________________ >>> > netmod mailing list >>> > netmod@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> >> >> > --047d7bdc0ef0fbb05304ec31a07b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 27, 2013 at 11:29 AM, Wojciech Dec &l= t;wdec.ietf@gmail.= com> wrote:
Hi Andy,

thanks for the reply. Con= tinued inline...


On 26 November 2013 17:43, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

I think the current home for restconf discussions is the NETCONF WG
mailing list and not the NETMOD WG mailing list.

/js

On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote:
> Hello Restconf authors,
>
> (retrying)
>
> got a question regarding your latest Restconf draft. This features the= split
> between /config and /operational URIs .
>
> The text in section 5.1.1 and 5.1.2 indicates that the data in these U= RIs
> use
> data-stores that are effectively dis-joint sets, i.e. Rw data is in /c= onfig
> and
> ro data is in /operational.
> Is that the intent, correct interpretation?
>

This is a conceptual API so = the split is an implementation detail.
The operational data inclu= des ancestor list+keys and containers.

Well, not sure I understand. The /config and /operation= al "resources" would appear to be anything but conceptual. I.e. A= ny restconf API implementation would expose these two top level resources, = irrespective of the data-store implementation used.=A0 Any client following= the Restconf API would use these URIs as absolutes. What am I missing?


Yes they would use these APIs, but it doesn't mean the server mainta= ins the
data in a way that resembles the API. =A0That's what = I mean by conceptual.
=A0
=A0
> If so, then the following example also in the draft indicates somethin= g
> else:
>
> The jukebox data model is:
>
> =A0 =A0 =A0 =A0 =A0| =A0+--ro artist-count? =A0 uint32
> =A0 =A0 =A0 =A0 | =A0+--ro album-count? =A0 =A0uint32
> =A0 =A0 =A0 =A0 | =A0+--rw song-count? =A0 =A0 uint32
>

Thanks for finding this bug = (song-count is supposed to be config false
in the example-jukebox= YANG module.

=A0
>
> (p102)
>
> While on p52 we see the following returned from the operational store:=
>
> GET /restconf/operational/example-jukebox:jukebox/library
> =A0 =A0 =A0 =A0 HTTP/1.1
> =A0 =A0 =A0Host: exam= ple.com <http://ex= ample.com/>
> =A0 =A0 =A0Accept: application/yang.data+json
>
> =A0 The server might respond:
>
> =A0 =A0 =A0HTTP/1.1 200 OK
> =A0 =A0 =A0Date: Mon, 23 Apr 2012 17:01:30 GMT
> =A0 =A0 =A0Server: example-server
> =A0 =A0 =A0Cache-Control: no-cache
> =A0 =A0 =A0Pragma: no-cache
> =A0 =A0 =A0Content-Type: application/yang.data+json
>
> =A0 =A0 =A0{
> =A0 =A0 =A0 =A0"example-jukebox:library" : {
> =A0 =A0 =A0 =A0 =A0 "artist-count" : 42,
> =A0 =A0 =A0 =A0 =A0 "album-count" : 59,
> =A0 =A0 =A0 =A0 =A0 "song-count" : 374
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0}
>
> Which interpretation is correct?
>

The retrieval is correct.
The YANG example will be fixed.

Cool.

=A0
> That said, personally I find this URI "fork" undesirable, an= d not
> something a Rest-like interface ought to provide. If anything, the
> example, even if it turns out to be due to a typo, offers a better
> alternative; ie have a resource that provides "all" info, co= nfig and
> operational, and another that delivers an oper or config only set. Som= e
> better even better options can also be thought of. Anyway, before goin= g
> there, it would be great to understand whether my interpretation is > correct.
>


I thought abo= ut this idea some more and it doesn't really work
because the= entity tags and last-modified timestamps for
config=3Dtrue data = nodes would be affected by changes to
descendant operational data nodes.=A0

Well, the big downside of the current approach is t= hat, for a client to get a "complete view" of the state of some r= esource, it needs to do two API calls to two rather distinct URIs.
Now, perhaps I should have explained better above, but the following would = still appear to offer the ETag and timestamps behaviour that you appear to = be indicating as a concern:
- the operational "tree" shows ev= erything (config and run time state). No one can assume that last-modified = timestamps have to do with "last time some config was changed" - the config "tree" shows just the config=A0 and there=A0 one can= assume that last-modified timestamps have to do with "last time some = config was changed".

Clients could pick which one th= ey want to use, or both.



Yes -- I think that's what we discussed offline....
=A0 /restconf/config =A0=3D=3D config=3Dtrue only
=A0 =A0 config parameter ignored

=A0 /restconf/data =3D=3D operational data or all
=A0 =A0 config=3Dtrue =3D=3D> all=
=A0 =A0 co= nfig =3D=3D false =3D=3D> operational data only



=A0
Regards,
Wojciech.
<= div>

Andy

=A0
=A0

From and HTTP caching POV, the ETag and Last-Modified h= eaders
need to be updated if the resource changes at all. From a RESTCONF POV= ,
only the configuration data nodes can affect these headers or e= lse they
are useless for If-Match testing for editing operations.

> Regards,
> Wojciech.


Andy
=A0
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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



--047d7bdc0ef0fbb05304ec31a07b-- From wdec.ietf@gmail.com Thu Nov 28 02:43:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D491ADFF3 for ; Thu, 28 Nov 2013 02:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 147mjn1nkHEY for ; Thu, 28 Nov 2013 02:43:53 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0BA1AD939 for ; Thu, 28 Nov 2013 02:43:53 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so11859279pde.27 for ; Thu, 28 Nov 2013 02:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zp7RxNc+bnoZCpwKCbDLANZ00LU5Wbz8j7ZRCCmsTyM=; b=t9ZXISP9jmdVckppzJ/z3FtbdWsYVY5RBIO2wMwhul3+yGIVwpLEwMrZJB/LNx/+mj 4U2MBPX0F13VUqdOkV5nIc7i97fzjrEENXpW+a/eiV6Yf2F7SjChn4tcmBsdIbVQah94 FLRN1kNXvJRpvgBUJVuh4CaCYutrUcLcK+7x9WBcbxBxuYstVQguDsTp91Tr/7//DSM6 QUwa0UsyEsCWUQC9GYhw58wZu4xQT7li3b+gwqnVcYAeTlG5mOZNfvjMzzi59e0jrG+E hcsl0vCKQoDzQFK7KlWe0tMATsHTRI2aEVwonO650/3xGerA6vvLCWlgL3gFYBi2W59y DAsg== MIME-Version: 1.0 X-Received: by 10.67.1.101 with SMTP id bf5mr45716316pad.50.1385635432653; Thu, 28 Nov 2013 02:43:52 -0800 (PST) Received: by 10.70.57.163 with HTTP; Thu, 28 Nov 2013 02:43:52 -0800 (PST) In-Reply-To: References: <20131126140557.GA63168@elstar.local> Date: Thu, 28 Nov 2013 11:43:52 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b15ac23c0690a04ec3a631a Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] [netmod] Restconf - config and operational data sets X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 10:43:56 -0000 --047d7b15ac23c0690a04ec3a631a Content-Type: text/plain; charset=ISO-8859-1 On 28 November 2013 01:16, Andy Bierman wrote: > > > > On Wed, Nov 27, 2013 at 11:29 AM, Wojciech Dec wrote: > >> Hi Andy, >> >> thanks for the reply. Continued inline... >> >> >> On 26 November 2013 17:43, Andy Bierman wrote: >> >>> >>> >>> >>> On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>>> Hi, >>>> >>>> I think the current home for restconf discussions is the NETCONF WG >>>> mailing list and not the NETMOD WG mailing list. >>>> >>>> /js >>>> >>>> On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote: >>>> > Hello Restconf authors, >>>> > >>>> > (retrying) >>>> > >>>> > got a question regarding your latest Restconf draft. This features >>>> the split >>>> > between /config and /operational URIs . >>>> > >>>> > The text in section 5.1.1 and 5.1.2 indicates that the data in these >>>> URIs >>>> > use >>>> > data-stores that are effectively dis-joint sets, i.e. Rw data is in >>>> /config >>>> > and >>>> > ro data is in /operational. >>>> > Is that the intent, correct interpretation? >>>> > >>>> >>> >>> This is a conceptual API so the split is an implementation detail. >>> The operational data includes ancestor list+keys and containers. >>> >> >> Well, not sure I understand. The /config and /operational "resources" >> would appear to be anything but conceptual. I.e. Any restconf API >> implementation would expose these two top level resources, irrespective of >> the data-store implementation used. Any client following the Restconf API >> would use these URIs as absolutes. What am I missing? >> > > > Yes they would use these APIs, but it doesn't mean the server maintains the > data in a way that resembles the API. That's what I mean by conceptual. > > >> >>> >>>> > If so, then the following example also in the draft indicates >>>> something >>>> > else: >>>> > >>>> > The jukebox data model is: >>>> > >>>> > | +--ro artist-count? uint32 >>>> > | +--ro album-count? uint32 >>>> > | +--rw song-count? uint32 >>>> > >>>> >>> >>> Thanks for finding this bug (song-count is supposed to be config false >>> in the example-jukebox YANG module. >>> >>> >>> >>>> > >>>> > (p102) >>>> > >>>> > While on p52 we see the following returned from the operational store: >>>> > >>>> > GET /restconf/operational/example-jukebox:jukebox/library >>>> > HTTP/1.1 >>>> > Host: example.com >>>> > Accept: application/yang.data+json >>>> > >>>> > The server might respond: >>>> > >>>> > HTTP/1.1 200 OK >>>> > Date: Mon, 23 Apr 2012 17:01:30 GMT >>>> > Server: example-server >>>> > Cache-Control: no-cache >>>> > Pragma: no-cache >>>> > Content-Type: application/yang.data+json >>>> > >>>> > { >>>> > "example-jukebox:library" : { >>>> > "artist-count" : 42, >>>> > "album-count" : 59, >>>> > "song-count" : 374 >>>> > } >>>> > } >>>> > >>>> > Which interpretation is correct? >>>> > >>>> >>> >>> The retrieval is correct. >>> The YANG example will be fixed. >>> >> >> Cool. >> >>> >>> >>> >>>> > That said, personally I find this URI "fork" undesirable, and not >>>> > something a Rest-like interface ought to provide. If anything, the >>>> > example, even if it turns out to be due to a typo, offers a better >>>> > alternative; ie have a resource that provides "all" info, config and >>>> > operational, and another that delivers an oper or config only set. >>>> Some >>>> > better even better options can also be thought of. Anyway, before >>>> going >>>> > there, it would be great to understand whether my interpretation is >>>> > correct. >>>> > >>>> >>> >>> >>> I thought about this idea some more and it doesn't really work >>> because the entity tags and last-modified timestamps for >>> config=true data nodes would be affected by changes to >>> descendant operational data nodes. >>> >> >> Well, the big downside of the current approach is that, for a client to >> get a "complete view" of the state of some resource, it needs to do two API >> calls to two rather distinct URIs. >> Now, perhaps I should have explained better above, but the following >> would still appear to offer the ETag and timestamps behaviour that you >> appear to be indicating as a concern: >> - the operational "tree" shows everything (config and run time state). No >> one can assume that last-modified timestamps have to do with "last time >> some config was changed" >> - the config "tree" shows just the config and there one can assume that >> last-modified timestamps have to do with "last time some config was >> changed". >> >> Clients could pick which one they want to use, or both. >> >> > > Yes -- I think that's what we discussed offline.... > > /restconf/config == config=true only > config parameter ignored > > /restconf/data == operational data or all > config=true ==> all > config == false ==> operational data only > > > Am I correct in assuming that this will be reflected in the next version of the draft? Thanks. > > >> Regards, >> Wojciech. >> > > > Andy > > > >> >> >>> >>> From and HTTP caching POV, the ETag and Last-Modified headers >>> need to be updated if the resource changes at all. From a RESTCONF POV, >>> only the configuration data nodes can affect these headers or else they >>> are useless for If-Match testing for editing operations. >>> >>> >>> > Regards, >>>> > Wojciech. >>>> >>>> >>> Andy >>> >>> >>>> > _______________________________________________ >>>> > netmod mailing list >>>> > netmod@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>>> Fax: +49 421 200 3103 >>>> >>> >>> >> > --047d7b15ac23c0690a04ec3a631a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 28 November 2013 01:16, Andy Bierman <andy@yumaworks.com&g= t; wrote:



On Wed, Nov 27, 2013 at 11:29 A= M, Wojciech Dec <wdec.ietf@gmail.com> wrote:
Hi Andy,

thanks for the reply. Con= tinued inline...


On 26 November 2013 17:43, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

I think the current home for restconf discussions is the NETCONF WG
mailing list and not the NETMOD WG mailing list.

/js

On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote:
> Hello Restconf authors,
>
> (retrying)
>
> got a question regarding your latest Restconf draft. This features the= split
> between /config and /operational URIs .
>
> The text in section 5.1.1 and 5.1.2 indicates that the data in these U= RIs
> use
> data-stores that are effectively dis-joint sets, i.e. Rw data is in /c= onfig
> and
> ro data is in /operational.
> Is that the intent, correct interpretation?
>

This is a conceptual API so = the split is an implementation detail.
The operational data inclu= des ancestor list+keys and containers.

Well, not sure I understand. The /config and /operation= al "resources" would appear to be anything but conceptual. I.e. A= ny restconf API implementation would expose these two top level resources, = irrespective of the data-store implementation used.=A0 Any client following= the Restconf API would use these URIs as absolutes. What am I missing?


Yes they would use these APIs, but it doesn't mean the server = maintains the
data in a way that resembles the API. =A0That's= what I mean by conceptual.
=A0
=A0
> If so, then the following example also in the draft indicates somethin= g
> else:
>
> The jukebox data model is:
>
> =A0 =A0 =A0 =A0 =A0| =A0+--ro artist-count? =A0 uint32
> =A0 =A0 =A0 =A0 | =A0+--ro album-count? =A0 =A0uint32
> =A0 =A0 =A0 =A0 | =A0+--rw song-count? =A0 =A0 uint32
>

Thanks for finding this bug = (song-count is supposed to be config false
in the example-jukebox= YANG module.

=A0
>
> (p102)
>
> While on p52 we see the following returned from the operational store:=
>
> GET /restconf/operational/example-jukebox:jukebox/library
> =A0 =A0 =A0 =A0 HTTP/1.1
> =A0 =A0 =A0Host: exam= ple.com <http://ex= ample.com/>
> =A0 =A0 =A0Accept: application/yang.data+json
>
> =A0 The server might respond:
>
> =A0 =A0 =A0HTTP/1.1 200 OK
> =A0 =A0 =A0Date: Mon, 23 Apr 2012 17:01:30 GMT
> =A0 =A0 =A0Server: example-server
> =A0 =A0 =A0Cache-Control: no-cache
> =A0 =A0 =A0Pragma: no-cache
> =A0 =A0 =A0Content-Type: application/yang.data+json
>
> =A0 =A0 =A0{
> =A0 =A0 =A0 =A0"example-jukebox:library" : {
> =A0 =A0 =A0 =A0 =A0 "artist-count" : 42,
> =A0 =A0 =A0 =A0 =A0 "album-count" : 59,
> =A0 =A0 =A0 =A0 =A0 "song-count" : 374
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0}
>
> Which interpretation is correct?
>

The retrieval is correct.
The YANG example will be fixed.

Cool.

=A0
> That said, personally I find this URI "fork" undesirable, an= d not
> something a Rest-like interface ought to provide. If anything, the
> example, even if it turns out to be due to a typo, offers a better
> alternative; ie have a resource that provides "all" info, co= nfig and
> operational, and another that delivers an oper or config only set. Som= e
> better even better options can also be thought of. Anyway, before goin= g
> there, it would be great to understand whether my interpretation is > correct.
>


I thought abo= ut this idea some more and it doesn't really work
because the= entity tags and last-modified timestamps for
config=3Dtrue data = nodes would be affected by changes to
descendant operational data nodes.=A0

Well, the big downside of the current approach is t= hat, for a client to get a "complete view" of the state of some r= esource, it needs to do two API calls to two rather distinct URIs.
Now, perhaps I should have explained better above, but the following would = still appear to offer the ETag and timestamps behaviour that you appear to = be indicating as a concern:
- the operational "tree" shows ev= erything (config and run time state). No one can assume that last-modified = timestamps have to do with "last time some config was changed" - the config "tree" shows just the config=A0 and there=A0 one can= assume that last-modified timestamps have to do with "last time some = config was changed".

Clients could pick which one th= ey want to use, or both.



Yes -- I think that's what we discussed offline....<= /div>

=A0 /restconf/config =A0=3D=3D config=3Dtrue only
=A0 =A0 config parameter ignored

=A0 /restconf/data =3D=3D operational data or all
=A0 =A0 config=3Dtrue =3D=3D> all=
=A0 =A0 co= nfig =3D=3D false =3D=3D> operational data only


=A0=
Am I correct in assuming that this will be reflected in the next= version of the draft?

Thanks.


=A0
Regards,
Wojciech.
=


Andy

<= div>=A0
=A0

From and HTTP caching POV, the ETag and Last-Modified h= eaders
need to be updated if the resource changes at all. From a RESTCONF POV= ,
only the configuration data nodes can affect these headers or e= lse they
are useless for If-Match testing for editing operations.

> Regards,
> Wojciech.


Andy
=A0
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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




--047d7b15ac23c0690a04ec3a631a-- From wdec.ietf@gmail.com Fri Nov 29 06:01:40 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFCF1AD943 for ; Fri, 29 Nov 2013 06:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 208VunnqpVlc for ; Fri, 29 Nov 2013 06:01:37 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D07A01AD7C2 for ; Fri, 29 Nov 2013 06:01:37 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id w10so13816211pde.21 for ; Fri, 29 Nov 2013 06:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uk0tH89Amx6WAiyvgq3hztJ7GZhrCE2s3YNSTnMhZyM=; b=pt1tPZJ2vufpQ3IgfFakoay64oCO3H0XhSc/SZtjn5YR80iha8u5+fwZxGvV+X3BW4 9bNQKWHAFXg9kU4GHLXRcaNMC/4CTUp1UFGsz465ShWRewLRVRzcY/FCKxinLpqHOm4K 389gXvm/PeRDlD1gDp0J/hKWDlsreKoAto83847VvmjKbGOmchTP5I6BEybHOw56un1R dLnk6yZ7CvzgTQN20+r+uVHv0/aS6UsiPl5EGdr8StBQ5IeI7rZsNOlymvdfa4VZlBQ6 aUvxyFglKT5ygudQ/uhzM32JlkeCjgNk0I2TQENH6X3vNf610hG3ODDMaChLzv15CWQy XJTA== MIME-Version: 1.0 X-Received: by 10.66.255.39 with SMTP id an7mr52259014pad.7.1385733696754; Fri, 29 Nov 2013 06:01:36 -0800 (PST) Received: by 10.70.57.163 with HTTP; Fri, 29 Nov 2013 06:01:36 -0800 (PST) Date: Fri, 29 Nov 2013 15:01:36 +0100 Message-ID: From: Wojciech Dec To: draft-bierman-netconf-restconf@tools.ietf.org, Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=047d7b15b25fbf981d04ec514449 Subject: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 14:01:40 -0000 --047d7b15b25fbf981d04ec514449 Content-Type: text/plain; charset=ISO-8859-1 Hello Restconf authors, I would like to ask a few questions and seek your thoughts on the topic of URL representation in the API Currently Yang allows two forms by which one could seek to have URI data be represented in a model: A. leaf someUri { type instance-identifier; //some Xpath expression to a node } B. leaf anotherUri { type yang:uri; default "/my_uri/is/here" } Now, while the above is perhaps sufficient for some well known absolute paths, there appear to be a couple of problems in terms of a Restful API: 1. Based on the current Restconf spec, both A and B above when faced with a GET would appear to expose a URI, which the client would have to do some manipulation magic on it before use. What a Restful API would be more likely to expose instead is a URL, eg in JSON: { "url" : "http://example.com/files/v1/documents/abc123" } It would appear to be sensible to add to the Restconf spec a URL generation capability. I.e. have Restconf transform URIs into canonical URLs. Thoughts? 2. A URL to a data-model specific method Suppose that the model was also defining an RPC, along the lines of the "play" RPC in the Jukebox example. Now, as part of the song resource access API, it would be natural to have such a method returned in a URL. That would also be much more Resful than the currently implicit "/operations" resource listing. While it may be possible to use B. above to some degree, that is still below par as it is not validated in the model. Use of A. appears, to me at least, not possible since the RPC is not a node. Thus, is there a way to have Restconf return an RPC/services list for the data? Eg: { "songs": [ a list of songs, 1, 2, etc ], "rpc": { "play": [ "http://example.com/operations/example-jukebox:play"] } } 3. Use of current() function as predicate in URIs/URLs It would be useful to be able to use the "current()" function to construct URIs/URLs returned in Restconf. The spec does not make it clear on whether this would actually work in A or B above. Would it, or is there some other way? Thanks, Wojciech. --047d7b15b25fbf981d04ec514449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Restconf authors,

I would like to ask a few quest= ions and seek your thoughts on the topic of URL representation in the API
Currently Yang allows two forms by which one could seek to have URI d= ata be represented in a model:

A.
leaf someUri {=
=A0=A0=A0 type instance-identifier;
//some Xpath express= ion to a node
}

B.
leaf anotherUri {
=A0=A0=A0 type y= ang:uri;
=A0=A0=A0 default "/my_uri/is/here"
}
Now, while the above is perhaps sufficient for some well known absol= ute paths, there appear to be a couple of problems in terms of=A0 a Restful= API:

1. Based on the current Restconf spec, both A and B above wh= en faced with a GET would appear to expose a URI, which the client would ha= ve to do some manipulation magic on it before use. What a Restful API would= be more likely to expose instead is a URL, eg in JSON:
{
=A0=A0=A0= =A0"url" : "http://example.com/files/v1/documents/abc123"
}

It woul= d appear to be sensible to add to the Restconf spec a URL generation capabi= lity. I.e. have Restconf transform URIs into canonical URLs. Thoughts?
<= /div>

2. A URL to a data-model specific method
Suppose th= at the model was also defining an RPC, along the lines of the "play&qu= ot; RPC in the Jukebox example. Now, as part of the song resource access AP= I, it would be natural to have such a method returned in a URL. That would = also be much more Resful than the currently implicit "/operations"= ; resource listing.
While it may be possible to use B. above to some degree, that is still belo= w par as it is not validated in the model.
Use of A. appears, to = me at least, not possible since the RPC is not a node.
Thus, is th= ere a way to have Restconf return an RPC/services list for the data? Eg:
{
=A0= =A0=A0=A0"songs":=
=A0=A0=A0=A0[
=A0=A0=A0=A0=A0=A0=A0 a li= st of songs, 1, 2, etc
=A0= =A0=A0=A0],
=A0=A0=A0=A0"= rpc":
=A0=A0=A0=A0{
=A0=A0=A0=A0=A0=A0=A0=A0"play&qu= ot;: [ "http://example.com/operations/examp= le-jukebox:play"]
=A0=A0=A0=A0}
}

3. Use of current() function as predicate in URIs/UR= Ls

It would be useful to be able to use the &= quot;current()" function to construct URIs/URLs returned in Restconf. = The spec does not make it clear on whether this would actually work in A or= B above. Would it, or is there some other way?

Thanks,
<= div class=3D"">Wojciech.

--047d7b15b25fbf981d04ec514449-- From j.schoenwaelder@jacobs-university.de Fri Nov 29 07:03:07 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A093E1AD9A9 for ; Fri, 29 Nov 2013 07:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8lipHB6e_J2 for ; Fri, 29 Nov 2013 07:03:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0021AD94A for ; Fri, 29 Nov 2013 07:03:05 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7D672008C; Fri, 29 Nov 2013 16:03:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q6pROHfZwZnS; Fri, 29 Nov 2013 16:03:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C37420040; Fri, 29 Nov 2013 16:03:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EF2CE29990B3; Fri, 29 Nov 2013 16:02:57 +0100 (CET) Date: Fri, 29 Nov 2013 16:02:57 +0100 From: Juergen Schoenwaelder To: Wojciech Dec Message-ID: <20131129150257.GA95546@elstar.local> Mail-Followup-To: Wojciech Dec , draft-bierman-netconf-restconf@tools.ietf.org, Andy Bierman , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 15:03:07 -0000 On Fri, Nov 29, 2013 at 03:01:36PM +0100, Wojciech Dec wrote: > Hello Restconf authors, > > I would like to ask a few questions and seek your thoughts on the topic of > URL representation in the API > Currently Yang allows two forms by which one could seek to have URI data be > represented in a model: > > A. > leaf someUri { > type instance-identifier; > //some Xpath expression to a node > } An instance-identifier is not a URI. > B. > leaf anotherUri { > type yang:uri; > default "/my_uri/is/here" > } > > Now, while the above is perhaps sufficient for some well known absolute > paths, there appear to be a couple of problems in terms of a Restful API: A path is not a URI either. It seems you are talking about some form of paths but not URIs. That said, I may agree that having a hard-wired logic how URIs to RESTful resources are constructed is somewhat unRESTful. It seems that discovery of URIs for such resources is what people prefer. But of course, the flexibility this allows comes at a price - you sometimes neeed to do additional lookups. The good news is that HTTP is providing decent caching support. /js > 1. Based on the current Restconf spec, both A and B above when faced with a > GET would appear to expose a URI, which the client would have to do some > manipulation magic on it before use. What a Restful API would be more > likely to expose instead is a URL, eg in JSON: > { > "url" : "http://example.com/files/v1/documents/abc123" > } > > It would appear to be sensible to add to the Restconf spec a URL generation > capability. I.e. have Restconf transform URIs into canonical URLs. Thoughts? > > 2. A URL to a data-model specific method > Suppose that the model was also defining an RPC, along the lines of the > "play" RPC in the Jukebox example. Now, as part of the song resource access > API, it would be natural to have such a method returned in a URL. That > would also be much more Resful than the currently implicit "/operations" > resource listing. > While it may be possible to use B. above to some degree, that is still > below par as it is not validated in the model. > Use of A. appears, to me at least, not possible since the RPC is not a node. > Thus, is there a way to have Restconf return an RPC/services list for the > data? Eg: > > { > "songs": > [ > a list of songs, 1, 2, etc > ], > "rpc": > { > "play": [ "http://example.com/operations/example-jukebox:play"] > } > } > > 3. Use of current() function as predicate in URIs/URLs > > It would be useful to be able to use the "current()" function to construct > URIs/URLs returned in Restconf. The spec does not make it clear on whether > this would actually work in A or B above. Would it, or is there some other > way? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Fri Nov 29 07:59:45 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8AB1ACCE2 for ; Fri, 29 Nov 2013 07:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b6_1yYrFYey for ; Fri, 29 Nov 2013 07:59:42 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 97B311AC4C5 for ; Fri, 29 Nov 2013 07:59:42 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id gc15so10387047qeb.21 for ; Fri, 29 Nov 2013 07:59:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gv3uRIUhMWU1PYVqN856q10ULLkclBykxb66CbJ0LBI=; b=ZP/WLTDUjGA1ANUus4aBnMBV+mesIrK7fbZtG6ykszq81+tFJ2jbjgmOFKsboDzFrV iDoT3+R1YkHyhjUsexc8wHtZSbURJH3HbT3kyX41VbHZdeCl7tZMBz2ZmrvgLjKs6y4u OIi1UizIQ7Cg85j+rZZhazEwYrcriT2s1SAQLWDvnPn+sjdCKGmueGiVqOh6EehZr5MB 8corM5G2b7Qo8qlX7OA/0Sk+T/RpO8SBwWUPTFZvyfB5oClHte+Lm+h1yF16q9xP1O2N eAwQt+RO+YmS/86O63CzwARflkF7AMPVzg8dYLtHUquIpIle46Plvk0mxrhvLZzSn3Iq ockA== X-Gm-Message-State: ALoCoQmRh8OTCJSyBghUKQQxSUU8JWcBdQq/Q8OqmyiVdfPtiDdY5D+iVMt+H7ZFUkcAC0VKo1bQ MIME-Version: 1.0 X-Received: by 10.49.84.105 with SMTP id x9mr35619617qey.65.1385740781094; Fri, 29 Nov 2013 07:59:41 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 29 Nov 2013 07:59:41 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 07:59:41 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7bdc0ef0021bdf04ec52eb23 Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 15:59:45 -0000 --047d7bdc0ef0021bdf04ec52eb23 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec wrote: > Hello Restconf authors, > > I would like to ask a few questions and seek your thoughts on the topic of > URL representation in the API > Currently Yang allows two forms by which one could seek to have URI data > be represented in a model: > > A. > leaf someUri { > type instance-identifier; > //some Xpath expression to a node > } > > B. > leaf anotherUri { > type yang:uri; > default "/my_uri/is/here" > } > > Now, while the above is perhaps sufficient for some well known absolute > paths, there appear to be a couple of problems in terms of a Restful API: > > 1. Based on the current Restconf spec, both A and B above when faced with > a GET would appear to expose a URI, which the client would have to do some > manipulation magic on it before use. What a Restful API would be more > likely to expose instead is a URL, eg in JSON: > { > "url" : "http://example.com/files/v1/documents/abc123" > } > I do not understand the concern. One leaf is //restconf/config/someUri and the other is /restconf/config/anotherUri. What is the manipulation magic? Constructing /path/to/data/node based on YANG? That is the point of RESTCONF. There are already plenty of solutions for using REST APIs for ad-hoc data. I do not see any reason to develop RESTCONF for clients that want to ignore YANG. There are already have plenty of choices for that. > > It would appear to be sensible to add to the Restconf spec a URL > generation capability. I.e. have Restconf transform URIs into canonical > URLs. Thoughts? > Can you describe the solution you have in mind? > > 2. A URL to a data-model specific method > Suppose that the model was also defining an RPC, along the lines of the > "play" RPC in the Jukebox example. Now, as part of the song resource access > API, it would be natural to have such a method returned in a URL. That > would also be much more Resful than the currently implicit "/operations" > resource listing. > While it may be possible to use B. above to some degree, that is still > below par as it is not validated in the model. > Use of A. appears, to me at least, not possible since the RPC is not a > node. > Thus, is there a way to have Restconf return an RPC/services list for the > data? Eg: > > { > "songs": > [ > a list of songs, 1, 2, etc > ], > "rpc": > { > "play": [ "http://example.com/operations/example-jukebox:play"] > } > } > > The API already has /restconf/operations/. YANG is not object-oriented, so /restconf/config/routing/ is not how the RPC is defined. You are describing a proprietary extension. 3. Use of current() function as predicate in URIs/URLs > > It would be useful to be able to use the "current()" function to construct > URIs/URLs returned in Restconf. The spec does not make it clear on whether > this would actually work in A or B above. Would it, or is there some other > way? > > The URI is not an XPath expression. There are no predicates allowed, I don't think current() is allowed outside a predicate. > Thanks, > Wojciech. > > Andy --047d7bdc0ef0021bdf04ec52eb23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
Hello Restconf authors,

= I would like to ask a few questions and seek your thoughts on the topic of = URL representation in the API
Currently Yang allows two forms by which one could seek to have URI d= ata be represented in a model:

A.
leaf someUri {=
=A0=A0=A0 type instance-identifier;
//some Xpath express= ion to a node
}

B.
leaf anotherUri {
=A0=A0=A0 type y= ang:uri;
=A0=A0=A0 default "/my_uri/is/here"
}
Now, while the above is perhaps sufficient for some well known absol= ute paths, there appear to be a couple of problems in terms of=A0 a Restful= API:

1. Based on the current Restconf spec, both A and B above wh= en faced with a GET would appear to expose a URI, which the client would ha= ve to do some manipulation magic on it before use. What a Restful API would= be more likely to expose instead is a URL, eg in JSON:
{
<= div>=A0=A0=A0=A0"url" : "http://example.com/files/v1/documents/abc123"
}
<= div>

I do not understand the concern.
One leaf is //restconf/config/someUri and the other is /restconf/config/a= notherUri.
What is the manipulation magic? =A0Constructing /path/to/data/node bas= ed on YANG?
That is the point of RESTCONF. =A0There are already p= lenty of solutions for using
REST APIs for ad-hoc data. =A0I do n= ot see any reason to develop RESTCONF for
clients that want to ignore YANG. =A0There are already have plenty of = choices for that.

=A0

It would appear to be s= ensible to add to the Restconf spec a URL generation capability. I.e. have = Restconf transform URIs into canonical URLs. Thoughts?

Can you describe the solution = you have in mind?
=A0

2. A URL to a data-model specific method
Suppose th= at the model was also defining an RPC, along the lines of the "play&qu= ot; RPC in the Jukebox example. Now, as part of the song resource access AP= I, it would be natural to have such a method returned in a URL. That would = also be much more Resful than the currently implicit "/operations"= ; resource listing.
While it may be possible to use B. above to some degree, that is still belo= w par as it is not validated in the model.
Use of A. appears, to = me at least, not possible since the RPC is not a node.
Thus, is th= ere a way to have Restconf return an RPC/services list for the data? Eg:
{
=A0=A0=A0=A0"songs":
=A0=A0=A0=A0[
=A0=A0=A0=A0=A0=A0= =A0 a list of songs, 1, 2, etc
=A0= =A0=A0=A0],
=A0=A0=A0=A0"rpc":
=A0=A0=A0=A0{
=A0=A0=A0= =A0=A0=A0=A0=A0"play": [ &= quot;http://ex= ample.com/operations/example-jukebox:play"]
=A0=A0=A0=A0}
}


The API already has /r= estconf/operations/<YANG-rpc-name>.

YANG is = not object-oriented, so /restconf/config/routing/<RPC-name>
is not how the RPC is defined. =A0You are describing a proprietary
extension. =A0

3. Use of current() function as predicate in URIs/URLs

It would be useful to be able to use the "current()" f= unction to construct URIs/URLs returned in Restconf. The spec does not make= it clear on whether this would actually work in A or B above. Would it, or= is there some other way?



The URI is not an XPath expression. There are no predicates allowed,
I don't think current() is allowed outside a predicate.=A0
=A0
Than= ks,
Wojciech.


Andy

--047d7bdc0ef0021bdf04ec52eb23-- From wdec.ietf@gmail.com Fri Nov 29 08:00:39 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02E81AE141 for ; Fri, 29 Nov 2013 08:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zdus_93WNVxy for ; Fri, 29 Nov 2013 08:00:37 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB51AE0EE for ; Fri, 29 Nov 2013 08:00:36 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so14054043pde.34 for ; Fri, 29 Nov 2013 08:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tIRm6uSpDQAv6zlb5bSpWTarqr+Yhn7/qyr8REvLyE4=; b=G4eGlej5/4eXPir7kPZBB8EGUVFV6T8YNWUcz4Bqghd9Q7HRrN89+trh44nHeWyEXq 4lOxTdYVlJB/e92Bg5ywbgdXs+yeOo0e2E6/g43tgr9DJfAnKovHvd3lKaI3L2yjaoy3 9JNus+y1gQmUiQ16/UlXbUx53w6SW3LUxC/bhV4H/gWZ3/Rr0THb7HPOFqr0zUNZG8eO kEhI2y1QCc6Dycj+3sEM39OZs5FzeOJSfvBQdnxeD/1Ul9XA/wPiIKnyyh+0ycKCXW3d WZ6oB9RFSifOT1MMeovUu4q0RNYzTqPJ0RTMzsw6GdZfeS5KnqxP9VwaA7RM0AtP1CYr 24CA== MIME-Version: 1.0 X-Received: by 10.66.179.143 with SMTP id dg15mr53193749pac.52.1385740835855; Fri, 29 Nov 2013 08:00:35 -0800 (PST) Received: by 10.70.57.163 with HTTP; Fri, 29 Nov 2013 08:00:35 -0800 (PST) In-Reply-To: <20131129150257.GA95546@elstar.local> References: <20131129150257.GA95546@elstar.local> Date: Fri, 29 Nov 2013 17:00:35 +0100 Message-ID: From: Wojciech Dec To: Juergen Schoenwaelder , Wojciech Dec , draft-bierman-netconf-restconf@tools.ietf.org, Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=047d7bea3f6445a40304ec52eeab Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 16:00:40 -0000 --047d7bea3f6445a40304ec52eeab Content-Type: text/plain; charset=ISO-8859-1 On 29 November 2013 16:02, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Nov 29, 2013 at 03:01:36PM +0100, Wojciech Dec wrote: > > Hello Restconf authors, > > > > I would like to ask a few questions and seek your thoughts on the topic > of > > URL representation in the API > > Currently Yang allows two forms by which one could seek to have URI data > be > > represented in a model: > > > > A. > > leaf someUri { > > type instance-identifier; > > //some Xpath expression to a node > > } > > An instance-identifier is not a URI. > Granted, but http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#page-57 speaks about how it ends up being a URI, possibly a URL, in the context of Now, what is missing, or at least not clear to me, is how this data-type ends up being transformed into something more usable in a Rest context (IMO a canonical URL). And then the other bits and pieces 1-3 below. > > B. > > leaf anotherUri { > > type yang:uri; > > default "/my_uri/is/here" > > } > > > > Now, while the above is perhaps sufficient for some well known absolute > > paths, there appear to be a couple of problems in terms of a Restful > API: > > A path is not a URI either. It seems you are talking about some form of > paths but not URIs. > With Restconf, the Yang data-nodes are effectively being mapped to Restful resources, accessible via URLs. Putting URLs direlcty into the data model does not look right, so I'm looking at ways in which these URLs could be generated by Restconf. Cheers, Wojciech. > > That said, I may agree that having a hard-wired logic how URIs to > RESTful resources are constructed is somewhat unRESTful. It seems that > discovery of URIs for such resources is what people prefer. But of > course, the flexibility this allows comes at a price - you sometimes > neeed to do additional lookups. The good news is that HTTP is > providing decent caching support. > > > /js > > > 1. Based on the current Restconf spec, both A and B above when faced > with a > > GET would appear to expose a URI, which the client would have to do some > > manipulation magic on it before use. What a Restful API would be more > > likely to expose instead is a URL, eg in JSON: > > { > > "url" : "http://example.com/files/v1/documents/abc123" > > } > > > > It would appear to be sensible to add to the Restconf spec a URL > generation > > capability. I.e. have Restconf transform URIs into canonical URLs. > Thoughts? > > > > 2. A URL to a data-model specific method > > Suppose that the model was also defining an RPC, along the lines of the > > "play" RPC in the Jukebox example. Now, as part of the song resource > access > > API, it would be natural to have such a method returned in a URL. That > > would also be much more Resful than the currently implicit "/operations" > > resource listing. > > While it may be possible to use B. above to some degree, that is still > > below par as it is not validated in the model. > > Use of A. appears, to me at least, not possible since the RPC is not a > node. > > Thus, is there a way to have Restconf return an RPC/services list for the > > data? Eg: > > > > { > > "songs": > > [ > > a list of songs, 1, 2, etc > > ], > > "rpc": > > { > > "play": [ "http://example.com/operations/example-jukebox:play"] > > } > > } > > > > 3. Use of current() function as predicate in URIs/URLs > > > > It would be useful to be able to use the "current()" function to > construct > > URIs/URLs returned in Restconf. The spec does not make it clear on > whether > > this would actually work in A or B above. Would it, or is there some > other > > way? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7bea3f6445a40304ec52eeab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 29 November 2013 16:02, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote:
On Fri,= Nov 29, 2013 at 03:01:36PM +0100, Wojciech Dec wrote:
> Hello Restconf authors,
>
> I would like to ask a few questions and seek your thoughts on the topi= c of
> URL representation in the API
> Currently Yang allows two forms by which one could seek to have URI da= ta be
> represented in a model:
>
> A.
> leaf someUri {
> =A0 =A0 type instance-identifier;
> //some Xpath expression to a node
> }

An instance-identifier is not a URI.

<= div>Granted, but http://tools.ietf.org/html/draft-bierman-netconf-res= tconf-02#page-57 speaks about how it ends up being a URI, possibly a UR= L, in the context of
Now, what is missing, or=A0 at least not clear to me, is how thi= s data-type ends up being transformed into something more usable in a Rest = context (IMO a canonical URL). And then the other bits and pieces 1-3 below= .


> B.
> leaf anotherUri {
> =A0 =A0 type yang:uri;
> =A0 =A0 default "/my_uri/is/here"
> }
>
> Now, while the above is perhaps sufficient for some well known absolut= e
> paths, there appear to be a couple of problems in terms of =A0a Restfu= l API:

A path is not a URI either. It seems you are talking about some form = of
paths but not URIs.

With Restconf, the Yang data-n= odes are effectively being mapped to Restful resources, accessible via URLs= .
Putting URLs direlcty into the data model does not look right, so I&#= 39;m looking at ways in which these URLs could be generated by Restconf.
Cheers,
Wojciech.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
That said, I may agree that having a hard-wired logic how URIs to
RESTful resources are constructed is somewhat unRESTful. It seems that
discovery of URIs for such resources is what people prefer. But of
course, the flexibility this allows comes at a price - you sometimes
neeed to do additional lookups. The good news is that HTTP is
providing decent caching support.


=A0

/js

> 1. Based on the current Restconf spec, both A and B above when faced w= ith a
> GET would appear to expose a URI, which the client would have to do so= me
> manipulation magic on it before use. What a Restful API would be more<= br> > likely to expose instead is a URL, eg in JSON:
> {
> =A0 =A0 "url" : "http://example.com/files/v1/documents/= abc123"
> }
>
> It would appear to be sensible to add to the Restconf spec a URL gener= ation
> capability. I.e. have Restconf transform URIs into canonical URLs. Tho= ughts?
>
> 2. A URL to a data-model specific method
> Suppose that the model was also defining an RPC, along the lines of th= e
> "play" RPC in the Jukebox example. Now, as part of the song = resource access
> API, it would be natural to have such a method returned in a URL. That=
> would also be much more Resful than the currently implicit "/oper= ations"
> resource listing.
> While it may be possible to use B. above to some degree, that is still=
> below par as it is not validated in the model.
> Use of A. appears, to me at least, not possible since the RPC is not a= node.
> Thus, is there a way to have Restconf return an RPC/services list for = the
> data? Eg:
>
> {
> =A0 =A0 "songs":
> =A0 =A0 [
> =A0 =A0 =A0 =A0 a list of songs, 1, 2, etc
> =A0 =A0 ],
> =A0 =A0 "rpc":
> =A0 =A0 {
> =A0 =A0 =A0 =A0 "play": [ "http://example.com/ope= rations/example-jukebox:play"]
> =A0 =A0 }
> }
>
> 3. Use of current() function as predicate in URIs/URLs
>
> It would be useful to be able to use the "current()" functio= n to construct
> URIs/URLs returned in Restconf. The spec does not make it clear on whe= ther
> this would actually work in A or B above. Would it, or is there some o= ther
> way?

/js

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

--047d7bea3f6445a40304ec52eeab-- From andy@yumaworks.com Fri Nov 29 08:24:24 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291CA1ADFCE for ; Fri, 29 Nov 2013 08:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy0o2388Qx6Z for ; Fri, 29 Nov 2013 08:24:21 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id DB1FA1AD738 for ; Fri, 29 Nov 2013 08:24:20 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id w5so2002611qac.6 for ; Fri, 29 Nov 2013 08:24:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yhg4blF8kv13kYj2jyFpv4e/odkJ2lfSBAwuwMpao2c=; b=SWmF0+lz0EHTCeuEWyrYqjUyJtYfDMWFG+RsEfS1f3OwP5oo8nxMFH6nnDa9uqFKL+ vDZZLrK2RApAy93OGa8L3gqnFhKx6Phaa8REcNSEjAYjZGnlT16ZxFVplPTOyeR0Tusb a8I1NAkhir5eGNLNaZXvLQBZp0+luwjQ3/eh9URGcDc4C/wRCS0080NEbjUJkIaSEIWG MwyGIvjgClaUyb3O4+9Sofj7xaapU/gmZRqESD+wvmUGbchS+J7qc0BFtgpirkZCJ8OS /p/faqFIA4MLastvu9OQSF1XKJT3sM4rJswyaQ4V+PVBh/8oG5aqL/yNELW7vXFASfwY Fl+Q== X-Gm-Message-State: ALoCoQmfdsVQj9gqT1fyORFJJScm7UZdBqIlZ1kbZLjtQd4PIa87vDT5uV+XMYNGs1snW16LAWmA MIME-Version: 1.0 X-Received: by 10.49.108.165 with SMTP id hl5mr88100093qeb.24.1385742259484; Fri, 29 Nov 2013 08:24:19 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 29 Nov 2013 08:24:19 -0800 (PST) In-Reply-To: References: <20131129150257.GA95546@elstar.local> Date: Fri, 29 Nov 2013 08:24:19 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7bdc0d122090c604ec534391 Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 16:24:24 -0000 --047d7bdc0d122090c604ec534391 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 29, 2013 at 8:00 AM, Wojciech Dec wrote: > > > > On 29 November 2013 16:02, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Fri, Nov 29, 2013 at 03:01:36PM +0100, Wojciech Dec wrote: >> > Hello Restconf authors, >> > >> > I would like to ask a few questions and seek your thoughts on the topic >> of >> > URL representation in the API >> > Currently Yang allows two forms by which one could seek to have URI >> data be >> > represented in a model: >> > >> > A. >> > leaf someUri { >> > type instance-identifier; >> > //some Xpath expression to a node >> > } >> >> An instance-identifier is not a URI. >> > > Granted, but > http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#page-57speaks about how it ends up being a URI, possibly a URL, in the context of > Now, what is missing, or at least not clear to me, is how this data-type > ends up being transformed into something more usable in a Rest context (IMO > a canonical URL). And then the other bits and pieces 1-3 below. > > There is a canonical UR for a data resource returned in the Location header when a resource is created. The URI path is constructed. First the client needs to know the URL to the predicable datastore http://server.example.com/restconf/config Datastore resources can only have data resources as child nodes. The URI for the data node is concatenated to the URI for the datastore. >> > B. >> > leaf anotherUri { >> > type yang:uri; >> > default "/my_uri/is/here" >> > } >> > >> > Now, while the above is perhaps sufficient for some well known absolute >> > paths, there appear to be a couple of problems in terms of a Restful >> API: >> >> A path is not a URI either. It seems you are talking about some form of >> paths but not URIs. >> > > With Restconf, the Yang data-nodes are effectively being mapped to Restful > resources, accessible via URLs. > Putting URLs direlcty into the data model does not look right, so I'm > looking at ways in which these URLs could be generated by Restconf. > > The co-authors have discussed a retrieval mode to have the URL of the data nodes returned. The client can currently use the query parameter "depth=2" to discover just the child nodes of the entry point, and walk the tree just as they would retrieving meta-data instead. The problem with always returning these URLs is that the size of the replies goes up by 8 or 10 fold. Cheers, > Wojciech. > > Andy > >> That said, I may agree that having a hard-wired logic how URIs to >> RESTful resources are constructed is somewhat unRESTful. It seems that >> discovery of URIs for such resources is what people prefer. But of >> course, the flexibility this allows comes at a price - you sometimes >> neeed to do additional lookups. The good news is that HTTP is >> providing decent caching support. >> > > > > >> >> /js >> >> > 1. Based on the current Restconf spec, both A and B above when faced >> with a >> > GET would appear to expose a URI, which the client would have to do some >> > manipulation magic on it before use. What a Restful API would be more >> > likely to expose instead is a URL, eg in JSON: >> > { >> > "url" : "http://example.com/files/v1/documents/abc123" >> > } >> > >> > It would appear to be sensible to add to the Restconf spec a URL >> generation >> > capability. I.e. have Restconf transform URIs into canonical URLs. >> Thoughts? >> > >> > 2. A URL to a data-model specific method >> > Suppose that the model was also defining an RPC, along the lines of the >> > "play" RPC in the Jukebox example. Now, as part of the song resource >> access >> > API, it would be natural to have such a method returned in a URL. That >> > would also be much more Resful than the currently implicit "/operations" >> > resource listing. >> > While it may be possible to use B. above to some degree, that is still >> > below par as it is not validated in the model. >> > Use of A. appears, to me at least, not possible since the RPC is not a >> node. >> > Thus, is there a way to have Restconf return an RPC/services list for >> the >> > data? Eg: >> > >> > { >> > "songs": >> > [ >> > a list of songs, 1, 2, etc >> > ], >> > "rpc": >> > { >> > "play": [ "http://example.com/operations/example-jukebox:play"] >> > } >> > } >> > >> > 3. Use of current() function as predicate in URIs/URLs >> > >> > It would be useful to be able to use the "current()" function to >> construct >> > URIs/URLs returned in Restconf. The spec does not make it clear on >> whether >> > this would actually work in A or B above. Would it, or is there some >> other >> > way? >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > > --047d7bdc0d122090c604ec534391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 29, 2013 at 8:00 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:



On 29 November 2013 16:02, Juergen S= choenwaelder <j.schoenwaelder@jacobs-university.de&= gt; wrote:
On Fri, Nov 29, 2013= at 03:01:36PM +0100, Wojciech Dec wrote:
> Hello Restconf authors,
>
> I would like to ask a few questions and seek your thoughts on the topi= c of
> URL representation in the API
> Currently Yang allows two forms by which one could seek to have URI da= ta be
> represented in a model:
>
> A.
> leaf someUri {
> =A0 =A0 type instance-identifier;
> //some Xpath expression to a node
> }

An instance-identifier is not a URI.

<= div>Granted, but http://tools.ietf.org/html/draft-b= ierman-netconf-restconf-02#page-57 speaks about how it ends up being a = URI, possibly a URL, in the context of
Now, what is missing, or=A0 at least not clear to me, is how thi= s data-type ends up being transformed into something more usable in a Rest = context (IMO a canonical URL). And then the other bits and pieces 1-3 below= .


There is a canonical UR for a data resource returned in the Loc= ation header
when a resource is created. =A0The URI path is const= ructed. =A0First the client
needs to know the URL to the predicable datastore=A0


Datastore = resources can only have data resources as child nodes.
The URI for the data node is concatenated to the URI for the datastore= .



> B.
> leaf anotherUri {
> =A0 =A0 type yang:uri;
> =A0 =A0 default "/my_uri/is/here"
> }
>
> Now, while the above is perhaps sufficient for some well known absolut= e
> paths, there appear to be a couple of problems in terms of =A0a Restfu= l API:

A path is not a URI either. It seems you are talking about some form = of
paths but not URIs.

With Restconf, the Yang data-n= odes are effectively being mapped to Restful resources, accessible via URLs= .
Putting URLs direlcty into the data model does not look right, so I&#= 39;m looking at ways in which these URLs could be generated by Restconf.

The co-authors= have discussed a retrieval mode to have the URL of the data nodes returned= .
The client can currently use the query parameter =A0"depth= =3D2" to discover just the child nodes
of the entry point, and walk the tree just as they would retrieving me= ta-data instead.

The problem with always returning= these URLs is that the size of the replies goes up
by 8 or 10 fo= ld.


Ch= eers,
Wojciech.
=A0



Andy
=A0

That said, I may agree that having a hard-wired logic how URIs to
RESTful resources are constructed is somewhat unRESTful. It seems that
discovery of URIs for such resources is what people prefer. But of
course, the flexibility this allows comes at a price - you sometimes
neeed to do additional lookups. The good news is that HTTP is
providing decent caching support.


=A0

/js

> 1. Based on the current Restconf spec, both A and B above when faced w= ith a
> GET would appear to expose a URI, which the client would have to do so= me
> manipulation magic on it before use. What a Restful API would be more<= br> > likely to expose instead is a URL, eg in JSON:
> {
> =A0 =A0 "url" : "http://example.com/files/v1/documents/= abc123"
> }
>
> It would appear to be sensible to add to the Restconf spec a URL gener= ation
> capability. I.e. have Restconf transform URIs into canonical URLs. Tho= ughts?
>
> 2. A URL to a data-model specific method
> Suppose that the model was also defining an RPC, along the lines of th= e
> "play" RPC in the Jukebox example. Now, as part of the song = resource access
> API, it would be natural to have such a method returned in a URL. That=
> would also be much more Resful than the currently implicit "/oper= ations"
> resource listing.
> While it may be possible to use B. above to some degree, that is still=
> below par as it is not validated in the model.
> Use of A. appears, to me at least, not possible since the RPC is not a= node.
> Thus, is there a way to have Restconf return an RPC/services list for = the
> data? Eg:
>
> {
> =A0 =A0 "songs":
> =A0 =A0 [
> =A0 =A0 =A0 =A0 a list of songs, 1, 2, etc
> =A0 =A0 ],
> =A0 =A0 "rpc":
> =A0 =A0 {
> =A0 =A0 =A0 =A0 "play": [ "http://example.com/ope= rations/example-jukebox:play"]
> =A0 =A0 }
> }
>
> 3. Use of current() function as predicate in URIs/URLs
>
> It would be useful to be able to use the "current()" functio= n to construct
> URIs/URLs returned in Restconf. The spec does not make it clear on whe= ther
> this would actually work in A or B above. Would it, or is there some o= ther
> way?

/js

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


--047d7bdc0d122090c604ec534391-- From wdec.ietf@gmail.com Fri Nov 29 09:33:03 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98E51AD73F for ; Fri, 29 Nov 2013 09:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be39LibgzzUU for ; Fri, 29 Nov 2013 09:33:01 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9221AD73E for ; Fri, 29 Nov 2013 09:33:01 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id y13so14219176pdi.33 for ; Fri, 29 Nov 2013 09:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RsfJy5Pv2h3f2Nq/0ivfbUPoQ0U1mUEP6mB4Ij+O6Gw=; b=EU6wI9ycQTR9uzIaQOwXxzxyhyqmcsD+ewC9yzTCYA9AjiIVR5WGWE1El6ATzvkAoa YOu6NxWoiYGpiQ2J3t7868q5VHwaQ57li4G3UnupAp8EOG1LEwFNG7Cv/wiwM432VXW7 728mhiaELUx8GdhX9r6Y0pHxmRQxgBlu7QlkWSIdyT4neHEbaC/kBgVvvzcJlHL4m37r tVlrz30R1ifWJYdZVadWMh9VkNsht4STTUrUxX1dr04jIP8JGLj0+hVUB0rKu6uGn95m odpqXHyt70c3Zi11qJ976epRsNcxnnlV4H2xJODrgmHniipW3g3VL4txbr9mV+w8RgZO s7Lg== MIME-Version: 1.0 X-Received: by 10.68.245.227 with SMTP id xr3mr4435537pbc.182.1385746380423; Fri, 29 Nov 2013 09:33:00 -0800 (PST) Received: by 10.70.57.163 with HTTP; Fri, 29 Nov 2013 09:33:00 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 18:33:00 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 17:33:04 -0000 On 29 November 2013 16:59, Andy Bierman wrote: > > > > > On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec wrote= : >> >> Hello Restconf authors, >> >> I would like to ask a few questions and seek your thoughts on the topic = of URL representation in the API >> Currently Yang allows two forms by which one could seek to have URI data= be represented in a model: >> >> A. >> leaf someUri { >> type instance-identifier; >> //some Xpath expression to a node >> } >> >> B. >> leaf anotherUri { >> type yang:uri; >> default "/my_uri/is/here" >> } >> >> Now, while the above is perhaps sufficient for some well known absolute = paths, there appear to be a couple of problems in terms of a Restful API: >> >> 1. Based on the current Restconf spec, both A and B above when faced wit= h a GET would appear to expose a URI, which the client would have to do som= e manipulation magic on it before use. What a Restful API would be more lik= ely to expose instead is a URL, eg in JSON: >> { >> "url" : "http://example.com/files/v1/documents/abc123" >> } > > > > I do not understand the concern. > One leaf is //restconf/config/someUri and the other is /restconf/config/a= notherUri. > What is the manipulation magic? Constructing /path/to/data/node based on= YANG? Well, so two "magical manipulation" pieces appear to be: i) The adding of the "/restconf/config/" path part. ii) Actually making a URL out of this. Neither of these appears to have to do with Yang as such. > > That is the point of RESTCONF. There are already plenty of solutions for= using > REST APIs for ad-hoc data. I do not see any reason to develop RESTCONF f= or > clients that want to ignore YANG. There are already have plenty of choic= es for that. Uhm, does RESTCONF requires a special client to be used? I.e. one having special behaviour/capabilities defined in the restconf spec. Personally, i see the construction of the REST APIs by the server, based on the Yang model as the major point of Restconf, irrespective of what the client side has. That in itself is a big plus. Naturally a client is free to "share" a model with the server, should one choose that approach - but it's not a must as the server's Resful API provides a contract, in this case data model driven. > > > >> >> >> It would appear to be sensible to add to the Restconf spec a URL generat= ion capability. I.e. have Restconf transform URIs into canonical URLs. Thou= ghts? > > > Can you describe the solution you have in mind? Let's use an ad-hoc modified jukebox as an example: container jukebox { container library { list artist { key name; leaf name { type string; } list album { key name; leaf-list influences { type instance-identifier; //For lack of a better choice } } } } } Now, suppose foobar_artist1, 2 and 3 are there, with 2 and 3 being put in as influnces for 1. when doing a GET to http://example.com/restconf/config/example:jukebox/library/artist/foobar_ar= tist1 The entries on the influences list would end up being shown via Restconf in JSON as URLs, ie: { ...some album... "influences" : [ "url" : "http://example.com/restconf/config/example:jukebox/library/fo= obar_artist2", "url" : "http://example.com/restconf/config/example:jukebox/library/fo= obar_artist3" ] } Other variations can also be made, including the of having Restconf making all 2nd level elements be served up as URLs instead of detail, which would be a good idea overall, but one would still like the ability to just have a URL reference when needed. > > >> >> >> 2. A URL to a data-model specific method >> Suppose that the model was also defining an RPC, along the lines of the = "play" RPC in the Jukebox example. Now, as part of the song resource access= API, it would be natural to have such a method returned in a URL. That wou= ld also be much more Resful than the currently implicit "/operations" resou= rce listing. >> While it may be possible to use B. above to some degree, that is still b= elow par as it is not validated in the model. >> Use of A. appears, to me at least, not possible since the RPC is not a n= ode. >> Thus, is there a way to have Restconf return an RPC/services list for th= e data? Eg: >> >> { >> "songs": >> [ >> a list of songs, 1, 2, etc >> ], >> "rpc": >> { >> "play": [ "http://example.com/operations/example-jukebox:play"] >> } >> } >> > > The API already has /restconf/operations/. > > YANG is not object-oriented, so /restconf/config/routing/ > is not how the RPC is defined. You are describing a proprietary > extension. Well, typo aside*, as I said above the point is to have the API return a link to the rpc operations applicable to the data. In other words, either in the data model or in the API spec it should be possible to convey to the client the RPCs that are there. The fact that it is there under /restconf/operations/ is cool, but it's not sufficent to a restful client. Granted, one could make these some part of a own Restconf implementation, but this is actually something that would appear to be worthy of the spec. * Corrected "play": "http://example.com/restconf/operations/example-jukebox:play" > >> 3. Use of current() function as predicate in URIs/URLs >> >> It would be useful to be able to use the "current()" function to constru= ct URIs/URLs returned in Restconf. The spec does not make it clear on wheth= er this would actually work in A or B above. Would it, or is there some oth= er way? >> > > > The URI is not an XPath expression. There are no predicates allowed, > I don't think current() is allowed outside a predicate. Yes, but the current instance-identifier is an XPath expression. However, I have not found any examples of current() being used in there though (and few examples of any use with an xpath expression at all). Would assuming that the instance-identifier gets munged to/from a URI by Restconf, be then sufficient? Wojciech. > > >> >> Thanks, >> Wojciech. >> > > Andy > From andy@yumaworks.com Fri Nov 29 10:07:25 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4C11AE15B for ; Fri, 29 Nov 2013 10:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCDL6ZEApLFm for ; Fri, 29 Nov 2013 10:07:22 -0800 (PST) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id A0A051AE119 for ; Fri, 29 Nov 2013 10:07:22 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id w7so10501845qeb.8 for ; Fri, 29 Nov 2013 10:07:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sbRxm+pz32HtWb9lyWl8sPdrK9gwVKma5YwypC6eqj0=; b=C1CONcZEx7CBPs0Zs9eYX+JIf3GMjjLKrqPGSpvjCeXUc10/xiD0Pc4TM54SbZycBs QRn8IJh3QUgphk2PGVO5g9JXFg0QmmMNFzOd2H6izNlwk2Fl93Lig6h8JmGpfPSlhEk5 bIPQlTG/bFv8473Hqh/RfNu5iXrKuRLmLP30ed6C5taxeSgV3lzdvHFgRmFdxH0OzVWR wvnYJTBZ+lUA/e+CmnMVqfN1GNwzoF4Lx32Tdd6kPMXC/OJLg14wxzq1bOCon83pfTCj SFZnBXrKVH1A6md5ObPZ1bLAsVtc0WUMnPdMfvvmwk2q3fqoQfGLmxxMwLgGysDv06Nw l87Q== X-Gm-Message-State: ALoCoQkmaf2AIaOjTTegTb0AuvNmrGvdBYdGiaP+vMrdvoCVwyCyqcg4tDTaaFozJTGfRyjNpiUm MIME-Version: 1.0 X-Received: by 10.224.51.74 with SMTP id c10mr54313989qag.7.1385748441164; Fri, 29 Nov 2013 10:07:21 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 29 Nov 2013 10:07:21 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 10:07:21 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=089e0158cb5495827204ec54b31a Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:07:26 -0000 --089e0158cb5495827204ec54b31a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 29, 2013 at 9:33 AM, Wojciech Dec wrote: > On 29 November 2013 16:59, Andy Bierman wrote: > > > > > > > > > > On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec > wrote: > >> > >> Hello Restconf authors, > >> > >> I would like to ask a few questions and seek your thoughts on the topic > of URL representation in the API > >> Currently Yang allows two forms by which one could seek to have URI > data be represented in a model: > >> > >> A. > >> leaf someUri { > >> type instance-identifier; > >> //some Xpath expression to a node > >> } > >> > >> B. > >> leaf anotherUri { > >> type yang:uri; > >> default "/my_uri/is/here" > >> } > >> > >> Now, while the above is perhaps sufficient for some well known absolute > paths, there appear to be a couple of problems in terms of a Restful API: > >> > >> 1. Based on the current Restconf spec, both A and B above when faced > with a GET would appear to expose a URI, which the client would have to do > some manipulation magic on it before use. What a Restful API would be more > likely to expose instead is a URL, eg in JSON: > >> { > >> "url" : "http://example.com/files/v1/documents/abc123" > >> } > > > > > > > > I do not understand the concern. > > One leaf is //restconf/config/someUri and the other is > /restconf/config/anotherUri. > > What is the manipulation magic? Constructing /path/to/data/node based > on YANG? > > > Well, so two "magical manipulation" pieces appear to be: > i) The adding of the "/restconf/config/" path part. > ii) Actually making a URL out of this. > > Neither of these appears to have to do with Yang as such. > > > > > That is the point of RESTCONF. There are already plenty of solutions > for using > > REST APIs for ad-hoc data. I do not see any reason to develop RESTCONF > for > > clients that want to ignore YANG. There are already have plenty of > choices for that. > > > Uhm, does RESTCONF requires a special client to be used? I.e. one > having special behaviour/capabilities defined in the restconf spec. > Personally, i see the construction of the REST APIs by the server, > based on the Yang model as the major point of Restconf, irrespective > of what the client side has. That in itself is a big plus. > Naturally a client is free to "share" a model with the server, should > one choose that approach - but it's not a must as the server's Resful > API provides a contract, in this case data model driven. > > It does not need a special client, but clients that know nothing about the data they are using can do little more than render it as valid XML or JSON. A client could be hard-wired based on media type, and not use YANG. I am not against a retrieval mode where the client retrieves the full Location header line for the target resource. The server could return the Location header for the target resource every GET (and make every reply that much bigger). These are the sorts of engineering trade-offs the WG decides by consensus. > > > > > > > >> > >> > >> It would appear to be sensible to add to the Restconf spec a URL > generation capability. I.e. have Restconf transform URIs into canonical > URLs. Thoughts? > > > > > > Can you describe the solution you have in mind? > > > Let's use an ad-hoc modified jukebox as an example: > > container jukebox { > container library { > list artist { > key name; > leaf name { > type string; > } > > list album { > key name; > > leaf-list influences { > > type instance-identifier; //For lack of a better choice > } > } > } > } > } > > Now, suppose foobar_artist1, 2 and 3 are there, with 2 and 3 being put > in as influnces for 1. when doing a GET to > > http://example.com/restconf/config/example:jukebox/library/artist/foobar_artist1 > > The entries on the influences list would end up being shown via > Restconf in JSON as URLs, ie: > > > { ...some album... > "influences" : [ > "url" : " > http://example.com/restconf/config/example:jukebox/library/foobar_artist2 > ", > "url" : " > http://example.com/restconf/config/example:jukebox/library/foobar_artist3" > ] > } > > You wouldn't use YANG instance-identifier if you wanted this format. Use the data-resource-identifier typedef instead. But I see your point. The description-stmt says start with the doc-root, not a full URI. I agree the server needs to accept a full URI or a path string, and always return the full URI as the canonical format. Also, this is not the correct encoding: A leaf-list maps to a a JSON array of the leaf-list type. leaf-list influences { type data-resource-identifier; } { "influences" : [ " http://example.com/restconf/config/example:jukebox/library/foobar_artist2", " http://example.com/restconf/config/example:jukebox/library/foobar_artist3" ] } Other variations can also be made, including the of having Restconf > making all 2nd level elements be served up as URLs instead of detail, > which would be a good idea overall, but one would still like the > ability to just have a URL reference when needed. > > > > > > >> > >> > >> 2. A URL to a data-model specific method > >> Suppose that the model was also defining an RPC, along the lines of the > "play" RPC in the Jukebox example. Now, as part of the song resource access > API, it would be natural to have such a method returned in a URL. That > would also be much more Resful than the currently implicit "/operations" > resource listing. > >> While it may be possible to use B. above to some degree, that is still > below par as it is not validated in the model. > >> Use of A. appears, to me at least, not possible since the RPC is not a > node. > >> Thus, is there a way to have Restconf return an RPC/services list for > the data? Eg: > >> > >> { > >> "songs": > >> [ > >> a list of songs, 1, 2, etc > >> ], > >> "rpc": > >> { > >> "play": [ "http://example.com/operations/example-jukebox:play"] > >> } > >> } > >> > > > > The API already has /restconf/operations/. > > > > YANG is not object-oriented, so /restconf/config/routing/ > > is not how the RPC is defined. You are describing a proprietary > > extension. > > > Well, typo aside*, as I said above the point is to have the API return > a link to the rpc operations applicable to the data. In other words, > either in the data model or in the API spec it should be possible to > convey to the client the RPCs that are there. The fact that it is > there under /restconf/operations/ is cool, but it's not > sufficent to a restful client. Granted, one could make these some part > of a own Restconf implementation, but this is actually something that > would appear to be worthy of the spec. > > * Corrected > "play": "http://example.com/restconf/operations/example-jukebox:play" > > This seems to be outside the scope of plain REST. There is no point in POSTing data with no idea what input parameters are required. Retrieving and editing resources with CRUD operations is fine, but the client needs to know the YANG rpc definitions in order to use custom operation resources. They are optional for the server to support. > > >> 3. Use of current() function as predicate in URIs/URLs > >> > >> It would be useful to be able to use the "current()" function to > construct URIs/URLs returned in Restconf. The spec does not make it clear > on whether this would actually work in A or B above. Would it, or is there > some other way? > >> > > > > > > The URI is not an XPath expression. There are no predicates allowed, > > I don't think current() is allowed outside a predicate. > > > Yes, but the current instance-identifier is an XPath expression. > However, I have not found any examples of current() being used in > there though (and few examples of any use with an xpath expression at > all). Would assuming that the instance-identifier gets munged to/from > a URI by Restconf, be then sufficient? > > The current() function is not even allowed in an instance-identifier. It is very restricted subset of an XPath absolute-path-expr. A data-resource-identifier is a URL-encoded path string with the list keys inserted as path components. Wojciech. > Andy --089e0158cb5495827204ec54b31a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 29, 2013 at 9:33 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
On 29 November 2013 16:59, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
>
> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>>
>> Hello Restconf authors,
>>
>> I would like to ask a few questions and seek your thoughts on the = topic of URL representation in the API
>> Currently Yang allows two forms by which one could seek to have UR= I data be represented in a model:
>>
>> A.
>> leaf someUri {
>> =A0 =A0 type instance-identifier;
>> //some Xpath expression to a node
>> }
>>
>> B.
>> leaf anotherUri {
>> =A0 =A0 type yang:uri;
>> =A0 =A0 default "/my_uri/is/here"
>> }
>>
>> Now, while the above is perhaps sufficient for some well known abs= olute paths, there appear to be a couple of problems in terms of =A0a Restf= ul API:
>>
>> 1. Based on the current Restconf spec, both A and B above when fac= ed with a GET would appear to expose a URI, which the client would have to = do some manipulation magic on it before use. What a Restful API would be mo= re likely to expose instead is a URL, eg in JSON:
>> {
>> =A0 =A0 "url" : "http://example.com/files/v1/docume= nts/abc123"
>> }
>
>
>
> I do not understand the concern.
> One leaf is //restconf/config/someUri and the other is /restconf/confi= g/anotherUri.
> What is the manipulation magic? =A0Constructing /path/to/data/node bas= ed on YANG?


Well, so two "magical manipulation" pieces appear to be:
i) The adding of the "/restconf/config/" path part.
ii) Actually making a URL out of this.

Neither of these appears to have to do with Yang as such.

>
> That is the point of RESTCONF. =A0There are already plenty of solution= s for using
> REST APIs for ad-hoc data. =A0I do not see any reason to develop RESTC= ONF for
> clients that want to ignore YANG. =A0There are already have plenty of = choices for that.


Uhm, does RESTCONF requires a special client to be used? I.e. one
having special behaviour/capabilities defined in the restconf spec.
Personally, i see the construction of the REST APIs by the server,
based on the Yang model as the major point of Restconf, irrespective
of what the client side has. That in itself is a big plus.
Naturally a client is free to "share" a model with the server, sh= ould
one choose that approach - but it's not a must as the server's Resf= ul
API provides a contract, in this case data model driven.



It does not need a spec= ial client, but clients that know nothing about the data
they are= using can do little more than render it as valid XML or JSON. =A0A client = could
be hard-wired based on media type, and not use YANG.

I am not against a retrieval mode where the client retrieves the fu= ll Location
header line for the target resource. The server could= return the Location
header for the target resource every GET (and make every reply that mu= ch bigger).
These are the sorts of engineering trade-offs the WG = decides by consensus.

=A0
>
>
>
>>
>>
>> It would appear to be sensible to add to the Restconf spec a URL g= eneration capability. I.e. have Restconf transform URIs into canonical URLs= . Thoughts?
>
>
> Can you describe the solution you have in mind?


Let's use an ad-hoc modified jukebox as an example:

container jukebox {
=A0 =A0 =A0 =A0 container library {
=A0 =A0 =A0 =A0 =A0 list artist {
=A0 =A0 =A0 =A0 =A0 =A0 key name;
=A0 =A0 =A0 =A0 =A0 =A0 leaf name {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 =A0 =A0 =A0 }

=A0 =A0 =A0 =A0 =A0 =A0 list album {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 key name;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf-list influences {

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type instance-identifier; //For lack of a b= etter choice
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0}
}

Now, suppose foobar_artist1, 2 and 3 are there, with 2 and 3 being put
in as influnces for 1. when doing a GET to
http://example.com/restconf/config/exam= ple:jukebox/library/artist/foobar_artist1

The entries on the influences list would end up being shown via
Restconf in JSON as URLs, ie:


{ ...some album...
"influences" : [
=A0 =A0 =A0"url" : "http://exam= ple.com/restconf/config/example:jukebox/library/foobar_artist2", =A0 =A0 =A0"url" : "http://exam= ple.com/restconf/config/example:jukebox/library/foobar_artist3" =A0 =A0 =A0 ]
}



You wouldn't use YA= NG instance-identifier if you wanted this format.
Use the data-re= source-identifier typedef instead.

But I see your = point. =A0The description-stmt says start with the doc-root, not a full URI= .
I agree the server needs to accept a full URI or a path string, and al= ways return
the full URI as the canonical format.=A0
Also, this is not the correct encoding:
A leaf-list = maps to a a JSON array of the leaf-list type.

leaf-list influences {
=A0 =A0type data-resou= rce-identifier;
}

{
=


Other variations can also be made, including the of having Restconf
making all 2nd level elements be served up as URLs instead of detail,
which would be a good idea overall, but one would still like the
ability to just have a URL reference when needed.

>
>
>>
>>
>> 2. A URL to a data-model specific method
>> Suppose that the model was also defining an RPC, along the lines o= f the "play" RPC in the Jukebox example. Now, as part of the song= resource access API, it would be natural to have such a method returned in= a URL. That would also be much more Resful than the currently implicit &qu= ot;/operations" resource listing.
>> While it may be possible to use B. above to some degree, that is s= till below par as it is not validated in the model.
>> Use of A. appears, to me at least, not possible since the RPC is n= ot a node.
>> Thus, is there a way to have Restconf return an RPC/services list = for the data? Eg:
>>
>> {
>> =A0 =A0 "songs":
>> =A0 =A0 [
>> =A0 =A0 =A0 =A0 a list of songs, 1, 2, etc
>> =A0 =A0 ],
>> =A0 =A0 "rpc":
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 "play": [ "http://example.com= /operations/example-jukebox:play"]
>> =A0 =A0 }
>> }
>>
>
> The API already has /restconf/operations/<YANG-rpc-name>.
>
> YANG is not object-oriented, so /restconf/config/routing/<RPC-name&= gt;
> is not how the RPC is defined. =A0You are describing a proprietary
> extension.


Well, typo aside*, as I said above the point is to have the API return
a link to the rpc operations applicable to the data. In other words,
either in the data model or in the API spec it should be possible to
convey to the client the RPCs that are there. The fact that it is
there under /restconf/operations/<name> is cool, but it's not
sufficent to a restful client. Granted, one could make these some part
of a own Restconf implementation, but this is actually something that
would appear to be worthy of the spec.

* Corrected
"play": "http://example.com/restconf/operatio= ns/example-jukebox:play"


This seems to be outside the scope of = plain REST.
There is no point in POSTing data with no idea
<= div>what input parameters are required. =A0Retrieving and
editing= resources with CRUD operations is fine,
but the client needs to know the YANG rpc definitions
in ord= er to use custom operation resources. =A0They are optional
for th= e server to support.


>
>> 3. Use of current() function as predicate in URIs/URLs
>>
>> It would be useful to be able to use the "current()" fun= ction to construct URIs/URLs returned in Restconf. The spec does not make i= t clear on whether this would actually work in A or B above. Would it, or i= s there some other way?
>>
>
>
> The URI is not an XPath expression. There are no predicates allowed, > I don't think current() is allowed outside a predicate.


Yes, but the current instance-identifier is an XPath expression.
However, I have not found any examples of current() being used in
there though (and few examples of any use with an xpath expression at
all). Would assuming that the instance-identifier gets munged to/from
a URI by Restconf, be then sufficient?


The current() function is not even all= owed in an instance-identifier.
It is very restricted subset of a= n XPath =A0absolute-path-expr.
A data-resource-identifier is a UR= L-encoded path string with the list keys
inserted as path components.


Wojciech.

Andy
=A0
--089e0158cb5495827204ec54b31a--