From nobody Tue Apr 1 12:12:01 2014 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 D620E1A09EA for ; Tue, 1 Apr 2014 12:11:58 -0700 (PDT) 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 kuLqy_FZi__g for ; Tue, 1 Apr 2014 12:11:53 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8131C1A09C0 for ; Tue, 1 Apr 2014 12:11:53 -0700 (PDT) Received: from mail180-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 1 Apr 2014 19:11:49 +0000 Received: from mail180-va3 (localhost [127.0.0.1]) by mail180-va3-R.bigfish.com (Postfix) with ESMTP id 64C003804BA; Tue, 1 Apr 2014 19:11:49 +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: -4 X-BigFish: VPS-4(zz1432I4015I168aJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail180-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=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(199002)(57704003)(189002)(51704005)(93136001)(94316002)(97186001)(93516002)(83506001)(95416001)(86362001)(94946001)(95666003)(97336001)(36756003)(4396001)(47736001)(81686001)(81816001)(47976001)(49866001)(99396002)(80976001)(50986001)(77096001)(76786001)(76176001)(76796001)(83322001)(99286001)(74662001)(66066001)(46102001)(98676001)(74502001)(47446002)(80022001)(65816001)(81342001)(79102001)(87266001)(81542001)(74366001)(92726001)(85306002)(31966008)(92566001)(20776003)(63696002)(69226001)(74706001)(83072002)(76482001)(90146001)(85852003)(56776001)(87936001)(2656002)(54316002)(59766001)(74876001)(77982001)(51856001)(53806001)(56816005)(54356001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:E610D015.8FF29103.AFE13F48.86C59F29.20584; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail180-va3 (localhost.localdomain [127.0.0.1]) by mail180-va3 (MessageSwitch) id 1396379506789689_26133; Tue, 1 Apr 2014 19:11:46 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.239]) by mail180-va3.bigfish.com (Postfix) with ESMTP id BA57520053; Tue, 1 Apr 2014 19:11:46 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 1 Apr 2014 19:11:46 +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.435.0; Tue, 1 Apr 2014 19:11:45 +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.898.11; Tue, 1 Apr 2014 19:11:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.69]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.69]) with mapi id 15.00.0908.008; Tue, 1 Apr 2014 19:11:42 +0000 From: Kent Watsen To: "Bajpai, Vaibhav" , "netconf@ietf.org" Thread-Topic: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] Thread-Index: AQHPTd43lQun1SgDxEC8DWvUeTyr9w== Date: Tue, 1 Apr 2014 19:11:42 +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.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 016885DD9B 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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9Mb1-M1iDb-LWR5mv_DDPR4msjw Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] 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, 01 Apr 2014 19:11:59 -0000 Hi Vaibhav and Radek, My responses to your issues are below. BTW, congratulations on having the first TLS-based NETCONF call-home implementation that I'm aware of. Did you use the current "netconf-server" configuration format for input? Best, Kent >Issue #1 >-------- > >- How to handle ssh host key verification when multiple hosts are behind a > NAT? - This is probably implementation specific. It depends how an SSH >client stores hosts keys. We thought to share this issue along anyway. This is for SSH? The Reverse-SSH draft describes options that don't rely on IP addresses specifically to support NAT cases. Whether forward or reverse, the same applies. >Issue #2 >-------- > >- How to handle TLS certificate hostname verification when multiple hosts >are > behind a NAT? - Similar to #1. The NMS should have some kind of >pre-defined >knowledge, that the hostname is correct (expected for the certificate). >Maybe >this can be mentioned more explicitely in the NETCONF over TLS text. The Reverse SSH draft also speaks to this too, recommending that the device's certificate encode a unique identifier (e.g., serial-number). But to remove the burden from the NMS, the device-vendor SHOULD ship their device's from factory with this certificate pre-installed. This certificate SHOULD be signed by a chain-of-trust to the vendor's well-known trust-anchor certificate. This way, the NMS only needs to trust the trust anchor and know in advance what unique-identifiers it expects, in order to authenticate devices. >Issue #3 >-------- > >- What shall be the strictness of the TLS certificate mutual verification? > a) validate the peer certificate against a trusted CA chain. > b) validate using a) and check if peer certificate is locally installed. > > - We think it should be configurable, but it is _not_ covered by > [ietf-netconf-server] data model. Should it be there? Since you ask if it should be configurable via the netconf-server module, I assume the question regards how the device authenticates the NMS's client-certificate, right? Is this what "cert-maps" in the netconf-server module is for? >Issue #4 >-------- > >- Do we need to document NETCONF client-side configuration for NETCONF >call > home? - This is connected with #3 - do we need to configure how the >client >should verify the server certificates? Or is validation of the >certificates >completely out of scope (for both, server and client)? For the server authenticating the client, the netconf-server module has "MUST close the connection" when no match found. For the client, it looks like the first paragraph of rfc5539bis section 2.4.1 (Server Identity) covers it. Are you looking for something more? >Issue #5 >-------- > >- [Section 2.6]: "Implementations of the protocol specified in this >document > MAY implement any TLS cipher suite that provides mutual authentication > [RFC5246]. However, implementations MUST support TLS 1.2 [RFC5246] and >are > REQUIRED to support the mandatory-to-implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to >future > versions of TLS; in which case, the mandatory-to- implement cipher >suite for > the implemented version MUST be supported." > > - The CIPHER suites for TLS v1.2 are mandated by [RFC 5246: Section 9]. >Do > we need to mention them in this document? We think we don't. >Mandatory > ciphers are specified by TLS specification and will probably change in > future versions of TLS. I don't think they need to be defined here, at least not now. >Issue #6 >-------- > >- [Section 2.4]: "Implementations MAY optionally support TLS >certificate-based > authentication [RFC5246]." > > a) Does the MAY hint towards allowing PSK-based TLS support? > b) We searched a bit on PSK-based TLS support in open-source projects: > - openssl supports PSK, also available in s_server > - stunnel does not support PSK, likely patchable. > - python does not support PSK (neither Python 2 nor Python 3) I'm not sure what other options this text might be alluding to either. >Issue #7 >-------- > >- [Section 2.4.1]: "the NETCONF client MUST check its understanding of the > NETCONF server hostname against the server's identity" [...] "If the >NETCONF > client has external information as to the expected identity of the >NETCONF > server, the hostname check MAY be omitted." > > a) MAY vs MUST There's one "MUST" and one "MAY" in the quoted text, but I don't have an issue with either statement as written. That said, there is a different concern related to how a "hostname" applies in the call-home case. >Issue #8 >-------- > >- [Section 2.3]: "The NETCONF server MUST NOT process any NETCONF messages > received after the operation." > > This is mandated by NETCONF protocol specification. Would it be better >to > just refer to RFC 6241? Yes, I think so. >Issue #9 >-------- > >- [Section 2.1.1]: Client to Server >- [Section 2.1.2]: Server to Client > > The client and server reverse roles during a NETCONF CALL HOME. Would >it be >better to explicitly prefix "NETCONF" in the section titles? Well, first off, section 2.1.2 is titled "Server to Client (Call Home)". The "(Call Home)" seems to clearly identify what each section is about. At least nothing seems out of place to me. Is the following what you'd like to see instead? - [Section 2.1.1]: NETCONF Client to NETCONF Server - [Section 2.1.2]: NETCONF Server to NETCONF Client I don't think this is better; it looks very busy. Not having the "(Call Home)" makes it harder to understand. My opinion only, maybe others feel strongly the other way. Thanks, Kent From nobody Wed Apr 2 05:55:46 2014 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 ACB8F1A01C0 for ; Wed, 2 Apr 2014 05:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 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, T_RP_MATCHES_RCVD=-0.01] 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 MjWHjvwCkxTf for ; Wed, 2 Apr 2014 05:55:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2571A01B3 for ; Wed, 2 Apr 2014 05:55:35 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 020CEED0CA2; Wed, 2 Apr 2014 14:55:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1396443329; bh=XSeZgmnjoQEcwxb9QMLjtsKSDeZ2fb2lkRZx5PdOvu0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Q0l+ez9D68lCLXyAI2exhY41Ttb5itZRZxfZ1WjMpDcwAb9sCnRRGLK6whcSAADX8 NT0kVo7TqtmaQV3qEQFS8d5Uz6Pj8zfhYXIEIZiNn5enx1yQIb1iksza//xpEjdBJh 2s99yB9HI9LDjNKaROeLG47SFQIGg2g9p2Vjv2Ec= Message-ID: <533C0850.6090308@cesnet.cz> Date: Wed, 02 Apr 2014 14:53:36 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , "Bajpai, Vaibhav" , "netconf@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/A-_XH7ONeHO0uK0bKdDp_WpMhnw Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] 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, 02 Apr 2014 12:55:40 -0000 HiKent, comments to issues, where I have something to say, inline.. Dne 1.4.2014 21:11, Kent Watsen napsal(a): > Hi Vaibhav and Radek, > > My responses to your issues are below. > > BTW, congratulations on having the first TLS-based NETCONF call-home > implementation that I'm aware of. Did you use the current > "netconf-server" configuration format for input? Not yet, but I'm working on it. So far, we have a standalone app that initiate call home according to the command line arguments. But I'm going to integrate it into the NETCONF server using ietf-netconf-server data model. >> Issue #1 >> -------- >> >> - How to handle ssh host key verification when multiple hosts are behind a >> NAT? - This is probably implementation specific. It depends how an SSH >> client stores hosts keys. We thought to share this issue along anyway. > > This is for SSH? The Reverse-SSH draft describes options that don't rely > on IP addresses specifically to support NAT cases. Whether forward or > reverse, the same applies. yes, as mentioned, this is probably implementation specific regarding how OpenSSH's client usually stores known hosts and then checks if the key of the specific remote host changed. I think that description in Reverse SSH draft sec 5 is enough. >> Issue #2 >> -------- >> >> - How to handle TLS certificate hostname verification when multiple hosts >> are >> behind a NAT? - Similar to #1. The NMS should have some kind of >> pre-defined >> knowledge, that the hostname is correct (expected for the certificate). >> Maybe >> this can be mentioned more explicitely in the NETCONF over TLS text. > The Reverse SSH draft also speaks to this too, recommending that the > device's certificate encode a unique identifier (e.g., serial-number). > But to remove the burden from the NMS, the device-vendor SHOULD ship their > device's from factory with this certificate pre-installed. This > certificate SHOULD be signed by a chain-of-trust to the vendor's > well-known trust-anchor certificate. This way, the NMS only needs to > trust the trust anchor and know in advance what unique-identifiers it > expects, in order to authenticate devices. > I just think, that description of the server side identification in Reverse SSH draft (sec 5) is more clear than the section in rfc5539bis (sec 2.4.1). Probably because in the first case, it is focused only to reverse connection while rfc5539bis describes both, forward and reverse connection. As mentioned in #7, the first paragraph of sec 2.4.1 states that "...client MUST check its understanding of the NETCONF server hostname..." but the last paragraph says "the hostname check MAY be omitted" (if it MUST be checked, it is not allowed to be omitted). I think that it should be clearly stated, what applies to forward and what applies to reverse connection. >> Issue #3 >> -------- >> >> - What shall be the strictness of the TLS certificate mutual verification? >> a) validate the peer certificate against a trusted CA chain. >> b) validate using a) and check if peer certificate is locally installed. >> >> - We think it should be configurable, but it is _not_ covered by >> [ietf-netconf-server] data model. Should it be there? > Since you ask if it should be configurable via the netconf-server module, > I assume the question regards how the device authenticates the NMS's > client-certificate, right? Is this what "cert-maps" in the netconf-server > module is for? in this point, it is about a device - but not actually authentication (which is covered by cert-maps), but verification if the client certificate is valid and mainly trusted and can be passed further to cert-to-username mapping. We have options to trust to all certificates signed by a trusted CA (chain) or trust only to an explicit list of certificates (similar to what client can do when checking server identity). But AFAIK there is no such setting in the netconf-server data model. We don't insist on putting this to the data model, we are just asking WG if it is supposed to be there or it is expected to be implementation-specific (because somewhere it must be specified/configured). >> Issue #4 >> -------- >> >> - Do we need to document NETCONF client-side configuration for NETCONF >> call >> home? - This is connected with #3 - do we need to configure how the >> client >> should verify the server certificates? Or is validation of the >> certificates >> completely out of scope (for both, server and client)? > For the server authenticating the client, the netconf-server module has > "MUST close the connection" when no match found. For the client, it looks > like the first paragraph of rfc5539bis section 2.4.1 (Server Identity) > covers it. Are you looking for something more? > just asking if someone is willing to explicitly describe configuration (data model?) for a client side. Specifically the configuration how the server certificate is supposed to be validated (chain-of-trust, list of trusted server certificates/keys,...). Personally, I don't think that this is necessary. >> Issue #7 >> -------- >> >> - [Section 2.4.1]: "the NETCONF client MUST check its understanding of the >> NETCONF server hostname against the server's identity" [...] "If the >> NETCONF >> client has external information as to the expected identity of the >> NETCONF >> server, the hostname check MAY be omitted." >> >> a) MAY vs MUST > There's one "MUST" and one "MAY" in the quoted text, but I don't have an > issue with either statement as written. That said, there is a different > concern related to how a "hostname" applies in the call-home case. Already mentioned in my comment to #2 - where it is said what applies to call-home? I don't see any note about difference between forward and reverse connection in whole section 2.4. Regards, Radek From nobody Wed Apr 2 09:53:03 2014 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 CA0871A0232 for ; Wed, 2 Apr 2014 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 VbOI__X2IELE for ; Wed, 2 Apr 2014 09:52:50 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE7581A02ED for ; Wed, 2 Apr 2014 09:52:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XRCU1ow7QS27ZvukdENYYT663pxAAi6+2no07i6YFHf9CmXDontbJJl7SdHwcsN4; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WVOP5-0000OC-MP for netconf@ietf.org; Wed, 02 Apr 2014 12:52:43 -0400 Received: from 99.23.160.131 by webmail.earthlink.net with HTTP; Wed, 2 Apr 2014 12:52:43 -0400 Message-ID: <10815243.1396457563710.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Wed, 2 Apr 2014 09:52:43 -0700 (GMT-07:00) From: Randy Presuhn To: "netconf@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbcbf6237eef192773b0d0d044b583c3af6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RionxtxFTXKeB4EmJjDsv4v1eDo Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:52:57 -0000 Hi - >From: Radek Krej=C4=8D=C3=AD >Sent: Apr 2, 2014 5:53 AM >To: Kent Watsen , "Bajpai, Vaibhav" , "netconf@ietf.org" >Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] ... >just asking if someone is willing to explicitly describe configuration >(data model?) for a client side. Specifically the configuration how the >server certificate is supposed to be validated (chain-of-trust, list of >trusted server certificates/keys,...). Personally, I don't think that >this is necessary. ... In light of the revelations about compromised CAs, I think this is an important concern and its configuration should not be implementation-specific. Randy From nobody Wed Apr 2 10:58:27 2014 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 9509A1A0326 for ; Wed, 2 Apr 2014 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 CtUmVzuWrTGI for ; Wed, 2 Apr 2014 10:58:21 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id D5F9E1A028D for ; Wed, 2 Apr 2014 10:58:20 -0700 (PDT) Received: from mail4-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 17:58:16 +0000 Received: from mail4-ch1 (localhost [127.0.0.1]) by mail4-ch1-R.bigfish.com (Postfix) with ESMTP id 777E560448; Wed, 2 Apr 2014 17:58:16 +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: -3 X-BigFish: VPS-3(zzd772h1dbaI1418I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h1155h) Received-SPF: pass (mail4-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=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(164054003)(199002)(93516002)(87936001)(87266001)(94316002)(85306002)(80022001)(93136001)(66066001)(20776003)(51856001)(74502001)(97186001)(81686001)(551544002)(56816005)(86362001)(59766001)(31966008)(99286001)(69226001)(85852003)(77982001)(94946001)(81342001)(54356001)(83506001)(74366001)(47446002)(2656002)(74662001)(98676001)(81542001)(83322001)(97336001)(95666003)(92566001)(83072002)(36756003)(4396001)(53806001)(81816001)(47976001)(77096001)(95416001)(49866001)(47736001)(90146001)(65816001)(74876001)(54316002)(76796001)(63696002)(74706001)(76786001)(56776001)(76482001)(46102001)(50986001)(80976001)(79102001)(92726001)(99396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:EEDCF211.87C251D3.CCF91D4B.95E4DBE1.203EA; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail4-ch1 (localhost.localdomain [127.0.0.1]) by mail4-ch1 (MessageSwitch) id 1396461493752733_26681; Wed, 2 Apr 2014 17:58:13 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail4-ch1.bigfish.com (Postfix) with ESMTP id AC3E22009C; Wed, 2 Apr 2014 17:58:13 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 17:58:13 +0000 Received: from BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 2 Apr 2014 17:58:12 +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.898.11; Wed, 2 Apr 2014 17:58:11 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.48]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.133]) with mapi id 15.00.0898.005; Wed, 2 Apr 2014 17:58:10 +0000 From: Kent Watsen To: =?iso-8859-2?Q?Radek_Krej=E8=ED?= , "Bajpai, Vaibhav" , "netconf@ietf.org" Thread-Topic: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] Thread-Index: AQHPTd43lQun1SgDxEC8DWvUeTyr95r+SWIAgAASDIA= Date: Wed, 2 Apr 2014 17:58:10 +0000 Message-ID: References: <533C0850.6090308@cesnet.cz> In-Reply-To: <533C0850.6090308@cesnet.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 0169092318 Content-Type: text/plain; charset="iso-8859-2" 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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/5Lj_SJzkmPZ9YzSu3bBoGil-QME Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] 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, 02 Apr 2014 17:58:26 -0000 >yes, as mentioned, this is probably implementation specific regarding >how OpenSSH's client usually stores known hosts and then checks if the >key of the specific remote host changed. I think that description in >Reverse SSH draft sec 5 is enough. Agreed. No change to Reverse SSH text. >I just think, that description of the server side identification in >Reverse SSH draft (sec 5) is more clear than the section in rfc5539bis >(sec 2.4.1). Probably because in the first case, it is focused only to >reverse connection while rfc5539bis describes both, forward and reverse >connection. As mentioned in #7, the first paragraph of sec 2.4.1 states >that "...client MUST check its understanding of the NETCONF server >hostname..." but the last paragraph says "the hostname check MAY be >omitted" (if it MUST be checked, it is not allowed to be omitted). I >think that it should be clearly stated, what applies to forward and what >applies to reverse connection. Agreed, a change to the 5529bis text is needed. >in this point, it is about a device - but not actually authentication >(which is covered by cert-maps), but verification if the client >certificate is valid and mainly trusted and can be passed further to >cert-to-username mapping. We have options to trust to all certificates >signed by a trusted CA (chain) or trust only to an explicit list of >certificates (similar to what client can do when checking server >identity). But AFAIK there is no such setting in the netconf-server data >model. We don't insist on putting this to the data model, we are just >asking WG if it is supposed to be there or it is expected to be >implementation-specific (because somewhere it must be >specified/configured). I think I see what you're saying now and I think that it might be an issue with draft-ietf-netmod-system-mgmt, which defines how user's passwords and ssh-keys can be configured. Missing from section 3.5 (User Authentication Model) in that draft is any place where a TLS client-certificate (or a CA that can vouch for client certificates) can be configured. Which I think your question is primarily about. There may also be a larger question regarding if the netconf-server draft should depend on the netmod-system draft. Also, we might want to double-check that it makes sense to have cert-maps and psk-maps in the netconf-server model at all. What do you think? >just asking if someone is willing to explicitly describe configuration >(data model?) for a client side. Specifically the configuration how the >server certificate is supposed to be validated (chain-of-trust, list of >trusted server certificates/keys,...). Personally, I don't think that >this is necessary. Agreed, no need to explain how clients can verify servers. Though, wherever server-certificates are configured, it should be noted that the certificate MAY be signed by a chain of CAs and that, when the case arises, that the server MUST return the entire chain-of-certificates during TLS connection establishment. >Already mentioned in my comment to #2 - where it is said what applies to >call-home? I don't see any note about difference between forward and >reverse connection in whole section 2.4. Yeap, and as mentioned in #2 above, a change to the 5529bis text is needed. Thanks, Kent From nobody Thu Apr 3 02:05:22 2014 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 2D7731A0127 for ; Thu, 3 Apr 2014 02:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 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, T_RP_MATCHES_RCVD=-0.01] 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 HHuY56rRoUlq for ; Thu, 3 Apr 2014 02:05:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id D87461A012B for ; Thu, 3 Apr 2014 02:05:15 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 072A3ED04DE; Thu, 3 Apr 2014 11:05:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1396515910; bh=RCw1Cd1dO1jBbxI8pU9lS1q9/85wyPxcMmxVsJJ7mds=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C3ZIvfhUReUKVIDueVrAc4O00KvAbqG7xSeJumu0wEn/aivt/trNDL97fxuO9LHL8 8ARY6tJwR3Pjegrr0GkiEBhD1rEqgwO5CurpO1l+XjhLeABhtPuQMLQJevZ7GFt6uZ vfrddDOU8CXmbGyPp8tBnauBE0fRgnX86qWNk2gU= Message-ID: <533D23D7.30403@cesnet.cz> Date: Thu, 03 Apr 2014 11:03:19 +0200 From: =?ISO-8859-2?Q?Radek_Krej=E8=ED?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , "Bajpai, Vaibhav" , "netconf@ietf.org" References: <533C0850.6090308@cesnet.cz> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tKdNQRToijBom8i48KgUwBsLUyM Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] 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, 03 Apr 2014 09:05:21 -0000 Dne 2.4.2014 19:58, Kent Watsen napsal(a): >> in this point, it is about a device - but not actually authentication >> (which is covered by cert-maps), but verification if the client >> certificate is valid and mainly trusted and can be passed further to >> cert-to-username mapping. We have options to trust to all certificates >> signed by a trusted CA (chain) or trust only to an explicit list of >> certificates (similar to what client can do when checking server >> identity). But AFAIK there is no such setting in the netconf-server data >> model. We don't insist on putting this to the data model, we are just >> asking WG if it is supposed to be there or it is expected to be >> implementation-specific (because somewhere it must be >> specified/configured). > I think I see what you're saying now and I think that it might be an issue > with draft-ietf-netmod-system-mgmt, which defines how user's passwords and > ssh-keys can be configured. Missing from section 3.5 (User Authentication > Model) in that draft is any place where a TLS client-certificate (or a CA > that can vouch for client certificates) can be configured. Which I think > your question is primarily about. yes, but I don't think that it can be set on per-user basis since in TLS you get username from a client certificate and this mapping is done after validation of the certificate. So, TLS client-cert / trusted CAs configuration should be placed into /system/authentication/ and it will be applied to all users (resp. in time when there is no knowledge about a specific username) > There may also be a larger question regarding if the netconf-server draft > should depend on the netmod-system draft. Also, we might want to > double-check that it makes sense to have cert-maps and psk-maps in the > netconf-server model at all. What do you think? > agree. Actually I don't have a preference where these configuration items should be (system-mgmt or netconf-server), but it should be all in the same document. Sec 3.5 in netmod-system-mgmt says that "the authentication parameters defined in this document are primarily used to configure authentication of NETCONF users" which can be also applied to cert-maps and psk-maps, right? Regards, Radek From nobody Thu Apr 3 04:38:23 2014 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 03FE21A0244 for ; Thu, 3 Apr 2014 04:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 S3RTGu_zKE9g for ; Thu, 3 Apr 2014 04:38:15 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id B06811A0079 for ; Thu, 3 Apr 2014 04:37:03 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVfwu-0004hn-0z; Thu, 03 Apr 2014 13:36:58 +0200 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-3.fritz.box) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WVfwt-0000W8-TH; Thu, 03 Apr 2014 13:36:47 +0200 Message-ID: <533D47CF.30402@bwijnen.net> Date: Thu, 03 Apr 2014 13:36:47 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Kent Watsen References: <201403251517.LAA15291@adminfs.snmp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49d86792ec4281fcaa08add18ae37939c Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/D79fOCuPOnFpqCvjgOZFrGSajpU Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments on draft-ietf-netconf-reverse-ssh-03.txt 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, 03 Apr 2014 11:38:20 -0000 WGLC period ended last Tuesday (April 1st). Kent, where are we with this one? Do you expect to post a rev 04 that addresses all comments we have received? Either WGLC comments or other comments? Once that is done, I would like to ask: - Kent to post which comments have not been addressed and why (if any) - If possible, Kent to post a summary of changes (although that may already be in the document, and that is fine too). - All those that made comments to check if they are OK with the way that they have been addressed or responded to. Bert On 27/03/14 17:02, Kent Watsen wrote: > > Hi Alan, > > > Awesome comments - thanks! > > > I applied all fixes mentioned below to my working copy of what will be > -04, so you'll have to wait until then to see the diff. The reason I'm > not posting -04 now is because I'm still trying to work out an issue with > Applicability Statement and with the port's name. > > Below are my detailed responses. > > Cheers, > Kent > > > > > > > >> Typos >> ----- >> > > I fixed all the issues you found. > > > > > > >> Section 2.1, Page 3, Second Paragraph: (wording) >> ------------------------------------------------- >> >> The second paragraph seems vague. Would something along the lines of >> the following text be clearer and/or more specific? > > I forwarded this comment to Steve Hanna, who wrote the Applicability > Statement. At first I was just going to ask if he was OK with the > proposed text, but then I started thinking that I didn't agree with it. > That is, I think that the SSH protocol does require mutual authentication > and that NETCONF's requirement that it be possible to derive a "username" > from the transport doesn't change that. I'm still OK limiting Reverse SSH > to just NETCONF, but I want the reason to be accurate. I'm now waiting > for a response from Steve on this. > > > > > > > >> Section 4, Page 4: (wording) >> ----------------------------- >> >> The current text reads: >> >> o The NETCONF server initiates a TCP connection to the NETCONF >> client on the IANA-assigned Reverse SSH port YYYY. >> >> o The TCP connection is accepted and a TCP session is established. > > > I'm not sure about this change since these bullet-points are preceded by > the line "From the NETCONF server's perspective:". The intent is to only > explain the NETCONF-server's perspective, and to let the next section > provide the client's perspective. Currently, neither section references > the remote peer, so that its text remains squarely focused on its side of > the connection. What do you think? > > > > > > > >> Section 5, Page 5, First Paragraph: (wording) >> ---------------------------------------------- >> >> The current text reads: >> >> "When the management system accepts a new incoming connection, it >> needs to authenticate the remote peer. Ultimately, this entails >> identifying the peer and verifying its SSH host key. >> >> Due to Reverse SSH having the network element initiate the TCP >> connection," > > > I changed the wording to be more clear, but did it another way, please let > me know if you think it's OK! > > > > > > > > >> Section 5, Page 6, First Paragraph: (clarification) >> ---------------------------------------------------- >> >> The current text reads: >> >> "However, configuring distinct host keys on the management system >> doesn't scale well, which is an important consideration to a network >> management system. A more scalable strategy is to have the network >> element's host key signed by a common trusted key, such as a >> certificate authority. Thus, the mangement system only needs to >> trust a single public key, which vouches for the authenticity of the >> various network element public keys." >> >> Please help me understand this. The way this paragraph is written, it >> is not clear to me why "signing each network element's host key with a >> common trusted key" scales better than "configuring distinct host keys >> on the management system". >> >> In either of these two situations, it seems like an administrator must >> do work for each network element. In one case, it is configuring host >> keys, in another, it is signing each network element's host key. If >> anything, it seems like signing a host key for each network element >> requires _more_ work for each network element, so it seems like this >> would scale less well. >> >> What am I missing here? > > > Very good question. Of course it comes down to how the device's "entity > certificates", as they are called, is distributed. In the best case, as > described in the zero-touch draft, the device would ship from factory with > a built-in entity-certificate, signed by a trust-chain to its vendor's > well-known trust anchor. In this case, there is no additional effort > needed, the management system only needs to trust the vendor's certificate > for its well-known trust anchor. For cases where the device doesn't ship > from factory with an entity-certificate, introducing PKI is still > advantageous as it decouples the management-system from direct > involvement, such that it could be outsourced to some 3rd-party. Makes > sense? What update would you like to see in the draft? > > > > > > > > >> Section 7, Page 7, Third Paragraph: (wording) >> ---------------------------------------------- >> >> In a few places in the third paragraph, and possibly in other places >> in the document, would changing "needs to" to lowercase "must", or >> lowercase "should", make the document a little more concise? Example: >> >> "Note that since the SSH server would have to be configured to know >> which IP address it needs to connect to," >> ^^^^^^^^ > > > I changed "needs to" to "is to" for this cited location and another I > found. > > > > > > Thanks again, > Kent > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Apr 3 04:42:04 2014 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 51D0E1A017C for ; Thu, 3 Apr 2014 04:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VPqBsD7psEOF for ; Thu, 3 Apr 2014 04:41:57 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id E5F611A0037 for ; Thu, 3 Apr 2014 04:41:55 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVg1d-0006UE-Bs for netconf@ietf.org; Thu, 03 Apr 2014 13:41:51 +0200 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-3.fritz.box) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WVg1d-00058R-74 for netconf@ietf.org; Thu, 03 Apr 2014 13:41:41 +0200 Message-ID: <533D48F5.6070803@bwijnen.net> Date: Thu, 03 Apr 2014 13:41:41 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Netconf References: <5327288E.7060503@ripe.net> In-Reply-To: <5327288E.7060503@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47d1f5fc00da6827b4448503700b38f7a Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PEqbiwFekhw0WGBP-KATbeq6x5k Subject: Re: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 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, 03 Apr 2014 11:42:02 -0000 Authors/Editors, where are we with this one? Do you expect to post a rev 06 that addresses all comments we have received? Either WGLC comments or other comments? I am not sure that we did get comments that justify a new rev, I'd like the authors/editors to post their view on this. Once that is done, I would like to ask: - Editors/authors to post which comments have not been addressed and why (if any) - If we do get a new rev, then - If possible, editors/authors to post a summary of changes (although that may already be in the document, and that is fine too). - All those that made comments to check if they are OK with the way that they have been addressed or responded to. Bert On 17/03/14 17:53, Bert Wijnen wrote: > Dear NETCONF participants, > > We hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-05 > > The document acn be found at: > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-05 > > Pls review and send any comments (a comment aka: I read/reviewed it > and believe it is ready for publication" is also good input) to > the WG mailing lists not later than March 30th 2014 (any timezone). > > Any reports on implementation status or plans to implement are also > very useful. > > Bert and Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Apr 4 04:46:00 2014 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 C76C91A0159 for ; Fri, 4 Apr 2014 04:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 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, T_RP_MATCHES_RCVD=-0.01] 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 DKhTZwWp9siV for ; Fri, 4 Apr 2014 04:45:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id AFC001A014B for ; Fri, 4 Apr 2014 04:45:53 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 1B167ED0447; Fri, 4 Apr 2014 13:45:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1396611947; bh=0Y1NGaCQVOE6FJovCFsymBrqK9WbJbaIPCvdnMTKL48=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qMjqbzb+dYT7vopDJ4kolAsthyrEaReiKy+pgRuspEsEw62F6hRF1U6PgNgKILGrO yLEd6e17f8a1g/sNxoRykudloAIVjfx6wngEeKL4GKUiVqG9xTYCctIT+YmN+VcFJu /acvsnlxC8u1kRUntZL14rgLiOhQdjIQBfF7JUYQ= Message-ID: <533E9AFC.2010305@cesnet.cz> Date: Fri, 04 Apr 2014 13:43:56 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , "Bajpai, Vaibhav" , "netconf@ietf.org" References: <533C0850.6090308@cesnet.cz> <533D23D7.30403@cesnet.cz> In-Reply-To: <533D23D7.30403@cesnet.cz> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eth4dBxUdrFYQembZBJHQf1zMks Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] 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, 04 Apr 2014 11:45:58 -0000 Hi, I have update to this. I checked ietf-x509-cert-to-name in more detail and I have a question to the description in grouping cert-to-name/list cert-to-name. The text says, that the fingerprint value in configuration data can match 1) a client certificate or 2) CA certificate that is part of CA chain in a client certificate. The text speaks about matching for purposes of cert-to-name mapping, but can it be also read as "presented certificate is _trusted_ if 1) its fingerprint matches.. or 2) fingerprint of one of its CA certificate in its chain matches ..fingerprint value in configuration data"? If so, it actually specifies what I was missing.Previously I missed that the fingerprint value can refer also to a CA certificate. However, moving user authentication config for SSH (currently in system-mgmt) and TLS (cert-maps and psk-maps) together may not to be a bad idea. Radek Dne 3.4.2014 11:03, Radek Krejčí napsal(a): > Dne 2.4.2014 19:58, Kent Watsen napsal(a): >>> in this point, it is about a device - but not actually authentication >>> (which is covered by cert-maps), but verification if the client >>> certificate is valid and mainly trusted and can be passed further to >>> cert-to-username mapping. We have options to trust to all certificates >>> signed by a trusted CA (chain) or trust only to an explicit list of >>> certificates (similar to what client can do when checking server >>> identity). But AFAIK there is no such setting in the netconf-server data >>> model. We don't insist on putting this to the data model, we are just >>> asking WG if it is supposed to be there or it is expected to be >>> implementation-specific (because somewhere it must be >>> specified/configured). >> I think I see what you're saying now and I think that it might be an issue >> with draft-ietf-netmod-system-mgmt, which defines how user's passwords and >> ssh-keys can be configured. Missing from section 3.5 (User Authentication >> Model) in that draft is any place where a TLS client-certificate (or a CA >> that can vouch for client certificates) can be configured. Which I think >> your question is primarily about. > yes, but I don't think that it can be set on per-user basis since in TLS > you get username from a client certificate and this mapping is done > after validation of the certificate. So, TLS client-cert / trusted CAs > configuration should be placed into /system/authentication/ and it will > be applied to all users (resp. in time when there is no knowledge about > a specific username) > >> There may also be a larger question regarding if the netconf-server draft >> should depend on the netmod-system draft. Also, we might want to >> double-check that it makes sense to have cert-maps and psk-maps in the >> netconf-server model at all. What do you think? >> > agree. Actually I don't have a preference where these configuration > items should be (system-mgmt or netconf-server), but it should be all in > the same document. Sec 3.5 in netmod-system-mgmt says that "the > authentication parameters defined in this document are primarily used to > configure authentication of NETCONF users" which can be also applied to > cert-maps and psk-maps, right? > > Regards, > Radek > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Apr 4 08:15:32 2014 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 E69771A01CD for ; Fri, 4 Apr 2014 08:15:29 -0700 (PDT) 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 ntMNk0K1g1x8 for ; Fri, 4 Apr 2014 08:15:25 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 17A621A0191 for ; Fri, 4 Apr 2014 08:15:24 -0700 (PDT) Received: from mail103-va3-R.bigfish.com (10.7.14.226) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 15:15:16 +0000 Received: from mail103-va3 (localhost [127.0.0.1]) by mail103-va3-R.bigfish.com (Postfix) with ESMTP id 113873E00EF; Fri, 4 Apr 2014 15:15:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VPS-37(zzbb2dI98dI9371I103dK154dI1dbaI1432I1418I14e3M111aIdf9Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail103-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(41574002)(24454002)(43784003)(479174003)(377454003)(51704005)(53474002)(189002)(199002)(35774003)(80022001)(92726001)(98676001)(66066001)(94316002)(46102001)(20776003)(92566001)(93136001)(99286001)(47976001)(97186001)(81342001)(56776001)(83322001)(81542001)(19580395003)(50986001)(4396001)(36756003)(59766001)(77982001)(19580405001)(54316002)(51856001)(54356001)(95666003)(97336001)(53806001)(79102001)(83072002)(94946001)(63696002)(49866001)(76482001)(85852003)(93516002)(47736001)(65816001)(95416001)(56816005)(86362001)(90146001)(99396002)(74876001)(81816001)(2656002)(69226001)(81686001)(87266001)(15975445006)(74366001)(80976001)(83506001)(74706001)(76796001)(74502001)(74662001)(87936001)(85306002)(31966008)(77096001)(76786001)(47446002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:DEECF156.ACF251A1.B2D0124B.5EE4D3F1.205C6; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail103-va3 (localhost.localdomain [127.0.0.1]) by mail103-va3 (MessageSwitch) id 1396624513690936_18827; Fri, 4 Apr 2014 15:15:13 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.235]) by mail103-va3.bigfish.com (Postfix) with ESMTP id 993393A0050; Fri, 4 Apr 2014 15:15:13 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 15:15:15 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 4 Apr 2014 15:15:16 +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.913.9; Fri, 4 Apr 2014 15:15:14 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Fri, 4 Apr 2014 15:15:13 +0000 From: Kent Watsen To: "Bert Wijnen (IETF)" Thread-Topic: WG Last Call Comments on draft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPTzENSOdcqjHhW06IOTXJgwBsspsBT+6A Date: Fri, 4 Apr 2014 15:15:13 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> In-Reply-To: <533D47CF.30402@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 01713B2841 Content-Type: text/plain; charset="us-ascii" Content-ID: <6E94957C2013734197EACCB3260737E0@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UVhDdVK5-rFsbaYvOnO-rDrzGLc Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments on draft-ietf-netconf-reverse-ssh-03.txt 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, 04 Apr 2014 15:15:30 -0000 Hi Bert, I just need to update the Change Log now. Also, Stave Hanna hasn't replied yet regarding the Applicability Statement. I'll ping him again while updating the Change Log. I apologize for missing the date, but I was recently put on the steering committee for a project and I had to spend time on it first. Kent On 4/3/14 7:36 AM, "Bert Wijnen (IETF)" wrote: >WGLC period ended last Tuesday (April 1st). > >Kent, where are we with this one? > >Do you expect to post a rev 04 that addresses all comments we have >received? >Either WGLC comments or other comments? Once that is done, I would like >to ask: >- Kent to post which comments have not been addressed and why (if any) >- If possible, Kent to post a summary of changes (although that may >already be > in the document, and that is fine too). >- All those that made comments to check if they are OK with the way that > they have been addressed or responded to. > >Bert > >On 27/03/14 17:02, Kent Watsen wrote: >> >> Hi Alan, >> >> >> Awesome comments - thanks! >> >> >> I applied all fixes mentioned below to my working copy of what will be >> -04, so you'll have to wait until then to see the diff. The reason I'm >> not posting -04 now is because I'm still trying to work out an issue >>with >> Applicability Statement and with the port's name. >> >> Below are my detailed responses. >> >> Cheers, >> Kent >> >> >> >> >> >> >> >>> Typos >>> ----- >>> >> >> I fixed all the issues you found. >> >> >> >> >> >> >>> Section 2.1, Page 3, Second Paragraph: (wording) >>> ------------------------------------------------- >>> >>> The second paragraph seems vague. Would something along the lines of >>> the following text be clearer and/or more specific? >> >> I forwarded this comment to Steve Hanna, who wrote the Applicability >> Statement. At first I was just going to ask if he was OK with the >> proposed text, but then I started thinking that I didn't agree with it. >> That is, I think that the SSH protocol does require mutual >>authentication >> and that NETCONF's requirement that it be possible to derive a >>"username" >> from the transport doesn't change that. I'm still OK limiting Reverse >>SSH >> to just NETCONF, but I want the reason to be accurate. I'm now waiting >> for a response from Steve on this. >> >> >> >> >> >> >> >>> Section 4, Page 4: (wording) >>> ----------------------------- >>> >>> The current text reads: >>> >>> o The NETCONF server initiates a TCP connection to the NETCONF >>> client on the IANA-assigned Reverse SSH port YYYY. >>> >>> o The TCP connection is accepted and a TCP session is established. >> >> >> I'm not sure about this change since these bullet-points are preceded by >> the line "From the NETCONF server's perspective:". The intent is to >>only >> explain the NETCONF-server's perspective, and to let the next section >> provide the client's perspective. Currently, neither section >>references >> the remote peer, so that its text remains squarely focused on its side >>of >> the connection. What do you think? >> >> >> >> >> >> >> >>> Section 5, Page 5, First Paragraph: (wording) >>> ---------------------------------------------- >>> >>> The current text reads: >>> >>> "When the management system accepts a new incoming connection, it >>> needs to authenticate the remote peer. Ultimately, this entails >>> identifying the peer and verifying its SSH host key. >>> >>> Due to Reverse SSH having the network element initiate the TCP >>> connection," >> >> >> I changed the wording to be more clear, but did it another way, please >>let >> me know if you think it's OK! >> >> >> >> >> >> >> >> >>> Section 5, Page 6, First Paragraph: (clarification) >>> ---------------------------------------------------- >>> >>> The current text reads: >>> >>> "However, configuring distinct host keys on the management system >>> doesn't scale well, which is an important consideration to a network >>> management system. A more scalable strategy is to have the network >>> element's host key signed by a common trusted key, such as a >>> certificate authority. Thus, the mangement system only needs to >>> trust a single public key, which vouches for the authenticity of the >>> various network element public keys." >>> >>> Please help me understand this. The way this paragraph is written, it >>> is not clear to me why "signing each network element's host key with a >>> common trusted key" scales better than "configuring distinct host keys >>> on the management system". >>> >>> In either of these two situations, it seems like an administrator must >>> do work for each network element. In one case, it is configuring host >>> keys, in another, it is signing each network element's host key. If >>> anything, it seems like signing a host key for each network element >>> requires _more_ work for each network element, so it seems like this >>> would scale less well. >>> >>> What am I missing here? >> >> >> Very good question. Of course it comes down to how the device's "entity >> certificates", as they are called, is distributed. In the best case, as >> described in the zero-touch draft, the device would ship from factory >>with >> a built-in entity-certificate, signed by a trust-chain to its vendor's >> well-known trust anchor. In this case, there is no additional effort >> needed, the management system only needs to trust the vendor's >>certificate >> for its well-known trust anchor. For cases where the device doesn't >>ship >> from factory with an entity-certificate, introducing PKI is still >> advantageous as it decouples the management-system from direct >> involvement, such that it could be outsourced to some 3rd-party. Makes >> sense? What update would you like to see in the draft? >> >> >> >> >> >> >> >> >>> Section 7, Page 7, Third Paragraph: (wording) >>> ---------------------------------------------- >>> >>> In a few places in the third paragraph, and possibly in other places >>> in the document, would changing "needs to" to lowercase "must", or >>> lowercase "should", make the document a little more concise? Example: >>> >>> "Note that since the SSH server would have to be configured to know >>> which IP address it needs to connect to," >>> ^^^^^^^^ >> >> >> I changed "needs to" to "is to" for this cited location and another I >> found. >> >> >> >> >> >> Thanks again, >> Kent >> >> >> >> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > From nobody Fri Apr 4 08:26:57 2014 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 29A8B1A01B5 for ; Fri, 4 Apr 2014 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 DeuxmmjbTQ1Z for ; Fri, 4 Apr 2014 08:26:52 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe007.messaging.microsoft.com [65.55.88.31]) by ietfa.amsl.com (Postfix) with ESMTP id DF9901A01D2 for ; Fri, 4 Apr 2014 08:26:51 -0700 (PDT) Received: from mail15-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 15:26:44 +0000 Received: from mail15-tx2 (localhost [127.0.0.1]) by mail15-tx2-R.bigfish.com (Postfix) with ESMTP id 20D2960091; Fri, 4 Apr 2014 15:26:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1418Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h1155h) Received-SPF: pass (mail15-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(76786001)(87266001)(97336001)(31966008)(69226001)(76796001)(83506001)(36756003)(81686001)(81816001)(81342001)(97186001)(87936001)(2656002)(77096001)(74706001)(4396001)(94946001)(74662001)(47976001)(50986001)(74502001)(95416001)(47446002)(49866001)(47736001)(95666003)(85306002)(79102001)(83072002)(99286001)(98676001)(59766001)(94316002)(80022001)(77982001)(51856001)(65816001)(20776003)(66066001)(53806001)(85852003)(86362001)(93516002)(54356001)(63696002)(92566001)(99396002)(80976001)(90146001)(81542001)(74876001)(93136001)(74366001)(46102001)(54316002)(76482001)(92726001)(83322001)(56816005)(56776001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:FE38F090.A5D45817.7CFA3D47.47606951.2020C; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail15-tx2 (localhost.localdomain [127.0.0.1]) by mail15-tx2 (MessageSwitch) id 1396625200721844_5719; Fri, 4 Apr 2014 15:26:40 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.230]) by mail15-tx2.bigfish.com (Postfix) with ESMTP id 9D41320053; Fri, 4 Apr 2014 15:26:40 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 15:26:40 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 4 Apr 2014 15:26:40 +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.913.9; Fri, 4 Apr 2014 15:26:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Fri, 4 Apr 2014 15:26:37 +0000 From: Kent Watsen To: =?iso-8859-2?Q?Radek_Krej=E8=ED?= , "Bajpai, Vaibhav" , "netconf@ietf.org" Thread-Topic: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] Thread-Index: AQHPTd43lQun1SgDxEC8DWvUeTyr95r+SWIAgAASDICAAT/ygIABumOA Date: Fri, 4 Apr 2014 15:26:37 +0000 Message-ID: References: <533C0850.6090308@cesnet.cz> <533D23D7.30403@cesnet.cz> In-Reply-To: <533D23D7.30403@cesnet.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 01713B2841 Content-Type: text/plain; charset="iso-8859-2" Content-ID: <79A8B2E3477A434EB0E2E1E3BB330730@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tLJKx42kUDM0wm3FcCI_m-bp-ds Subject: Re: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] 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, 04 Apr 2014 15:26:56 -0000 +andy >yes, but I don't think that it can be set on per-user basis since in TLS >you get username from a client certificate and this mapping is done >after validation of the certificate. So, TLS client-cert / trusted CAs >configuration should be placed into /system/authentication/ and it will >be applied to all users (resp. in time when there is no knowledge about >a specific username) OK, so missing is a way to configure a list of trusted CA certs and trusted client certs at a system-wide level. >agree. Actually I don't have a preference where these configuration >items should be (system-mgmt or netconf-server), but it should be all in >the same document. Sec 3.5 in netmod-system-mgmt says that "the >authentication parameters defined in this document are primarily used to >configure authentication of NETCONF users" which can be also applied to >cert-maps and psk-maps, right? Yes, I think that netmod-system-mgmt should be updated. Unfortunately, it is currently being reviewed by IESG. I don't know if it's too late now. Andy, if you're already updating netmod-system-mgmt, can we move the cert-maps, psk-maps into it? - and also add the configuration of system-wide trusted CA and client certs mentioned above? Kent From nobody Sat Apr 5 20:55:19 2014 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 8FE401A0248 for ; Sat, 5 Apr 2014 20:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 V3HHlPSSfWCR for ; Sat, 5 Apr 2014 20:55:14 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 37D3E1A0375 for ; Sat, 5 Apr 2014 20:55:14 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWeAd-0004ry-PO for netconf@ietf.org; Sun, 06 Apr 2014 05:55:08 +0200 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-3.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WWeAd-0002xa-44 for netconf@ietf.org; Sun, 06 Apr 2014 05:54:59 +0200 Message-ID: <5340D011.10501@bwijnen.net> Date: Sun, 06 Apr 2014 05:54:57 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: netconf References: <20140405165803.1481.90261.idtracker@ietfa.amsl.com> In-Reply-To: <20140405165803.1481.90261.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140405165803.1481.90261.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a40e7fe4f674394b9a1b38c714e6f854 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JC4wWdUvHsgwLwgCq6TcBDXGY9Y Subject: [Netconf] Fwd: Reminder: xml2rfc v2 transition 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, 06 Apr 2014 03:55:18 -0000 For document editors/authors. I am not sure what this exactly menas yet (I have not tried to write a document with xml2rfc myself recently). But please be aware of the upcoming change. Bert -------- Original Message -------- Subject: Reminder: xml2rfc v2 transition Date: Sat, 05 Apr 2014 09:58:03 -0700 From: RFC Series Editor Reply-To: ietf@ietf.org, rfc-interest@rfc-editor.org To: IETF Announcement List CC: rfc-interest@rfc-editor.org As a reminder to the community, the RFC Editor will transition completely to xml2rfc v2 for processing XML source for drafts in July, 2014. That means that we will not be able to benefit from your XML source if it doesn't work with xml2rfc v2. Since we do appreciate receiving XML source for the drafts which are approved for publication, we encourage those who are still working with a tool-chain based on xml2rfc v1 (the TCL releases) to transition to v2 (the Python releases). The RFC Editor will continue to accept XML source for Internet-Drafts created using v1 that are approved for publication until 30 June 2014. Authors may also continue to submit documents in nroff or txt. The original announcement is available here: If you have questions about xml2rfc v2, please send them to the xml2rfc mailing list . Heather Flanagan, RFC Series Editor Jari Arkko, IETF Chair From nobody Mon Apr 7 06:19:53 2014 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 7FC951A0404 for ; Mon, 7 Apr 2014 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.691 X-Spam-Level: * X-Spam-Status: No, score=1.691 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 OeFTWwCm5lnx for ; Mon, 7 Apr 2014 06:19:45 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) by ietfa.amsl.com (Postfix) with ESMTP id D2B431A0403 for ; Mon, 7 Apr 2014 06:19:44 -0700 (PDT) Received: from AMXPRD0310HT005.eurprd03.prod.outlook.com (157.56.248.133) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 13:19:37 +0000 Message-ID: <000f01cf5263$caa53ba0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen References: <20140216.104746.335052742.mbj@tail-f.com> Date: Mon, 7 Apr 2014 10:54:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMSPR07CA002.eurprd07.prod.outlook.com (10.242.77.170) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Forefront-PRVS: 0174BD4BDA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(74662001)(93516002)(99396002)(93136001)(42186004)(44736004)(77156001)(88136002)(95416001)(85306002)(98676001)(87976001)(56816005)(23756003)(31966008)(50466002)(89996001)(53806001)(74502001)(47446002)(76786001)(90146001)(77096001)(14496001)(51856001)(558084003)(76796001)(50226001)(47976001)(95666003)(47736001)(4396001)(49866001)(69226001)(50986001)(59766001)(97336001)(94946001)(81542001)(74876001)(47776003)(63696002)(20776003)(46102001)(79102001)(44716002)(74366001)(62236002)(94316002)(54316002)(56776001)(74706001)(1941001)(80022001)(66066001)(62966002)(33646001)(87266001)(84392001)(80976001)(97186001)(77982001)(81342001)(92566001)(83322001)(65816001)(92726001)(86362001)(76482001)(93916002)(87286001)(83072002)(85852003)(61296002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB055; H:AMXPRD0310HT005.eurprd03.prod.outlook.com; FPR:9CD54658.341D5FA.6DC25EEB.11B2F045.2005B; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mkQrlpVkr_4Bb79qMiz0D26Un6I Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 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, 07 Apr 2014 13:19:49 -0000 Kent draft-ietf-netconf-rfc5539bis-03 had +--rw tls +--rw enabled? boolean which draft-kwatsen-netconf-server-00 lacks. Why? Tom Petch From nobody Mon Apr 7 08:05:10 2014 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 8E8241A0796; Mon, 7 Apr 2014 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 c78fGMY4ft53; Mon, 7 Apr 2014 08:05:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 527A01A045E; Mon, 7 Apr 2014 08:05:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407150503.3491.36270.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 08:05:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8_jI2f4unI6PpcCXuitCzW4S3OE Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:05:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Reverse SSH for NETCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-reverse-ssh-04.txt Pages : 10 Date : 2014-04-07 Abstract: This document presents a technique for a NETCONF server to initiate a SSH connection to a NETCONF client. This is accomplished by the NETCONF client listening on IANA-assigned TCP port YYYY and starting the SSH client protocol immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH server, in order for the NETCONF client to open the IANA-assigned SSH subsystem "netconf". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-reverse-ssh-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 7 08:29:26 2014 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 D4EEE1A0463; Mon, 7 Apr 2014 08:29:22 -0700 (PDT) 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 XTCAcWzNnne1; Mon, 7 Apr 2014 08:29:18 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id F1CD51A0366; Mon, 7 Apr 2014 08:29:17 -0700 (PDT) Received: from mail202-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Mon, 7 Apr 2014 15:28:58 +0000 Received: from mail202-ch1 (localhost [127.0.0.1]) by mail202-ch1-R.bigfish.com (Postfix) with ESMTP id BADD41C0071; Mon, 7 Apr 2014 15:28:57 +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: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I936eI154dI1432I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail202-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=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(164054003)(189002)(199002)(24454002)(377454003)(479174003)(377424004)(4396001)(49866001)(94946001)(74706001)(87936001)(97336001)(31966008)(83506001)(76796001)(69226001)(87266001)(76786001)(47976001)(74502001)(74662001)(47446002)(50986001)(47736001)(98676001)(85306002)(79102001)(95666003)(95416001)(83072002)(81816001)(77096001)(20776003)(36756003)(2656002)(86362001)(54356001)(66066001)(94316002)(93516002)(63696002)(92566001)(76482001)(19580395003)(56816005)(93136001)(54316002)(46102001)(92726001)(74366001)(83322001)(81542001)(80022001)(77982001)(81342001)(81686001)(74876001)(53806001)(97186001)(85852003)(59766001)(65816001)(56776001)(19580405001)(90146001)(80976001)(99396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:3CCCF175.ACF2EFC9.95FF917B.46E9DA5D.2030C; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail202-ch1 (localhost.localdomain [127.0.0.1]) by mail202-ch1 (MessageSwitch) id 139688453580549_3539; Mon, 7 Apr 2014 15:28:55 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail202-ch1.bigfish.com (Postfix) with ESMTP id 0FB934200A1; Mon, 7 Apr 2014 15:28:55 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 7 Apr 2014 15:28:54 +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.435.0; Mon, 7 Apr 2014 15:29:00 +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.913.9; Mon, 7 Apr 2014 15:28:58 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Mon, 7 Apr 2014 15:28:58 +0000 From: Kent Watsen To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-04.txt Thread-Index: AQHPUnLOkx3yKvhu3Ei0uW1S0+g+ypsGAHQA Date: Mon, 7 Apr 2014 15:28:58 +0000 Message-ID: References: <20140407150503.3491.36270.idtracker@ietfa.amsl.com> In-Reply-To: <20140407150503.3491.36270.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0174BD4BDA Content-Type: text/plain; charset="us-ascii" Content-ID: <406AE0584E48234DA8E26960F67D896F@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/5B-QOz_WGxeXCsqjLgFu2IuDLmA Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-04.txt 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, 07 Apr 2014 15:29:23 -0000 Please see the Change Log to see what's new in the draft. I have not heard back from Steve yet on the Applicability Statement. This is the only open issue I'm aware of and otherwise the draft is ready for last call. The draft contains a reference to "draft-ietf-netconf-server-model", which doesn't exist yet, as that draft was last submitted as "draft-kwatsen-netconf-server" and hasn't been updated yet. I don't believe this is an issue since the reference happens in text that clearly says the model is outside the scope. PS: Bert, I'm already using the xml2rfc v2 script Thanks, Kent On 4/7/14 11:05 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : Reverse SSH for NETCONF Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-reverse-ssh-04.txt > Pages : 10 > Date : 2014-04-07 > >Abstract: > This document presents a technique for a NETCONF server to initiate a > SSH connection to a NETCONF client. This is accomplished by the > NETCONF client listening on IANA-assigned TCP port YYYY and starting > the SSH client protocol immediately after accepting a TCP connection > on it. This role-reversal is necessary as the NETCONF server must > also be the SSH server, in order for the NETCONF client to open the > IANA-assigned SSH subsystem "netconf". > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-reverse-ssh-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From nobody Tue Apr 8 03:07:33 2014 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 B02AE1A02C2 for ; Tue, 8 Apr 2014 03:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 KLlmQrbiq7qO for ; Tue, 8 Apr 2014 03:07:25 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE6F1A01CD for ; Tue, 8 Apr 2014 03:07:25 -0700 (PDT) Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 10:07:18 +0000 Message-ID: <018201cf5312$160e8200$4001a8c0@gateway.2wire.net> From: t.petch To: Bert Wijnen , Netconf References: <5327288E.7060503@ripe.net> Date: Tue, 8 Apr 2014 11:04:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DB3PR07CA003.eurprd07.prod.outlook.com (10.242.134.43) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Forefront-PRVS: 017589626D X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(3?= =?iso-8859-1?Q?77454003)(13464003)(51444003)(51704005)(74662001)(15202345?= =?iso-8859-1?Q?003)(42186004)(87976001)(93136001)(44736004)(56816005)(954?= =?iso-8859-1?Q?16001)(88136002)(99396002)(93516002)(98676001)(85306002)(2?= =?iso-8859-1?Q?3756003)(31966008)(50466002)(89996001)(53806001)(74502001)?= =?iso-8859-1?Q?(47446002)(76786001)(14496001)(47976001)(47736001)(7679600?= =?iso-8859-1?Q?1)(4396001)(77096001)(49866001)(95666003)(90146001)(502260?= =?iso-8859-1?Q?01)(69226001)(77156001)(50986001)(15975445006)(59766001)(8?= =?iso-8859-1?Q?1542001)(74876001)(80022001)(47776003)(66066001)(63696002)?= =?iso-8859-1?Q?(20776003)(46102001)(79102001)(44716002)(74366001)(6223600?= =?iso-8859-1?Q?2)(94316002)(54316002)(56776001)(74706001)(83322001)(33646?= =?iso-8859-1?Q?001)(87266001)(92726001)(80976001)(81342001)(62966002)(973?= =?iso-8859-1?Q?36001)(65816001)(94946001)(84392001)(19580395003)(92566001?= =?iso-8859-1?Q?)(77982001)(85852003)(87286001)(76482001)(93916002)(863620?= =?iso-8859-1?Q?01)(83072002)(19580405001)(97186001)(61296002)(74416001)(7?= =?iso-8859-1?Q?726001);DIR:OUT;SFP:1101;SCL:1;SRVR:AMXPR07MB055;H:DBXPRD0?= =?iso-8859-1?Q?610HT003.eurprd06.prod.outlook.com;FPR:FC74F13C.ACF697D6.3?= =?iso-8859-1?Q?CD2237F.44E3D278.20386;MLV:sfv;PTR:InfoNoRecords;MX:1;A:0;?= =?iso-8859-1?Q?LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Yw1FIxvUWhXfYGH8Z3LisfoxCMA Subject: Re: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 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, 08 Apr 2014 10:07:30 -0000 I have read it and reviewed it and do not think that it is ready to advance. I think that the basic problem is the question of what goes in what document; an SSH one, a TLS one, a server config one or a system mgmt one, as flagged by the comments of Radek Krejc. This is still evolving and, for me, it is draft-kwatsen-netconf-server that must progress, since it contains a lot about transport and TLS and should be a normative reference for this, 5539bis. (I think that it was a mistake to separate the material that was in this I-D, but that that structure can be made to work as long as all the documents are treated as a set, with the information about one topic - e.g. keepalive, server cert validation - in one place; relational database anyone?). I note that Kent asks "Andy, if you're already updating netmod-system-mgmt, can we move the cert-maps, psk-maps into it? - and also add the configuration of system-wide trusted CA and client certs mentioned above?" Yes, that highlights the problem of document structure we have. Many structures can be made to work, but at the moment, I do not think we have one that does. I also agree with Radek's comments about terminology, an allied problem. Since we have TCP clients, TLS clients, NETCONF clients, ditto servers, then I think that every reference to client and server should be prefixed by TCP/TLS/NETCONF. (And, as Martin flagged on draft-kwatsen-netconf-server, application is another terminological minefield although this I-D is less affected by that one) Tom Petch ----- Original Message ----- From: "Bert Wijnen" To: "Netconf" Sent: Monday, March 17, 2014 5:53 PM Subject: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 > Dear NETCONF participants, > > We hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-05 > > The document acn be found at: > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-05 > > Pls review and send any comments (a comment aka: I read/reviewed it > and believe it is ready for publication" is also good input) to > the WG mailing lists not later than March 30th 2014 (any timezone). > > Any reports on implementation status or plans to implement are also > very useful. > > Bert and Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Apr 8 08:52:36 2014 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 906D41A0470 for ; Tue, 8 Apr 2014 08:52:34 -0700 (PDT) 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_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 2JU7J4u0ZRlL for ; Tue, 8 Apr 2014 08:52:29 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) by ietfa.amsl.com (Postfix) with ESMTP id 044591A0460 for ; Tue, 8 Apr 2014 08:52:28 -0700 (PDT) Received: from AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) by AMSPR07MB373.eurprd07.prod.outlook.com (10.242.21.13) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 15:52:28 +0000 Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.0.918.8; Tue, 8 Apr 2014 15:52:26 +0000 Message-ID: <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> From: t.petch To: "Bert Wijnen (IETF)" , Kent Watsen References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> Date: Tue, 8 Apr 2014 14:44:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: DB4PR07CA032.eurprd07.prod.outlook.com (10.242.229.42) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Forefront-PRVS: 017589626D X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(479174003)(377454?= =?iso-8859-1?Q?003)(189002)(199002)(51704005)(51444003)(24454002)(3577400?= =?iso-8859-1?Q?3)(41574002)(13464003)(23756003)(54316002)(76482001)(85306?= =?iso-8859-1?Q?002)(84392001)(93516002)(85852003)(50466002)(66066001)(597?= =?iso-8859-1?Q?66001)(74662001)(77982001)(80976001)(74366001)(31966008)(6?= =?iso-8859-1?Q?2966002)(83072002)(63696002)(49866001)(61296002)(79102001)?= =?iso-8859-1?Q?(44716002)(65816001)(53806002)(50986002)(47976002)(4773600?= =?iso-8859-1?Q?2)(47446003)(80022001)(44736004)(74706001)(62236002)(74876?= =?iso-8859-1?Q?001)(81342001)(4396001)(15975445006)(74502001)(56776001)(9?= =?iso-8859-1?Q?4946001)(47776003)(98676001)(81542001)(50226001)(20776003)?= =?iso-8859-1?Q?(46102001)(95416001)(99396002)(87976001)(94316002)(8636200?= =?iso-8859-1?Q?1)(69226001)(90146001)(77096001)(42186004)(97336001)(56816?= =?iso-8859-1?Q?005)(92726001)(88136002)(77156001)(97186001)(89996001)(144?= =?iso-8859-1?Q?96001)(92566001)(76786001)(93916002)(76796001)(95666003)(9?= =?iso-8859-1?Q?3136001)(33646001)(19580405001)(83322001)(87266001)(872860?= =?iso-8859-1?Q?01)(19580395003)(74416001)(7726001);DIR:OUT;SFP:1101;SCL:1?= =?iso-8859-1?Q?;SRVR:AMSPR07MB049;H:DBXPRD0510HT001.eurprd05.prod.outlook?= =?iso-8859-1?Q?.com;FPR:C6ECF156.ACFA5151.B2D3124B.52E4D3F1.20656;MLV:sfv?= =?iso-8859-1?Q?;PTR:InfoNoRecords;MX:1;A:0;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2SEAo7wdSqa63LuTitO7QIXcEXg Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 08 Apr 2014 15:52:34 -0000 I do not think that this is ready to advance. I had not intended to comment but having started on netconf-server, and found I had to read 5539bis to understand where it was going, I then found that reverse-ssh was another piece of the jigsaw. In particular, I think that this I-D is more or less updating RFC4742 in its considerations of security. And I think it may be confused about public keys and certificates and their role in authentication. Taken together, and I do not think they can be considered separately, I do not think that the three I-Ds give a coherent view of how to secure a NETCONF session. I would point to the queries raised by Tadek and Bajpai which, to me on the one hand seem spot on and on the other, seem to regard the subject material of these three I-Ds as of a one - which I obviously agree with. I think that netconf-server is the one in most need of progress and see it as a Normative, not Informative, prerequisite. Tom Petch ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Kent Watsen" Cc: Sent: Thursday, April 03, 2014 12:36 PM > WGLC period ended last Tuesday (April 1st). > > Kent, where are we with this one? > > Do you expect to post a rev 04 that addresses all comments we have received? > Either WGLC comments or other comments? Once that is done, I would like to ask: > - Kent to post which comments have not been addressed and why (if any) > - If possible, Kent to post a summary of changes (although that may already be > in the document, and that is fine too). > - All those that made comments to check if they are OK with the way that > they have been addressed or responded to. > > Bert > > On 27/03/14 17:02, Kent Watsen wrote: > > > > Hi Alan, > > > > > > Awesome comments - thanks! > > > > > > I applied all fixes mentioned below to my working copy of what will be > > -04, so you'll have to wait until then to see the diff. The reason I'm > > not posting -04 now is because I'm still trying to work out an issue with > > Applicability Statement and with the port's name. > > > > Below are my detailed responses. > > > > Cheers, > > Kent > > > > > > > > > > > > > > > >> Typos > >> ----- > >> > > > > I fixed all the issues you found. > > > > > > > > > > > > > >> Section 2.1, Page 3, Second Paragraph: (wording) > >> ------------------------------------------------- > >> > >> The second paragraph seems vague. Would something along the lines of > >> the following text be clearer and/or more specific? > > > > I forwarded this comment to Steve Hanna, who wrote the Applicability > > Statement. At first I was just going to ask if he was OK with the > > proposed text, but then I started thinking that I didn't agree with it. > > That is, I think that the SSH protocol does require mutual authentication > > and that NETCONF's requirement that it be possible to derive a "username" > > from the transport doesn't change that. I'm still OK limiting Reverse SSH > > to just NETCONF, but I want the reason to be accurate. I'm now waiting > > for a response from Steve on this. > > > > > > > > > > > > > > > >> Section 4, Page 4: (wording) > >> ----------------------------- > >> > >> The current text reads: > >> > >> o The NETCONF server initiates a TCP connection to the NETCONF > >> client on the IANA-assigned Reverse SSH port YYYY. > >> > >> o The TCP connection is accepted and a TCP session is established. > > > > > > I'm not sure about this change since these bullet-points are preceded by > > the line "From the NETCONF server's perspective:". The intent is to only > > explain the NETCONF-server's perspective, and to let the next section > > provide the client's perspective. Currently, neither section references > > the remote peer, so that its text remains squarely focused on its side of > > the connection. What do you think? > > > > > > > > > > > > > > > >> Section 5, Page 5, First Paragraph: (wording) > >> ---------------------------------------------- > >> > >> The current text reads: > >> > >> "When the management system accepts a new incoming connection, it > >> needs to authenticate the remote peer. Ultimately, this entails > >> identifying the peer and verifying its SSH host key. > >> > >> Due to Reverse SSH having the network element initiate the TCP > >> connection," > > > > > > I changed the wording to be more clear, but did it another way, please let > > me know if you think it's OK! > > > > > > > > > > > > > > > > > >> Section 5, Page 6, First Paragraph: (clarification) > >> ---------------------------------------------------- > >> > >> The current text reads: > >> > >> "However, configuring distinct host keys on the management system > >> doesn't scale well, which is an important consideration to a network > >> management system. A more scalable strategy is to have the network > >> element's host key signed by a common trusted key, such as a > >> certificate authority. Thus, the mangement system only needs to > >> trust a single public key, which vouches for the authenticity of the > >> various network element public keys." > >> > >> Please help me understand this. The way this paragraph is written, it > >> is not clear to me why "signing each network element's host key with a > >> common trusted key" scales better than "configuring distinct host keys > >> on the management system". > >> > >> In either of these two situations, it seems like an administrator must > >> do work for each network element. In one case, it is configuring host > >> keys, in another, it is signing each network element's host key. If > >> anything, it seems like signing a host key for each network element > >> requires _more_ work for each network element, so it seems like this > >> would scale less well. > >> > >> What am I missing here? > > > > > > Very good question. Of course it comes down to how the device's "entity > > certificates", as they are called, is distributed. In the best case, as > > described in the zero-touch draft, the device would ship from factory with > > a built-in entity-certificate, signed by a trust-chain to its vendor's > > well-known trust anchor. In this case, there is no additional effort > > needed, the management system only needs to trust the vendor's certificate > > for its well-known trust anchor. For cases where the device doesn't ship > > from factory with an entity-certificate, introducing PKI is still > > advantageous as it decouples the management-system from direct > > involvement, such that it could be outsourced to some 3rd-party. Makes > > sense? What update would you like to see in the draft? > > > > > > > > > > > > > > > > > >> Section 7, Page 7, Third Paragraph: (wording) > >> ---------------------------------------------- > >> > >> In a few places in the third paragraph, and possibly in other places > >> in the document, would changing "needs to" to lowercase "must", or > >> lowercase "should", make the document a little more concise? Example: > >> > >> "Note that since the SSH server would have to be configured to know > >> which IP address it needs to connect to," > >> ^^^^^^^^ > > > > > > I changed "needs to" to "is to" for this cited location and another I > > found. > > > > > > > > > > > > Thanks again, > > Kent > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 From nobody Tue Apr 8 09:24:20 2014 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 80C0E1A04AA for ; Tue, 8 Apr 2014 09:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 IW7hI_a3RyGF for ; Tue, 8 Apr 2014 09:24:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 84F841A0484 for ; Tue, 8 Apr 2014 09:24:09 -0700 (PDT) Received: from mail24-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Apr 2014 16:23:51 +0000 Received: from mail24-ch1 (localhost [127.0.0.1]) by mail24-ch1-R.bigfish.com (Postfix) with ESMTP id 5258E3E065B; Tue, 8 Apr 2014 16:23:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -38 X-BigFish: VPS-38(z579ehzbb2dI98dI9371I103dK542I1dbaI1432I1418I14e3M4015I111aIdf9Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail24-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: =?us-ascii?Q?SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(199002)(357?= =?us-ascii?Q?74003)(189002)(24454002)(479174003)(377454003)(51704005)(437?= =?us-ascii?Q?84003)(51444003)(164054003)(41574002)(53474002)(13464003)(19?= =?us-ascii?Q?580395003)(93136001)(56816005)(76482001)(81342001)(92726001)?= =?us-ascii?Q?(74366001)(46102001)(81542001)(83322001)(93516002)(94316002)?= =?us-ascii?Q?(66066001)(86362001)(63696002)(92566001)(77982001)(195804050?= =?us-ascii?Q?01)(56776001)(99396002)(80976001)(53806002)(50986002)(518560?= =?us-ascii?Q?02)(54316003)(74876001)(90146001)(65816001)(81686001)(800220?= =?us-ascii?Q?01)(15975445006)(97186001)(59766001)(85852003)(31966008)(835?= =?us-ascii?Q?06001)(76796001)(69226001)(76786001)(87266001)(4396001)(9494?= =?us-ascii?Q?6001)(49866001)(74706001)(81816001)(74502001)(97336001)(8793?= =?us-ascii?Q?6001)(36756003)(20776003)(2656002)(77096001)(98676001)(85306?= =?us-ascii?Q?002)(74662001)(99286001)(95416001)(79102001)(95666003)(83072?= =?us-ascii?Q?002)(54356002)(47736002)(47446003)(47976002)(969003)(989001)?= =?us-ascii?Q?(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:CO1PR?= =?us-ascii?Q?05MB458;H:CO1PR05MB458.namprd05.prod.outlook.com;FPR:66CF155?= =?us-ascii?Q?.A4DA5141.B2D1124B.52E4D3F1.206DE;MLV:ovrnspm;PTR:InfoNoReco?= =?us-ascii?Q?rds;A:1;MX:1;LANG:en;?= Received: from mail24-ch1 (localhost.localdomain [127.0.0.1]) by mail24-ch1 (MessageSwitch) id 1396974229812499_29328; Tue, 8 Apr 2014 16:23:49 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail24-ch1.bigfish.com (Postfix) with ESMTP id B76984400C2; Tue, 8 Apr 2014 16:23:49 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Apr 2014 16:23:48 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Tue, 8 Apr 2014 16:24:05 +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.913.9; Tue, 8 Apr 2014 16:24:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 16:24:02 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsHpGQA Date: Tue, 8 Apr 2014 16:24:01 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> In-Reply-To: <01f401cf5342$4d48d740$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.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 017589626D Content-Type: text/plain; charset="us-ascii" Content-ID: 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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/L06pg4tJPswifiG9pCxTP6IIVQc Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 08 Apr 2014 16:24:15 -0000 Hi Tom, Thank you for voicing my own thoughts as well. I had previously raised the idea of merging the reverse-ssh draft into a 4742bis, but the WG agreed to keep it separate for simplicity sake. That said, I like symmetry, and it would be more consistent for 5539bis and a 4447bis, rather than what we have now. Just saying ;) Regarding Normative vs Informative, I recently asked about this and Bert said that it comes down to if said draft needs to be understood and/or implemented. If this is the condition, then I believe it swings to being Informative, as proprietary vendor-specific configuration could be used alternatively. As it is, the vendor can decide if they want to advertise urn:ietf:params:xml:ns:yang:ietf-netconf-server-model in their message. Are you suggesting that advertising this capability in the message should be required in order for an implementation to claim they implement Reverse SSH for NETCONF Call Home? Thanks, Kent On 4/8/14 9:44 AM, "t.petch" wrote: >I do not think that this is ready to advance. I had not intended to >comment but having started on netconf-server, and found I had to read >5539bis to understand where it was going, I then found that reverse-ssh >was another piece of the jigsaw. > >In particular, I think that this I-D is more or less updating RFC4742 in >its considerations of security. And I think it may be confused about >public keys and certificates and their role in authentication. > >Taken together, and I do not think they can be considered separately, I >do not think that the three I-Ds give a coherent view of how to secure a >NETCONF session. > >I would point to the queries raised by Tadek and Bajpai which, to me on >the one hand seem spot on and on the other, seem to regard the subject >material of these three I-Ds as of a one - which I obviously agree with. > >I think that netconf-server is the one in most need of progress and see >it as a Normative, not Informative, prerequisite. > >Tom Petch > > >----- Original Message ----- >From: "Bert Wijnen (IETF)" >To: "Kent Watsen" >Cc: >Sent: Thursday, April 03, 2014 12:36 PM > >> WGLC period ended last Tuesday (April 1st). >> >> Kent, where are we with this one? >> >> Do you expect to post a rev 04 that addresses all comments we have >received? >> Either WGLC comments or other comments? Once that is done, I would >like to ask: >> - Kent to post which comments have not been addressed and why (if any) >> - If possible, Kent to post a summary of changes (although that may >already be >> in the document, and that is fine too). >> - All those that made comments to check if they are OK with the way >that >> they have been addressed or responded to. >> >> Bert >> >> On 27/03/14 17:02, Kent Watsen wrote: >> > >> > Hi Alan, >> > >> > >> > Awesome comments - thanks! >> > >> > >> > I applied all fixes mentioned below to my working copy of what will >be >> > -04, so you'll have to wait until then to see the diff. The reason >I'm >> > not posting -04 now is because I'm still trying to work out an issue >with >> > Applicability Statement and with the port's name. >> > >> > Below are my detailed responses. >> > >> > Cheers, >> > Kent >> > >> > >> > >> > >> > >> > >> > >> >> Typos >> >> ----- >> >> >> > >> > I fixed all the issues you found. >> > >> > >> > >> > >> > >> > >> >> Section 2.1, Page 3, Second Paragraph: (wording) >> >> ------------------------------------------------- >> >> >> >> The second paragraph seems vague. Would something along the lines >of >> >> the following text be clearer and/or more specific? >> > >> > I forwarded this comment to Steve Hanna, who wrote the Applicability >> > Statement. At first I was just going to ask if he was OK with the >> > proposed text, but then I started thinking that I didn't agree with >it. >> > That is, I think that the SSH protocol does require mutual >authentication >> > and that NETCONF's requirement that it be possible to derive a >"username" >> > from the transport doesn't change that. I'm still OK limiting >Reverse SSH >> > to just NETCONF, but I want the reason to be accurate. I'm now >waiting >> > for a response from Steve on this. >> > >> > >> > >> > >> > >> > >> > >> >> Section 4, Page 4: (wording) >> >> ----------------------------- >> >> >> >> The current text reads: >> >> >> >> o The NETCONF server initiates a TCP connection to the NETCONF >> >> client on the IANA-assigned Reverse SSH port YYYY. >> >> >> >> o The TCP connection is accepted and a TCP session is >established. >> > >> > >> > I'm not sure about this change since these bullet-points are >preceded by >> > the line "From the NETCONF server's perspective:". The intent is to >only >> > explain the NETCONF-server's perspective, and to let the next >section >> > provide the client's perspective. Currently, neither section >references >> > the remote peer, so that its text remains squarely focused on its >side of >> > the connection. What do you think? >> > >> > >> > >> > >> > >> > >> > >> >> Section 5, Page 5, First Paragraph: (wording) >> >> ---------------------------------------------- >> >> >> >> The current text reads: >> >> >> >> "When the management system accepts a new incoming connection, >it >> >> needs to authenticate the remote peer. Ultimately, this >entails >> >> identifying the peer and verifying its SSH host key. >> >> >> >> Due to Reverse SSH having the network element initiate the TCP >> >> connection," >> > >> > >> > I changed the wording to be more clear, but did it another way, >please let >> > me know if you think it's OK! >> > >> > >> > >> > >> > >> > >> > >> > >> >> Section 5, Page 6, First Paragraph: (clarification) >> >> ---------------------------------------------------- >> >> >> >> The current text reads: >> >> >> >> "However, configuring distinct host keys on the management >system >> >> doesn't scale well, which is an important consideration to a >network >> >> management system. A more scalable strategy is to have the >network >> >> element's host key signed by a common trusted key, such as a >> >> certificate authority. Thus, the mangement system only needs to >> >> trust a single public key, which vouches for the authenticity of >the >> >> various network element public keys." >> >> >> >> Please help me understand this. The way this paragraph is written, >it >> >> is not clear to me why "signing each network element's host key >with a >> >> common trusted key" scales better than "configuring distinct host >keys >> >> on the management system". >> >> >> >> In either of these two situations, it seems like an administrator >must >> >> do work for each network element. In one case, it is configuring >host >> >> keys, in another, it is signing each network element's host key. >If >> >> anything, it seems like signing a host key for each network element >> >> requires _more_ work for each network element, so it seems like >this >> >> would scale less well. >> >> >> >> What am I missing here? >> > >> > >> > Very good question. Of course it comes down to how the device's >"entity >> > certificates", as they are called, is distributed. In the best >case, as >> > described in the zero-touch draft, the device would ship from >factory with >> > a built-in entity-certificate, signed by a trust-chain to its >vendor's >> > well-known trust anchor. In this case, there is no additional >effort >> > needed, the management system only needs to trust the vendor's >certificate >> > for its well-known trust anchor. For cases where the device doesn't >ship >> > from factory with an entity-certificate, introducing PKI is still >> > advantageous as it decouples the management-system from direct >> > involvement, such that it could be outsourced to some 3rd-party. >Makes >> > sense? What update would you like to see in the draft? >> > >> > >> > >> > >> > >> > >> > >> > >> >> Section 7, Page 7, Third Paragraph: (wording) >> >> ---------------------------------------------- >> >> >> >> In a few places in the third paragraph, and possibly in other >places >> >> in the document, would changing "needs to" to lowercase "must", or >> >> lowercase "should", make the document a little more concise? >Example: >> >> >> >> "Note that since the SSH server would have to be configured to >know >> >> which IP address it needs to connect to," >> >> ^^^^^^^^ >> > >> > >> > I changed "needs to" to "is to" for this cited location and another >I >> > found. >> > >> > >> > >> > >> > >> > Thanks again, >> > Kent >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > > From nobody Tue Apr 8 09:30:40 2014 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 520D61A04A6 for ; Tue, 8 Apr 2014 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 ETELchNF5YPv for ; Tue, 8 Apr 2014 09:30:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe008.messaging.microsoft.com [65.55.88.32]) by ietfa.amsl.com (Postfix) with ESMTP id E20991A0484 for ; Tue, 8 Apr 2014 09:30:35 -0700 (PDT) Received: from mail25-tx2-R.bigfish.com (10.9.14.231) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Apr 2014 16:30:18 +0000 Received: from mail25-tx2 (localhost [127.0.0.1]) by mail25-tx2-R.bigfish.com (Postfix) with ESMTP id E7C161A0240; Tue, 8 Apr 2014 16:30:17 +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: VPS2(z579ehz1432I4015I12dclzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail25-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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(164054003)(51704005)(77096001)(90146001)(87936001)(97336001)(56816005)(69226001)(86362001)(97186001)(92726001)(94316002)(46102001)(95416001)(93136001)(95666003)(99396002)(2656002)(92566001)(83322001)(54316003)(36756003)(87266001)(76796001)(76786001)(85852003)(93516002)(59766001)(74662001)(77982001)(74366001)(31966008)(80976001)(66066001)(81686001)(81816001)(76482001)(85306002)(74502001)(83506001)(98676001)(56776001)(81342001)(94946001)(4396001)(81542001)(20776003)(63696002)(83072002)(80022001)(65816001)(74876001)(49866001)(50986002)(74706001)(53806002)(47736002)(54356002)(79102001)(47446003)(47976002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:FC58441D.2DE210E7.68E29FEF.44D09931.2017D; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail25-tx2 (localhost.localdomain [127.0.0.1]) by mail25-tx2 (MessageSwitch) id 1396974615641027_5213; Tue, 8 Apr 2014 16:30:15 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.246]) by mail25-tx2.bigfish.com (Postfix) with ESMTP id 3774622006D; Tue, 8 Apr 2014 16:30:15 +0000 (UTC) Received: from BL2PRD0510HT004.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; Tue, 8 Apr 2014 16:30:14 +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.435.0; Tue, 8 Apr 2014 16:30:31 +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.918.8; Tue, 8 Apr 2014 16:30:28 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 16:30:27 +0000 From: Kent Watsen To: t.petch , Bert Wijnen , Netconf Thread-Topic: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 Thread-Index: AQHPQgGJ/fnLQrDOhkW0AQHs2dYqnpsHoM9lgAAn4QA= Date: Tue, 8 Apr 2014 16:30:26 +0000 Message-ID: References: <5327288E.7060503@ripe.net> <018201cf5312$160e8200$4001a8c0@gateway.2wire.net> In-Reply-To: <018201cf5312$160e8200$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.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 017589626D Content-Type: text/plain; charset="us-ascii" Content-ID: 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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Sk7a1hWx--uOOrX9CmOICFSpSHA Subject: Re: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 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, 08 Apr 2014 16:30:37 -0000 >I note that Kent asks > >"Andy, if you're already updating netmod-system-mgmt, can we move the >cert-maps, psk-maps into it? - and also add the configuration of >system-wide trusted CA and client certs mentioned above?" > >Yes, that highlights the problem of document structure we have. Many >structures can be made to work, but at the moment, I do not think we >have one that does. I'm not sure if it's Andy's call now, so much as the NETMOD WB chairs (Juergen?) which might explain why Andy didn't reply before. I am waiting for this to get settled, as it is partially holding up the update for draft-ietf-netconf-server-model. Thanks, Kent From nobody Tue Apr 8 09:43:31 2014 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 EECCF1A0431 for ; Tue, 8 Apr 2014 09:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 MLWXQ7hP2LcP for ; Tue, 8 Apr 2014 09:43:23 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEC11A03C4 for ; Tue, 8 Apr 2014 09:43:22 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id x13so1383376qcv.15 for ; Tue, 08 Apr 2014 09:43:22 -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=bWjXFhZdqe0vju89+MJw2dMoi/0Kt9Pon+MJNC4JFPc=; b=eX8MjIZlc3PAW8lygwXBBDChBWL9bmr20SskRRCw/KVTVQmX09k5ddn2deLV+j111Y GYYbuA9+I0tFM8kT4ip2rNL+BhtFy9sWXmmZ9iieNQjEXoiUrl0peQcYD+rqTv7jNZnJ KP106gvn97Z3BwpseN13YuWfN9RCwtuFn04ayhG51kKjrMPHrWxB1GxicNkko5krjNyg L5t8bFM2tCSscoxm/on4oiSBAKzaMc7h9W2i4zgijCqaq+7662RyxY8FkercV57+OZfq t4LU4I7yplEs74Qp3ydBaI4jZdGjFZ59E7vxUHuzDsAkVbxRYs4vYKCZPbF3lc3XUGao Hjrw== X-Gm-Message-State: ALoCoQmMDqdhDRfc6iDkGEHbWyOYBV5U7P+dbDKZbtHxNqx6WS5vqKmOvANB/jQjq9h6rxbr6ceC MIME-Version: 1.0 X-Received: by 10.224.165.1 with SMTP id g1mr5998406qay.16.1396975402153; Tue, 08 Apr 2014 09:43:22 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 8 Apr 2014 09:43:22 -0700 (PDT) In-Reply-To: References: <5327288E.7060503@ripe.net> <018201cf5312$160e8200$4001a8c0@gateway.2wire.net> Date: Tue, 8 Apr 2014 09:43:22 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0153819a9b0bc604f68aaef9 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rrGkc9x_Tn3ntbIvATZfs8LUSBQ Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 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, 08 Apr 2014 16:43:29 -0000 --089e0153819a9b0bc604f68aaef9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 8, 2014 at 9:30 AM, Kent Watsen wrote: > > > > >I note that Kent asks > > > >"Andy, if you're already updating netmod-system-mgmt, can we move the > >cert-maps, psk-maps into it? - and also add the configuration of > >system-wide trusted CA and client certs mentioned above?" > > > >Yes, that highlights the problem of document structure we have. Many > >structures can be made to work, but at the moment, I do not think we > >have one that does. > > > I'm not sure if it's Andy's call now, so much as the NETMOD WB chairs > (Juergen?) which might explain why Andy didn't reply before. I am > waiting for this to get settled, as it is partially holding up the update > for draft-ietf-netconf-server-model. > > The system draft will need to have another WGLC to hopefully resolve some DISCUSS comments. I don't know if the WG prefers to finish the system module or keep adding new features. I prefer to just address the DISCUSS comments and publish. Starting the entire review cycle over again is a waste of time and energy. > Thanks, > Kent > > Andy --089e0153819a9b0bc604f68aaef9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 8, 2014 at 9:30 AM, Kent Watsen <<= a href=3D"mailto:kwatsen@juniper.net" target=3D"_blank">kwatsen@juniper.net= > wrote:



>I note that Kent asks
>
>"Andy, if you're already updating netmod-system-mgmt, can we m= ove the
>cert-maps, psk-maps into it? =A0- and also add the configuration of
>system-wide trusted CA and client certs mentioned above?"
>
>Yes, that highlights the problem of document structure we have. =A0Many=
>structures can be made to work, but at the moment, I do not think we >have one that does.


I'm not sure if it's Andy's call now, so much as the NETMOD WB = chairs
(Juergen?) which might explain why Andy didn't reply before. =A0 I am waiting for this to get settled, as it is partially holding up the update for draft-ietf-netconf-server-model.


The system draft will need to have ano= ther WGLC to hopefully
resolve some DISCUSS comments.
<= br>
I don't know if the WG prefers to finish the system modul= e
or keep adding new features. =A0I prefer to just address the DISCUSS
comments and publish. =A0Starting the entire review cycle over aga= in
is a waste of time and energy.

=A0
Thanks,
Kent



Andy

--089e0153819a9b0bc604f68aaef9-- From nobody Tue Apr 8 09:47:50 2014 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 ADE411A041E for ; Tue, 8 Apr 2014 09:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 dNL7vOtnOjdP for ; Tue, 8 Apr 2014 09:47:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8A51A041B for ; Tue, 8 Apr 2014 09:47:41 -0700 (PDT) Received: from mail58-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE021.bigfish.com (10.43.70.78) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Apr 2014 16:47:23 +0000 Received: from mail58-ch1 (localhost [127.0.0.1]) by mail58-ch1-R.bigfish.com (Postfix) with ESMTP id 745661A04B2 for ; Tue, 8 Apr 2014 16:47:23 +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: -3 X-BigFish: VPS-3(zz1432I1418I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail58-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=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(51704005)(51444003)(164054003)(93136001)(56816005)(46102001)(74366001)(92726001)(81342001)(81542001)(83322001)(93516002)(77982001)(94316002)(66066001)(86362001)(76482001)(92566001)(63696002)(56776001)(99396002)(80976001)(53806002)(50986002)(54316003)(74876001)(90146001)(65816001)(81686001)(31966008)(80022001)(97186001)(59766001)(85852003)(83506001)(76796001)(69226001)(76786001)(87266001)(4396001)(94946001)(49866001)(74706001)(81816001)(74502001)(97336001)(87936001)(36756003)(20776003)(2656002)(77096001)(98676001)(85306002)(74662001)(95416001)(79102001)(95666003)(83072002)(54356002)(47446003)(47976002)(47736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:FD8526C.A102273A.5EC093FB.C4EDFEC9.20214; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1 (MessageSwitch) id 139697564286736_19290; Tue, 8 Apr 2014 16:47:22 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail58-ch1.bigfish.com (Postfix) with ESMTP id 049AB2E0103; Tue, 8 Apr 2014 16:47:22 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Apr 2014 16:47:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.435.0; Tue, 8 Apr 2014 16:47:37 +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.913.9; Tue, 8 Apr 2014 16:47:35 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 16:47:35 +0000 From: Kent Watsen To: t.petch Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-server-00 Thread-Index: AQHPKv0ucc5p8aJ330OdaW2Ybc6v6pq7ahEAgAkOewCAQfmZuoABiUoA Date: Tue, 8 Apr 2014 16:47:34 +0000 Message-ID: References: <20140216.104746.335052742.mbj@tail-f.com> <000f01cf5263$caa53ba0$4001a8c0@gateway.2wire.net> In-Reply-To: <000f01cf5263$caa53ba0$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.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 017589626D Content-Type: text/plain; charset="us-ascii" Content-ID: <529892B1EE2BCD4280E17CBEA5146B24@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/J1lad44sA3bTKUK3RR1O8JCVRV4 Cc: "netconf@ietf.org" Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 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, 08 Apr 2014 16:47:44 -0000 >draft-ietf-netconf-rfc5539bis-03 had > > +--rw tls > +--rw enabled? boolean > >which draft-kwatsen-netconf-server-00 lacks. Why? > >Tom Petch This must've gotten dropped do to the draft-kwatsen-netconf-server model having a didn't structure, but as the original 5539 had no model, I think that it's a fair topic for discussion. Personally, I'd rather stick with the original intent of presence containers: "enabled" if-and-only-if "configured". We're using these "enabled" configuration nodes as a substitute to having XML attributes for metadata describing the node's enablement, such as is described in draft-kwatsen-conditional-enablement. At the time that draft was written, there didn't seem to be much interest, but then later I heard some support from Andy. My thinking is to dust it off and get it going again, maybe something simpler this time. Again, I'm thinking that it's OK, and even a good thing, to just use the original intent of presence containers for now, knowing that a more complete solution (which is clearly in demand) is right around the corner. What do people think? Is there support to work on draft-kwatsen-conditional-enablement? Thanks, Kent From nobody Tue Apr 8 09:49:36 2014 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 A20DD1A03C4 for ; Tue, 8 Apr 2014 09:49:32 -0700 (PDT) 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_HELO_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 ME3z-xZjLGzz for ; Tue, 8 Apr 2014 09:49:22 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA81A056D for ; Tue, 8 Apr 2014 09:49:13 -0700 (PDT) Received: from AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) by AMSPR07MB294.eurprd07.prod.outlook.com (10.242.20.14) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 16:49:12 +0000 Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.0.918.8; Tue, 8 Apr 2014 16:49:11 +0000 Message-ID: <03ac01cf534a$3b2e2940$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen References: <20140407150503.3491.36270.idtracker@ietfa.amsl.com> Date: Tue, 8 Apr 2014 17:44:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AMSPR07CA014.eurprd07.prod.outlook.com (10.242.225.172) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Forefront-PRVS: 017589626D X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(479174003)(377454?= =?iso-8859-1?Q?003)(189002)(199002)(51704005)(164054003)(24454002)(377424?= =?iso-8859-1?Q?004)(13464003)(23756003)(76482001)(85306002)(93516002)(746?= =?iso-8859-1?Q?62001)(85852003)(84392001)(50466002)(66066001)(74366001)(3?= =?iso-8859-1?Q?1966008)(59766001)(77982001)(80976001)(83072002)(62966002)?= =?iso-8859-1?Q?(63696002)(61296002)(49866001)(79102001)(53806002)(6581600?= =?iso-8859-1?Q?1)(44716002)(50986002)(54316003)(44736004)(80022001)(74706?= =?iso-8859-1?Q?001)(74876001)(62236002)(81342001)(15975445006)(4396001)(5?= =?iso-8859-1?Q?6776001)(74502001)(47776003)(98676001)(94946001)(81542001)?= =?iso-8859-1?Q?(50226001)(20776003)(46102001)(95416001)(99396002)(8797600?= =?iso-8859-1?Q?1)(94316002)(86362001)(69226001)(90146001)(77096001)(42186?= =?iso-8859-1?Q?004)(97336001)(56816005)(92726001)(88136002)(77156001)(971?= =?iso-8859-1?Q?86001)(89996001)(14496001)(92566001)(76786001)(76796001)(9?= =?iso-8859-1?Q?3916002)(93136001)(95666003)(33646001)(19580405001)(833220?= =?iso-8859-1?Q?01)(87266001)(87286001)(19580395003)(47446003)(47976002)(4?= =?iso-8859-1?Q?7736002)(74416001)(7726001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM?= =?iso-8859-1?Q?SPR07MB049;H:DBXPRD0510HT004.eurprd05.prod.outlook.com;FPR?= =?iso-8859-1?Q?:3CCCF175.ACF2EFCA.B5FF914B.46E9DA5D.203C3;MLV:sfv;PTR:Inf?= =?iso-8859-1?Q?oNoRecords;MX:1;A:0;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/t8f0T6crLMVmgrl9R8OZ-wZ2c1s Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-04.txt 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, 08 Apr 2014 16:49:32 -0000 Kent I saw your exchange with Alan about the paragraph starting "However, configuring distinct host keys on the management system doesn't scale well, which is an important consideration to a network management system. " That sounds plausible but seems to me to undermine the use of SSH for NETCONF generally, nothing to do with call home. Why is this not an implicit update to RFC4742? Tom Petch ----- Original Message ----- From: "Kent Watsen" To: ; Cc: Sent: Monday, April 07, 2014 4:28 PM > > Please see the Change Log to see what's new in the draft. > > I have not heard back from Steve yet on the Applicability Statement. This > is the only open issue I'm aware of and otherwise the draft is ready for > last call. > > The draft contains a reference to "draft-ietf-netconf-server-model", which > doesn't exist yet, as that draft was last submitted as > "draft-kwatsen-netconf-server" and hasn't been updated yet. I don't > believe this is an issue since the reference happens in text that clearly > says the model is outside the scope. > > PS: Bert, I'm already using the xml2rfc v2 script > > Thanks, > Kent > > > > On 4/7/14 11:05 AM, "internet-drafts@ietf.org" > wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Network Configuration Working Group of > >the IETF. > > > > Title : Reverse SSH for NETCONF Call Home > > Author : Kent Watsen > > Filename : draft-ietf-netconf-reverse-ssh-04.txt > > Pages : 10 > > Date : 2014-04-07 > > > >Abstract: > > This document presents a technique for a NETCONF server to initiate a > > SSH connection to a NETCONF client. This is accomplished by the > > NETCONF client listening on IANA-assigned TCP port YYYY and starting > > the SSH client protocol immediately after accepting a TCP connection > > on it. This role-reversal is necessary as the NETCONF server must > > also be the SSH server, in order for the NETCONF client to open the > > IANA-assigned SSH subsystem "netconf". > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-04 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-reverse-ssh-04 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >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 From nobody Tue Apr 8 09:51:50 2014 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 91B081A050E for ; Tue, 8 Apr 2014 09:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 d8CvQx2XIrV6 for ; Tue, 8 Apr 2014 09:51:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4728D1A03E4 for ; Tue, 8 Apr 2014 09:51:27 -0700 (PDT) Received: from mail3-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Apr 2014 16:51:09 +0000 Received: from mail3-am1 (localhost [127.0.0.1]) by mail3-am1-R.bigfish.com (Postfix) with ESMTP id DFA43480489; Tue, 8 Apr 2014 16:51:08 +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: -2 X-BigFish: VPS-2(z579ehz1432I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail3-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=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(51704005)(199002)(189002)(74366001)(94946001)(83506001)(74706001)(74876001)(63696002)(76786001)(76796001)(93516002)(46102001)(86362001)(36756003)(81542001)(80976001)(81686001)(31966008)(74662001)(95666003)(81816001)(54316003)(74502001)(79102001)(95416001)(77096001)(20776003)(66066001)(59766001)(77982001)(65816001)(80022001)(85852003)(97336001)(47736002)(81342001)(98676001)(47446003)(53806002)(69226001)(83072002)(90146001)(54356002)(56816005)(56776001)(76482001)(50986002)(97186001)(92726001)(92566001)(83322001)(87266001)(19580405001)(19580395003)(94316002)(2656002)(85306002)(49866001)(47976002)(99396002)(87936001)(4396001)(93136001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:FEF6C694.90124407.C9520354.C4EE9961.2015B; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail3-am1 (localhost.localdomain [127.0.0.1]) by mail3-am1 (MessageSwitch) id 1396975867123846_20583; Tue, 8 Apr 2014 16:51:07 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.232]) by mail3-am1.bigfish.com (Postfix) with ESMTP id 1A962801F7; Tue, 8 Apr 2014 16:51:07 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Apr 2014 16:51:06 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Tue, 8 Apr 2014 16:51:21 +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.913.9; Tue, 8 Apr 2014 16:51:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 16:51:19 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 Thread-Index: AQHPQgGJ/fnLQrDOhkW0AQHs2dYqnpsHoM9lgAAn4QCAAEabAP//vycA Date: Tue, 8 Apr 2014 16:51:18 +0000 Message-ID: References: <5327288E.7060503@ripe.net> <018201cf5312$160e8200$4001a8c0@gateway.2wire.net> 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.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 017589626D Content-Type: text/plain; charset="us-ascii" Content-ID: <8DC7CB25B9C6E741950D5DC773A0736C@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RGp0Tip0Rbk6NeXIcxRQnK0s7tk Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 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, 08 Apr 2014 16:51:39 -0000 From: Andy Bierman > > The system draft will need to have another WGLC to hopefully > resolve some DISCUSS comments. > > I don't know if the WG prefers to finish the system module > or keep adding new features. I prefer to just address the DISCUSS > comments and publish. Starting the entire review cycle over again > is a waste of time and energy. Can we add this to the DISCUSS list? Regardless, it needs to be discussed. Don't you agree that the psk-maps, cert-maps, and the configuring of system-wide trusted CA and client certs should be in the draft that claims to support user-authentication? Thanks, Kent From nobody Tue Apr 8 09:53:51 2014 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 302F71A056D for ; Tue, 8 Apr 2014 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 sIUbLeQY7FCP for ; Tue, 8 Apr 2014 09:53:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id B81CE1A0537 for ; Tue, 8 Apr 2014 09:53:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6ABFA1024; Tue, 8 Apr 2014 18:53:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lYtXM10a9ZCd; Tue, 8 Apr 2014 18:53:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Apr 2014 18:53:40 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEDB020034; Tue, 8 Apr 2014 18:53:40 +0200 (CEST) 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 17f0WLKkoryg; Tue, 8 Apr 2014 18:53:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCE4C2002F; Tue, 8 Apr 2014 18:53:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0245F2C2CE67; Tue, 8 Apr 2014 18:53:34 +0200 (CEST) Date: Tue, 8 Apr 2014 18:53:34 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140408165334.GF6864@elstar.local> Mail-Followup-To: Kent Watsen , "t.petch" , "netconf@ietf.org" References: <20140216.104746.335052742.mbj@tail-f.com> <000f01cf5263$caa53ba0$4001a8c0@gateway.2wire.net> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GgLQBxzKcHT5O1ZkjU_jy2Y3uJM Cc: "netconf@ietf.org" Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 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, 08 Apr 2014 16:53:46 -0000 The enabled with a default true leaf allows to disable a transport without having to remove all config. There is currently no other mechanism available in RFCs to do this and hence this pattern may still have value. /js On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote: > > > > >draft-ietf-netconf-rfc5539bis-03 had > > > > +--rw tls > > +--rw enabled? boolean > > > >which draft-kwatsen-netconf-server-00 lacks. Why? > > > >Tom Petch > > > This must've gotten dropped do to the draft-kwatsen-netconf-server model > having a didn't structure, but as the original 5539 had no model, I think > that it's a fair topic for discussion. > > Personally, I'd rather stick with the original intent of presence > containers: "enabled" if-and-only-if "configured". We're using these > "enabled" configuration nodes as a substitute to having XML attributes for > metadata describing the node's enablement, such as is described in > draft-kwatsen-conditional-enablement. At the time that draft was written, > there didn't seem to be much interest, but then later I heard some support > from Andy. My thinking is to dust it off and get it going again, maybe > something simpler this time. > > Again, I'm thinking that it's OK, and even a good thing, to just use the > original intent of presence containers for now, knowing that a more > complete solution (which is clearly in demand) is right around the corner. > What do people think? Is there support to work on > draft-kwatsen-conditional-enablement? > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 8 09:58:43 2014 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 319EA1A04A1 for ; Tue, 8 Apr 2014 09:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BXQ2zIpbXoSC for ; Tue, 8 Apr 2014 09:58:37 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by ietfa.amsl.com (Postfix) with ESMTP id 556F51A041E for ; Tue, 8 Apr 2014 09:58:37 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so300762qge.26 for ; Tue, 08 Apr 2014 09:58:37 -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=bRjjte1bqcV6Ysq441JPJfsr4jF9kxbH8iq+EsYafDA=; b=DLDI8LbmPzYYYTWz8XJ8lr3YnhpVYXKTSwneJIvWGo0Y19qb9O9XZFV52/0bp1T3pE GsBOwOTNDJ8P//EY7Gem5WTbKAbkdPF7cuv8HP0BlJaGBQSvIket2bXNuSFrPl7pR2j+ o8SAiAxkZ1hBS3HVYQE5jdirdrGcCa4oAkjgl+y2AWqfQe0UlDfEbqWAjF+3qpk+4rb0 YFvc0Xi7CZEc7/Q6w9UlmTecYyjgOXIwgDOsc8DkW0+q3Au0JIfvJlTDN1q6OkgPaGvz W0FI3WakwomyEYCO1bOgV1DrmiCo8or4CDzer44OY1hWQi3XKJQKQ/llvu07iKToTshK TILA== X-Gm-Message-State: ALoCoQn0vAo3WTRqFkbAehoiRE5+qhwTkAc8fJQzB5JURHA0wqjvxlPbGEaE/4UfJgLAPKaIhyqF MIME-Version: 1.0 X-Received: by 10.140.92.110 with SMTP id a101mr5765544qge.34.1396976317019; Tue, 08 Apr 2014 09:58:37 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 8 Apr 2014 09:58:36 -0700 (PDT) In-Reply-To: References: <5327288E.7060503@ripe.net> <018201cf5312$160e8200$4001a8c0@gateway.2wire.net> Date: Tue, 8 Apr 2014 09:58:36 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a113ab2a822ccc204f68ae5ec Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6GqITYhENPf2p9IzLYyVBXoCovw Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 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, 08 Apr 2014 16:58:38 -0000 --001a113ab2a822ccc204f68ae5ec Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 8, 2014 at 9:51 AM, Kent Watsen wrote: > > > > From: Andy Bierman > > > > The system draft will need to have another WGLC to hopefully > > resolve some DISCUSS comments. > > > > I don't know if the WG prefers to finish the system module > > or keep adding new features. I prefer to just address the DISCUSS > > comments and publish. Starting the entire review cycle over again > > is a waste of time and energy. > > Can we add this to the DISCUSS list? Regardless, it needs to be > discussed. Don't you agree that the psk-maps, cert-maps, and the > configuring of system-wide trusted CA and client certs should be in the > draft that claims to support user-authentication? > > I was referring to IESG DISCUSS, not WG discuss ;-) I think the Document Shepherd and IESG need to decide what the WG can change. > Thanks, > Kent > > > Andy --001a113ab2a822ccc204f68ae5ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 8, 2014 at 9:51 AM, Kent Watsen <<= a href=3D"mailto:kwatsen@juniper.net" target=3D"_blank">kwatsen@juniper.net= > wrote:



From: =A0Andy Bierman <andy@yumawo= rks.com>
>
> The system draft will need to have another WGLC to hopefully
> resolve some DISCUSS comments.
>
> I don't know if the WG prefers to finish the system module
> or keep adding new features. =A0I prefer to just address the DISCUSS > comments and publish. =A0Starting the entire review cycle over again > is a waste of time and energy.

Can we add this to the DISCUSS list? =A0Regardless, it needs to be
discussed. =A0Don't you agree that the psk-maps, cert-maps, and the
configuring of system-wide trusted CA and client certs should be in the
draft that claims to support user-authentication?



I was referring to IESG= DISCUSS, not WG discuss ;-)
I think the Document Shepherd and IE= SG need to decide what the WG can change.


=A0
Thanks,
Kent



Andy

--001a113ab2a822ccc204f68ae5ec-- From nobody Tue Apr 8 10:13:11 2014 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 5F8D11A064F for ; Tue, 8 Apr 2014 10:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 q6TZVaEO1xa8 for ; Tue, 8 Apr 2014 10:13:02 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 48D761A0479 for ; Tue, 8 Apr 2014 10:13:01 -0700 (PDT) Received: from mail113-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Apr 2014 17:12:43 +0000 Received: from mail113-tx2 (localhost [127.0.0.1]) by mail113-tx2-R.bigfish.com (Postfix) with ESMTP id 79D973A038B for ; Tue, 8 Apr 2014 17:12:43 +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: -6 X-BigFish: VPS-6(zzbb2dI98dI9371I1dbaI1432I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail113-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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(24454002)(164054003)(51704005)(479174003)(377454003)(76482001)(56776001)(50986002)(97186001)(98676001)(47446003)(97336001)(47736002)(81342001)(90146001)(56816005)(54356002)(53806002)(69226001)(83072002)(47976002)(2656002)(85306002)(49866001)(4396001)(87936001)(54316003)(93136001)(99396002)(83322001)(19580395003)(19580405001)(87266001)(92566001)(92726001)(94316002)(46102001)(86362001)(93516002)(36756003)(83506001)(94946001)(74706001)(74876001)(74366001)(63696002)(76786001)(76796001)(20776003)(95416001)(79102001)(77096001)(65816001)(85852003)(80022001)(77982001)(66066001)(59766001)(80976001)(81686001)(81542001)(74502001)(31966008)(74662001)(95666003)(81816001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:2864C015.AE121C09.ED38F84.40E09069.2022E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2 (MessageSwitch) id 1396977161727637_32544; Tue, 8 Apr 2014 17:12:41 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.243]) by mail113-tx2.bigfish.com (Postfix) with ESMTP id A2813320056; Tue, 8 Apr 2014 17:12:41 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Apr 2014 17:12:41 +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.435.0; Tue, 8 Apr 2014 17:12:57 +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.913.9; Tue, 8 Apr 2014 17:12:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 17:12:55 +0000 From: Kent Watsen To: t.petch Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-04.txt Thread-Index: AQHPUnLOkx3yKvhu3Ei0uW1S0+g+ypsGAHQAgAHvzWb//8NXAA== Date: Tue, 8 Apr 2014 17:12:54 +0000 Message-ID: References: <20140407150503.3491.36270.idtracker@ietfa.amsl.com> <03ac01cf534a$3b2e2940$4001a8c0@gateway.2wire.net> In-Reply-To: <03ac01cf534a$3b2e2940$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.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 017589626D Content-Type: text/plain; charset="us-ascii" Content-ID: <09BA81F8242ABC4ABBCAC3DACC9B0539@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jEy527z3Rxgl6At5L29YDt3gprc Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-04.txt 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, 08 Apr 2014 17:13:04 -0000 On 4/8/14 12:44 PM, "t.petch" wrote: >Kent > >I saw your exchange with Alan about the paragraph starting > >"However, configuring distinct host keys on the management system > doesn't scale well, which is an important consideration to a network > management system. " > >That sounds plausible but seems to me to undermine the use of SSH for >NETCONF generally, nothing to do with call home. Why is this not an >implicit update to RFC4742? > >Tom Petch True, using PKI-based keys (e.g., X.509) would help scale the rolling out of deployments, regardless if TLS or SSH, and regardless if "normal" or reversed. So do we put something about this into all three documents, or remove it from all three documents, citing that key-distribution is a known problem? If we do remove it from these documents, we'd have to be sure that stated clearly in draft-ietf-netconf-zero-touch, as the solution described there relies on vendors shipping devices with a PKI-based X.509 "entity certificate" used for TLS and SSH NETCONF connections. What do you think? Thanks, Kent=20 From nobody Tue Apr 8 10:16:47 2014 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 EA4701A0652 for ; Tue, 8 Apr 2014 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mZ_UO55sIotN for ; Tue, 8 Apr 2014 10:16:29 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by ietfa.amsl.com (Postfix) with ESMTP id 35E3D1A0659 for ; Tue, 8 Apr 2014 10:16:24 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so327726qge.40 for ; Tue, 08 Apr 2014 10:16:24 -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:content-type; bh=U9t4JduG7eWd4a+cAAwCoTUE6UlF62UFwpZd3TZivH8=; b=i+vNCUAkALJam+EFdadTSJP//68Mb/1lRNVwHsi07Uv7RM1n6jK9T8FKLEBlJqY8Ty /W3kFTNww/hVQNBpFSzbUwudXjs6+IzhURc0XeMQ13+I+gWrOArPMDhKx87J/q4GTLcj vpqaEBGBekel1WPon1Wy4pYxbjpmp0I6jJF7yZJZB2oXGvNzmnuzaYZfeArRauxNWRSH OWlC0Trzyj0T8p0nHP0wlPUC9g5BVMdpnCae7VQx93Vmik+GyEiJZ1F7JXm4wCXDuNEw 4onuGIFi7Z19WpUwq6ZbaDe1wdhtpoUodqLOZY8n7Q8V83fm7/Hxdu4l+CH+XWqubnMp eDVg== X-Gm-Message-State: ALoCoQkvpZIB7Il6OuVnBVscev1OUFF//321dChiqyl2Qxm3qMYzxO6dQp8tlJNz561lNSsogd7d MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr5988061qgx.18.1396977383880; Tue, 08 Apr 2014 10:16:23 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 8 Apr 2014 10:16:23 -0700 (PDT) In-Reply-To: <20140408165334.GF6864@elstar.local> References: <20140216.104746.335052742.mbj@tail-f.com> <000f01cf5263$caa53ba0$4001a8c0@gateway.2wire.net> <20140408165334.GF6864@elstar.local> Date: Tue, 8 Apr 2014 10:16:23 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Kent Watsen , "t.petch" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1233ab9de3c04f68b246f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fwta2cUva4Msn1w3YM-P2oA4ufk Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 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, 08 Apr 2014 17:16:33 -0000 --001a11c1233ab9de3c04f68b246f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 8, 2014 at 9:53 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > The enabled with a default true leaf allows to disable a transport > without having to remove all config. There is currently no other > mechanism available in RFCs to do this and hence this pattern may > still have value. > > Is this something that can be fixed in YANG 1.1? You are right -- there is no way to disable some sub-tree except to add an ad-hoc "enabled" leaf somewhere. IMO this is wrong because it distorts must/when expressions. Objects that have dependencies on specific nodes within the disabled subtree will appear to be active and valid. The YANG validation statements are only supposed to consider active configuration. leafref can only use valid instances of the path object. leaf A { type leafref { path /B/C; } } leaf AA { type string; when "/B/enabled and /B/C = 'foo'"; } list B { key C; leaf enabled { type boolean; } leaf C { type string; } } The A leaf will be valid even for key entries in list B that are disabled. This is broken. The when-expr in AA has to account for the enabled flag or it would be broken. IMO we are making a big mistake by using this approach instead of the Conditional Enablement approach in Kent's draft. The server has to treat the entire subtree as removed from the config, not use an ad-hoc flag in the data model. > /js > Andy > > On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote: > > > > > > > > >draft-ietf-netconf-rfc5539bis-03 had > > > > > > +--rw tls > > > +--rw enabled? boolean > > > > > >which draft-kwatsen-netconf-server-00 lacks. Why? > > > > > >Tom Petch > > > > > > This must've gotten dropped do to the draft-kwatsen-netconf-server model > > having a didn't structure, but as the original 5539 had no model, I think > > that it's a fair topic for discussion. > > > > Personally, I'd rather stick with the original intent of presence > > containers: "enabled" if-and-only-if "configured". We're using these > > "enabled" configuration nodes as a substitute to having XML attributes > for > > metadata describing the node's enablement, such as is described in > > draft-kwatsen-conditional-enablement. At the time that draft was > written, > > there didn't seem to be much interest, but then later I heard some > support > > from Andy. My thinking is to dust it off and get it going again, maybe > > something simpler this time. > > > > Again, I'm thinking that it's OK, and even a good thing, to just use the > > original intent of presence containers for now, knowing that a more > > complete solution (which is clearly in demand) is right around the > corner. > > What do people think? Is there support to work on > > draft-kwatsen-conditional-enablement? > > > > Thanks, > > Kent > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > 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 > --001a11c1233ab9de3c04f68b246f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 8, 2014 at 9:53 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
The enabled with a default true leaf allows to disable a t= ransport
without having to remove all config. There is currently no other
mechanism available in RFCs to do this and hence this pattern may
still have value.


Is this something that can be fixed in= YANG 1.1?
You are right -- there is no way to disable some sub-t= ree except
to add an ad-hoc "enabled" leaf somewhere.

IMO this is wrong because it distorts must/when express= ions.
Objects that have dependencies on specific nodes within the=
disabled subtree will appear to be active and valid.

The YANG validation statements are only supposed to con= sider
active configuration. leafref can only use valid instances = of the path object.


=A0 =A0leaf A {=
=A0 =A0 =A0 type leafref { path /B/C; }
=A0 =A0}
<= br>
=A0 =A0leaf AA {
=A0 =A0 =A0 type string;
=A0 =A0 =A0 when "/B/enabled and /B/C =3D 'foo'";
=A0 =A0}

=A0 =A0list B {
=A0 =A0 =A0 key C;
= =A0 =A0 =A0 leaf enabled { type boolean; }
=A0 =A0 =A0 leaf C { t= ype string; }
=A0 =A0}

The A leaf will b= e valid even for key entries in list B
that are disabled. =A0This is broken. =A0The when-expr in AA
has to account for the enabled flag or it would be broken.

<= /div>
IMO we are making a big mistake by using this approach instead
of the Conditional Enablement approach in Kent's draft.
= The server has to treat the entire subtree as removed from the config,
not use an ad-hoc flag in the data model.

=A0
/js


Andy
=A0

On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote:
>
>
>
> >draft-ietf-netconf-rfc5539bis-03 had
> >
> > =A0 =A0 =A0 =A0 +--rw tls
> > =A0 =A0 =A0 =A0 =A0 =A0+--rw enabled? =A0 =A0 boolean
> >
> >which draft-kwatsen-netconf-server-00 lacks. =A0Why?
> >
> >Tom Petch
>
>
> This must've gotten dropped do to the draft-kwatsen-netconf-server= model
> having a didn't structure, but as the original 5539 had no model, = I think
> that it's a fair topic for discussion.
>
> Personally, I'd rather stick with the original intent of presence<= br> > containers: "enabled" if-and-only-if =A0"configured&quo= t;. =A0We're using these
> "enabled" configuration nodes as a substitute to having XML = attributes for
> metadata describing the node's enablement, such as is described in=
> draft-kwatsen-conditional-enablement. =A0At the time that draft was wr= itten,
> there didn't seem to be much interest, but then later I heard some= support
> from Andy. =A0My thinking is to dust it off and get it going again, ma= ybe
> something simpler this time.
>
> Again, I'm thinking that it's OK, and even a good thing, to ju= st use the
> original intent of presence containers for now, knowing that a more > complete solution (which is clearly in demand) is right around the cor= ner.
> =A0What do people think? =A0Is there support to work on
> draft-kwatsen-conditional-enablement?
>
> Thanks,
> Kent
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

--
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>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a11c1233ab9de3c04f68b246f-- From nobody Tue Apr 8 10:21:52 2014 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 39FEB1A0660 for ; Tue, 8 Apr 2014 10:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 KViBlYTDWz_e for ; Tue, 8 Apr 2014 10:21:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 58BD41A0663 for ; Tue, 8 Apr 2014 10:21:28 -0700 (PDT) Received: from mail23-tx2-R.bigfish.com (10.9.14.226) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Apr 2014 17:21:11 +0000 Received: from mail23-tx2 (localhost [127.0.0.1]) by mail23-tx2-R.bigfish.com (Postfix) with ESMTP id 1F87CA03C3; Tue, 8 Apr 2014 17:21:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371Ic85fh1432I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h1155h) Received-SPF: pass (mail23-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(164054003)(377454003)(51704005)(199002)(189002)(24454002)(74366001)(94946001)(83506001)(74706001)(74876001)(63696002)(76796001)(76786001)(93516002)(46102001)(86362001)(36756003)(15975445006)(81542001)(80976001)(81686001)(31966008)(74662001)(95666003)(81816001)(74502001)(79102001)(95416001)(77096001)(20776003)(66066001)(59766001)(77982001)(65816001)(80022001)(85852003)(97336001)(47736002)(81342001)(98676001)(47446003)(53806002)(69226001)(83072002)(90146001)(54356002)(56816005)(56776001)(76482001)(50986002)(15202345003)(97186001)(92726001)(16236675002)(83322001)(87266001)(92566001)(19580405001)(19580395003)(94316002)(2656002)(49866001)(85306002)(47976002)(99396002)(87936001)(4396001)(54316003)(93136001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:8CF4D12B.A302D7B4.7DF7917B.80E7D049.204D6; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail23-tx2 (localhost.localdomain [127.0.0.1]) by mail23-tx2 (MessageSwitch) id 1396977669118228_16755; Tue, 8 Apr 2014 17:21:09 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.239]) by mail23-tx2.bigfish.com (Postfix) with ESMTP id 166843C004C; Tue, 8 Apr 2014 17:21:09 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Apr 2014 17:21:06 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Tue, 8 Apr 2014 17:21:23 +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.913.9; Tue, 8 Apr 2014 17:21:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 17:21:21 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , t.petch , "netconf@ietf.org" Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-server-00 Thread-Index: AQHPKv0ucc5p8aJ330OdaW2Ybc6v6pq7ahEAgAkOewCAQfmZuoABiUoAgABEvgCAAAZggP//vk8A Date: Tue, 8 Apr 2014 17:21:20 +0000 Message-ID: References: <20140216.104746.335052742.mbj@tail-f.com> <000f01cf5263$caa53ba0$4001a8c0@gateway.2wire.net> <20140408165334.GF6864@elstar.local> 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.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 017589626D Content-Type: multipart/alternative; boundary="_000_CF69A7C368676kwatsenjunipernet_" 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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2d25-XGLvhLZCYoquqe1pmWWi3A Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 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, 08 Apr 2014 17:21:44 -0000 --_000_CF69A7C368676kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right, and if we agree to that in principle, then it seems that we should s= top polluting our data-models with the "enabled" flag. That way we have l= ess number of data-models to clean up later, if we even can update them wit= hout breaking backwards-compatibility. Thanks, Kent From: Andy Bierman > Date: Tuesday, April 8, 2014 1:16 PM To: Juergen Schoenwaelder >, Kent Watsen >, "t.petch" >, NetConf > Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 On Tue, Apr 8, 2014 at 9:53 AM, Juergen Schoenwaelder > wrote: The enabled with a default true leaf allows to disable a transport without having to remove all config. There is currently no other mechanism available in RFCs to do this and hence this pattern may still have value. Is this something that can be fixed in YANG 1.1? You are right -- there is no way to disable some sub-tree except to add an ad-hoc "enabled" leaf somewhere. IMO this is wrong because it distorts must/when expressions. Objects that have dependencies on specific nodes within the disabled subtree will appear to be active and valid. The YANG validation statements are only supposed to consider active configuration. leafref can only use valid instances of the path obje= ct. leaf A { type leafref { path /B/C; } } leaf AA { type string; when "/B/enabled and /B/C =3D 'foo'"; } list B { key C; leaf enabled { type boolean; } leaf C { type string; } } The A leaf will be valid even for key entries in list B that are disabled. This is broken. The when-expr in AA has to account for the enabled flag or it would be broken. IMO we are making a big mistake by using this approach instead of the Conditional Enablement approach in Kent's draft. The server has to treat the entire subtree as removed from the config, not use an ad-hoc flag in the data model. /js Andy On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote: > > > > >draft-ietf-netconf-rfc5539bis-03 had > > > > +--rw tls > > +--rw enabled? boolean > > > >which draft-kwatsen-netconf-server-00 lacks. Why? > > > >Tom Petch > > > This must've gotten dropped do to the draft-kwatsen-netconf-server model > having a didn't structure, but as the original 5539 had no model, I think > that it's a fair topic for discussion. > > Personally, I'd rather stick with the original intent of presence > containers: "enabled" if-and-only-if "configured". We're using these > "enabled" configuration nodes as a substitute to having XML attributes fo= r > metadata describing the node's enablement, such as is described in > draft-kwatsen-conditional-enablement. At the time that draft was written= , > there didn't seem to be much interest, but then later I heard some suppor= t > from Andy. My thinking is to dust it off and get it going again, maybe > something simpler this time. > > Again, I'm thinking that it's OK, and even a good thing, to just use the > original intent of presence containers for now, knowing that a more > complete solution (which is clearly in demand) is right around the corner= . > What do people think? Is there support to work on > draft-kwatsen-conditional-enablement? > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- 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 --_000_CF69A7C368676kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Right, and if we agree to that in principle, then it seems that we sho= uld stop polluting our data-models with the "enabled" flag.  = ; That way we have less number of data-models to clean up later, if we even= can update them without breaking backwards-compatibility.

Thanks,
Kent


From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, April 8, 2014 1:16 P= M
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-u= niversity.de>, Kent Watsen <kwatsen@juniper.net>, "t.petch" <ietfc@btconnect.com>, NetConf <netconf@ietf.org> Subject: Re: [Netconf] comments on = draft-kwatsen-netconf-server-00




On Tue, Apr 8, 2014 at 9:53 AM, Juergen Schoenwa= elder <j.schoenwaelder@jacobs-university.de> wrote:
The enabled with a default true leaf allows to disable a transport
without having to remove all config. There is currently no other
mechanism available in RFCs to do this and hence this pattern may
still have value.


Is this something that can be fixed in YANG 1.1?
You are right -- there is no way to disable some sub-tree except
to add an ad-hoc "enabled" leaf somewhere.

IMO this is wrong because it distorts must/when expressions.
Objects that have dependencies on specific nodes within the
disabled subtree will appear to be active and valid.

The YANG validation statements are only supposed to consider
active configuration. leafref can only use valid instances of the path= object.


   leaf A {
      type leafref { path /B/C; }
   }

   leaf AA {
      type string;
      when "/B/enabled and /B/C =3D 'foo'";
   }

   list B {
      key C;
      leaf enabled { type boolean; }
      leaf C { type string; }
   }

The A leaf will be valid even for key entries in list B
that are disabled.  This is broken.  The when-expr in AA
has to account for the enabled flag or it would be broken.

IMO we are making a big mistake by using this approach instead
of the Conditional Enablement approach in Kent's draft.
The server has to treat the entire subtree as removed from the config,=
not use an ad-hoc flag in the data model.

 
/js


Andy
 

On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote:
>
>
>
> >draft-ietf-netconf-rfc5539bis-03 had
> >
> >         +--rw tls
> >            +--rw enabled?  = ;   boolean
> >
> >which draft-kwatsen-netconf-server-00 lacks.  Why?
> >
> >Tom Petch
>
>
> This must've gotten dropped do to the draft-kwatsen-netconf-server mod= el
> having a didn't structure, but as the original 5539 had no model, I th= ink
> that it's a fair topic for discussion.
>
> Personally, I'd rather stick with the original intent of presence
> containers: "enabled" if-and-only-if  "configured&= quot;.  We're using these
> "enabled" configuration nodes as a substitute to having XML = attributes for
> metadata describing the node's enablement, such as is described in
> draft-kwatsen-conditional-enablement.  At the time that draft was= written,
> there didn't seem to be much interest, but then later I heard some sup= port
> from Andy.  My thinking is to dust it off and get it going again,= maybe
> something simpler this time.
>
> Again, I'm thinking that it's OK, and even a good thing, to just use t= he
> original intent of presence containers for now, knowing that a more > complete solution (which is clearly in demand) is right around the cor= ner.
>  What do people think?  Is there support to work on
> draft-kwatsen-conditional-enablement?
>
> Thanks,
> Kent
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

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

--_000_CF69A7C368676kwatsenjunipernet_-- From nobody Tue Apr 8 14:58:25 2014 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 A4E1D1A04BA for ; Tue, 8 Apr 2014 14:58:22 -0700 (PDT) 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 5tVBHoB_bZSR for ; Tue, 8 Apr 2014 14:58:16 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 51DE91A0215 for ; Tue, 8 Apr 2014 14:58:16 -0700 (PDT) Received: from mail201-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Apr 2014 21:57:57 +0000 Received: from mail201-va3 (localhost [127.0.0.1]) by mail201-va3-R.bigfish.com (Postfix) with ESMTP id 8D8F8BC0372; Tue, 8 Apr 2014 21:57:57 +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: -6 X-BigFish: VPS-6(zzbb2dI98dI9371I1dbaI1432I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail201-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=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(24454002)(189002)(479174003)(377454003)(51704005)(164054003)(93136001)(92726001)(46102001)(19580395003)(19580405001)(74366001)(83322001)(81542001)(81342001)(94316002)(77982001)(86362001)(93516002)(76482001)(92566001)(80976001)(50986002)(56776002)(47976003)(90146001)(74876001)(53806002)(31966008)(81686001)(80022001)(97186001)(99396002)(85852003)(83506001)(76796001)(76786001)(69226001)(87266001)(4396001)(94946001)(49866001)(74706001)(81816001)(74502001)(87936001)(97336001)(2656002)(20776003)(36756003)(66066001)(98676001)(77096001)(85306002)(83072002)(74662001)(95666003)(79102001)(47446003)(54356002)(47736002)(54316003)(95416001)(56816006)(63696004)(59766002)(65816002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:AEE7F25D.A7325401.DDF3D48.84D6F8E1.204DF; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail201-va3 (localhost.localdomain [127.0.0.1]) by mail201-va3 (MessageSwitch) id 1396994275191097_8164; Tue, 8 Apr 2014 21:57:55 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.237]) by mail201-va3.bigfish.com (Postfix) with ESMTP id 1DFC8260031; Tue, 8 Apr 2014 21:57:55 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Apr 2014 21:57:54 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.435.0; Tue, 8 Apr 2014 21:58:12 +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.913.9; Tue, 8 Apr 2014 21:58:04 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.33]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 21:58:04 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 Thread-Index: AQHPOGPi0lBZ6ooeOE+AzxE/IuduwJrmqu6AgAA9VwCAAEzpAIAACbOAgAQDw4CAHPS+gA== Date: Tue, 8 Apr 2014 21:58:03 +0000 Message-ID: References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> <20140321074646.GA12080@elstar.local> In-Reply-To: <20140321074646.GA12080@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 017589626D Content-Type: text/plain; charset="us-ascii" Content-ID: <29AB7AC99B27C54494CE39540EDD3E1D@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZVFvh8hdcJnzmLc0CLPIsl7t3M0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 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, 08 Apr 2014 21:58:22 -0000 I was going to ask about updates needed for 5539bis, when I remembered this unfinished thread... Kent On 3/21/14 3:46 AM, "Juergen Schoenwaelder" wrote: >On Tue, Mar 18, 2014 at 10:28:12PM +0000, Kent Watsen wrote: >>=20 >>=20 >> >No. First, there needs to be an interoperable procedure for a >> >standard. Second, this is not about how to extract an identity or >> >something like that but how to check that the identity presented is an >> >expected identity, means it is trust worthy and not an attempt to fool >> >the NETCONF client. >>=20 >> There is no foolery here, this is how it works. When using a TLS-client >> library, it undoubtedly provides a callback that will be executed for >>the >> app to state whether the server's certificate can be trusted. In >>addition >> to the certificate itself (and any intermediate certs that may also have >> been provided), the callback will likely also a handle to a "connection" >> object of some sort, from which the application can learn the peer's >> source IP address. So that's it, the app has an IP-address, a >>certificate >> (+intermediate certs), and its preconfigured state. > >So what is this preconfigured state? How is the decision been taken? >All implementation specific? So I need to study the vendors handbooks >to figure out how setup things? The preconfigured state being what certificates and/or information inside of certificates (e.g., unique identifiers) it trusts. It's implementation-specific only up to the application's local policy. But for each part of certificate path-verification it implements, I believe that it is unambiguous (RFC3280, section 6) >> >>You are probably familiar with SSH host-keys like "id_rsa.pub" and >> >> "id_dsa.pub". >> > >> >These typically are _not_ host keys. >>=20 >> You're right, I meant ssh_host_rsa_key.pub and ssh_host_dsa_key.pub. >>=20 >>=20 >>=20 >> >> When using OpenSSH, the sshd_config file can contain one of >> >> more "HostKey" entries, an ordered list. The ordering is important >>to >> >>the >> >> SSH protocol, not just the OpenSSH implementation. The configuration >> >> described in the netconf server configuration draft mentioned above >>maps >> >> directly onto this concept, enabling it to be configurable per NMS. >> > >> >If this is the thing you want to solve, this first of needs to be >> >described clearly. But then I am not sure why this needs to be solved. >> >My SSH servers all have keys of different types, e.g., >> > >> >HostKey /etc/ssh/ssh_host_rsa_key >> >HostKey /etc/ssh/ssh_host_dsa_key >> > >> >and somehow clients manage to use the servers without me configuring >> >things. Are we moving into general SSH server configuration territory? >> >Should these details be handled by a generic SSH server configuration >> >data model, I mean is this essential for every NETCONF over SSH call >> >home implementation? >>=20 >> It is SSH-server configuration, yes, but not for the generic server >> listening on port 22 and also not for any generic configuration option. >> We just need enough to support the netconf-server config model draft >>(keep >> alive interval, keep alive count max, etc.). Being able to configure >> which SSH HostKeys are presented is equivalent to being able to >>configure >> which TLS server-certificate the device should present, if there is more >> than one, which is completely possible. > >This is inconsistent. We have no configuration model for all these >things for the regular case - why do we now go ahead and define some >of this for the call home case? This is Tom Petch's point from just this morning, where I wrote back: "True, using PKI-based keys (e.g., X.509) would help scale the rolling out of deployments, regardless if TLS or SSH, and regardless if "normal" or reversed. So do we put something about this into all three documents, or remove it from all three documents, citing that key-distribution is a known problem? What do you think? Thanks, Kent From nobody Wed Apr 9 10:49:14 2014 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 3E6231A02D4 for ; Wed, 9 Apr 2014 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 UuMRx-xGZBVM for ; Wed, 9 Apr 2014 10:49:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3D91A01F2 for ; Wed, 9 Apr 2014 10:49:10 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id C9647394157; Wed, 9 Apr 2014 19:49:08 +0200 (CEST) Date: Wed, 09 Apr 2014 19:49:08 +0200 (CEST) Message-Id: <20140409.194908.499378124.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20140408165334.GF6864@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/i6os2cCeyrl0PEy2-QMs-gsl5bI Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 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, 09 Apr 2014 17:49:12 -0000 Kent Watsen wrote: > > Right, and if we agree to that in principle, then it seems that we should stop > polluting our data-models with the "enabled" flag. That way we have less > number of data-models to clean up later, if we even can update them without > breaking backwards-compatibility. While I do agree that "conditional enablement" would be best, I think we have to design our data models for the mechanisms we have today. In order for us to make use of conditional enablement in our data models (i.e., NOT add enabled leafs), it has to be mandatory to implement, probably part of the protocol itself. So, for this particular issue, I think we should add the enabled leaf. /martin From nobody Wed Apr 9 11:51:14 2014 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 0A9541A0161 for ; Wed, 9 Apr 2014 11:51:12 -0700 (PDT) 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 Gtwbl4qwXgMx for ; Wed, 9 Apr 2014 11:51:07 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 879711A0443 for ; Wed, 9 Apr 2014 11:51:07 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so3172381qcx.41 for ; Wed, 09 Apr 2014 11:51:06 -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=1SDftR6gIt0fEA2TorcIasW1j8wRw1Yc0n9ERNRGazg=; b=GPAk9bwyT8LxrRO4/N/yg3a7JBReRHQ31WFjIsgMRh+nYS5TarbIHecpemjusvBpWt PkEXteg9su9XtNBujqvCuSY6TFDBPEZG15VF73o/X8F0JVq7Rm1o3FRBJ4YhdFWxA5yV Haudtk+ZDdFtTgjSAf1ZvjhLzDanVtKaH2MOGYQ/NRmTVbc6rErKn3GCbyKL4uZtIwbK D//++f1kjvWUy5EWDDrRlFh2k8vAi0TcFV4tPff2kPiwvyM+65dSSQcHaanyJQZVrvua Vj1W1VJwQ0vEcDuLjwOdsZ47ef6nObpHAZSCTZsJEf9DxyrtIuf9B9FkxA/BeMWzC/WL 1AJw== X-Gm-Message-State: ALoCoQl68cJNjqlBYA0rLey2sc+ABjmhgM9jEDQ6ryDtww3keaJyGxP9qd0grPIOfaHUGEwH5Pic MIME-Version: 1.0 X-Received: by 10.224.125.194 with SMTP id z2mr4888096qar.99.1397069466428; Wed, 09 Apr 2014 11:51:06 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 9 Apr 2014 11:51:06 -0700 (PDT) In-Reply-To: <20140409.194908.499378124.mbj@tail-f.com> References: <20140408165334.GF6864@elstar.local> <20140409.194908.499378124.mbj@tail-f.com> Date: Wed, 9 Apr 2014 11:51:06 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2068845fb5504f6a09522 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/M2epx-ATZyDP4J0yn9ctcVwmLhw Cc: Netconf Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 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, 09 Apr 2014 18:51:12 -0000 --001a11c2068845fb5504f6a09522 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 9, 2014 at 10:49 AM, Martin Bjorklund wrote: > Kent Watsen wrote: > > > > Right, and if we agree to that in principle, then it seems that we > should stop > > polluting our data-models with the "enabled" flag. That way we have less > > number of data-models to clean up later, if we even can update them > without > > breaking backwards-compatibility. > > While I do agree that "conditional enablement" would be best, I think > we have to design our data models for the mechanisms we have today. > > In order for us to make use of conditional enablement in our data > models (i.e., NOT add enabled leafs), it has to be mandatory to > implement, probably part of the protocol itself. > > So, for this particular issue, I think we should add the enabled > leaf. > > As long as we continue to do nothing, each short-term decision will be the same (use enabled leaf). If the leaf is written in a protocol-specific way, that is a word-around (e.g. foo server will not send or receive foo packets if set to 'false'), but confusing. At a high-level we have to decide what nodes returned in a for the running configuration really mean. What about leafrefs, etc. where YANG validation rules ignore the enabled leaf? The SMIv3/EoS effort failed spectacularly many years ago, in part because of features that needed some data modeling work and some protocol work to accomplish. Neither WG would fix anything, blaming it on the inability to control the other WG. We should avoid the same procedural excuses. The "enabled flag" is an ad-hoc flawed solution, although it is mandatory-to-implement and mandatory-to-use. I agree we need a mandatory solution, but a good solution. > /martin > Andy --001a11c2068845fb5504f6a09522 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 9, 2014 at 10:49 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Kent Watsen <kwatsen@juniper.net> wrote:
>
> Right, and if we agree to that in principle, then it seems that we sho= uld stop
> polluting our data-models with the "enabled" flag. =A0That w= ay we have less
> number of data-models to clean up later, if we even can update them wi= thout
> breaking backwards-compatibility.

While I do agree that "conditional enablement" would be best, I t= hink
we have to design our data models for the mechanisms we have today.

In order for us to make use of conditional enablement in our data
models (i.e., NOT add enabled leafs), it has to be mandatory to
implement, probably part of the protocol itself.

So, for this particular issue, I think we should add the enabled
leaf.


As long as we continue to do nothing, each short-ter= m decision
will be the same (use enabled leaf). =A0If the leaf is= written in
a protocol-specific way, that is a word-around (e.g. foo server will
not send or receive foo packets if set to 'false'), but co= nfusing.

At a high-level we have to decide what no= des returned in a <get-config>
for the running configuration really mean. =A0What about leafrefs, etc= .
where YANG validation rules ignore the enabled leaf?
=
The SMIv3/EoS effort failed spectacularly many years ago, in= part
because of features that needed some data modeling work and
= some protocol work to accomplish. =A0Neither WG would fix anything,
blaming it on the inability to control the other WG. We should avoid
the same procedural excuses.

The "enable= d flag" is an ad-hoc flawed solution, although it is mandatory-to-impl= ement
and mandatory-to-use. =A0I agree we need a mandatory soluti= on, but a good solution.



/martin

Andy<= /div>

--001a11c2068845fb5504f6a09522-- From nobody Thu Apr 10 04:31:02 2014 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 26A901A01D2 for ; Thu, 10 Apr 2014 04:31:01 -0700 (PDT) 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_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 8La-CpIQO8Hx for ; Thu, 10 Apr 2014 04:30:56 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) by ietfa.amsl.com (Postfix) with ESMTP id CD3191A01F4 for ; Thu, 10 Apr 2014 04:30:55 -0700 (PDT) Received: from DBXPRD0610HT002.eurprd06.prod.outlook.com (157.56.252.181) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 10 Apr 2014 11:30:53 +0000 Message-ID: <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> Date: Thu, 10 Apr 2014 12:28:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: AM3PR07CA010.eurprd07.prod.outlook.com (10.242.16.50) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Forefront-PRVS: 0177904E6B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(479174003)(377454003)(51704005)(13464003)(41574002)(164054003)(51444003)(35774003)(24454002)(61296002)(81342001)(33646001)(50986999)(76176999)(81686999)(81542001)(23756003)(50466002)(77156001)(44736004)(84392001)(31966008)(74662001)(74502001)(4396001)(87286001)(14496001)(89996001)(50226001)(88136002)(85852003)(87976001)(42186004)(83072002)(76482001)(81816999)(46102001)(80022001)(66066001)(19580395003)(19580405001)(92566001)(15975445006)(86362001)(92726001)(80976001)(83322001)(62966002)(93916002)(62236002)(44716002)(20776003)(47776003)(79102001)(99396002)(77982001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB061; H:DBXPRD0610HT002.eurprd06.prod.outlook.com; FPR:66CF1E5.ABDA5371.BED1214B.92E6D3F1.20861; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0DeUmu3bCAqYUCXsIBSElaXOYpc Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 10 Apr 2014 11:31:01 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Tuesday, April 08, 2014 5:24 PM Hi Tom, Thank you for voicing my own thoughts as well. I had previously raised the idea of merging the reverse-ssh draft into a 4742bis, but the WG agreed to keep it separate for simplicity sake. That said, I like symmetry, and it would be more consistent for 5539bis and a 4447bis, rather than what we have now. Just saying ;) Regarding Normative vs Informative, I recently asked about this and Bert said that it comes down to if said draft needs to be understood and/or implemented. If this is the condition, then I believe it swings to being Informative, as proprietary vendor-specific configuration could be used alternatively. As it is, the vendor can decide if they want to advertise urn:ietf:params:xml:ns:yang:ietf-netconf-server-model in their message. Are you suggesting that advertising this capability in the message should be required in order for an implementation to claim they implement Reverse SSH for NETCONF Call Home? Kent, There is a lot of inconsistency between reverse-ssh and 5539-bis and I think the latter is the better model. The biggest difference is that 5539-bis never talks about reverse-TLS because TLS is not reversed; NETCONF client = TLS client, NETCONF server = TLS server always - simple, straightforward. So why does reverse-ssh talk about reverse-ssh when ssh is NOT reversed? To confuse people and raise hackles? I know, times past we - or at least I - was really talking about SSH role reversal but now we are not. Keeping the term reverse-ssh I think politically unwise since we know it rings alarm bells with those who know the security properties of SSH. It confuses those who were not around when we really were discussing it, since the term is technically wrong. It makes ssh call home sound completely different to TLS call home, which will confuse even more people. And it leads to section 5 which, since the usage of SSH is identical to that of RFC4742, effectively updates RFC4742. So, make it RFC4742bis? Could do, or have done so, but I do not think it necessary. Rather - change the terminology from reverse-ssh to call home - specify that it updates the security considerations of RFC4742 by fleshing out what is acceptable verification and authentication in the Security Considerations of RFC4742 - point to 5539-bis for the rules on X.509 cert checking when certs are used for identification - I think that 5539-bis does a good job there which reverse-ssh s.5 does not - provide text on security checking with raw host keys (as in current section 5), since that is SSH specific; netmod-system has something on this but probably not enough. The other grey area is that netconf-server introduces periodic connections, heartbeats, reconnection, timeouts. All good transport-ey stuff which impacts both SSH and TLS transports and, at least for heartbeats and probably for more than that, needs protocol specific details. I think reverse-ssh and 5539-bis incomplete if netconf-server includes these features and the other two do not at least reference them; which makes netconf-server a Normative Reference. The rod we make for our backs is to introduce functional enhancements as part of a data model, not something the IETF has tended to do in the past; rather the function has been sorted out first as text, or pseudo-code or some such, and then the data model has been created to support it i.e. we should not be introducing new function in netconf-server, as if having a data model is all we need. This also means that whether or not something is optional in the data model is irrelevant. The question should be, does it make sense, in future, to implement NETCONF over SSH or TLS while being completely ignorant of periodic connections, heartbeats, reconnection, timeouts because they are only in netconf-server which is only a passing, Informative Reference, nothing you need to know about? If netconf-server progresses with something like its current contents, then I think my answer is apparent. Given the xml, I would be willing to edit the reverse-ssh I-D changing all references to 'reverse-ssh' to 'call home' leaving the rest of the text unchanged pro tem. I feel that strongly about it. Tom Petch Thanks, Kent On 4/8/14 9:44 AM, "t.petch" wrote: >I do not think that this is ready to advance. I had not intended to >comment but having started on netconf-server, and found I had to read >5539bis to understand where it was going, I then found that reverse-ssh >was another piece of the jigsaw. > >In particular, I think that this I-D is more or less updating RFC4742 in >its considerations of security. And I think it may be confused about >public keys and certificates and their role in authentication. > >Taken together, and I do not think they can be considered separately, I >do not think that the three I-Ds give a coherent view of how to secure a >NETCONF session. > >I would point to the queries raised by Tadek and Bajpai which, to me on >the one hand seem spot on and on the other, seem to regard the subject >material of these three I-Ds as of a one - which I obviously agree with. > >I think that netconf-server is the one in most need of progress and see >it as a Normative, not Informative, prerequisite. > >Tom Petch > > >----- Original Message ----- >From: "Bert Wijnen (IETF)" >To: "Kent Watsen" >Cc: >Sent: Thursday, April 03, 2014 12:36 PM > >> WGLC period ended last Tuesday (April 1st). >> >> Kent, where are we with this one? >> >> Do you expect to post a rev 04 that addresses all comments we have >received? >> Either WGLC comments or other comments? Once that is done, I would >like to ask: >> - Kent to post which comments have not been addressed and why (if any) >> - If possible, Kent to post a summary of changes (although that may >already be >> in the document, and that is fine too). >> - All those that made comments to check if they are OK with the way >that >> they have been addressed or responded to. >> >> Bert >> >> On 27/03/14 17:02, Kent Watsen wrote: >> > >> > Hi Alan, >> > >> > >> > Awesome comments - thanks! >> > >> > >> > I applied all fixes mentioned below to my working copy of what will >be >> > -04, so you'll have to wait until then to see the diff. The reason >I'm >> > not posting -04 now is because I'm still trying to work out an issue >with >> > Applicability Statement and with the port's name. >> > >> > Below are my detailed responses. >> > >> > Cheers, >> > Kent >> > >> > >> > >> > >> > >> > >> > >> >> Typos >> >> ----- >> >> >> > >> > I fixed all the issues you found. >> > >> > >> > >> > >> > >> > >> >> Section 2.1, Page 3, Second Paragraph: (wording) >> >> ------------------------------------------------- >> >> >> >> The second paragraph seems vague. Would something along the lines >of >> >> the following text be clearer and/or more specific? >> > >> > I forwarded this comment to Steve Hanna, who wrote the Applicability >> > Statement. At first I was just going to ask if he was OK with the >> > proposed text, but then I started thinking that I didn't agree with >it. >> > That is, I think that the SSH protocol does require mutual >authentication >> > and that NETCONF's requirement that it be possible to derive a >"username" >> > from the transport doesn't change that. I'm still OK limiting >Reverse SSH >> > to just NETCONF, but I want the reason to be accurate. I'm now >waiting >> > for a response from Steve on this. >> > >> > >> > >> > >> > >> > >> > >> >> Section 4, Page 4: (wording) >> >> ----------------------------- >> >> >> >> The current text reads: >> >> >> >> o The NETCONF server initiates a TCP connection to the NETCONF >> >> client on the IANA-assigned Reverse SSH port YYYY. >> >> >> >> o The TCP connection is accepted and a TCP session is >established. >> > >> > >> > I'm not sure about this change since these bullet-points are >preceded by >> > the line "From the NETCONF server's perspective:". The intent is to >only >> > explain the NETCONF-server's perspective, and to let the next >section >> > provide the client's perspective. Currently, neither section >references >> > the remote peer, so that its text remains squarely focused on its >side of >> > the connection. What do you think? >> > >> > >> > >> > >> > >> > >> > >> >> Section 5, Page 5, First Paragraph: (wording) >> >> ---------------------------------------------- >> >> >> >> The current text reads: >> >> >> >> "When the management system accepts a new incoming connection, >it >> >> needs to authenticate the remote peer. Ultimately, this >entails >> >> identifying the peer and verifying its SSH host key. >> >> >> >> Due to Reverse SSH having the network element initiate the TCP >> >> connection," >> > >> > >> > I changed the wording to be more clear, but did it another way, >please let >> > me know if you think it's OK! >> > >> > >> > >> > >> > >> > >> > >> > >> >> Section 5, Page 6, First Paragraph: (clarification) >> >> ---------------------------------------------------- >> >> >> >> The current text reads: >> >> >> >> "However, configuring distinct host keys on the management >system >> >> doesn't scale well, which is an important consideration to a >network >> >> management system. A more scalable strategy is to have the >network >> >> element's host key signed by a common trusted key, such as a >> >> certificate authority. Thus, the mangement system only needs to >> >> trust a single public key, which vouches for the authenticity of >the >> >> various network element public keys." >> >> >> >> Please help me understand this. The way this paragraph is written, >it >> >> is not clear to me why "signing each network element's host key >with a >> >> common trusted key" scales better than "configuring distinct host >keys >> >> on the management system". >> >> >> >> In either of these two situations, it seems like an administrator >must >> >> do work for each network element. In one case, it is configuring >host >> >> keys, in another, it is signing each network element's host key. >If >> >> anything, it seems like signing a host key for each network element >> >> requires _more_ work for each network element, so it seems like >this >> >> would scale less well. >> >> >> >> What am I missing here? >> > >> > >> > Very good question. Of course it comes down to how the device's >"entity >> > certificates", as they are called, is distributed. In the best >case, as >> > described in the zero-touch draft, the device would ship from >factory with >> > a built-in entity-certificate, signed by a trust-chain to its >vendor's >> > well-known trust anchor. In this case, there is no additional >effort >> > needed, the management system only needs to trust the vendor's >certificate >> > for its well-known trust anchor. For cases where the device doesn't >ship >> > from factory with an entity-certificate, introducing PKI is still >> > advantageous as it decouples the management-system from direct >> > involvement, such that it could be outsourced to some 3rd-party. >Makes >> > sense? What update would you like to see in the draft? >> > >> > >> > >> > >> > >> > >> > >> > >> >> Section 7, Page 7, Third Paragraph: (wording) >> >> ---------------------------------------------- >> >> >> >> In a few places in the third paragraph, and possibly in other >places >> >> in the document, would changing "needs to" to lowercase "must", or >> >> lowercase "should", make the document a little more concise? >Example: >> >> >> >> "Note that since the SSH server would have to be configured to >know >> >> which IP address it needs to connect to," >> >> ^^^^^^^^ >> > >> > >> > I changed "needs to" to "is to" for this cited location and another >I >> > found. >> > >> > >> > >> > >> > >> > Thanks again, >> > Kent >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > > From nobody Thu Apr 10 14:55:33 2014 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 B81E71A0236 for ; Thu, 10 Apr 2014 14:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 2xtzqESmlM_d for ; Thu, 10 Apr 2014 14:55:27 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id CA4761A01AF for ; Thu, 10 Apr 2014 14:55:27 -0700 (PDT) Received: from mail36-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE033.bigfish.com (10.236.130.96) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Apr 2014 21:55:02 +0000 Received: from mail36-co9 (localhost [127.0.0.1]) by mail36-co9-R.bigfish.com (Postfix) with ESMTP id 16A5ADC01F5; Thu, 10 Apr 2014 21:55:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(z579ehz1418I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail36-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(51444003)(164054003)(92726001)(4396001)(92566001)(87936001)(76482001)(2656002)(79102001)(77982001)(80976001)(83072002)(80022001)(20776003)(76176999)(50986999)(54356999)(83506001)(85852003)(46102001)(36756003)(99396002)(99286001)(81342001)(86362001)(74662001)(66066001)(83322001)(81542001)(74502001)(31966008); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:EEE7CEE5.ABF2D391.FED12DB7.9EE6D171.205DC; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail36-co9 (localhost.localdomain [127.0.0.1]) by mail36-co9 (MessageSwitch) id 1397166898975582_29500; Thu, 10 Apr 2014 21:54:58 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.249]) by mail36-co9.bigfish.com (Postfix) with ESMTP id E98F4F00048; Thu, 10 Apr 2014 21:54:58 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Apr 2014 21:54:59 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Thu, 10 Apr 2014 21:55:22 +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.913.9; Thu, 10 Apr 2014 21:55:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.17]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.17]) with mapi id 15.00.0913.002; Thu, 10 Apr 2014 21:55:20 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsHpGQAgAMV01OAAGtSAA== Date: Thu, 10 Apr 2014 21:55:19 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> In-Reply-To: <005101cf54b0$16a93940$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.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0177904E6B Content-Type: text/plain; charset="us-ascii" Content-ID: <6278DCFFBB140849B9B96E770EA2692D@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Yt9mJUMErHeTuUzZqVf_c7jpuew Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 10 Apr 2014 21:55:30 -0000 Hi Tom, >The biggest difference is that 5539-bis never talks about reverse-TLS >because TLS is not reversed; NETCONF client =3D TLS client, NETCONF server >=3D TLS server always - simple, straightforward. With SSH, it is also always the case that the NETCONF client =3D SSH client= , and the NETCONF server =3D SSH server. Please take another look at 5539-bis, section 2.1.3, as it regards the call-home case and it's definitely the case that TLS is reversed in exactly the same way that SSH is in the reverse-ssh draft. The two are very consistent in this regard. >So why does reverse-ssh talk about reverse-ssh when ssh is NOT reversed? >To confuse people and raise hackles? I know, times past we - or at >least I - was really talking about SSH role reversal but now we are not. SSH *is* reversed or, more specifically, the directionality of the SSH transport on top of its TCP transport is reversed (same way as with the TLS-based call-home). The best way to fix the consistency issue with the drafts is to merge reverse-SSH into rfc4742 (i.e. rfc4742bis). >Keeping the term reverse-ssh I think politically unwise since we know it >rings alarm bells with those who know the security properties of SSH. >It confuses those who were not around when we really were discussing it, >since the term is technically wrong. It makes ssh call home sound >completely different to TLS call home, which will confuse even more >people. And it leads to section 5 which, since the usage of SSH is >identical to that of RFC4742, effectively updates RFC4742. Perhaps, I don't know. As it stands, "reverse ssh" is pretty well known, but we certainly wouldn't want ssh call home to sound completely different to TLS call home... >So, make it RFC4742bis? Could do, or have done so, but I do not think >it necessary. Rather >- change the terminology from reverse-ssh to call home >- specify that it updates the security considerations of RFC4742 by >fleshing out what is acceptable verification and authentication in the >Security Considerations of RFC4742 >- point to 5539-bis for the rules on X.509 cert checking when certs are >used for identification - I think that 5539-bis does a good job there >which reverse-ssh s.5 does not >- provide text on security checking with raw host keys (as in current >section 5), since that is SSH specific; netmod-system has something on >this but probably not enough. It's good to have a concrete list of suggestions to work off of, thanks. These are fairly extensive changes, before jumping in and doing it, how does this look to everyone else? >The other grey area is that netconf-server introduces periodic >connections, heartbeats, reconnection, timeouts. All good transport-ey >stuff which impacts both SSH and TLS transports and, at least for >heartbeats and probably for more than that, needs protocol specific >details. I think reverse-ssh and 5539-bis incomplete if netconf-server >includes these features and the other two do not at least reference >them; which makes netconf-server a Normative Reference. All but heartbeats don't require interoperability. It was mentioned in London that Heartbeats were under-specified. For SSH, heartbeats are done within the existing SSH protocol, so there is nothing for an NMS to do special in order to reply to heartbeats from a device, but I'm perfectly OK with calling it out explicitly in the reverse-ssh draft. For TLS, heartbeats depend on rfc6520 (e.g. run a OpenSSL version 1.0.1 or greater*), which *needs* to be called out in 5539-bis. Once how heartbeating is needed and is implemented is called out in both drafts, then I believe NMS/device interoperability can be achieve, without a Normative reference to netconf-server-model. For instance, the NMS doesn't need to know if the device's connection is periodic or a reconnection, or if it was disconnected due to a timeout - all that state is solely on the device side. Thus I still think that the netconf-server-model is optional to support and hence should be Informational. * or the very very latest if you want to avoid the recent "heartbleed" bug >The rod we make for our backs is to introduce functional enhancements as >part of a data model, not something the IETF has tended to do in the >past; rather the function has been sorted out first as text, or >pseudo-code or some such, and then the data model has been created to >support it i.e. we should not be introducing new function in >netconf-server, as if having a data model is all we need. I agree with the statement, but disagree that it applies here (with the caveat that we add some explicit text into 5539bis and reverse-ssh draft about heartbeats). >This also means that whether or not something is optional in the data >model is irrelevant. The question should be, does it make sense, in >future, to implement NETCONF over SSH or TLS while being completely >ignorant of periodic connections, heartbeats, reconnection, timeouts >because they are only in netconf-server which is only a passing, >Informative Reference, nothing you need to know about? If >netconf-server progresses with something like its current contents, then >I think my answer is apparent. For reverse-ssh, I think it's Informative, as it truly is an optional data-model (see above) For 5539bis, there may be a need for a Normative reference, but only because of the psk-maps and cert-maps, which *might* get moved to the netmod-system-mgmt draft. >Given the xml, I would be willing to edit the reverse-ssh I-D changing >all references to 'reverse-ssh' to 'call home' leaving the rest of the >text unchanged pro tem. I feel that strongly about it. I appreciate the offer and gladly accept it, but let's wait to hear if anyone has objections, or if we plan to merge reverse-ssh into a 4742bis. Thanks, Kent From nobody Thu Apr 10 15:38:30 2014 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 EBC9E1A031E for ; Thu, 10 Apr 2014 15:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 5kzonro3NSLG for ; Thu, 10 Apr 2014 15:38:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 69D801A0316 for ; Thu, 10 Apr 2014 15:38:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 14EB110EA; Fri, 11 Apr 2014 00:38:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id u76fW3sTVU27; Fri, 11 Apr 2014 00:38:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 11 Apr 2014 00:38:18 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 689F820033; Fri, 11 Apr 2014 00:38:18 +0200 (CEST) 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 NWIz5WtSkXJt; Fri, 11 Apr 2014 00:38:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01E232002F; Fri, 11 Apr 2014 00:38:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8EB5C2C57DF0; Fri, 11 Apr 2014 00:38:15 +0200 (CEST) Date: Fri, 11 Apr 2014 00:38:15 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140410223815.GA99552@elstar.local> Mail-Followup-To: Kent Watsen , "t.petch" , "Bert Wijnen (IETF)" , "netconf@ietf.org" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WoWKJqfXj1P_FvfOZj4U1ObNAwE Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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: Thu, 10 Apr 2014 22:38:26 -0000 On Thu, Apr 10, 2014 at 09:55:19PM +0000, Kent Watsen wrote: > > Hi Tom, > > >The biggest difference is that 5539-bis never talks about reverse-TLS > >because TLS is not reversed; NETCONF client = TLS client, NETCONF server > >= TLS server always - simple, straightforward. > > With SSH, it is also always the case that the NETCONF client = SSH client, > and the NETCONF server > = SSH server. Please take another look at 5539-bis, section 2.1.3, as it > regards the call-home case and it's definitely the case that TLS is > reversed in exactly the same way that SSH is in the reverse-ssh draft. > The two are very consistent in this regard. > > > >So why does reverse-ssh talk about reverse-ssh when ssh is NOT reversed? > >To confuse people and raise hackles? I know, times past we - or at > >least I - was really talking about SSH role reversal but now we are not. > > SSH *is* reversed or, more specifically, the directionality of the SSH > transport on top of its TCP transport is reversed (same way as with the > TLS-based call-home). The best way to fix the consistency issue with the > drafts is to merge reverse-SSH into rfc4742 (i.e. rfc4742bis). > I tend to agree with Tom that 'reverse SSH' is potentially misleading or that we should pick a consistent terminology for both the TLS and the SSH transports. (I do not see that merging reverse SSH into RFC 4742 fixes the terminology split we have.) And to make things a bit more confusing, we use 'inbound' and 'outbound' in the netconf server configuration data model. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Apr 10 16:09:08 2014 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 0B28C1A0314 for ; Thu, 10 Apr 2014 16:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 s1knUfuEebsv for ; Thu, 10 Apr 2014 16:09:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDB31A02ED for ; Thu, 10 Apr 2014 16:09:02 -0700 (PDT) Received: from mail149-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Apr 2014 23:08:35 +0000 Received: from mail149-va3 (localhost [127.0.0.1]) by mail149-va3-R.bigfish.com (Postfix) with ESMTP id B9F9C46021E; Thu, 10 Apr 2014 23:08:35 +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(z579ehz4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail149-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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(199002)(189002)(2656002)(36756003)(77982001)(99286001)(87936001)(20776003)(86362001)(92566001)(92726001)(99396002)(83072002)(85852003)(80022001)(79102001)(66066001)(74662001)(31966008)(4396001)(46102001)(74502001)(83506001)(76482001)(81342001)(50986999)(76176999)(54356999)(80976001)(83322001)(81542001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:B0FAD41D.8C300C03.CCE7A374.44E5D178.201DF; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail149-va3 (localhost.localdomain [127.0.0.1]) by mail149-va3 (MessageSwitch) id 1397171314297857_21428; Thu, 10 Apr 2014 23:08:34 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.232]) by mail149-va3.bigfish.com (Postfix) with ESMTP id 39E5D2000A6; Thu, 10 Apr 2014 23:08:34 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Apr 2014 23:08:33 +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.435.0; Thu, 10 Apr 2014 23:08:58 +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.913.9; Thu, 10 Apr 2014 23:08:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.17]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.17]) with mapi id 15.00.0913.002; Thu, 10 Apr 2014 23:08:55 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsHpGQAgAMV01OAAGtSAIAATxGA///FfoA= Date: Thu, 10 Apr 2014 23:08:53 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <20140410223815.GA99552@elstar.local> In-Reply-To: <20140410223815.GA99552@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.16] x-forefront-prvs: 0177904E6B Content-Type: text/plain; charset="us-ascii" Content-ID: <0238D725D4287C4B94EC22298313E78B@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/EkZxJiGfOchH1G9Rz4sxtLx7Cf4 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 10 Apr 2014 23:09:07 -0000 Hi Juergen, >I tend to agree with Tom that 'reverse SSH' is potentially misleading >or that we should pick a consistent terminology for both the TLS and >the SSH transports. (I do not see that merging reverse SSH into RFC >4742 fixes the terminology split we have.) What terminology change do you propose? I can only think that adding the word "reverse" into 5539-bis would be simpler than removing "reverse" from the reverse-ssh draft... >And to make things a bit more confusing, we use 'inbound' and >'outbound' in the netconf server configuration data model. ;-) These are in feature statements only. For instance: feature ssh { description "A server implements this feature if it supports NETCONF over Secure Shell (SSH)."; reference "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; } feature inbound-ssh { description "The inbound-ssh feature indicates that the server can open a port to listen for incoming client connections."; } feature outbound-ssh { description "The outbound-ssh feature indicates that the server can connect to a client."; reference "RFC XXXX: Reverse SSH for NETCONF Call Home"; } Thanks, Kent From nobody Fri Apr 11 00:05:22 2014 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 2D6C81A011F for ; Fri, 11 Apr 2014 00:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 gdhOIBoRNY2K for ; Fri, 11 Apr 2014 00:05:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E87A81A00EF for ; Fri, 11 Apr 2014 00:04:59 -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 A226E476C0D; Fri, 11 Apr 2014 09:04:57 +0200 (CEST) Date: Fri, 11 Apr 2014 09:04:57 +0200 (CEST) Message-Id: <20140411.090457.714176375997293507.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20140410223815.GA99552@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Lv6LRPrxkBFlViSR1f4D5qX0bbM Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 11 Apr 2014 07:05:07 -0000 Kent Watsen wrote: > > Hi Juergen, > > >I tend to agree with Tom that 'reverse SSH' is potentially misleading +1 I think a phrase like "call home for SSH" describes it better. > >or that we should pick a consistent terminology for both the TLS and > >the SSH transports. (I do not see that merging reverse SSH into RFC > >4742 fixes the terminology split we have.) > > What terminology change do you propose? I can only think that adding the > word "reverse" into 5539-bis would be simpler than removing "reverse" from > the reverse-ssh draft... > > > > >And to make things a bit more confusing, we use 'inbound' and > >'outbound' in the netconf server configuration data model. ;-) > > These are in feature statements only. The terms should still be correct. "outbound-ssh" sounds like a normal SSH client, but that is not the case here. /martin For instance: > > feature ssh { > description > "A server implements this feature if it supports NETCONF > over Secure Shell (SSH)."; > reference > "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; > } > > feature inbound-ssh { > description > "The inbound-ssh feature indicates that the server can > open a port to listen for incoming client connections."; > } > > feature outbound-ssh { > description > "The outbound-ssh feature indicates that the server can > connect to a client."; > reference > "RFC XXXX: Reverse SSH for NETCONF Call Home"; > } > > > > > > Thanks, > Kent > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Apr 11 02:07:53 2014 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 A59861A044D for ; Fri, 11 Apr 2014 02:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 DE5P3XyDieFQ for ; Fri, 11 Apr 2014 02:07:47 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id B3A161A0196 for ; Fri, 11 Apr 2014 02:07:46 -0700 (PDT) Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.0.918.8; Fri, 11 Apr 2014 09:07:43 +0000 Message-ID: <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> Date: Fri, 11 Apr 2014 10:00:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-ClientProxiedBy: DB3PR07CA001.eurprd07.prod.outlook.com (10.242.134.41) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Forefront-PRVS: 0178184651 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(377454003)(13464003)(164054003)(19580405001)(80976001)(74662001)(31966008)(81816999)(19580395003)(50226001)(83322001)(76176999)(81686999)(50986999)(74502001)(92566001)(33646001)(79102001)(44716002)(89996001)(62236002)(50466002)(88136002)(85852003)(83072002)(23756003)(62966002)(61296002)(77982001)(66066001)(87286001)(4396001)(81342001)(20776003)(47776003)(87976001)(81542001)(99396002)(76482001)(44736004)(77156001)(84392001)(93916002)(46102001)(42186004)(1941001)(80022001)(86362001)(92726001)(14496001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB064; H:DB3PRD0210HT003.eurprd02.prod.outlook.com; FPR:ECBBC2E5.A3FA81BA.7CD39D77.8AFAF141.2043B; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/b3YTCV1qjDPS6BYtSlp7kcBhzk8 Cc: netconf@ietf.org Subject: [Netconf] periodic connections, heartbeats, reconnection, timeout was Re: WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 11 Apr 2014 09:07:51 -0000 Snipping out the issues of terminology and security ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Thursday, April 10, 2014 10:55 PM >The other grey area is that netconf-server introduces periodic >connections, heartbeats, reconnection, timeouts. All good transport-ey >stuff which impacts both SSH and TLS transports and, at least for >heartbeats and probably for more than that, needs protocol specific >details. I think reverse-ssh and 5539-bis incomplete if netconf-server >includes these features and the other two do not at least reference >them; which makes netconf-server a Normative Reference. All but heartbeats don't require interoperability. It was mentioned in London that Heartbeats were under-specified. For SSH, heartbeats are done within the existing SSH protocol, so there is nothing for an NMS to do special in order to reply to heartbeats from a device, but I'm perfectly OK with calling it out explicitly in the reverse-ssh draft. For TLS, heartbeats depend on rfc6520 (e.g. run a OpenSSL version 1.0.1 or greater*), which *needs* to be called out in 5539-bis. Once how heartbeating is needed and is implemented is called out in both drafts, then I believe NMS/device interoperability can be achieve, without a Normative reference to netconf-server-model. For instance, the NMS doesn't need to know if the device's connection is periodic or a reconnection, or if it was disconnected due to a timeout - all that state is solely on the device side. Thus I still think that the netconf-server-model is optional to support and hence should be Informational. * or the very very latest if you want to avoid the recent "heartbleed" bug ssh-server introduces introduces periodic connections, heartbeats, reconnection and timeouts, all good functions to have in a transport protocol. There is at least some impact on 5539-bis, perhaps on reverse-ssh, but the starting point that I would like clarified is a question of scope. Reading the details, I struggle to see why these functions should be tied to - SSH - TLS - listen - call home - NETCONF client - NETCONF server That is, why shouldn't any NETCONF engine send a heartbeat, timeout if no response in a suitable period, drop a connection and reconnect when it wants to? These functions seem useful in any setting, rather than specific to a particular scenario. So, as and when this I-D is put up for adoption by the WG, I would like that to be clarified before the I-D is adopted, not after. What is the scope, what is the applicability of these new transport functions? Not what the I-D currently says, I can see that, but where do we want to end up? This then has consequences. Do we, for example, need a different message for 'I am closing in the normal fashion' v 'I am closing for a timeout' (tricky - long established protocols are still wrestling with this one) v 'I am closing pro tem but expect to return when I have something to do'? (And may be the answer is that we do not want to progress all of these functions at this time). Tom Petch Thanks, Kent From nobody Fri Apr 11 02:07:58 2014 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 BEFE21A0458 for ; Fri, 11 Apr 2014 02:07:56 -0700 (PDT) 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_HELO_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 dvGXb7LPhq9u for ; Fri, 11 Apr 2014 02:07:51 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id 188B01A043F for ; Fri, 11 Apr 2014 02:07:48 -0700 (PDT) Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.0.918.8; Fri, 11 Apr 2014 09:07:45 +0000 Message-ID: <008901cf5565$418c3800$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Juergen Schoenwaelder References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <20140410223815.GA99552@elstar.local> Date: Fri, 11 Apr 2014 10:04:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-ClientProxiedBy: DB3PR07CA001.eurprd07.prod.outlook.com (10.242.134.41) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Forefront-PRVS: 0178184651 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(377454003)(13464003)(51444003)(164054003)(19580405001)(80976001)(74662001)(31966008)(81816999)(19580395003)(50226001)(83322001)(76176999)(81686999)(50986999)(74502001)(92566001)(33646001)(79102001)(44716002)(89996001)(62236002)(50466002)(88136002)(85852003)(83072002)(23756003)(62966002)(61296002)(77982001)(66066001)(87286001)(4396001)(81342001)(20776003)(47776003)(87976001)(81542001)(99396002)(76482001)(44736004)(77156001)(84392001)(93916002)(46102001)(42186004)(1941001)(80022001)(86362001)(92726001)(14496001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB064; H:DB3PRD0210HT003.eurprd02.prod.outlook.com; FPR:BCF8F61D.8CE21FF1.FCE7A370.4E6DE61.2036E; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/47p_evh1KiTC-IhyFMOVlqZTldY Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 11 Apr 2014 09:07:56 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Juergen Schoenwaelder" Cc: "t.petch" ; "Bert Wijnen (IETF)" ; Sent: Friday, April 11, 2014 12:08 AM Hi Juergen, >I tend to agree with Tom that 'reverse SSH' is potentially misleading >or that we should pick a consistent terminology for both the TLS and >the SSH transports. (I do not see that merging reverse SSH into RFC >4742 fixes the terminology split we have.) What terminology change do you propose? I can only think that adding the word "reverse" into 5539-bis would be simpler than removing "reverse" from the reverse-ssh draft... >And to make things a bit more confusing, we use 'inbound' and >'outbound' in the netconf server configuration data model. ;-) These are in feature statements only. For instance: feature ssh { description "A server implements this feature if it supports NETCONF over Secure Shell (SSH)."; reference "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; } feature inbound-ssh { description "The inbound-ssh feature indicates that the server can open a port to listen for incoming client connections."; } feature outbound-ssh { description "The outbound-ssh feature indicates that the server can connect to a client."; reference "RFC XXXX: Reverse SSH for NETCONF Call Home"; } Kent I know, I was leaving that issue for the moment:-) I think that parts of ssh-server have nothing to do with the server and apply to the client as well, so that as long as you remember very clearly that the document title is 'server' then inbound and outbound is unambiguous (well, as long as you remember that it is the ssh server and not the tcp server:-) But as and when parts of ssh-server relate to the client, well then inbound and outbound are less clear, so I think that the use of inbound and outbound is an issue that needs more thought. And inbound is quite widespread in ssh-server, appearing in sections 2.4, 2.5, 3.1, 3.2, 3.3, 3.4. The usage is consistent within ssh-server but at odds with what I see as a set of documents, 5539-bis, reverse-ssh, ssh-server (and, perhaps, system-mgmt). I read them all before making any comments and it is the inconsistency between them that is driving me now. And, as I said before, I do see 5539-bis as the simplest, the clearest and so the one to move reverse-ssh and ssh-server towards. Which gives you the work to do, which is why I offered to help. Tom Petch Thanks, Kent From nobody Fri Apr 11 03:47:43 2014 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 9B2D01A0225 for ; Fri, 11 Apr 2014 03:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 WTpke47thp32 for ; Fri, 11 Apr 2014 03:47:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id AAAE81A00FB for ; Fri, 11 Apr 2014 03:47:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3B44818000C; Fri, 11 Apr 2014 03:47:27 -0700 (PDT) To: andy@yumaworks.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140411104727.3B44818000C@rfc-editor.org> Date: Fri, 11 Apr 2014 03:47:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XXpVSqePlWaHfULNl3ldK-W2CeI Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC6470 (3957) 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, 11 Apr 2014 10:47:41 -0000 The following errata report has been submitted for RFC6470, "Network Configuration Protocol (NETCONF) Base Notifications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6470&eid=3957 -------------------------------------- Type: Technical Reported by: Martin Bjrklund Section: 2.2 Original Text ------------- uses common-session-parms { when "../confirm-event != 'timeout'"; } leaf confirm-event { Corrected Text -------------- uses common-session-parms { when "confirm-event != 'timeout'"; } leaf confirm-event { Notes ----- "uses" does not define a node. RFC 6020, 7.19.5 specifies that the context node for "when" is the node above the "uses" statement: o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice", or "case" node that is also a data node. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6470 (draft-ietf-netconf-system-notifications-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Base Notifications Publication Date : February 2012 Author(s) : A. Bierman Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Apr 11 09:06:26 2014 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 B3FCF1A0700 for ; Fri, 11 Apr 2014 09:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 RJ166Ceqtj-w for ; Fri, 11 Apr 2014 09:06:23 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 161AA1A06FD for ; Fri, 11 Apr 2014 09:06:22 -0700 (PDT) Received: from mail95-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE004.bigfish.com (10.236.130.67) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Apr 2014 16:05:55 +0000 Received: from mail95-co9 (localhost [127.0.0.1]) by mail95-co9-R.bigfish.com (Postfix) with ESMTP id 16B81700299; Fri, 11 Apr 2014 16:05:55 +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(z579ehz1432I1418I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail95-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:(10009001)(6009001)(428001)(199002)(189002)(164054003)(51444003)(51704005)(79102001)(66066001)(80022001)(31966008)(74662001)(4396001)(92726001)(92566001)(83072002)(85852003)(99396002)(81342001)(76176999)(54356999)(50986999)(81542001)(80976001)(83322001)(74502001)(83506001)(46102001)(76482001)(36756003)(2656002)(99286001)(87936001)(20776003)(86362001)(77982001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:AEE4C01D.BED24CC1.41EF8F70.4C1AE70.201FB; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail95-co9 (localhost.localdomain [127.0.0.1]) by mail95-co9 (MessageSwitch) id 139723235332313_11108; Fri, 11 Apr 2014 16:05:53 +0000 (UTC) Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.226]) by mail95-co9.bigfish.com (Postfix) with ESMTP id EE161580053; Fri, 11 Apr 2014 16:05:52 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Apr 2014 16:05:52 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 11 Apr 2014 16:06:18 +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.913.9; Fri, 11 Apr 2014 16:06:16 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.17]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.17]) with mapi id 15.00.0913.002; Fri, 11 Apr 2014 16:06:16 +0000 From: Kent Watsen To: t.petch , Juergen Schoenwaelder Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsHpGQAgAMV01OAAGtSAIAATxGA///FfoCAAOp8rIAAMcUA Date: Fri, 11 Apr 2014 16:06:15 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <20140410223815.GA99552@elstar.local> <008901cf5565$418c3800$4001a8c0@gateway.2wire.net> In-Reply-To: <008901cf5565$418c3800$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.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0178184651 Content-Type: text/plain; charset="us-ascii" Content-ID: <1149F1307DE9AB4C9C82844D604CC8F8@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VA7vQF3zqEljJ1aDx5jniLfMrlU Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 11 Apr 2014 16:06:25 -0000 Hi Tom, >But as and when parts of ssh-server relate to the client, well then >inbound and outbound are less clear, so I think that the use of inbound >and outbound is an issue that needs more thought. How about "listen" and "call-home", mimicing the names used for the configuration nodes? >And inbound is quite widespread in ssh-server, appearing in sections >2.4, 2.5, 3.1, 3.2, 3.3, 3.4. The usage is consistent within >ssh-server but at odds with what I see as a set of documents, 5539-bis, >reverse-ssh, ssh-server >(and, perhaps, system-mgmt). I read them all before making any comments >and it is the inconsistency between them that is driving me now. > >And, as I said before, I do see 5539-bis as the simplest, the clearest >and so the one to move reverse-ssh and ssh-server towards. > >Which gives you the work to do, which is why I offered to help. There looks to be WG consensus to do this now so, yes, please make this change. I suppose if we're removing "reverse" from the draft, then we should rename it too - how about ietf-netconf-ssh-call-home? Thanks, Kent From nobody Sat Apr 12 05:24:00 2014 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 CDEE71A0095 for ; Sat, 12 Apr 2014 05:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 bDmSUf--HsVW for ; Sat, 12 Apr 2014 05:23:52 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) by ietfa.amsl.com (Postfix) with ESMTP id 48B921A0092 for ; Sat, 12 Apr 2014 05:23:50 -0700 (PDT) Received: from DB3PRD0710HT003.eurprd07.prod.outlook.com (10.255.75.38) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.0.913.9; Sat, 12 Apr 2014 12:23:47 +0000 Received: from pc6 (86.171.207.36) by pod51017.outlook.com (10.255.75.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Sat, 12 Apr 2014 12:23:46 +0000 Message-ID: <009801cf5649$cd979b20$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Juergen Schoenwaelder References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <20140410223815.GA99552@elstar.local> <008901cf5565$418c3800$4001a8c0@gateway.2wire.net> Date: Sat, 12 Apr 2014 13:20:44 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0091_01CF5652.024F6B60" 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: [86.171.207.36] X-Forefront-PRVS: 01792087B6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51444003)(164054003)(377454003)(189002)(199002)(13464003)(54534003)(51704005)(512934002)(61296002)(71636004)(4396001)(50226001)(44736004)(81542001)(83322001)(19580395003)(62966002)(81342001)(33646001)(99396002)(80976001)(71186001)(76482001)(14496001)(66066001)(86362001)(93916002)(1941001)(76176999)(575134002)(20776003)(87936001)(89996001)(88136002)(87286001)(84392001)(84326002)(77982001)(50986999)(77156001)(46102001)(81816999)(92726001)(79102001)(568964001)(19580405001)(80022001)(85852003)(92566001)(44716002)(62236002)(81686999)(31966008)(74502001)(74662001)(83072002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB058; H:DB3PRD0710HT003.eurprd07.prod.outlook.com; FPR:EE34F01D.BEF26BF1.B3F35D70.94C2EDE1.20384; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yHksud4QkIf1LzJNxCsC3L2ZtLs Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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: Sat, 12 Apr 2014 12:23:57 -0000 ------=_NextPart_000_0091_01CF5652.024F6B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Kent I attach the updated XML. I have replaced 'Reverse SSH' with 'call home' or, where it seems necessary, 'NETCONF over SSH (call home), following the style of 5539-bis. xml2rfc says it is ok. I update the version to -05 and added a change log. I think it would be wrong to change the draft I-D name - yes, that name persists for ever in the data tracker even after the RFC is created, but I think that the change of name creates a discontinuity in the tracker that is a worse result. I think it would be better if you submitted this I-D - continuity again. I would like to revise the first sentence of the Introduction/Abstract (as I suggested last November) but including 'call home', but don't see consensus on that yet so I have left that. I will get back to you next week ( a busy one for me) on the other points. Tom Petch ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Juergen Schoenwaelder" Cc: "Bert Wijnen (IETF)" ; Sent: Friday, April 11, 2014 5:06 PM Hi Tom, >But as and when parts of ssh-server relate to the client, well then >inbound and outbound are less clear, so I think that the use of inbound >and outbound is an issue that needs more thought. How about "listen" and "call-home", mimicing the names used for the configuration nodes? >And inbound is quite widespread in ssh-server, appearing in sections >2.4, 2.5, 3.1, 3.2, 3.3, 3.4. The usage is consistent within >ssh-server but at odds with what I see as a set of documents, 5539-bis, >reverse-ssh, ssh-server >(and, perhaps, system-mgmt). I read them all before making any comments >and it is the inconsistency between them that is driving me now. > >And, as I said before, I do see 5539-bis as the simplest, the clearest >and so the one to move reverse-ssh and ssh-server towards. > >Which gives you the work to do, which is why I offered to help. There looks to be WG consensus to do this now so, yes, please make this change. I suppose if we're removing "reverse" from the draft, then we should rename it too - how about ietf-netconf-ssh-call-home? Thanks, Kent ------=_NextPart_000_0091_01CF5652.024F6B60 Content-Type: text/xml; name="draft-ietf-netconf-reverse-ssh-05.xml" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-netconf-reverse-ssh-05.xml" NETCONF over SSH Call Home Juniper Networks
kwatsen@juniper.net
Operations NETCONF Working Group reverse-ssh call-home This document presents a technique for a NETCONF server = to=20 initiate a SSH connection to a NETCONF client. This is=20 accomplished by the NETCONF client listening on = IANA-assigned TCP port YYYY and starting the SSH client protocol = immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH = server, in order for the NETCONF client to open the IANA-assigned SSH subsystem "netconf".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .
This document presents a technique for a NETCONF=20 server to initiate a =20 Secure Shell (SSH) connection to a NETCONF client. This is accomplished by the NETCONF client listening on IANA-assigned TCP port YYYY and starting the SSH client protocol immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH server, in order for the NETCONF client to open the IANA-assigned SSH subsystem "netconf" .
The techniques described in this document are suitable for network management scenarios such as the ones described in section 3. However, these techniques MUST only be used for a NETCONF server to initiate a connection to a NETCONF client, as described in this document. The reason for this restriction is that different protocols have different security assumptions. The NETCONF over SSH specification requires NETCONF clients and servers to verify the identity of the other party before starting the NETCONF protocol. This contrasts with the base SSH protocol, which does not require programmatic verification of the other party. In such circumstances, allowing the SSH server to contact the SSH client would open new vulnerabilities. Therefore, any use of call home over SSH for purposes other than NETCONF will need a thorough, contextual security analysis.
This document updates the SSH Transport Layer Protocol only by removing the restriction in Section 4 (Connection Setup) of that the SSH Client must initiate the transport connection. Security implications related to this change are discussed in Security Considerations ().
The SSH protocol is nearly ubiquitous for device = management, as it is the transport for the command-line applications = `ssh`, `scp`, and `sftp` and is the required transport for the = NETCONF protocol . However, all these = SSH-based protocols expect the network element to be the SSH = server. =20 Call home enables the network element to consistently be=20 the SSH server regardless of which peer initiates the = underlying TCP connection. Maintaining the role of SSH server is both=20 necessary and desirable. It is necessary because SSH channels and subsystems can only be opened on the SSH = server. It is desirable because it conveniently leverages = infrastructure that may be deployed for host-key verification and user authentication. Call home is useful for both initial deployment and on-going device management and may be used to enable any of the following scenarios: The network element may proactively "call home" = after being powered on for the first time to register itself with its management system. The network element may access the network in a way = that dynamically assigns it an IP address and it doesn't register its assigned IP addressed to a mapping = service. The network element may be configured in "stealth = mode" and thus doesn't have any open ports for the = management system to connect to. The network element may be deployed behind a = firewall that doesn't allow SSH access to the internal = network. The network element may be deployed behind a = firewall that implements network address translation (NAT) for all internal network IP addresses, thus = complicating the ability for a management system to connect to = it. The operator may prefer to have network elements = initiate management connections believing it is easier to secure one open-port in the data center than to have an open port on each network element in the = network. One key benefit of using SSH as the transport protocol is = its ability to multiplex an unspecified number of = independently flow-controlled TCP sessions . = This is valuable as the network element only needs to be = configured=20 to initiate a single call home=20 connection to the management system, regardless the number of NETCONF channels the = management system wants to open.
The NETCONF server's perspective (e.g., the network = element) The NETCONF server initiates a TCP connection to the NETCONF client on the IANA-assigned=20 NETCONF over SSH (call home) port YYYY. The TCP connection is accepted and a TCP session is established. Using this TCP connection, the NETCONF server immediately starts the SSH server protocol. That is, the next message sent on the TCP stream is SSH's Protocol Version Exchange message (section 4.2, ). The SSH connection is established. The NETCONF client's perspective (e.g., the management = system) The NETCONF client listens for TCP connections on the IANA-assigned SSH port YYYY. The NETCONF client accepts an incoming TCP connection and a TCP session is established. Using this TCP connection, the NETCONF client = immediately starts the SSH Client protocol, starting with sending the SSH's Protocol Version Exchange message (section = 4.2, ). The SSH connection is established.
When the management system accepts a new incoming TCP connection on the NETCONF over SSH (call home) port, it starts the SSH client protocol. As the SSH client, it MUST=20 authenticate the SSH server, by both identifying the network element and verifying its SSH host key. Due to call home having the network element initiate the TCP connection, the management system MAY identify the remote peer using the source IP=20 address of the TCP connection. However, identifying the remote peer using the source IP address of the=20 TCP connection is NOT RECOMMENDED as it can only=20 work in networks that use known static addresses. To support network elements having dynamically-assigned IP addresses, or deployed behind gateways that translate their IP addresses (e.g., NAT), the management system MAY identify the device using its SSH host key. For instance, a fingerprint of the network element's host key could itself be used as an identifier since each device has a = statistically unique host key. However, identifying the remote peer using its host key directly is NOT RECOMMENDED as it requires the host key to be manually verified the first time the network element connects and anytime its host key changes thereafter. Yet another option for identifying the network element is for its host key to encode the network element's identity, such as if the host key were a certificate. This option enables the host key to change over time,=20 so long as it continues to encode the same identity, but brings the next issue of how the management system=20 can verify the network element's host key is authentic. The security of SSH is anchored in the ability for the SSH client to verify the SSH server's host key. Typically this is done by comparing the host key presented by the SSH server with one that was previously configured on the=20 SSH client, looking it up in a local database using the identity of the SSH client as the lookup key. Nothing=20 changes regarding this requirement due to the direction reversal of the underlying TCP connection. To ensure security, the management system MUST verify the network element's SSH host key each time a SSH session is established. However, configuring distinct host keys on the=20 management system doesn't scale well, which is an important consideration to a network management system. A more scalable strategy for the management system is for the=20 network element's manufacturer to sign the network-element's host key with a common trusted key, such as a certificate authority. Then, when the network-element is deployed, the management system only needs to trust a single = certificate, which vouches for the authenticity of the various=20 network element host keys. Since both the identification and verification issues are addressed using certificates, this draft RECOMMENDS network elements use a host key that can encode a unique (e.g., its serial number) and be signed by a common trust=20 anchor (e.g., a certificate authority). Examples of=20 suitable public host keys are the X.509v3 keys defined=20 in defined in .
Configuring a device to initiate a call home=20 over SSH connection is outside the scope of this document, but entails setting=20 what IP address a device should connect to and what SSH=20 host-key it should present. A complete YANG model to configure call home over = SSH=20 is specified in
This RFC deviates from standard SSH protocol usage by allowing the SSH server to initiate the TCP connection. This conflicts with section 4 of the SSH Transport Layer Protocol RFC , which states "The client initiates the connection". However this statement is made without rationalization and it's not clear how it impacts the security of the protocol, so this section analyzes the security offered by=20 having the client initiate the connection. =20 First, assuming the SSH server is not using a public host key algorithm that certifies its identity, the security of the protocol doesn't seem to be sensitive to which peer initiates the connection. That is, it is still the case that reliable distribution of host keys (or their fingerprints) should occur prior to first = connection and that verification for subsequent connections happens by comparing the host keys in a locally cached database. It does not seem to matter if the SSH server's host=20 name is derived from user-input or extracted from the TCP layer, potentially via a reverse-DNS lookup. Once the host name-to-key association is stored in a local database, no man-in-the-middle attack is possible due to the attacker being unable to guess the real SSH server's private key (Section 9.3.4 (Man-in-the-middle) of=20 ). =20 That said, this RFC recommends implementations use a public host key algorithm that certifies the SSH server's identity. The identity can be any unique=20 identifier, such as a device's serial number or a deployment-specific value. If this recommendation is followed, then no information from the TCP layer would be needed to lookup the device in a local database and therefore the directionality of the TCP layer is=20 clearly inconsequential. =20 The SSH protocol negotiates which algorithms it will use during key exchange (Section 7.1 (Algorithm Negotiation) in ). The algorithm selected is essentially the first compatible algorithm=20 listed by the SSH client that is also listed by the SSH server. For a network management application, there=20 may be a need to advertise a large number of algorithms to be compatible with the various devices it manages. The SSH client SHOULD order its list of public host key algorithms such that all the certifiable public host key algorithms are listed first. Additionally, when possible, SSH servers SHOULD only list certifiable public host key algorithms. Note that since the SSH server would have to be configured to know which IP address it is to connect to, it is expected that it will also be configured to know which host key algorithm to use for the particular application, and hence only needs to list just that one public host key algorithm. This RFC suggests implementations can use a device's serial number as a form of identity. A potential concern with using a serial number is that the SSH protocol passes the SSH server's host-key in the clear and many times serial numbers encode revealing information about the device, such as what kind of device it is and when it was manufactured. While there is little security in trying to hide this information from an attacker, it is understood that some deployments may want to keep=20 this information private. If this is a concern,=20 deployments MAY consider using instead a hash of the=20 device's serial number or an application-specified=20 unique identifier.=20 An attacker could DoS the application by having it perform computationally expensive operations, before deducing that the attacker doesn't posses a valid key. This is no different than any secured service and all common = precautions apply (e.g., blacklisting the source address after a set number of unsuccessful login attempts).
This document requests that IANA assigns a TCP port number in the "Registered Port Numbers" range with the service name "netconf-ssh-ch". This port will be the default port for=20 NETCONF over SSH (call home) protocol and will be used when the NETCONF server is to initiate a connection to a NETCONF client using SSH. Below is the registration template following the rules in=20 .
Contact: IETF Chair Description: NETCONF over SSH (call home) Reference: RFC XXXX Port Number: YYYY ]]>
The author would like to thank for following for lively discussions on list and in the halls (ordered by last name): Andy Bierman, Martin Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David Harrington, Jeffrey = Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ Mundy, Tom Petch,=20 Peter Saint-Andre, Joe Touch, Sean Turner, Bert Wijnen.
Key words for use in RFCs to Indicate Requirement = Levels Harvard University The Secure Shell (SSH) Protocol Assigned Numbers SSH Communications Security Corp Cisco Systems, Inc. The Secure Shell (SSH) Protocol Architecture SSH Communications Security Corp Cisco Systems, Inc. The Secure Shell (SSH) Authentication Protocol SSH Communications Security Corp Cisco Systems, Inc. The Secure Shell (SSH) Transport Layer Protocol SSH Communications Security Corp Cisco Systems, Inc. The Secure Shell (SSH) Connection Protocol SSH Communications Security Corp Cisco Systems, Inc. YANG - A Data Modeling Language for the=20 Network Configuration Protocol (NETCONF) Tail-f Systems X.509v3 Certificates for Secure Shell = Authentication National Security = Agency Queensland University of Technology NETCONF Configuration Protocol Juniper Networks Tail-f Systems Jacobs University Brocade Using the NETCONF Protocol over Secure Shell = (SSH) Painless Security, = LLC Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Internet Corporation for Assigned = Names and Numbers Nokia Research = Center USC/ISI Ericsson Apple Inc. A YANG Data Model for NETCONF Server = Configuration Juniper Networks Jacobs University
Changed "Reverse SSH" to "Call Home"
Changed title to "Reverse SSH for NETCONF Call = Home" Removed statement on how other SSH channels might be = used for other protocols Improved language on how the management system, as the = SSH client, MUST authenticate the SSH server Clarified that identifying the network element using = source IP address is NOT RECOMMENDED Clarified that identifying the NE using simple = certificate comparison is NOT RECOMMENDED Device Configuration section now more clearly states = that the YANG model is out of scope Change requested port name to "netconf-ssh-ch" General edits for grammer, capitalization, and = spellings
Updated Device Configuration section to reference
Added Applicability Statement Removed references to ZeroConf / ZeroTouch Clarified the protocol section Added a section for identification and verification
Removed the hmac-* family of algorithms
------=_NextPart_000_0091_01CF5652.024F6B60-- From nobody Mon Apr 14 12:27:23 2014 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 2335E1A02E9 for ; Mon, 14 Apr 2014 12:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 XXFyJPEWkfCp for ; Mon, 14 Apr 2014 12:27:15 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4081A06EA for ; Mon, 14 Apr 2014 12:27:15 -0700 (PDT) Received: from mail219-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Apr 2014 19:26:36 +0000 Received: from mail219-ch1 (localhost [127.0.0.1]) by mail219-ch1-R.bigfish.com (Postfix) with ESMTP id D7A48200069; Mon, 14 Apr 2014 19:26:36 +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(z579ehz1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail219-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=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(51704005)(46102001)(99396002)(54356999)(80976001)(2656002)(87936001)(50986999)(36756003)(76176999)(99286001)(83322001)(86362001)(92566001)(31966008)(92726001)(66066001)(76482001)(74502001)(83506001)(4396001)(81342001)(77982001)(74662001)(85852003)(20776003)(80022001)(83072002)(79102001)(81542001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:BEA6F299.A3FA8DC9.6EF78D73.EF9C241.20331; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail219-ch1 (localhost.localdomain [127.0.0.1]) by mail219-ch1 (MessageSwitch) id 1397503594911727_27372; Mon, 14 Apr 2014 19:26:34 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail219-ch1.bigfish.com (Postfix) with ESMTP id D9A221A0072; Mon, 14 Apr 2014 19:26:34 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Apr 2014 19:26:34 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.435.0; Mon, 14 Apr 2014 19:27:08 +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.918.8; Mon, 14 Apr 2014 19:27:06 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.219]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.219]) with mapi id 15.00.0918.000; Mon, 14 Apr 2014 19:27:05 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: periodic connections, heartbeats, reconnection, timeout was Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsHpGQAgAMV01OAAGtSAIAA/wKkgAUg6IA= Date: Mon, 14 Apr 2014 19:27:05 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> In-Reply-To: <008701cf5565$408130a0$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.9.131030 x-originating-ip: [66.129.241.18] x-forefront-prvs: 0181F4652A Content-Type: text/plain; charset="us-ascii" Content-ID: <6FC54C277B258F488F0AB63AD891BCB6@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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HBtb4d3MwvJuKWGe5kBWugJxy3g Cc: "netconf@ietf.org" Subject: Re: [Netconf] periodic connections, heartbeats, reconnection, timeout was Re: WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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, 14 Apr 2014 19:27:19 -0000 >ssh-server introduces introduces periodic connections, heartbeats, >reconnection and timeouts, all good functions to have in a transport >protocol. There is at least some impact on 5539-bis, perhaps on >reverse-ssh, but the starting point that I would like clarified is a >question of scope. > >Reading the details, I struggle to see why these functions should be >tied to > - SSH > - TLS > - listen > - call home > - NETCONF client > - NETCONF server >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if >no response in a suitable period, drop a connection and reconnect when >it wants to? These functions seem useful in any setting, rather than >specific to a particular scenario. Any NETCONF engine? Are you suggesting an RPC? The peer that initiates a connection is the one that should provocatively test the aliveness of the remote peer. Normally, the northbound app initiates the connection, and thus it should do it, but IETF don't have to standardize anything for everything to work (so long as we use SSH/TLS-level keep-alives). The only reason we're defining these things now is so NETCONF server's can be generically configured. Are you looking for a change in the text? >So, as and when this I-D is put up for adoption by the WG, I would like >that to be clarified before the I-D is adopted, not after. What is the >scope, what is the applicability of these new transport functions? Not >what the I-D currently says, I can see that, but where do we want to end >up? The scope is for the NETCONF server to be configurable - both TLS/SSH and both listen/call-home. >This then has consequences. Do we, for example, need a different >message for 'I am closing in the normal fashion' v 'I am closing for a >timeout' (tricky - long established protocols are still wrestling with >this one) v 'I am closing pro tem but expect to return when I have >something to do'? I'm not a fan of putting semantics into the method. And in the call-home case, since it's the NETCONF server that would timeout, it can't send an RPC to the NETCONF client anyways, it simply closes the underlying transport. Kent From nobody Tue Apr 15 11:27:41 2014 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 6CF2C1A06D1; Tue, 15 Apr 2014 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-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 f-_ZLHZ_2N-v; Tue, 15 Apr 2014 11:27:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36A1A0330; Tue, 15 Apr 2014 11:27:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7F51E1801A3; Tue, 15 Apr 2014 11:27:11 -0700 (PDT) To: mbj@tail-f.com, andy@yumaworks.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140415182711.7F51E1801A3@rfc-editor.org> Date: Tue, 15 Apr 2014 11:27:11 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jO0uZnolM5dlahsCypuaB8_8QgQ Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Verified] RFC6470 (3957) 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, 15 Apr 2014 18:27:41 -0000 The following errata report has been verified for RFC6470, "Network Configuration Protocol (NETCONF) Base Notifications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6470&eid=3957 -------------------------------------- Status: Verified Type: Technical Reported by: Martin Bj?rklund Date Reported: 2014-04-11 Verified by: Benoit Claise (IESG) Section: 2.2 Original Text ------------- uses common-session-parms { when "../confirm-event != 'timeout'"; } leaf confirm-event { Corrected Text -------------- uses common-session-parms { when "confirm-event != 'timeout'"; } leaf confirm-event { Notes ----- "uses" does not define a node. RFC 6020, 7.19.5 specifies that the context node for "when" is the node above the "uses" statement: o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice", or "case" node that is also a data node. -------------------------------------- RFC6470 (draft-ietf-netconf-system-notifications-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Base Notifications Publication Date : February 2012 Author(s) : A. Bierman Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Apr 18 08:31:48 2014 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 B18881A0407; Fri, 18 Apr 2014 08:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 zARYVDZkD4jc; Fri, 18 Apr 2014 08:31:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B154A1A0429; Fri, 18 Apr 2014 08:31:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1091418000C; Fri, 18 Apr 2014 08:30:50 -0700 (PDT) To: jernej.tuljak@mg-soft.com, andy@yumaworks.com, mbj@tail-f.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140418153050.1091418000C@rfc-editor.org> Date: Fri, 18 Apr 2014 08:30:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/m9F6QMCftTw9zlDYTi6QYHNRkXY Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Verified] RFC6536 (3862) 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, 18 Apr 2014 15:31:44 -0000 The following errata report has been verified for RFC6536, "Network Configuration Protocol (NETCONF) Access Control Model". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3862 -------------------------------------- Status: Verified Type: Technical Reported by: Jernej Tuljak Date Reported: 2014-01-10 Verified by: Benoit Claise (IESG) Section: 3.5.2. Original Text ------------- typedef matchall-string-type { type string { pattern "\*"; } description "The string containing a single asterisk '*' is used to conceptually represent all possible values for the particular leaf using this data type."; } Corrected Text -------------- typedef matchall-string-type { type string { pattern '\*'; } description "The string containing a single asterisk '*' is used to conceptually represent all possible values for the particular leaf using this data type."; } Notes ----- As per RFC6020, Section 6.1.3., a backslash within a double-quoted string introduces a special character. The only valid escape sequences inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not a valid escape sequence, a single quoted string should be used to specify the offending pattern statement's argument. The quotes could also be omitted. -------------------------------------- RFC6536 (draft-ietf-netconf-access-control-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Access Control Model Publication Date : March 2012 Author(s) : A. Bierman, M. Bjorklund Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Apr 18 09:09:38 2014 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 97F521A0256; Fri, 18 Apr 2014 09:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 0jy0k6s5Lvbk; Fri, 18 Apr 2014 09:09:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 083D41A0228; Fri, 18 Apr 2014 09:09:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4ACE218000C; Fri, 18 Apr 2014 09:08:48 -0700 (PDT) To: jernej.tuljak@mg-soft.com, andy@yumaworks.com, mbj@tail-f.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140418160848.4ACE218000C@rfc-editor.org> Date: Fri, 18 Apr 2014 09:08:48 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/z8j_LncW6UQ_JZoHVz683kwSStU Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Verified] RFC6536 (3863) 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, 18 Apr 2014 16:09:28 -0000 The following errata report has been verified for RFC6536, "Network Configuration Protocol (NETCONF) Access Control Model". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3863 -------------------------------------- Status: Verified Type: Technical Reported by: Jernej Tuljak Date Reported: 2014-01-10 Verified by: Benoit Claise (IESG) Section: 3.5.2. Original Text ------------- typedef group-name-type { type string { length "1..max"; pattern "[^\*].*"; } description "Name of administrative group to which users can be assigned."; } Corrected Text -------------- typedef group-name-type { type string { length "1..max"; pattern '[^\*].*'; } description "Name of administrative group to which users can be assigned."; } Notes ----- As per RFC6020, Section 6.1.3., a backslash within a double-quoted string introduces a special character. The only valid escape sequences inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not a valid escape sequence, a single quoted string should be used to specify the offending pattern statement's argument. The quotes could also be omitted. -------------------------------------- RFC6536 (draft-ietf-netconf-access-control-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Access Control Model Publication Date : March 2012 Author(s) : A. Bierman, M. Bjorklund Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Apr 18 14:18:17 2014 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 CF8751A02D8; Fri, 18 Apr 2014 14:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gTjEFem0fQR4; Fri, 18 Apr 2014 14:18:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0991A007B; Fri, 18 Apr 2014 14:18:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418211812.10472.87210.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 14:18:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/q2dwiged6AGsHfadfiymMcaVJi0 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 21:18:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF over SSH Call Home Author : Kent Watsen Filename : draft-ietf-netconf-reverse-ssh-05.txt Pages : 10 Date : 2014-04-18 Abstract: This document presents a technique for a NETCONF server to initiate a SSH connection to a NETCONF client. This is accomplished by the NETCONF client listening on IANA-assigned TCP port YYYY and starting the SSH client protocol immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH server, in order for the NETCONF client to open the IANA-assigned SSH subsystem "netconf". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-reverse-ssh-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 18 14:39:10 2014 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 BF01E1A0109; Fri, 18 Apr 2014 14:39:07 -0700 (PDT) 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 6jE7lSEBFtKz; Fri, 18 Apr 2014 14:39:05 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id E4A431A007B; Fri, 18 Apr 2014 14:39:04 -0700 (PDT) Received: from mail47-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE015.bigfish.com (10.3.207.137) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Apr 2014 21:38:12 +0000 Received: from mail47-am1 (localhost [127.0.0.1]) by mail47-am1-R.bigfish.com (Postfix) with ESMTP id B9FC9A01AE; Fri, 18 Apr 2014 21:38: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: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I936eI1432I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h1155h) Received-SPF: pass (mail47-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:(10009001)(6009001)(428001)(24454002)(164054003)(377424004)(51704005)(377454003)(479174003)(189002)(199002)(74502001)(92566001)(74662001)(87936001)(31966008)(99396002)(92726001)(50986999)(83072002)(85852003)(54356999)(76176999)(80022001)(81542001)(66066001)(81342001)(36756003)(79102001)(20776003)(4396001)(77982001)(80976001)(83322001)(99286001)(19580405001)(19580395003)(86362001)(76482001)(2656002)(46102001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:BC07FD7D.9CF22BC9.BDE31348.44E9DA51.20331; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail47-am1 (localhost.localdomain [127.0.0.1]) by mail47-am1 (MessageSwitch) id 1397857090832498_23301; Fri, 18 Apr 2014 21:38:10 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.226]) by mail47-am1.bigfish.com (Postfix) with ESMTP id C6EC460049; Fri, 18 Apr 2014 21:38:10 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Apr 2014 21:38:10 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 18 Apr 2014 21:38:56 +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.921.12; Fri, 18 Apr 2014 21:38:53 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.170]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.170]) with mapi id 15.00.0921.000; Fri, 18 Apr 2014 21:38:53 +0000 From: Kent Watsen To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-05.txt Thread-Index: AQHPW0vEBf3+F0ueckiWAYNVS9qYEpsXo4gA Date: Fri, 18 Apr 2014 21:38:52 +0000 Message-ID: References: <20140418211812.10472.87210.idtracker@ietfa.amsl.com> In-Reply-To: <20140418211812.10472.87210.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.10] x-forefront-prvs: 018577E36E Content-Type: text/plain; charset="iso-8859-1" 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% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LuI1g4Iep7bQRp8er4tz-xBYeNQ Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-05.txt 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, 18 Apr 2014 21:39:07 -0000 This version has two updates: - Removed =B3vagueness=B2 in second paragraph of the Applicability Statem= ent reported by Alan Luchuk. This is achieved by adding RFC references for key assertions made there. - Changed "Reverse SSH" to "Call Home=B2, per the XML Tom Petch sent out. I made a couple minor tweaks on top of what Tom had. In terms of last-call, there only remains the issue of if this draft's reference to the netconf-server-model draft needs to be normative (not informative). I don=B9t think so, but am OK either way. If we think the reference needs to be normative, then I guess we delay last-call on this draft (and 5539-bis) until netconf-server-model is also ready - right? Thanks, Kent On 4/18/14, 5:18 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF over SSH Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-reverse-ssh-05.txt > Pages : 10 > Date : 2014-04-18 > >Abstract: > This document presents a technique for a NETCONF server to initiate a > SSH connection to a NETCONF client. This is accomplished by the > NETCONF client listening on IANA-assigned TCP port YYYY and starting > the SSH client protocol immediately after accepting a TCP connection > on it. This role-reversal is necessary as the NETCONF server must > also be the SSH server, in order for the NETCONF client to open the > IANA-assigned SSH subsystem "netconf". > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-05 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-reverse-ssh-05 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From nobody Sat Apr 19 08:08:30 2014 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 97C5E1A0009 for ; Sat, 19 Apr 2014 08:08:29 -0700 (PDT) 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_HELO_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 K5aRKXzs6VLS for ; Sat, 19 Apr 2014 08:08:25 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) by ietfa.amsl.com (Postfix) with ESMTP id A4E9C1A0002 for ; Sat, 19 Apr 2014 08:08:24 -0700 (PDT) Received: from DBXPRD0610HT002.eurprd06.prod.outlook.com (157.56.252.181) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.0.921.12; Sat, 19 Apr 2014 15:08:18 +0000 Message-ID: <00cf01cf5be0$ecf1b860$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> Date: Sat, 19 Apr 2014 16:02:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: AM3PR07CA0038.eurprd07.prod.outlook.com (10.141.45.166) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-Forefront-PRVS: 018632C080 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(13464003)(199002)(189002)(377454003)(47776003)(20776003)(62236002)(79102001)(44716002)(50466002)(83322001)(81342001)(19580405001)(19580395003)(88136002)(14496001)(89996001)(85852003)(83072002)(1941001)(62966002)(81542001)(77156001)(80976001)(23756003)(92566001)(92726001)(61296002)(44736004)(74502001)(31966008)(50226001)(74662001)(46102001)(4396001)(42186004)(84392001)(87286001)(86362001)(87976001)(77982001)(76482001)(99396002)(33646001)(50986999)(76176999)(66066001)(81816999)(93916002)(81686999)(80022001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB063; H:DBXPRD0610HT002.eurprd06.prod.outlook.com; FPR:BEB4F219.A3FA993A.7DF7BD7B.4AFAD271.204B7; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GVVrgm_LWBRNmsF1fPoQgTvRyOI Cc: netconf@ietf.org Subject: Re: [Netconf] periodic connections, heartbeats, reconnection, timeout was Re: WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt 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: Sat, 19 Apr 2014 15:08:29 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Monday, April 14, 2014 8:27 PM >ssh-server introduces introduces periodic connections, heartbeats, >reconnection and timeouts, all good functions to have in a transport >protocol. There is at least some impact on 5539-bis, perhaps on >reverse-ssh, but the starting point that I would like clarified is a >question of scope. > >Reading the details, I struggle to see why these functions should be >tied to > - SSH > - TLS > - listen > - call home > - NETCONF client > - NETCONF server >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if >no response in a suitable period, drop a connection and reconnect when >it wants to? These functions seem useful in any setting, rather than >specific to a particular scenario. Any NETCONF engine? Are you suggesting an RPC? The peer that initiates a connection is the one that should provocatively test the aliveness of the remote peer. Normally, the northbound app initiates the connection, and thus it should do it, but IETF don't have to standardize anything for everything to work (so long as we use SSH/TLS-level keep-alives). The only reason we're defining these things now is so NETCONF server's can be generically configured. Are you looking for a change in the text? Kent The heartbeat protocols that I know are symmetric, even when there is, at some protocol level, a client and server. Sometimes the one protocol so that either end can detect a loss of connectivity, sometimes two protocols, one for each end, perhaps with different properties to suit the different ends. And when you say 'initiates the connection', which connection:-) The TCP one or the NETCONF one? You say, in netconf-server, " This connection type minimizes any application-to-server data-transfer delay, albeit at the expense of holding resources longer."; which I see by way of justification, but I see the argument as being equally valid for both ends. TCP famously can be down for hours with noone noticing as some developers of syslog found to their surprise. Is it more important for the device generating a syslog messge to know that the transport is up and running, or that the receiver of the messages knows that a transport failure has not stopped them coming through? I would like to see more justification of why this hearbeat should be asymmetric, suspecting that down the tracks we will wish it were otherwise This then drives the mechanics but at a protocol level, I would hope we would be re-using the existing SSH/TLS facilities, keeping them the same in-so-far as we can. Tom Petch >So, as and when this I-D is put up for adoption by the WG, I would like >that to be clarified before the I-D is adopted, not after. What is the >scope, what is the applicability of these new transport functions? Not >what the I-D currently says, I can see that, but where do we want to end >up? The scope is for the NETCONF server to be configurable - both TLS/SSH and both listen/call-home. >This then has consequences. Do we, for example, need a different >message for 'I am closing in the normal fashion' v 'I am closing for a >timeout' (tricky - long established protocols are still wrestling with >this one) v 'I am closing pro tem but expect to return when I have >something to do'? I'm not a fan of putting semantics into the method. And in the call-home case, since it's the NETCONF server that would timeout, it can't send an RPC to the NETCONF client anyways, it simply closes the underlying transport. Kent From nobody Mon Apr 21 09:10:18 2014 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 7BDB61A0010 for ; Mon, 21 Apr 2014 09:10:15 -0700 (PDT) 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 D9KDS8ip2yg5 for ; Mon, 21 Apr 2014 09:10:11 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id DA5CF1A022B for ; Mon, 21 Apr 2014 09:10:10 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so4110284qcq.23 for ; Mon, 21 Apr 2014 09:10:05 -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:content-type; bh=DwEczQSOSZPKJ9BlN94RpO62zOVAAnSqLvM0s+1QljA=; b=X/dbGN9EDTJFvJAeoUGL+kTKfD73eYLpo60OnMMsxcsO0aIR96fiscRq2xiVLlFDEk gmsvayqpHHQBr3LMAQnGC7V93WFeo+6vQztx2wDxSfISho96qXrCCocav3Wwll7AmWAn Rk8C4eL9zbwq90zLaFKr266skvQU/L5EjkuXyzH4sBAb4wd6WonduxY6UhsDafo4FLNo bunxnLQ0Fz0SdApcMLb+QpdseLfrrWjIMStyF/cHGTSmrZzBTIwSuD+nEdoHhG+cPxe5 XMFFTdJtWMN+2hHcDowlhbVOYkUEJ4uiD2t3jAn3h+aQtULmjISt95AZDz9/ZRufrkZN oWfw== X-Gm-Message-State: ALoCoQms+3LG/7orfNFVB8WoAgPkx3cgfFOO69uXTLj4POchy/8u8ZqQOTutQqIqZSolLmYiN8q9 MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr42412818qai.16.1398096605611; Mon, 21 Apr 2014 09:10:05 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 09:10:05 -0700 (PDT) In-Reply-To: <20140421160840.22073.20611.idtracker@ietfa.amsl.com> References: <20140421160840.22073.20611.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 09:10:05 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c20e7a8a1e6a04f78fbbff Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WsnnNVGxLdYSBvXgMeY6pM1YC90 Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-efficiency-extensions-01.txt 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, 21 Apr 2014 16:10:15 -0000 --001a11c20e7a8a1e6a04f78fbbff Content-Type: text/plain; charset=ISO-8859-1 FYI, The NETCONF-EX draft has been updated based on comments and discussion at the last IETF meeting. Andy ---------- Forwarded message ---------- From: Date: Mon, Apr 21, 2014 at 9:08 AM Subject: I-D Action: draft-bierman-netconf-efficiency-extensions-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Efficiency Extensions Author : Andy Bierman Filename : draft-bierman-netconf-efficiency-extensions-01.txt Pages : 69 Date : 2014-04-21 Abstract: This document describes protocol extensions to improve the efficiency of the Network Configuration Protocol (NETCONF). Protocol capabilities and operations are defined to reduce network usage and transaction complexity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-efficiency-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-efficiency-extensions-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c20e7a8a1e6a04f78fbbff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

The NETCONF-EX draft has been upda= ted based on comments
and discussion at the last IETF meeting.


Andy


---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Apr 21, 2014 at 9:08 = AM
Subject: I-D Action: draft-bierman-netconf-efficiency-extensions-01.txt
= To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : NETCONF Efficiency Extensions =A0 =A0 =A0 =A0 Author =A0 =A0 =A0 =A0 =A0: Andy Bierman
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-efficiency-= extensions-01.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 69
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-04-21

Abstract:
=A0 =A0This document describes protocol extensions to improve the efficienc= y
=A0 =A0of the Network Configuration Protocol (NETCONF). =A0Protocol
=A0 =A0capabilities and operations are defined to reduce network usage and<= br> =A0 =A0transaction complexity.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bie= rman-netconf-efficiency-extensions/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netco= nf-efficiency-extensions-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddra= ft-bierman-netconf-efficiency-extensions-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c20e7a8a1e6a04f78fbbff--