From balazs.lengyel@ericsson.com Mon Jun 3 05:36:58 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5D21F8904 for ; Mon, 3 Jun 2013 05:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB5LKo+HwrLG for ; Mon, 3 Jun 2013 05:36:51 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1521F962D for ; Mon, 3 Jun 2013 05:36:50 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-71-51ac8de0a13d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B6.BF.09795.0ED8CA15; Mon, 3 Jun 2013 14:36:49 +0200 (CEST) Received: from [159.107.197.117] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 3 Jun 2013 14:36:48 +0200 Message-ID: <51AC8DE0.8000605@ericsson.com> Date: Mon, 3 Jun 2013 14:36:48 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCJMWRmVeSWpSXmKPExsUyM+Jvre7D3jWBBn3buS2mbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDkrjApes1Q07FvD0sB4grmLkYNDQsBE4scjri5GTiBTTOLC vfVsXYxcHEICpxgl5jxeyQySEBJYwygxdYMgiM0roC3x4nsbI4jNIqAi8fjrHSYQm03ASGJq /3kWEFtUIEpizroHbBD1ghInZz4Bi4sIaEo0zvrACmILCzhLPHp6HGwOs4CtxIU511kgbHmJ 7W/nQO3VkHh44S/rBEa+WUhGzULSMgtJywJG5lWM7LmJmTnp5eabGIEhc3DLb4MdjJvuix1i lOZgURLn1eddHCgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0WjKlcU59iJs0vtYTGRdChj+ Bn1fOSs9sdRHadunX39mhgbZ9XCYHuE+2XzxgFjkpFvXfV0DNZ7mSNsK2Lz8K3mv93jGt6Rl 16NvPD655T7H7cbKtebbq946ekiaOM9foxKwydim/7FUZDn/4t4ViVME1rwInlGera7iM2c/ 37W5G3OU1m0VUmIpzkg01GIuKk4EAJv9ZprnAQAA Subject: [Netconf] Error-Option: why is stop and continue on error mandatory? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:36:58 -0000 Hello, I know I should know this, but ... Why are the error-option values stop-on-error and continue-on-error mandatory? Many of our systems operate on a strict transactional basis, you either commit the full edit-config or nothing. Both stop and continue imply that you should be able to store a partial transaction. Why mess up the configuration if you can do a rollback? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From andy@yumaworks.com Thu Jun 6 10:09:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662C721F9A6E for ; Thu, 6 Jun 2013 10:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ2ez0XE0vNG for ; Thu, 6 Jun 2013 10:09:26 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 70D3521F9A38 for ; Thu, 6 Jun 2013 10:09:24 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id wp1so1890719pac.17 for ; Thu, 06 Jun 2013 10:09:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=OYwJl6oDxipWNgXNE7yMXZyieO52ESsduj9W/BTzsiw=; b=GpXyGRxKyiCgzxibFUtHBp/iQqRntyxbCOivLdyLQs7ONc6QgSVbS7wqkt/f9lHmhc 9pKMaoxpTBteCTFZtcqb+s1BwD7jwzmdwu9MRyOBrJe6uh1UnatN8Bsb35/3269Mh+Em S0yVcqKW/JdZ91swHXfmdNNYCJwkoMVf4TG5ZanygkcM163ZPRE7R5mJvlzEWoL1jcEd oN7iSKhCU66IdQLb/R4Z4YY1E3SZfYkSZwu0r80brIk97uTXOjYtbZ1CoXW7sVtFxJIQ IQmMFws2gxpw2lpgUP8eBeXks7ZGnVpWI73kSaEsMrNeSYccaOlmxA040iKbrLERdgah EJ/g== MIME-Version: 1.0 X-Received: by 10.66.228.98 with SMTP id sh2mr22474424pac.80.1370538564443; Thu, 06 Jun 2013 10:09:24 -0700 (PDT) Received: by 10.70.87.103 with HTTP; Thu, 6 Jun 2013 10:09:24 -0700 (PDT) In-Reply-To: <51AC8DE0.8000605@ericsson.com> References: <51AC8DE0.8000605@ericsson.com> Date: Thu, 6 Jun 2013 10:09:24 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=047d7b15a8d148f2dc04de7f6035 X-Gm-Message-State: ALoCoQnZXqYnzmp3Jgj18+bq43srWKOSjufarnYFVdNwr2zmMqXkFUX7GtiA75deq+SvW5tWWbCJ Cc: "netconf@ietf.org" Subject: Re: [Netconf] Error-Option: why is stop and continue on error mandatory? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:09:27 -0000 --047d7b15a8d148f2dc04de7f6035 Content-Type: text/plain; charset=ISO-8859-1 Hi Balazs, We discussed this exact issue at the test event, and whether the text was clear or not. IMO, the error-option parameter is very system-specific. Our server works like yours -- you get rollback-on-error no matter what you choose. I think the consensus was that stop-on-error and continue-on-error meant the server was allowed to do those actions, but it did not have to leave the config in a partial unknown state (stop) or intentionally leave errors in the config (continue). The only robust solution is all-or-nothing (except for 'rollback-failed' errors). We support a CLI parameter: --startup-error=stop|continue. This is another area of contention -- errors loading the running config from NV-storage. Some devices just prune the error instances and continue. Some shutdown and don't attempt to prune errors. Andy On Mon, Jun 3, 2013 at 5:36 AM, Balazs Lengyel wrote: > Hello, > I know I should know this, but ... > > Why are the error-option values stop-on-error and continue-on-error > mandatory? Many of our systems operate on a strict transactional basis, you > either commit the full edit-config or nothing. Both stop and continue imply > that you should be able to store a partial transaction. Why mess up the > configuration if you can do a rollback? > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > ______________________________**_________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/**listinfo/netconf > --047d7b15a8d148f2dc04de7f6035 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Balazs,

We discussed this exact issue at the test eve= nt, and whether
the text was clear or not. =A0IMO, the error-opti= on parameter
is very system-specific. =A0Our server works like yo= urs -- you get
rollback-on-error no matter what you choose. =A0I think the consensus<= /div>
was that stop-on-error and continue-on-error meant the server was=
allowed to do those actions, but it did not have to leave the
config in a partial unknown state (stop) or intentionally leave errors=
in the config (continue). =A0The only robust solution is all-or-= nothing
(except for 'rollback-failed' errors).

We support a CLI parameter: --startup-error=3Dstop|continue.=
This is another area of contention -- errors loading the running=
config from NV-storage. Some devices just prune the error instan= ces
and continue. =A0Some shutdown and don't attempt to prune errors.<= /div>


Andy

On Mon, Jun 3, 2013 at 5:36 AM, Balazs Lengyel <balaz= s.lengyel@ericsson.com> wrote:
Hello,
I know I should know this, but ...

Why are the error-option values stop-on-error and continue-on-error mandato= ry? Many of our systems operate on a strict transactional basis, you either= commit the full edit-config or nothing. Both stop and continue imply that = you should be able to store a partial transaction. Why mess up the configur= ation if you can do a rollback?
regards Balazs

--
Balazs Lengyel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ericsson Hungary= Ltd.
System Manager
ECN: 831 7320 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tel: +36-1-437= -7320
Mobile: +36-70-330-7909 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: Balazs.Lengyel@ericsson.com=

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

--047d7b15a8d148f2dc04de7f6035-- From lhotka@nic.cz Thu Jun 6 11:05:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB48221E80A5 for ; Thu, 6 Jun 2013 11:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4+CoZyGsvvE for ; Thu, 6 Jun 2013 11:05:30 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD0421E80A7 for ; Thu, 6 Jun 2013 11:05:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 12F3B5401A0 for ; Thu, 6 Jun 2013 20:05:04 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMwKj5NONGhR for ; Thu, 6 Jun 2013 20:04:55 +0200 (CEST) Received: from [172.29.2.202] (unknown [172.29.2.202]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8E83254012E for ; Thu, 6 Jun 2013 20:04:50 +0200 (CEST) From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <348A55BA-AE21-4E6B-A3A7-E0CEDC63DAB7@nic.cz> Date: Thu, 6 Jun 2013 20:04:50 +0200 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Netconf] NETCONF extensions in 6020 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:05:35 -0000 Hi, today I got a tricky question that I couldn't adequately answer: RFC = 6020 introduces extensions to the NETCONF protocol - specifically, = several new attributes for edit-config. However, this extension is not = explicitly advertised as a capability. Does it mean that advertising = *any* YANG module in hello automatically includes support for these = YANG-based extensions? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Jun 6 13:39:17 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC9711E80E4 for ; Thu, 6 Jun 2013 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko015vyf8TJy for ; Thu, 6 Jun 2013 13:39:11 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE2C11E8102 for ; Thu, 6 Jun 2013 13:39:11 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 433571200A35; Thu, 6 Jun 2013 22:39:09 +0200 (CEST) Date: Thu, 06 Jun 2013 22:39:08 +0200 (CEST) Message-Id: <20130606.223908.83610371.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <348A55BA-AE21-4E6B-A3A7-E0CEDC63DAB7@nic.cz> References: <348A55BA-AE21-4E6B-A3A7-E0CEDC63DAB7@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF extensions in 6020 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:39:17 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > today I got a tricky question that I couldn't adequately answer: RFC 6020 > introduces extensions to the NETCONF protocol - specifically, several new > attributes for edit-config. However, this extension is not explicitly > advertised as a capability. Does it mean that advertising *any* YANG module in > hello automatically includes support for these YANG-based extensions? No. These attributes are only applicable for ordered-by user (leaf-)lists. If a server advertises support for a YANG module with such nodes, it means it supports these attributes (for these nodes). If a server does not support any modules with ordered-by user (leaf-)lists, these attributes don't apply. /martin From lhotka@nic.cz Fri Jun 7 01:54:43 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5115821F8F4D for ; Fri, 7 Jun 2013 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Siyi2k+PJAni for ; Fri, 7 Jun 2013 01:54:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 95D9C21F8E8F for ; Fri, 7 Jun 2013 01:54:36 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CB7F913F8E3; Fri, 7 Jun 2013 10:54:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1370595274; bh=hw+IDuqvrluxDx/kNchJE+p8k5o69kvTdP52YPhZbVw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nQetaDitJvluxeoq9keq775ryKiSXTDKBXoofdEkaH1JohrcmLzz6xzTNLqz3JWYl hM7355Di9isumEo55XNUzDV4ZmdEfiCEgOmXYgmo5nBimQwXI+sMZPi8VLiCCFsgLr UoGV3napZ/Q6BNN3XtwBuFoA/xtZximNyWr+jamk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130606.223908.83610371.mbj@tail-f.com> Date: Fri, 7 Jun 2013 10:54:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <816C8E52-059D-46C6-8743-814C5B9ACAE5@nic.cz> References: <348A55BA-AE21-4E6B-A3A7-E0CEDC63DAB7@nic.cz> <20130606.223908.83610371.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF extensions in 6020 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 08:54:43 -0000 On Jun 6, 2013, at 10:39 PM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> today I got a tricky question that I couldn't adequately answer: RFC = 6020 >> introduces extensions to the NETCONF protocol - specifically, several = new >> attributes for edit-config. However, this extension is not explicitly >> advertised as a capability. Does it mean that advertising *any* YANG = module in >> hello automatically includes support for these YANG-based extensions? >=20 > No. These attributes are only applicable for ordered-by user > (leaf-)lists. If a server advertises support for a YANG module with > such nodes, it means it supports these attributes (for these nodes). >=20 > If a server does not support any modules with ordered-by user > (leaf-)lists, these attributes don't apply. OK. The question came from a colleague who implements NETCONF fro = OpenWRT's Unified Configuration Interface, and he doesn't want to = support the "before" and "after" updates even for ordered-by-user lists = - so the entire list would have to be completely replaced instead. I = will try to change his mind=85 Thanks, Lada >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From prvs=6873f506fa=balazs.lengyel@ericsson.com Mon Jun 10 08:59:10 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A5C21F86C0 for ; Mon, 10 Jun 2013 08:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvSkZqpVtWu3 for ; Mon, 10 Jun 2013 08:59:04 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 646BA21F869F for ; Mon, 10 Jun 2013 08:59:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-54-51b5f7c61316 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 50.A5.09795.6C7F5B15; Mon, 10 Jun 2013 17:59:02 +0200 (CEST) Received: from [159.107.197.58] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Jun 2013 17:59:02 +0200 Message-ID: <51B5F7C5.9010505@ericsson.com> Date: Mon, 10 Jun 2013 17:59:01 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Bierman References: <51AC8DE0.8000605@ericsson.com> In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42KZGfG3VvfY962BBt/adSweHJnFbjF1021W ByaPJUt+Mnm09F9kCWCK4rZJSiwpC85Mz9O3S+DOuLzpGFtBi2rF+iM/WRsYu6W6GDk4JARM JPYdVuxi5AQyxSQu3FvP1sXIxSEkcIpR4tqTw0wQzhpGic9/fjKBVPEKaEvs+HmaBcRmEVCV aGyYyA5iswkYSUztPw8WFxWIkpiz7gEbRL2gxMmZT8DiIkD1F+ZOZAaxmQU0Jdb+/QhmCwsE Skz8fYcRxBYSKJC49+UTWJwTKL7x5E82iHpdiQv/p7BA2PIS29/OYYao15B4eOEv6wRGwVlI 1s1C0jILScsCRuZVjOy5iZk56eXmmxiBQXlwy2+DHYyb7osdYpTmYFES59XnXRwoJJCeWJKa nZpakFoUX1Sak1p8iJGJgxNEcEk1MOZd7ZqVbKhRZpoT3LroXfll8x5uzq+XTabn6pz34n1q U+PksqBugppH2w7nY/9sjglPOVix5+6cH9b9ux019obqP8usKTy1ft2ZFzO/5utM/dpU6+g3 11Ve53gyb7Ti3IyZATltifY7yuM4cvemxGy7xi2QGZ8UKb2P05jl2WUluUBPtjM8SizFGYmG WsxFxYkA08kIeh0CAAA= Cc: "netconf@ietf.org" Subject: Re: [Netconf] Error-Option: why is stop and continue on error mandatory? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:59:10 -0000 Hello Andy,
Thanks for the info.
For me these seem to be errors in the RFC. If I just read the text, continue-on-error does not allow roll-back or at least strongly hints at not doing it.
If I had the time I would consider writing errata about them: to make them optional.
regards Balazs

.
On 2013-06-06 19:09, Andy Bierman wrote:
Hi Balazs,

We discussed this exact issue at the test event, and whether
the text was clear or not.  IMO, the error-option parameter
is very system-specific.  Our server works like yours -- you get
rollback-on-error no matter what you choose.  I think the consensus
was that stop-on-error and continue-on-error meant the server was
allowed to do those actions, but it did not have to leave the
config in a partial unknown state (stop) or intentionally leave errors
in the config (continue).  The only robust solution is all-or-nothing
(except for 'rollback-failed' errors).

We support a CLI parameter: --startup-error=stop|continue.
This is another area of contention -- errors loading the running
config from NV-storage. Some devices just prune the error instances
and continue.  Some shutdown and don't attempt to prune errors.


Andy

On Mon, Jun 3, 2013 at 5:36 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello,
I know I should know this, but ...

Why are the error-option values stop-on-error and continue-on-error mandatory? Many of our systems operate on a strict transactional basis, you either commit the full edit-config or nothing. Both stop and continue imply that you should be able to store a partial transaction. Why mess up the configuration if you can do a rollback?
regards Balazs

--
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com

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


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From andy@yumaworks.com Mon Jun 10 09:15:50 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCE521F9711 for ; Mon, 10 Jun 2013 09:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20UqH7KbkEe7 for ; Mon, 10 Jun 2013 09:15:46 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id BD4D221F97E6 for ; Mon, 10 Jun 2013 09:15:42 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so4679144pdi.2 for ; Mon, 10 Jun 2013 09:15:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=joIiaFWS1IU9DmGncFiCLS3jTdYHPiAuTVRhTUB5dR0=; b=IejibPbyR6Rn0Gi0fH7eAKCOhlWbkY0vnL7NHoyuxNSiyuAddciU8ptO0fBMGjFLVZ 7JrjItmiXHYzZ7rHnL4DPF481QLzhQTGlYSBYsRdvdPYq3YBTpLkMe3qvaYLxof3UDe9 ZWwN6JK81uFv1WJsbRyxOnb1Hh5Z5j6ddJlOLwQ7b6uwHMDwGUpJ+fsmjb4qOMWn9Dyv hx5Qfcs+/0TmLfOvlCyFUFUkMmEdOPTRNCOA7auWRso37G9OSmwT37/+50lpy2bAcsdM hCaUFecC92r7UXHMlh0zLQuG4o36j+wtVzmu5MjTby889YfJOomjYYpOHwidDbeTUMrF LwgQ== MIME-Version: 1.0 X-Received: by 10.66.159.66 with SMTP id xa2mr14915466pab.36.1370880942199; Mon, 10 Jun 2013 09:15:42 -0700 (PDT) Received: by 10.70.87.103 with HTTP; Mon, 10 Jun 2013 09:15:42 -0700 (PDT) In-Reply-To: <51B5F7C5.9010505@ericsson.com> References: <51AC8DE0.8000605@ericsson.com> <51B5F7C5.9010505@ericsson.com> Date: Mon, 10 Jun 2013 09:15:42 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=047d7bacbde696eb4104decf1734 X-Gm-Message-State: ALoCoQl7x/bxjRqfEDsxNljYMLkC6dez3BFfeCTHoEecI6MLm30BSr5IYXlJkDbPd0MNxOX2venk Cc: "netconf@ietf.org" Subject: Re: [Netconf] Error-Option: why is stop and continue on error mandatory? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:15:50 -0000 --047d7bacbde696eb4104decf1734 Content-Type: text/plain; charset=ISO-8859-1 Hi, Keep in mind that error-option was written with the CLI model in mind. It was intended to allow a server to process the XML in document order as commands. It should be deprecated. Servers that use a transaction model always do rollback-on-error. The entire request is validated before any of it is applied. Every patch within the or is a recoverable edit. Essentially the operation is implemented for any database write. I agree that the error-option text might lead people to think it is actually some sort of a parameter, when in fact it is a server capability instead. We completely ignore that parameter in our implementation, after checking it is a valid enum. You can't ask the server to leave the database corrupted, let alone 2 specific ways to leave it corrupted. Andy On Mon, Jun 10, 2013 at 8:59 AM, Balazs Lengyel wrote: > Hello Andy, > Thanks for the info. > For me these seem to be errors in the RFC. If I just read the text, > continue-on-error does not allow roll-back or at least strongly hints at > not doing it. > If I had the time I would consider writing errata about them: to make them > optional. > regards Balazs > > . > On 2013-06-06 19:09, Andy Bierman wrote: > > Hi Balazs, > > We discussed this exact issue at the test event, and whether > the text was clear or not. IMO, the error-option parameter > is very system-specific. Our server works like yours -- you get > rollback-on-error no matter what you choose. I think the consensus > was that stop-on-error and continue-on-error meant the server was > allowed to do those actions, but it did not have to leave the > config in a partial unknown state (stop) or intentionally leave errors > in the config (continue). The only robust solution is all-or-nothing > (except for 'rollback-failed' errors). > > We support a CLI parameter: --startup-error=stop|continue. > This is another area of contention -- errors loading the running > config from NV-storage. Some devices just prune the error instances > and continue. Some shutdown and don't attempt to prune errors. > > > Andy > > On Mon, Jun 3, 2013 at 5:36 AM, Balazs Lengyel < > balazs.lengyel@ericsson.com> wrote: > >> Hello, >> I know I should know this, but ... >> >> Why are the error-option values stop-on-error and continue-on-error >> mandatory? Many of our systems operate on a strict transactional basis, you >> either commit the full edit-config or nothing. Both stop and continue imply >> that you should be able to store a partial transaction. Why mess up the >> configuration if you can do a rollback? >> regards Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> System Manager >> ECN: 831 7320 Tel: +36-1-437-7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > --047d7bacbde696eb4104decf1734 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Keep in mind that error-option was written with the = CLI model in mind.
It was intended to allow a server to process t= he XML in document order
as commands. =A0It should be deprecated.=

Servers that use a transaction model always do rollback= -on-error.
The entire request is validated before any of it is ap= plied.
Every patch within the <edit-config> or <copy-con= fig> is a recoverable edit.
Essentially the <commit> operation is implemented for any databa= se write.

I agree that the error-option text might= lead people to think it is actually
some sort of a parameter, wh= en in fact it is a server capability instead.
We completely ignore that parameter in our implementation, after check= ing
it is a valid enum. =A0You can't ask the server to leave = the database corrupted,
let alone 2 specific ways to leave it cor= rupted.


Andy


On Mon, Jun 10, 2013 at 8:59 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
=20 =20 =20
Hello Andy,
Thanks for the info.
For me these seem to be errors in the RFC. If I just read the text, continue-on-error does not allow roll-back or at least strongly hints at not doing it.
If I had the time I would consider writing errata about them: to make them optional.
regards Balazs

.
On 2013-06-06 19:09, Andy Bierman wrote:
=20 Hi Balazs,

We discussed this exact issue at the test event, and whether
the text was clear or not. =A0IMO, the error-option parameter
is very system-specific. =A0Our server works like yours -- you get
rollback-on-error no matter what you choose. =A0I think the consensus
was that stop-on-error and continue-on-error meant the server was
allowed to do those actions, but it did not have to leave the
config in a partial unknown state (stop) or intentionally leave errors
in the config (continue). =A0The only robust solution is all-or-nothing
(except for 'rollback-failed' errors).

We support a CLI parameter: --startup-error=3Dstop|continue.
This is another area of contention -- errors loading the running
config from NV-storage. Some devices just prune the error instances
and continue. =A0Some shutdown and don't attempt to prune errors.


Andy

On Mon, Jun 3, 2013 at 5:36 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello,
I know I should know this, but ...

Why are the error-option values stop-on-error and continue-on-error mandatory? Many of our systems operate on a strict transactional basis, you either commit the full edit-config or nothing. Both stop and continue imply that you should be able to store a partial transaction. Why mess up the configuration if you can do a rollback?
regards Balazs

--
Balazs Lengyel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Ericsson Hungary Ltd.
System Manager
ECN: 831 7320 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Tel: +36-1-437-7320
Mobile: +36-70-330-7909 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: <= a href=3D"mailto:Balazs.Lengyel@ericsson.com" target=3D"_blank">Balazs.Leng= yel@ericsson.com

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


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20

--047d7bacbde696eb4104decf1734-- From internet-drafts@ietf.org Wed Jun 19 01:00:54 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF63C21F9B85; Wed, 19 Jun 2013 01:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT4nqvHLryU4; Wed, 19 Jun 2013 01:00:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EF421F991E; Wed, 19 Jun 2013 01:00:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 01:00:54 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:00:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : Reverse Secure Shell (Reverse SSH) Author(s) : Kent Watsen Filename : draft-ietf-netconf-reverse-ssh-00.txt Pages : 16 Date : 2013-06-18 Abstract: This memo 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 XXX 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfdbh@comcast.net Wed Jun 19 07:02:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2021F9C1E for ; Wed, 19 Jun 2013 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhtWdHWX9Lpq for ; Wed, 19 Jun 2013 07:02:36 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9A59421F9C38 for ; Wed, 19 Jun 2013 07:02:31 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id qD0B1l0031wpRvQ53E2W3E; Wed, 19 Jun 2013 14:02:30 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id qE2V1l00k2yZEBF3eE2VbQ; Wed, 19 Jun 2013 14:02:30 +0000 From: "ietfdbh" To: References: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> In-Reply-To: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 10:02:21 -0400 Message-ID: <011901ce6cf5$9e7b4870$db71d950$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQD45+X2mFEm72nCCFv7fOwTSthORJroFhWA Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371650550; bh=1QxcA/9jIPro1Fe6asxtqMphWV/Txw4/3ZqLiw0prCc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=qXINqsxGusSXbo/DAbpQX0+ScjFoSBre9Raq1HKNyPwQH5GcYLCSAfgvz5DPf4kK+ +WHXVmoow0Rfz2l6jqYakev7ra88dL0O2X4jv4sMfZZj6jQhoUhS3+t9Cqb6Z83zup m1uAVUW4lgcC9r85YAx3rvDKsNCl0qFmdlxIZ82Y9GjkKNIoko4I30PL29xQfbJcVU eZPsYzM0qFhlT7jpr1SoBQYdg9VqZmUYSWK2TWgrcIBoDceTcsTDY+I/fn2uN+elnd 8B3uoiMQ98OEN0vmffXymdS66SGGN/cqzpQ0Xwka8wcUlVpJeibyv5Py6/QS2XZoTX BfZ3herpYmYJQ== Cc: netconf@ietf.org, saag@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:02:42 -0000 Hi Kent, I think your draft needs to target two different audiences - the security audience for SSH security considerations, and application designers that want to use reverse-SSH, such as Netconf. Few people are experts both in hmac and SSH, and in Netconf and YANG. I think this would be better written as two separate drafts, with different audiences in mind, even if each draft would be short. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, June 19, 2013 4:01 AM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: I-D Action: draft-ietf-netconf-reverse-ssh-00.txt 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 Secure Shell (Reverse SSH) Author(s) : Kent Watsen Filename : draft-ietf-netconf-reverse-ssh-00.txt Pages : 16 Date : 2013-06-18 Abstract: This memo 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 XXX 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-00 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 From bertietf@bwijnen.net Wed Jun 19 07:41:00 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C1421F8F29 for ; Wed, 19 Jun 2013 07:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw-BXsgGvEJA for ; Wed, 19 Jun 2013 07:40:55 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id F294021F8CDD for ; Wed, 19 Jun 2013 07:40:54 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UpJZ3-0004zz-PU; Wed, 19 Jun 2013 16:40:51 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1UpJZ3-0004nw-M9; Wed, 19 Jun 2013 16:40:49 +0200 Message-ID: <51C1C2F1.2080904@bwijnen.net> Date: Wed, 19 Jun 2013 16:40:49 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ietfdbh , Netconf References: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> <011901ce6cf5$9e7b4870$db71d950$@comcast.net> In-Reply-To: <011901ce6cf5$9e7b4870$db71d950$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130619 clean 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: 86ab03e524994f79ca2c75a176445dd46b67c84ea4bd4fe8b34b96b4399fa8a1 Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:41:00 -0000 Can anybody reach dbh via above email? All my emails to him keep bouncing. Yet, he is posting from that addess. Bert On 6/19/13 4:02 PM, ietfdbh wrote: > Hi Kent, > > I think your draft needs to target two different audiences - the security > audience for SSH security considerations, and application designers that > want to use reverse-SSH, such as Netconf. > > Few people are experts both in hmac and SSH, and in Netconf and YANG. > I think this would be better written as two separate drafts, with different > audiences in mind, even if each draft would be short. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, June 19, 2013 4:01 AM > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: I-D Action: draft-ietf-netconf-reverse-ssh-00.txt > > > 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 Secure Shell (Reverse SSH) > Author(s) : Kent Watsen > Filename : draft-ietf-netconf-reverse-ssh-00.txt > Pages : 16 > Date : 2013-06-18 > > Abstract: > This memo 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 XXX 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-00 > > > 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 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From lhotka@nic.cz Wed Jun 19 09:04:05 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491F021F9DE3 for ; Wed, 19 Jun 2013 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x0i4R1XGX7a for ; Wed, 19 Jun 2013 09:04:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 11D9321F9D96 for ; Wed, 19 Jun 2013 09:03:21 -0700 (PDT) Received: from [10.0.0.43] (pha-2-239.adsl.sky.cz [193.165.2.239]) by mail.nic.cz (Postfix) with ESMTPSA id 0A62B13FA81; Wed, 19 Jun 2013 18:03:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371657800; bh=k0ciYgscPwJoT5pzhIW73NRwdyveqXoZwZoNZmL0aaA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jNaBSBT+7HGkLHb1nRdVtAVEWtQUnVf4oXNssEu0Lwk7yqwF3JEZ3dw6s91eYy/Mh qDODbmxbXA+SN2Emx8UgrRVwvXZrdO+9Z+oB9vlksjQ7q+ze8zakbULCtC9dkKNLpf v5AyWd1rD05qz9PtGJdJvH062jny7wZr29+BMncM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <51C1C2F1.2080904@bwijnen.net> Date: Wed, 19 Jun 2013 18:03:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16CB078C-45C6-43D9-A51D-217C042FB82C@nic.cz> References: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> <011901ce6cf5$9e7b4870$db71d950$@comcast.net> <51C1C2F1.2080904@bwijnen.net> To: "Bert Wijnen (IETF)" X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: ietfdbh , Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:04:05 -0000 Hi Bert, the address works, as far as I can tell: Jun 19 18:00:21 trail postfix/smtp[528]: 61EEB5402F3: = to=3D, relay=3Dmx2.comcast.net[76.96.40.147]:25, = delay=3D2.5, delays=3D0.07/0.02/1.4/0.99, dsn=3D2.0.0, status=3Dsent = (250 2.0.0 qG0K1l02J07cNv90BG0LsS mail accepted for delivery) Lada On Jun 19, 2013, at 4:40 PM, "Bert Wijnen (IETF)" = wrote: > Can anybody reach dbh via above email? >=20 > All my emails to him keep bouncing. > Yet, he is posting from that addess. >=20 > Bert >=20 > On 6/19/13 4:02 PM, ietfdbh wrote: >> Hi Kent, >>=20 >> I think your draft needs to target two different audiences - the = security >> audience for SSH security considerations, and application designers = that >> want to use reverse-SSH, such as Netconf. >>=20 >> Few people are experts both in hmac and SSH, and in Netconf and YANG. >> I think this would be better written as two separate drafts, with = different >> audiences in mind, even if each draft would be short. >>=20 >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of internet-drafts@ietf.org >> Sent: Wednesday, June 19, 2013 4:01 AM >> To: i-d-announce@ietf.org >> Cc: netconf@ietf.org >> Subject: I-D Action: draft-ietf-netconf-reverse-ssh-00.txt >>=20 >>=20 >> 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. >>=20 >> Title : Reverse Secure Shell (Reverse SSH) >> Author(s) : Kent Watsen >> Filename : draft-ietf-netconf-reverse-ssh-00.txt >> Pages : 16 >> Date : 2013-06-18 >>=20 >> Abstract: >> This memo 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 XXX 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". >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfdbh@comcast.net Wed Jun 19 12:20:14 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B592F21F9FDE for ; Wed, 19 Jun 2013 12:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET5lw3YkcvXj for ; Wed, 19 Jun 2013 12:20:14 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id A248821E8055 for ; Wed, 19 Jun 2013 12:20:07 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id qBiN1l0040SCNGk54KL6FM; Wed, 19 Jun 2013 19:20:06 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta09.westchester.pa.mail.comcast.net with comcast id qKL61l00m2yZEBF3VKL6W6; Wed, 19 Jun 2013 19:20:06 +0000 From: "ietfdbh" To: "'Jeffrey Hutzelman'" References: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> Date: Wed, 19 Jun 2013 21:19:58 +0200 Message-ID: <0b9e01ce6d21$fcf24fd0$f6d6ef70$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQD45+X2mFEm72nCCFv7fOwTSthORAIaCC9GAlIuTwGaxQmGoA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371669606; bh=e4fxTAcLLxDNUL8Z1UbEZF4onbSa0vfh4RA2Eue8frs=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ggvj6Kx4CsNrW5W2TCMz4i+/CKyhcm+Mm5UpocvDAavbwowtNemTOmiLc3Cql9a9Q qcae3zu6su0N10n2kvb3dAWuUi8aq+JLLxddMdtCbIXz0BxxOpFgFSyGOItCQf8Fms WjjauqL6UX0DK3MRaMKiKoqJlOq8GB6mSibG1LeOc5/7r2I2rqai7vPyOsIgeLvfsm RadPx05DkXxe3rfTPr9m8SaUdzhfxMa/waVHynGGfWJ0FtZBbH/dmcLUxy7MNFxQ6H kB9oDlkp08lksqMM+aX9DKV6w8EJKUyzN0azyaBWufweaA6kK+a9pfH5l+UdTqmD6Y JOacfuQ82sL9A== Cc: draft-ietf-netconf-reverse-ssh@tools.ietf.org, netconf@ietf.org, saag@ietf.org Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 19:20:15 -0000 For anyone who wishes to access/subscribe to the secsh mailing list, See http://www.ietf.org/wg/concluded/secsh.html Jeff, I assume that is the list you refer to?? David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Wednesday, June 19, 2013 7:22 PM To: ietfdbh Cc: jhutz@cmu.edu; draft-ietf-netconf-reverse-ssh@tools.ietf.org; = netconf@ietf.org; saag@ietf.org Subject: Re: [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt On Wed, 2013-06-19 at 10:02 -0400, ietfdbh wrote: > Hi Kent, >=20 > I think your draft needs to target two different audiences - the=20 > security audience for SSH security considerations, and application=20 > designers that want to use reverse-SSH, such as Netconf. This was discussed two years ago on the ietf-ssh mailing list, which is = the appropriate forum for discussion of SSH extensions and protocol = changes. There was much discussion about what port number things should = run on, but unfortunately relatively little discussion of the security = aspects of running SSH "in reverse" like this. I haven't read this recent document, but when this came up in 2011, I = was concerned about the security aspects of running SSH "in reverse" like this; it's really not designed for that. I expressed concerns = about the new hmac-* host key algorithms defined in that version, about = the layering violations inherent in using them for negotiation, and = commented that they don't really provide any operational advantage over = using X.509 certificates or pre-shared RSA keys. Those comments were = never really addressed. The SECSH WG concluded some time ago, but its mailing list is still = somewhat active and regularly discusses SSH protocol extensions. I = would be very concerned if the NETCONF WG were to send the IESG an SSH = protocol document without the involvement of that group. I will note = that the 2011 discussion included approaches that did not require this = level of protocol change, or indeed any. I'm fine with NETCONF not = having chosen one of those approaches, but this really does need to = involve people with SSH expertise. -- Jeff From kwatsen@juniper.net Wed Jun 19 13:17:33 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321B121E8051; Wed, 19 Jun 2013 13:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQhj29EqSw4C; Wed, 19 Jun 2013 13:17:27 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3BB21E8050; Wed, 19 Jun 2013 13:17:27 -0700 (PDT) Received: from mail111-tx2-R.bigfish.com (10.9.14.233) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 20:17:26 +0000 Received: from mail111-tx2 (localhost [127.0.0.1]) by mail111-tx2-R.bigfish.com (Postfix) with ESMTP id 4B083180071; Wed, 19 Jun 2013 20:17:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I936eI542I1432I4015I853kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail111-tx2: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=kwatsen@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail111-tx2 (localhost.localdomain [127.0.0.1]) by mail111-tx2 (MessageSwitch) id 1371673044913228_21433; Wed, 19 Jun 2013 20:17:24 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.250]) by mail111-tx2.bigfish.com (Postfix) with ESMTP id D10F58005F; Wed, 19 Jun 2013 20:17:24 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 20:17:22 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Jun 2013 13:17:09 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Jun 2013 13:17:09 -0700 Received: from DB8EHSOBE022.bigfish.com (213.199.154.189) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Jun 2013 13:29:08 -0700 Received: from mail209-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE022.bigfish.com (10.174.4.85) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 20:17:07 +0000 Received: from mail209-db8 (localhost [127.0.0.1]) by mail209-db8-R.bigfish.com (Postfix) with ESMTP id 85718200BC; Wed, 19 Jun 2013 20:17:07 +0000 (UTC) Received: from mail209-db8 (localhost.localdomain [127.0.0.1]) by mail209-db8 (MessageSwitch) id 1371673025401361_2287; Wed, 19 Jun 2013 20:17:05 +0000 (UTC) Received: from DB8EHSMHS025.bigfish.com (unknown [10.174.8.243]) by mail209-db8.bigfish.com (Postfix) with ESMTP id 59D5A480045; Wed, 19 Jun 2013 20:17:05 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by DB8EHSMHS025.bigfish.com (10.174.4.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 19 Jun 2013 20:16:58 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0324.000; Wed, 19 Jun 2013 20:16:54 +0000 From: Kent Watsen To: ietfdbh , "draft-ietf-netconf-reverse-ssh@tools.ietf.org" Thread-Topic: I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHObPW+Vn5jk8r2NUOmxzx4RR9st5k9NuUA Date: Wed, 19 Jun 2013 20:16:54 +0000 Message-ID: In-Reply-To: <011901ce6cf5$9e7b4870$db71d950$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <9FE78B020E582240AFF0A4CFF660D5C7@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%COMCAST.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "netconf@ietf.org" , "saag@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 20:17:33 -0000 Hi David, Thanks for your comments. My suggestion for partitioning this draft is to extract the hmac-* family of public host key algorithms into its own draft. There is precedent for defining new public key algorithms in a distinct draft given by RFC 6187. However, this strategy would retain the YANG module definition in the current draft and thus doesn't address your stated concern. That said, please consider: 1. It is generally hoped that the design of any device feature (e.g. a routing protocol) includes a YANG module for how it can be managed. Keeping the YANG module definition in this draft is consistent with that goal. 2. The configuration model has no impact on the protocol and hence can be ignored by those who are only interested in the protocol/security aspects. The draft almost says this itself in the first paragraph of section 6 (Device Configuration). Another option would to extract the YANG module definition into its own draft. As you say, it would be very small, but at least it would be focused. And, of course, we could do both options - resulting in a total of three distinct drafts. Which of these options you think is best? Thanks, Kent On 6/19/13 10:02 AM, "ietfdbh" wrote: >Hi Kent, > >I think your draft needs to target two different audiences - the security >audience for SSH security considerations, and application designers that >want to use reverse-SSH, such as Netconf. > >Few people are experts both in hmac and SSH, and in Netconf and YANG. >I think this would be better written as two separate drafts, with >different >audiences in mind, even if each draft would be short. > >David Harrington >ietfdbh@comcast.net >+1-603-828-1401 >-----Original Message----- >From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >On Behalf Of internet-drafts@ietf.org >Sent: Wednesday, June 19, 2013 4:01 AM >To: i-d-announce@ietf.org >Cc: netconf@ietf.org >Subject: I-D Action: draft-ietf-netconf-reverse-ssh-00.txt > > >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 Secure Shell (Reverse SSH) > Author(s) : Kent Watsen > Filename : draft-ietf-netconf-reverse-ssh-00.txt > Pages : 16 > Date : 2013-06-18 > >Abstract: > This memo 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 XXX 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-00 > > >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 > > > From kwatsen@juniper.net Wed Jun 19 15:03:39 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179BF21F9D4D; Wed, 19 Jun 2013 15:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkAp7Un5GwrA; Wed, 19 Jun 2013 15:03:33 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2921F9D70; Wed, 19 Jun 2013 15:03:33 -0700 (PDT) Received: from mail78-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 22:03:32 +0000 Received: from mail78-co9 (localhost [127.0.0.1]) by mail78-co9-R.bigfish.com (Postfix) with ESMTP id AFAB7A01E2; Wed, 19 Jun 2013 22:03:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I936eI1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail78-co9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=kwatsen@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail78-co9 (localhost.localdomain [127.0.0.1]) by mail78-co9 (MessageSwitch) id 1371679410187461_5539; Wed, 19 Jun 2013 22:03:30 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.230]) by mail78-co9.bigfish.com (Postfix) with ESMTP id 2B9802E0062; Wed, 19 Jun 2013 22:03:30 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.52) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 22:03:27 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Jun 2013 15:03:26 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Jun 2013 15:03:25 -0700 Received: from CO9EHSOBE038.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Jun 2013 15:15:24 -0700 Received: from mail121-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 22:03:25 +0000 Received: from mail121-co9 (localhost [127.0.0.1]) by mail121-co9-R.bigfish.com (Postfix) with ESMTP id 30E66940342; Wed, 19 Jun 2013 22:03:25 +0000 (UTC) Received: from mail121-co9 (localhost.localdomain [127.0.0.1]) by mail121-co9 (MessageSwitch) id 1371679403250852_30544; Wed, 19 Jun 2013 22:03:23 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.239]) by mail121-co9.bigfish.com (Postfix) with ESMTP id 31204BC004C; Wed, 19 Jun 2013 22:03:23 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 22:03:21 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0324.000; Wed, 19 Jun 2013 22:03:21 +0000 From: Kent Watsen To: Jeffrey Hutzelman , ietfdbh Thread-Topic: [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHObRGgGnqI147cKUqC8qWv6JY1X5k9VGoA Date: Wed, 19 Jun 2013 22:03:20 +0000 Message-ID: In-Reply-To: <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%COMCAST.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , "netconf@ietf.org" , "saag@ietf.org" Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 22:03:39 -0000 Hi Jeff, You've touched on a lot of points. First, yes, this was discussed a couple years ago. I wanted this submission to indicate it was a continuation of the previous I-D draft-kwatsen-reverse-ssh-01. That it doesn't is only because I didn't see an option to indicate that during submission - I'll check again... The discussion from two years ago died because no common ground could be reached. It has resurfaced now because operators have requested the NETCONF WG to define strategies for devices to "call home" using both NETCONF's transports, SSH and TLS. The NETCONF WG has now chartered this work and I volunteered to pick it up again. >From a protocol perspective, the solution presented in this draft is the same as presented in draft-kwatsen-reverse-ssh-01 with one exception, it now requests an IANA-assigned port, instead of using port 22, to be consistent with draft-ietf-netconf-rfc5539bis-03, which makes the same request. Regarding the security aspects of running SSH "in reverse", this draft's Security Considerations section has been greatly expanded to address this concern and I very much hope that the SAAG will take it up now. I also hope SAAG will consider the security aspects of running TLS "in reverse", as one of my comments on rfc5539bis-03 [1] was that doing so would enable the "client" to defer sending its client-certificate until after receiving the server's cert, consistent with draft-agl-tls-encryptedclientcerts and draft-badra-tls-identity-protection. Though both of these drafts are now defunct, it seems that there's sufficient interest in protecting the client's identity, which a TLS-based "call home" could only leverage someday if it ran TLS "in reverse" as well. Finally, regarding the HMAC-* family of public host key algorithms, I think herein lies a good reason to extract them into a draft of their own, as it would be a shame for them to distract from the primary discussion of running SSH (and TLS) in reverse. [1] http://www.ietf.org/mail-archive/web/netconf/current/msg08075.html Thanks, Kent On 6/19/13 1:21 PM, "Jeffrey Hutzelman" wrote: >On Wed, 2013-06-19 at 10:02 -0400, ietfdbh wrote: >> Hi Kent, >>=20 >> I think your draft needs to target two different audiences - the >>security >> audience for SSH security considerations, and application designers that >> want to use reverse-SSH, such as Netconf. > >This was discussed two years ago on the ietf-ssh mailing list, which is >the appropriate forum for discussion of SSH extensions and protocol >changes. There was much discussion about what port number things should >run on, but unfortunately relatively little discussion of the security >aspects of running SSH "in reverse" like this. > >I haven't read this recent document, but when this came up in 2011, I >was concerned about the security aspects of running SSH "in reverse" >like this; it's really not designed for that. I expressed concerns >about the new hmac-* host key algorithms defined in that version, about >the layering violations inherent in using them for negotiation, and >commented that they don't really provide any operational advantage over >using X.509 certificates or pre-shared RSA keys. Those comments were >never really addressed. > > >The SECSH WG concluded some time ago, but its mailing list is still >somewhat active and regularly discusses SSH protocol extensions. I >would be very concerned if the NETCONF WG were to send the IESG an SSH >protocol document without the involvement of that group. I will note >that the 2011 discussion included approaches that did not require this >level of protocol change, or indeed any. I'm fine with NETCONF not >having chosen one of those approaches, but this really does need to >involve people with SSH expertise. > >-- Jeff > > > From kwatsen@juniper.net Wed Jun 19 16:04:07 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722D21F9F26 for ; Wed, 19 Jun 2013 16:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHs+Rx1rKDjy for ; Wed, 19 Jun 2013 16:04:00 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7E33021F9F16 for ; Wed, 19 Jun 2013 16:04:00 -0700 (PDT) Received: from mail94-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 23:04:00 +0000 Received: from mail94-co9 (localhost [127.0.0.1]) by mail94-co9-R.bigfish.com (Postfix) with ESMTP id CC8CDB80419 for ; Wed, 19 Jun 2013 23:03:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371Id772h4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail94-co9: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=kwatsen@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail94-co9 (localhost.localdomain [127.0.0.1]) by mail94-co9 (MessageSwitch) id 1371683037205979_12287; Wed, 19 Jun 2013 23:03:57 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.242]) by mail94-co9.bigfish.com (Postfix) with ESMTP id 2F65E300062 for ; Wed, 19 Jun 2013 23:03:57 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.51) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 23:03:57 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Jun 2013 16:03:55 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Jun 2013 16:03:55 -0700 Received: from DB8EHSOBE033.bigfish.com (213.199.154.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Jun 2013 16:07:25 -0700 Received: from mail114-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE033.bigfish.com (10.174.4.96) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 23:03:53 +0000 Received: from mail114-db8 (localhost [127.0.0.1]) by mail114-db8-R.bigfish.com (Postfix) with ESMTP id 5DFFB1000AE for ; Wed, 19 Jun 2013 23:03:53 +0000 (UTC) Received: from mail114-db8 (localhost.localdomain [127.0.0.1]) by mail114-db8 (MessageSwitch) id 137168303167720_18124; Wed, 19 Jun 2013 23:03:51 +0000 (UTC) Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.236]) by mail114-db8.bigfish.com (Postfix) with ESMTP id F0213420047; Wed, 19 Jun 2013 23:03:50 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 19 Jun 2013 23:03:50 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0324.000; Wed, 19 Jun 2013 23:03:50 +0000 From: Kent Watsen To: Mouse , "jhutz@cmu.edu" Thread-Topic: [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHObRGgGnqI147cKUqC8qWv6JY1X5k9eeyA///rZQA= Date: Wed, 19 Jun 2013 23:03:49 +0000 Message-ID: In-Reply-To: <201306192017.QAA29603@Chip.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <955BD919DF1754429D0F59480B3F6138@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%RODENTS-MONTREAL.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 23:04:07 -0000 On 6/19/13 4:17 PM, "Mouse" wrote: >My own reaction is that I think it does less violence to ssh's security >properties for the netconf client to be the ssh server, with the >"netconf" subsystem being special in that its protocol recognizes that >the netconf roles are reversed from the ssh roles: the ssh server is >the netconf client and vice versa. The issue is that we very much want the managed-device to be the SSH server. Consider the following: Regarding Transport protocol (RFC 4253): Devices can ship from their vendors with a TPM chip that embeds a private key and a certificate chain of trust to a vendor-specific CA. This can be used as a trust-root for SSH, but only if it's the SSH server. Regarding Authentication protocol (RFC 4252): Devices already support inbound SSH and have mechanisms to auth users (password, public key, PAM) and associate RBAC permissions. Maintaining the client/server roles independent of the transport connection's directionality preserves all this. Regarding Connection protocol (RFC 4254): Only clients are allowed to open a "session" on the server (section-6.1), and running the "netconf" subsystem requires a "session". =20 Thanks, Kent From kwatsen@juniper.net Wed Jun 19 17:38:09 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6A21F9E3F; Wed, 19 Jun 2013 17:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os74HYI7dVMH; Wed, 19 Jun 2013 17:38:02 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8925D21F9E37; Wed, 19 Jun 2013 17:38:02 -0700 (PDT) Received: from mail94-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 00:38:02 +0000 Received: from mail94-co9 (localhost [127.0.0.1]) by mail94-co9-R.bigfish.com (Postfix) with ESMTP id 0A35CB8024F; Thu, 20 Jun 2013 00:38:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275bhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail94-co9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=kwatsen@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail94-co9 (localhost.localdomain [127.0.0.1]) by mail94-co9 (MessageSwitch) id 1371688679549562_20774; Thu, 20 Jun 2013 00:37:59 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.238]) by mail94-co9.bigfish.com (Postfix) with ESMTP id 7A5F5300060; Thu, 20 Jun 2013 00:37:59 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Jun 2013 00:37:59 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Jun 2013 17:37:58 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Jun 2013 17:37:58 -0700 Received: from CO9EHSOBE018.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Jun 2013 17:41:28 -0700 Received: from mail125-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 00:37:57 +0000 Received: from mail125-co9 (localhost [127.0.0.1]) by mail125-co9-R.bigfish.com (Postfix) with ESMTP id 4879C2E06DF; Thu, 20 Jun 2013 00:37:57 +0000 (UTC) Received: from mail125-co9 (localhost.localdomain [127.0.0.1]) by mail125-co9 (MessageSwitch) id 1371688675126316_16297; Thu, 20 Jun 2013 00:37:55 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.245]) by mail125-co9.bigfish.com (Postfix) with ESMTP id 19F52400060; Thu, 20 Jun 2013 00:37:55 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Jun 2013 00:37:54 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0324.000; Thu, 20 Jun 2013 00:37:54 +0000 From: Kent Watsen To: Joe Touch Thread-Topic: [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHObRGgGnqI147cKUqC8qWv6JY1X5k9VGoAgABF3gD//+VQgA== Date: Thu, 20 Jun 2013 00:37:53 +0000 Message-ID: In-Reply-To: <51C22D02.9030802@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ISI.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%COMCAST.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "saag@ietf.org" , "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , ietfdbh , "netconf@ietf.org" , Jeffrey Hutzelman Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 00:38:09 -0000 On 6/19/13 6:13 PM, "Joe Touch" wrote: >I was party to the discussion of this issue during the original draft >(see archives of 5/24/2011), and thought there was appreciation that >there was no reason to need a new port for this service. This is why the -01 draft from before was using port 22, but the problem is that there will be a conflict if the application may want to run real SSH on port 22. >Regarding the netconf draft, that might warrant a single port, but again >not two ports for the different directions. The same principle applies here. Yes, we could repurpose the NETCONF port (830), but then there will be a port conflict if the application server itself wants to be managed via NETCONF on port 830. Besides, this draft is truly about reversing SSH, any SSH subsystem could be run on top of it... >As I noted on this list in 2011, directionality should be negotiated >in-band, not by port number. This seem fine (assuming it's done in the SSH Transport protocol, such the device is the SSH server and the application is the SSH client), except for one thing, it's not implementable *today*. Optimistically, it might take a couple years for implementations to support it, if ever. Case in point, did you know that after more than two years, there is still not a single implementation for RFC 6187 (x.509v3 certs for SSH)? In contrast, I have running code for the solution presented in the current draft that I hope to post to code.google.com as a reference implementation. Mind you that this implementation doesn't make use of all the the host-key algs we'd like, but it works with at least two SSH-implementations (Petrov's patch to OpenSSH and a Java library called J2SSH Maverick). A little off topic, but the -00 draft I submitted before, in 2011, worked with *every* SSH implementation I tried, without any patches necessary. But I chose to model this draft after the -01 proposal because I believe it's better to leverage the algorithm negotiation built into SSH and I have running code for the common case of the device running openssh and the management app written in Java. Thanks, Kent From touch@isi.edu Wed Jun 19 18:04:00 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E221F9F15; Wed, 19 Jun 2013 18:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.982 X-Spam-Level: X-Spam-Status: No, score=-104.982 tagged_above=-999 required=5 tests=[AWL=1.617, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5up7sSCkvER; Wed, 19 Jun 2013 18:03:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD5B21F9EBD; Wed, 19 Jun 2013 18:03:43 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5K12l34014404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 18:02:51 -0700 (PDT) Message-ID: <51C254A2.2020409@isi.edu> Date: Wed, 19 Jun 2013 18:02:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "saag@ietf.org" , "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , ietfdbh , "netconf@ietf.org" , Jeffrey Hutzelman Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 01:04:00 -0000 On 6/19/2013 5:37 PM, Kent Watsen wrote: > > > On 6/19/13 6:13 PM, "Joe Touch" wrote: >> I was party to the discussion of this issue during the original draft >> (see archives of 5/24/2011), and thought there was appreciation that >> there was no reason to need a new port for this service. > > This is why the -01 draft from before was using port 22, but > the problem is that there will be a conflict if the application > may want to run real SSH on port 22. Why is this a conflict in that way? It's just a matter of who initiates the connection, and who initiates the security exchange after that. I.e., why wouldn't this be most naturally implemented as "real SSH on port 22"? >> Regarding the netconf draft, that might warrant a single port, but again >> not two ports for the different directions. > > The same principle applies here. Yes, we could repurpose the > NETCONF port (830), but then there will be a port conflict if > the application server itself wants to be managed via NETCONF > on port 830. The same answer above applies. > Besides, this draft is truly about reversing SSH, > any SSH subsystem could be run on top of it... > >> As I noted on this list in 2011, directionality should be negotiated >> in-band, not by port number. > > This seem fine (assuming it's done in the SSH Transport protocol, > such the device is the SSH server and the application is the SSH > client), except for one thing, it's not implementable *today*. I understand why it has not yet been *implemented*, but disagree that it is not *implementable*. > Optimistically, it might take a couple years for implementations > to support it, if ever. Case in point, did you know that after > more than two years, there is still not a single implementation > for RFC 6187 (x.509v3 certs for SSH)? > > In contrast, I have running code for the solution presented in > the current draft that I hope to post to code.google.com as a > reference implementation. Mind you that this implementation > doesn't make use of all the the host-key algs we'd like, but > it works with at least two SSH-implementations (Petrov's patch > to OpenSSH and a Java library called J2SSH Maverick). I sincerely hope you are posting code that uses some arbitrary dynamic port, rather than squatting on an assigned port. However, it would be useful to explain further the issue here. So far, all I can tell is that it would be easier to pull up a demo implementation using a separate port, but there doesn't seem to be enough justification as to why this is a separate *service* than forward SSH. Joe From kwatsen@juniper.net Wed Jun 19 18:23:46 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD421F9F15; Wed, 19 Jun 2013 18:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc67-zgE0ibz; Wed, 19 Jun 2013 18:23:41 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id B921221F9F13; Wed, 19 Jun 2013 18:23:38 -0700 (PDT) Received: from mail46-db9-R.bigfish.com (10.174.16.241) by DB9EHSOBE003.bigfish.com (10.174.14.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 01:23:37 +0000 Received: from mail46-db9 (localhost [127.0.0.1]) by mail46-db9-R.bigfish.com (Postfix) with ESMTP id 2AA82BE0323; Thu, 20 Jun 2013 01:23:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I15bfK111aIzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail46-db9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=kwatsen@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail46-db9 (localhost.localdomain [127.0.0.1]) by mail46-db9 (MessageSwitch) id 1371691415766849_639; Thu, 20 Jun 2013 01:23:35 +0000 (UTC) Received: from DB9EHSMHS031.bigfish.com (unknown [10.174.16.240]) by mail46-db9.bigfish.com (Postfix) with ESMTP id B73F0680049; Thu, 20 Jun 2013 01:23:35 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by DB9EHSMHS031.bigfish.com (10.174.14.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 20 Jun 2013 01:23:29 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Jun 2013 18:23:28 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Jun 2013 18:23:27 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.253) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Jun 2013 18:26:57 -0700 Received: from mail151-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE011.bigfish.com (10.174.14.74) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 01:23:25 +0000 Received: from mail151-db9 (localhost [127.0.0.1]) by mail151-db9-R.bigfish.com (Postfix) with ESMTP id EF2533E0092; Thu, 20 Jun 2013 01:23:24 +0000 (UTC) Received: from mail151-db9 (localhost.localdomain [127.0.0.1]) by mail151-db9 (MessageSwitch) id 1371691402813796_28321; Thu, 20 Jun 2013 01:23:22 +0000 (UTC) Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.228]) by mail151-db9.bigfish.com (Postfix) with ESMTP id B874B4000DC; Thu, 20 Jun 2013 01:23:22 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 20 Jun 2013 01:23:21 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0324.000; Thu, 20 Jun 2013 01:23:21 +0000 From: Kent Watsen To: Jeffrey Hutzelman Thread-Topic: [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHObRGgGnqI147cKUqC8qWv6JY1X5k9VGoAgABIzoD//+8TAA== Date: Thu, 20 Jun 2013 01:23:20 +0000 Message-ID: In-Reply-To: <1371680633.23088.71.camel@destiny.pc.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F5E6F46F3340E478AA2BB6BA600A4E6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%COMCAST.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , ietfdbh , "netconf@ietf.org" , "saag@ietf.org" Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 01:23:47 -0000 On 6/19/13 6:23 PM, "Jeffrey Hutzelman" wrote: >However, unless I'm >misunderstanding the intent here, using a fixed port at all seems >limiting to me. What if I'm running two different applications on my >machine, and expect different devices to connect to them, or even the >same device to both? What if there are other people sharing my machine? >Shouldn't be port be either one dynamically assigned to the application >by the OS, or configured by an administrator? Indeed, it is not uncommon for deployments to use non-standard ports. For this reason, the YANG module presented in the Device Configuration section defines the field as optional, stating that the IANA- assigned port is assumed if it's not filled in. >OK; I'll try to find some time to re-review it, then. In the meantime, >it would probably be good to bring this document up on the ietf-ssh list >again. Very much looking forward to your review of the Security Considerations. If at all possible, please also try to expand your review to the possibility of reversing the TLS protocol in the same fashion (i.e. The TCP client becomes the TLS server, and visa versa). As for the ietf-ssh list, I know you're right, but we have a problem, the mail archives have half of today's messages under the NETCONF list and half under the SAAG list: http://www.ietf.org/mail-archive/web/netconf/current/maillist.html http://www.ietf.org/mail-archive/web/saag/current/maillist.html Worse, at least one message shows up under both archives and clicking the "Follow-Ups" links drops some of the responses because they're in the other group's archive. This will make it very hard for someone to piece together the exchange that has occurred so far. Suggestions? Thanks again, Kent From internet-drafts@ietf.org Fri Jun 21 06:33:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7929621E811D; Fri, 21 Jun 2013 06:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LcgT5i0o60B; Fri, 21 Jun 2013 06:33:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE13C21E8087; Fri, 21 Jun 2013 06:33:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130621133340.26792.55620.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 06:33:40 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:33:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : Reverse Secure Shell (Reverse SSH) Author(s) : Kent Watsen Filename : draft-ietf-netconf-reverse-ssh-01.txt Pages : 13 Date : 2013-06-20 Abstract: This memo 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-reverse-ssh-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kwatsen@juniper.net Fri Jun 21 10:26:41 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8D721F9AF8 for ; Fri, 21 Jun 2013 10:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APF-ma+iJQJw for ; Fri, 21 Jun 2013 10:26:35 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id B010E21F9A95 for ; Fri, 21 Jun 2013 10:26:35 -0700 (PDT) Received: from mail101-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE024.bigfish.com (10.243.66.87) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 17:26:35 +0000 Received: from mail101-co1 (localhost [127.0.0.1]) by mail101-co1-R.bigfish.com (Postfix) with ESMTP id EEBB53C02E1 for ; Fri, 21 Jun 2013 17:26:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc85eh4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah18c673h8275bhz2fh2a8h683h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail101-co1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=kwatsen@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail101-co1 (localhost.localdomain [127.0.0.1]) by mail101-co1 (MessageSwitch) id 137183559359097_17646; Fri, 21 Jun 2013 17:26:33 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.230]) by mail101-co1.bigfish.com (Postfix) with ESMTP id 0C2C2580055 for ; Fri, 21 Jun 2013 17:26:33 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 17:26:31 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 10:26:30 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 10:26:30 -0700 Received: from DB8EHSOBE003.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 10:38:27 -0700 Received: from mail145-db8-R.bigfish.com (10.174.8.227) by DB8EHSOBE003.bigfish.com (10.174.4.66) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 17:26:28 +0000 Received: from mail145-db8 (localhost [127.0.0.1]) by mail145-db8-R.bigfish.com (Postfix) with ESMTP id 5EACD1E021C for ; Fri, 21 Jun 2013 17:26:28 +0000 (UTC) Received: from mail145-db8 (localhost.localdomain [127.0.0.1]) by mail145-db8 (MessageSwitch) id 1371835586299267_12382; Fri, 21 Jun 2013 17:26:26 +0000 (UTC) Received: from DB8EHSMHS012.bigfish.com (unknown [10.174.8.243]) by mail145-db8.bigfish.com (Postfix) with ESMTP id CD9608004A for ; Fri, 21 Jun 2013 17:26:25 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by DB8EHSMHS012.bigfish.com (10.174.4.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Jun 2013 17:26:22 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 17:26:17 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: reverse ssh recommendation Thread-Index: AQHObqRv5meQ36z/ZkiSrX2w9SROIA== Date: Fri, 21 Jun 2013 17:26:16 +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.2.130206 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CDEA04F6395C1kwatsenjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:26:41 -0000 --_000_CDEA04F6395C1kwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, The discussion so far regarding the Reverse SSH draft is almost a perfect r= epeat of the one that occurred two years ago, with some wanting direction-n= egotiation in the SSH protocol itself (not via a port), even though it woul= d mean no implementation available for years... However, there is a significant difference now, which is that this draft is= in the hands of the NETCONF WG as a chartered WG item. Before, when my dr= aft was effectively posted to the SSH WG (the ieft-ssh list), it was unders= tandable why they would look for solutions that changed the SSH protocol it= self, as that is *their* charter=85 However, in order to realize implementations in the near-term, this draft d= oesn't alter the SSH protocol at all, it merely bootstraps it differently, = using an IANA-assigned port. Assuming our WG agrees this is the right stra= tegy, can we ask the SAAG folks to not try to change the design and just an= alyze the security of the existing draft? If there's a security issue, the= n of course we'll need to address it but, otherwise, isn't it just a matter= of preference? Can we get a virtual hum? http://www.surveymonkey.com/s/MWVNT7M Thanks, Kent --_000_CDEA04F6395C1kwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Dear NETC= ONF WG,

The discu= ssion so far regarding the Reverse SSH draft is almost a perfect repea= t of the one that occurred two years ago, with some wanting direction-negotiation in the SSH protocol itself (not vi= a a port), even though it would mean no implementation available for years.= ..

However, = there is a significant difference now, which is that this draft is in the h= ands of the NETCONF WG as a chartered WG item.  Before, when my draft = was effectively posted to the SSH WG (the ieft-ssh list), it was understandable why they would look for solutions th= at changed the SSH protocol itself, as that is *their* charter=85

However, = in order to realize implementations in the near-term, this draft doesn't al= ter the SSH protocol at all, it merely bootstraps it differently, using an IANA-assigned port.  Assum= ing our WG agrees this is the right strategy, can we ask the= SAAG folks to not try to change the design and just analyze the security of the existing draft?  If there= 's a security issue, then of course we'll need to address it but, otherwise= , isn't it just a matter of preference?  

Can we get a virtual hum?    http://www.surveymonkey.com/s/M= WVNT7M

Thanks,
Kent

--_000_CDEA04F6395C1kwatsenjunipernet_-- From touch@isi.edu Fri Jun 21 10:53:18 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E94721F9FE4 for ; Fri, 21 Jun 2013 10:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WgtxgMJ4B0W for ; Fri, 21 Jun 2013 10:53:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7AC21E812D for ; Fri, 21 Jun 2013 10:53:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5LHqrxL024074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 10:52:53 -0700 (PDT) Message-ID: <51C492DE.7070705@isi.edu> Date: Fri, 21 Jun 2013 10:52:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:53:18 -0000 On 6/21/2013 10:26 AM, Kent Watsen wrote: > > Dear NETCONF WG, > > The discussion so far regarding the Reverse SSH draft is almost a > perfect repeat of the one that occurred two years ago, with some wanting > direction-negotiation in the SSH protocol itself (not via a port), even > though it would mean no implementation available for years... > > However, there is a significant difference now, which is that this draft > is in the hands of the NETCONF WG as a chartered WG item. Before, when > my draft was effectively posted to the SSH WG (the ieft-ssh list), it > was understandable why they would look for solutions that changed the > SSH protocol itself, as that is *their* charter… > > However, in order to realize implementations in the near-term, this > draft doesn't alter the SSH protocol at all, it merely bootstraps it > differently, using an IANA-assigned port. Assuming our WG agrees this > is the right strategy, can we ask the SAAG folks to not try to change > the design and just analyze the security of the existing draft? If > there's a security issue, then of course we'll need to address it but, > otherwise, isn't it just a matter of preference? Not really; what you've described is a design approach intended to trade implementation complexity and organizational challenges (WG boundaries) for port consumption. Ports are a scarce resource; they should not be consumed for convenience. Joe > Can we get a virtual hum? http://www.surveymonkey.com/s/MWVNT7M > > Thanks, > Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From kwatsen@juniper.net Fri Jun 21 12:03:39 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FF021E813A for ; Fri, 21 Jun 2013 12:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqwkJiQB4UUu for ; Fri, 21 Jun 2013 12:03:32 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 983B421F9DFA for ; Fri, 21 Jun 2013 12:02:54 -0700 (PDT) Received: from mail28-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:02:51 +0000 Received: from mail28-va3 (localhost [127.0.0.1]) by mail28-va3-R.bigfish.com (Postfix) with ESMTP id E77CF3C015C for ; Fri, 21 Jun 2013 19:02:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail28-va3: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=kwatsen@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail28-va3 (localhost.localdomain [127.0.0.1]) by mail28-va3 (MessageSwitch) id 1371841368340806_1113; Fri, 21 Jun 2013 19:02:48 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.245]) by mail28-va3.bigfish.com (Postfix) with ESMTP id 45FF740055 for ; Fri, 21 Jun 2013 19:02:48 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:02:47 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 12:02:46 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 12:02:45 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 12:06:11 -0700 Received: from mail131-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:02:45 +0000 Received: from mail131-ch1 (localhost [127.0.0.1]) by mail131-ch1-R.bigfish.com (Postfix) with ESMTP id CBD7040F0B for ; Fri, 21 Jun 2013 19:02:44 +0000 (UTC) Received: from mail131-ch1 (localhost.localdomain [127.0.0.1]) by mail131-ch1 (MessageSwitch) id 1371841362804309_15484; Fri, 21 Jun 2013 19:02:42 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail131-ch1.bigfish.com (Postfix) with ESMTP id C1A5E260054; Fri, 21 Jun 2013 19:02:42 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:02:40 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 19:02:40 +0000 From: Kent Watsen To: Joe Touch Thread-Topic: [Netconf] reverse ssh recommendation Thread-Index: AQHObqg7LGEz7Pg9q0aFwSCqa9bVYplAQ2uA Date: Fri, 21 Jun 2013 19:02:39 +0000 Message-ID: In-Reply-To: <51C492DE.7070705@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <867FB9073C92F24D86B42EE7CB9088DF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ISI.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:03:39 -0000 >Ports are a scarce resource; they should not be consumed for convenience. I've been wondering about why tcpmux (port #1, rfc 1078) hasn't been more popular, after all, no one believes port-based firewalls matter anymore and, with it, only one port would ever need to be opened... With the potential desire to reverse the TLS protocol as well, I was thinking that we could ourselves use tcpmux with service names "NETCONF_REVERSE_SSH" and "NETCONF_REVERSE_TLS". But no other protocol does this and there is no IANA-maintained assignment for TCPMUX services, so maybe the port-scarcity issue isn't quite so dire? Note for anyone who wants to take the survey, please assume that in question #2, using TCPMUX is the same as using "an IANA-assigned port". Thanks, Kent From andy@yumaworks.com Fri Jun 21 12:35:30 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6148421E8123 for ; Fri, 21 Jun 2013 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id verQMDSZI9IK for ; Fri, 21 Jun 2013 12:35:29 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 837EB21E8119 for ; Fri, 21 Jun 2013 12:35:29 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so8167106pbc.40 for ; Fri, 21 Jun 2013 12:35:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=g2sG56aMdQsQk4PwKNf2kmKTOSFmiwBrji60gxj4D04=; b=V7IJapU+vIlp8WWpVhL4751tsdvSBhuFgRSyDnAw2ylRmzYNSm3uhlxOp5T+cPOKMb kDt/dJiW3snSIJNe+AT7IGK0il9T0NtHQ08h+E3rsCDyVcxo14HR0l94uWvI/mqpOZHR BtfcFI5BsmzYknZK/qeN1GWRS6a03fgcEfuh5LHLrkrk1pzDr+OoPfpKixSScFEpK5l6 bBPKFEK1PBgn5WbqrN1QkK/MJLOhwUL1w2/DWSamSYo32ztecXrbYQyM0K/STjhQuf+v WxkG+9FWLuiId1UTc1RyqhSm/luFBGMxhD8ftxe0onXHkUOFOAvxvaUPet7MMIT98ebP NJMQ== MIME-Version: 1.0 X-Received: by 10.68.164.97 with SMTP id yp1mr13738148pbb.77.1371843328220; Fri, 21 Jun 2013 12:35:28 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 21 Jun 2013 12:35:28 -0700 (PDT) In-Reply-To: <51C492DE.7070705@isi.edu> References: <51C492DE.7070705@isi.edu> Date: Fri, 21 Jun 2013 12:35:28 -0700 Message-ID: From: Andy Bierman To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bae446e4431db04dfaf2a2a X-Gm-Message-State: ALoCoQnQhhKLeZAC4r2UZ6rm3psYkYP6LieK19RaN5P18FcWcWwIAplLc+OaTSKe36O0cA/59HLn Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:35:30 -0000 --047d7bae446e4431db04dfaf2a2a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2013 at 10:52 AM, Joe Touch wrote: > > > On 6/21/2013 10:26 AM, Kent Watsen wrote: > >> >> Dear NETCONF WG, >> >> The discussion so far regarding the Reverse SSH draft is almost a >> perfect repeat of the one that occurred two years ago, with some wanting >> direction-negotiation in the SSH protocol itself (not via a port), even >> though it would mean no implementation available for years... >> >> However, there is a significant difference now, which is that this draft >> is in the hands of the NETCONF WG as a chartered WG item. Before, when >> my draft was effectively posted to the SSH WG (the ieft-ssh list), it >> was understandable why they would look for solutions that changed the >> SSH protocol itself, as that is *their* charter=85 >> >> However, in order to realize implementations in the near-term, this >> draft doesn't alter the SSH protocol at all, it merely bootstraps it >> differently, using an IANA-assigned port. Assuming our WG agrees this >> is the right strategy, can we ask the SAAG folks to not try to change >> the design and just analyze the security of the existing draft? If >> there's a security issue, then of course we'll need to address it but, >> otherwise, isn't it just a matter of preference? >> > > Not really; what you've described is a design approach intended to trade > implementation complexity and organizational challenges (WG boundaries) f= or > port consumption. > > Ports are a scarce resource; they should not be consumed for convenience. > I don't think the WG is using a port is for convenience in this case. We need a standard way for a managed device to poke a manager and say "start a NM session to me for app X". IMO, "call-home" is not specific to SSH and this solution is not really even specific to SSH. It seems to be that the TCP connection is being reused for efficiency, not coupled to SSH for this use-case. The protocol could just as well be defined to poke the manager and say "start an NM session with me for app X, using protocol Y." Since the server does not bypass any session security to do this, I am unclear on the security implications of this draft. > > Joe > > Andy > Can we get a virtual hum? http://www.surveymonkey.com/s/**MWVNT7M >> >> Thanks, >> 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 > --047d7bae446e4431db04dfaf2a2a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 21, 2013 at 10:52 AM, Joe To= uch <touch@isi.edu> wrote:


On 6/21/2013 10:26 AM, Kent Watsen wrote:

Dear NETCONF WG,

The discussion so far regarding the Reverse SSH draft is almost a
perfect repeat of the one that occurred two years ago, with some wanting direction-negotiation in the SSH protocol itself (not via a port), even
though it would mean no implementation available for years...

However, there is a significant difference now, which is that this draft is in the hands of the NETCONF WG as a chartered WG item. =A0Before, when my draft was effectively posted to the SSH WG (the ieft-ssh list), it
was understandable why they would look for solutions that changed the
SSH protocol itself, as that is *their* charter=85

However, in order to realize implementations in the near-term, this
draft doesn't alter the SSH protocol at all, it merely bootstraps it differently, using an IANA-assigned port. =A0Assuming our WG agrees this is the right strategy, can we ask the SAAG folks to not try to change
the design and just analyze the security of the existing draft? If
there's a security issue, then of course we'll need to address it b= ut,
otherwise, isn't it just a matter of preference?

Not really; what you've described is a design approach intended to trad= e implementation complexity and organizational challenges (WG boundaries) f= or port consumption.

Ports are a scarce resource; they should not be consumed for convenience.

I don't think the WG is using a port= is for convenience in this case.
We need a standard way for a ma= naged device to poke a manager
and say "start a NM session to me for app X".

=
IMO, "call-home" is not specific to SSH and this solut= ion is not really
even specific to SSH.

It seems to be that the TCP connection is being reused for efficiency,
not coupled to SSH for this use-case. =A0The protocol could just as w= ell
be defined to poke the manager and say "start an NM sess= ion with me
for app X, using protocol Y."

Since the = server does not bypass any session security to do this,
I am uncl= ear on the security implications of this draft.

=A0

Joe


Andy


=A0
Can we get a virtual hum? =A0 =A0http://www.surveymonkey.com/s/MWVNT7M<= br>
Thanks,
Kent



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

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

--047d7bae446e4431db04dfaf2a2a-- From kwatsen@juniper.net Fri Jun 21 13:18:01 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9B21F9C0F; Fri, 21 Jun 2013 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.038 X-Spam-Level: X-Spam-Status: No, score=-0.038 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7AxmLuVK8An; Fri, 21 Jun 2013 13:17:55 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 41B0421F9C1B; Fri, 21 Jun 2013 13:17:55 -0700 (PDT) Received: from mail4-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE038.bigfish.com (10.174.4.101) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 20:17:54 +0000 Received: from mail4-db8 (localhost [127.0.0.1]) by mail4-db8-R.bigfish.com (Postfix) with ESMTP id 2952C900125; Fri, 21 Jun 2013 20:17:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I936eI1b0bI1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail4-db8: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=kwatsen@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail4-db8 (localhost.localdomain [127.0.0.1]) by mail4-db8 (MessageSwitch) id 1371845871883040_10016; Fri, 21 Jun 2013 20:17:51 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.253]) by mail4-db8.bigfish.com (Postfix) with ESMTP id CFD0A4C0046; Fri, 21 Jun 2013 20:17:51 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.53) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Jun 2013 20:17:00 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 13:16:58 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 13:16:58 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 13:28:55 -0700 Received: from mail162-tx2-R.bigfish.com (10.9.14.234) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 20:16:57 +0000 Received: from mail162-tx2 (localhost [127.0.0.1]) by mail162-tx2-R.bigfish.com (Postfix) with ESMTP id 3951E4A0098; Fri, 21 Jun 2013 20:16:57 +0000 (UTC) Received: from mail162-tx2 (localhost.localdomain [127.0.0.1]) by mail162-tx2 (MessageSwitch) id 1371845815550109_26863; Fri, 21 Jun 2013 20:16:55 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.253]) by mail162-tx2.bigfish.com (Postfix) with ESMTP id 78178100046; Fri, 21 Jun 2013 20:16:55 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 20:16:50 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 20:16:50 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-01.txt Thread-Index: AQHOboQGz506FfWViUq1SGyFWdeosplAWG0A Date: Fri, 21 Jun 2013 20:16:49 +0000 Message-ID: In-Reply-To: <20130621133340.26792.55620.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.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NETBSD.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:18:01 -0000 FYI, this -01 update simply removes the hmac-* family of public host key algorithms, since they were distracting from the primary focus of the document and can be easily defined in a draft of their own, at anytime, without affecting the remaining draft's validity. For ietf-ssh and saag list members, yesterday we had a snafu with the mail-archives because messages were being sent to multiple lists. If you want to reply, please consider joining the NETCONF mailing list so we can keep the discussion in one place. Thanks, Kent On 6/21/13 9:33 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 Secure Shell (Reverse SSH) > Author(s) : Kent Watsen > Filename : draft-ietf-netconf-reverse-ssh-01.txt > Pages : 13 > Date : 2013-06-20 > >Abstract: > This memo 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-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-reverse-ssh-01 > > >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 kwatsen@juniper.net Fri Jun 21 13:39:23 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DC221F9DBC for ; Fri, 21 Jun 2013 13:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMU8+PmQ9dsG for ; Fri, 21 Jun 2013 13:39:18 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 3936621F9DBA for ; Fri, 21 Jun 2013 13:39:17 -0700 (PDT) Received: from mail128-db8-R.bigfish.com (10.174.8.231) by DB8EHSOBE040.bigfish.com (10.174.4.103) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 20:39:16 +0000 Received: from mail128-db8 (localhost [127.0.0.1]) by mail128-db8-R.bigfish.com (Postfix) with ESMTP id AFE961602ED for ; Fri, 21 Jun 2013 20:39:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I1519M4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h683h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail128-db8: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=kwatsen@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail128-db8 (localhost.localdomain [127.0.0.1]) by mail128-db8 (MessageSwitch) id 1371847024280095_5870; Fri, 21 Jun 2013 20:37:04 +0000 (UTC) Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.228]) by mail128-db8.bigfish.com (Postfix) with ESMTP id 85A184E0896 for ; Fri, 21 Jun 2013 20:25:07 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Jun 2013 20:25:07 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 13:24:59 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 13:24:59 -0700 Received: from CO9EHSOBE018.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 13:36:55 -0700 Received: from mail108-co9-R.bigfish.com (10.236.132.233) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 20:24:57 +0000 Received: from mail108-co9 (localhost [127.0.0.1]) by mail108-co9-R.bigfish.com (Postfix) with ESMTP id 805E6C01B4 for ; Fri, 21 Jun 2013 20:24:57 +0000 (UTC) Received: from mail108-co9 (localhost.localdomain [127.0.0.1]) by mail108-co9 (MessageSwitch) id 1371846295332010_14055; Fri, 21 Jun 2013 20:24:55 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.242]) by mail108-co9.bigfish.com (Postfix) with ESMTP id 4E78838005A; Fri, 21 Jun 2013 20:24:55 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 20:24:54 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 20:24:53 +0000 From: Kent Watsen To: Andy Bierman , Joe Touch Thread-Topic: [Netconf] reverse ssh recommendation Thread-Index: AQHObqg7LGEz7Pg9q0aFwSCqa9bVYplAj6cA///KvoA= Date: Fri, 21 Jun 2013 20:24:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ISI.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:39:24 -0000 Hi Andy Please keep in mind that to manage some devices (e.g. behind firewalls), that the NETCONF session must be on a TCP connection the device initiated. The device sending a one-way knock-knock (e.g. SNMP trap) to cause the application to connect back to it won't work in these situations. Thanks, Kent From: Andy Bierman Date: Friday, June 21, 2013 3:35 PM To: Joe Touch Cc: Kent Watsen , NetConf Subject: Re: [Netconf] reverse ssh recommendation On Fri, Jun 21, 2013 at 10:52 AM, Joe Touch wrote: On 6/21/2013 10:26 AM, Kent Watsen wrote: Dear NETCONF WG, The discussion so far regarding the Reverse SSH draft is almost a perfect repeat of the one that occurred two years ago, with some wanting direction-negotiation in the SSH protocol itself (not via a port), even though it would mean no implementation available for years... However, there is a significant difference now, which is that this draft is in the hands of the NETCONF WG as a chartered WG item. Before, when my draft was effectively posted to the SSH WG (the ieft-ssh list), it was understandable why they would look for solutions that changed the SSH protocol itself, as that is *their* charter=8A However, in order to realize implementations in the near-term, this draft doesn't alter the SSH protocol at all, it merely bootstraps it differently, using an IANA-assigned port. Assuming our WG agrees this is the right strategy, can we ask the SAAG folks to not try to change the design and just analyze the security of the existing draft? If there's a security issue, then of course we'll need to address it but, otherwise, isn't it just a matter of preference? Not really; what you've described is a design approach intended to trade implementation complexity and organizational challenges (WG boundaries) for port consumption. Ports are a scarce resource; they should not be consumed for convenience. I don't think the WG is using a port is for convenience in this case. We need a standard way for a managed device to poke a manager and say "start a NM session to me for app X". IMO, "call-home" is not specific to SSH and this solution is not really even specific to SSH. It seems to be that the TCP connection is being reused for efficiency, not coupled to SSH for this use-case. The protocol could just as well be defined to poke the manager and say "start an NM session with me for app X, using protocol Y." Since the server does not bypass any session security to do this, I am unclear on the security implications of this draft. =20 Joe Andy =20 Can we get a virtual hum? http://www.surveymonkey.com/s/MWVNT7M Thanks, 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 touch@isi.edu Fri Jun 21 13:43:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A943721F9DF0 for ; Fri, 21 Jun 2013 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.015 X-Spam-Level: X-Spam-Status: No, score=-103.015 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q5+-jlGJiXR for ; Fri, 21 Jun 2013 13:43:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E321F9DB9 for ; Fri, 21 Jun 2013 13:43:24 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5LKgtrJ026300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 13:42:55 -0700 (PDT) Message-ID: <51C4BAB7.2050602@isi.edu> Date: Fri, 21 Jun 2013 13:42:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Bierman References: <51C492DE.7070705@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:43:57 -0000 On 6/21/2013 12:35 PM, Andy Bierman wrote: > I don't think the WG is using a port is for convenience in this case. > We need a standard way for a managed device to poke a manager > and say "start a NM session to me for app X". Having a port for NETCONF over SSH is fine - but that's already done (RFC6264), and a port for that is already available: 830. That same port can and should be used for reverse SSH for Netconf. Joe From andy@yumaworks.com Fri Jun 21 14:02:17 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF74121F9DE3 for ; Fri, 21 Jun 2013 14:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVwrA5+hOTOu for ; Fri, 21 Jun 2013 14:02:17 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7302D21F9DD4 for ; Fri, 21 Jun 2013 14:02:17 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so8395051pad.37 for ; Fri, 21 Jun 2013 14:02:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2N7qG4uv6B3dgfZtlIavo7GxI1wObI+sR2wdMmPO6s4=; b=CZKhoW+p6L1sVf03ip6kptEHk3OiosDpRuJRKSC7TGqSlPh31deJVqMtZ2h9IfR/Bh uGrAiJ36KnhD3AgZSCRi4oYu2ym5xtOCvASvg/Rqsob/jXR2jOz9Dzk+HW7yrUg6Zb1j 2vLgviY/CgHFH3PTNepbWIZzhzEbmGMLzrqkv061Tvu70pol2tdnFQPzlrCS9HhnMqc1 6PKa/KgrTP0aGFh49P4NZ3okxPY0xyegRAnfldJllo7xy78JZKfFaDBHozreNduDTblH XKcdda35f0I6qhetuWk47nWLa1TnIaRvCQtf5GEC+ihhQth6g19Dls22iiHiLf4wmseG xgCA== MIME-Version: 1.0 X-Received: by 10.66.228.98 with SMTP id sh2mr17608473pac.80.1371848537212; Fri, 21 Jun 2013 14:02:17 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 21 Jun 2013 14:02:17 -0700 (PDT) In-Reply-To: <51C4BAB7.2050602@isi.edu> References: <51C492DE.7070705@isi.edu> <51C4BAB7.2050602@isi.edu> Date: Fri, 21 Jun 2013 14:02:17 -0700 Message-ID: From: Andy Bierman To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b15a8d1bf1db504dfb060e5 X-Gm-Message-State: ALoCoQnvXBFU5XIMw2LiNInk6YLeuiU8aeNC/acCn1zjul9lDIhTaFOR8kIEn7H3Sq31BzZ2sfUL Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:02:18 -0000 --047d7b15a8d1bf1db504dfb060e5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch wrote: > On 6/21/2013 12:35 PM, Andy Bierman wrote: > >> I don't think the WG is using a port is for convenience in this case. >> We need a standard way for a managed device to poke a manager >> and say "start a NM session to me for app X". >> > > Having a port for NETCONF over SSH is fine - but that's already done > (RFC6264), and a port for that is already available: 830. > > That same port can and should be used for reverse SSH for Netconf. > > How do we have a NETCONF server and a NETCONF client listening to be poked on the same IP address if we re-use port 830? Joe > Andy --047d7b15a8d1bf1db504dfb060e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 21, 2013 at 1:42 PM, Joe Tou= ch <touch@isi.edu> wrote:
On 6/21/2013 12:35 PM, Andy Bierman wrote:
I don't think the WG is using a port is for convenience in this case. We need a standard way for a managed device to poke a manager
and say "start a NM session to me for app X".

Having a port for NETCONF over SSH is fine - but that's already done (R= FC6264), and a port for that is already available: 830.

That same port can and should be used for reverse SSH for Netconf.


How do we have a NETCONF= server and a NETCONF client listening
to be poked on the same IP= address if we re-use port 830?

Joe


Andy
--047d7b15a8d1bf1db504dfb060e5-- From touch@isi.edu Fri Jun 21 14:08:30 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A9121F9D53 for ; Fri, 21 Jun 2013 14:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.004 X-Spam-Level: X-Spam-Status: No, score=-103.004 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJPniPHu3tPU for ; Fri, 21 Jun 2013 14:08:24 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25121F9DFD for ; Fri, 21 Jun 2013 14:08:23 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r5LL7wPm028616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 14:07:58 -0700 (PDT) Message-ID: <51C4C097.7010707@isi.edu> Date: Fri, 21 Jun 2013 14:07:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Bierman References: <51C492DE.7070705@isi.edu> <51C4BAB7.2050602@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:08:30 -0000 On 6/21/2013 2:02 PM, Andy Bierman wrote: > > > On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch > wrote: > > On 6/21/2013 12:35 PM, Andy Bierman wrote: > > I don't think the WG is using a port is for convenience in this > case. > We need a standard way for a managed device to poke a manager > and say "start a NM session to me for app X". > > > Having a port for NETCONF over SSH is fine - but that's already done > (RFC6264), and a port for that is already available: 830. > > That same port can and should be used for reverse SSH for Netconf. > > > How do we have a NETCONF server and a NETCONF client listening > to be poked on the same IP address if we re-use port 830? If they're different *services*, they warrant different ports. What is the different service each are offering? Is it just who initiates the connection, or who initiates the certificate exchange (that's not a new service). Joe From touch@isi.edu Fri Jun 21 14:19:48 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB42E21F9E16 for ; Fri, 21 Jun 2013 14:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.994 X-Spam-Level: X-Spam-Status: No, score=-102.994 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbX-Qt3xedbP for ; Fri, 21 Jun 2013 14:19:43 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 75ED121F9E01 for ; Fri, 21 Jun 2013 14:19:39 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r5LLJL30002090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 14:19:21 -0700 (PDT) Message-ID: <51C4C342.4010108@isi.edu> Date: Fri, 21 Jun 2013 14:18:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:19:48 -0000 On 6/21/2013 12:02 PM, Kent Watsen wrote: > >> Ports are a scarce resource; they should not be consumed for convenience. > > > I've been wondering about why tcpmux (port #1, rfc 1078) hasn't been more > popular, after all, no one believes port-based firewalls matter anymore > and, with it, only one port would ever need to be opened... See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt, esp. Section 2.4 We are actually implementing the TCP port option described in this doc (which isn't TCPMUX), but that doesn't address this problem at all - nor does TCPMUX. Either way, the question is whether this is one service or two different services. > With the potential desire to reverse the TLS protocol as well, I was > thinking that we could ourselves use tcpmux with service names > "NETCONF_REVERSE_SSH" and "NETCONF_REVERSE_TLS". But no other protocol > does this and there is no IANA-maintained assignment for TCPMUX services, > so maybe the port-scarcity issue isn't quite so dire? It isn't dire, but that's *because* they require substantial review, and many requests for "yet another port for the same service for convenience" are declined. The modern equivalent of TCPMUX, FWIW, would be Service Names in the DNS service records, for which there is an active IANA registry and a BOF coming up (dnssdext). > Note for anyone who wants to take the survey, please assume that in > question #2, using TCPMUX is the same as using "an IANA-assigned port". Yes, if you mean DNS SRV records. No, if you mean TCPMUX. It effectively doesn't exist. Joe From andy@yumaworks.com Fri Jun 21 14:44:59 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C255521F9E4A for ; Fri, 21 Jun 2013 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KS-It96yaZo for ; Fri, 21 Jun 2013 14:44:59 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EAD9C21F9E33 for ; Fri, 21 Jun 2013 14:44:53 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so8381048pbc.17 for ; Fri, 21 Jun 2013 14:44:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VJgssGbFVMaDKirzVAPuEY3v7k+5TriI08hOAv0VE40=; b=FJUJ1wFdiI2zL6mpaOWKai9PGaHmZehzkJFdiOrINiYriqv5szVqbq8rC8BOtWR74I ewHyRutG0vrZJDpx3nFCDgDTKhN1Kwohtk1obdE90NYWyTyT3IpeBJjVVkkrsx4ylAXc swLZmS7XSlzRAbwDGEOfGOIYFEYHAQ0xW14ZY+MBgRpP3DGNmozDnZ4zTgjdn2ySUG6F KFo7mtRGKNOGb9+e701bRh+fvidn4JnA6mvhe3yvm9psSEmJInUi5HaKpf190TC2yY5v 5X5CW1BBjsuS19uX/8yPVpqwhCQtDtppfq40grLEHOtSObQgNtV7/WRAF9MZGEn+DAT8 Rnig== MIME-Version: 1.0 X-Received: by 10.68.241.104 with SMTP id wh8mr14344237pbc.36.1371851093656; Fri, 21 Jun 2013 14:44:53 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 21 Jun 2013 14:44:53 -0700 (PDT) In-Reply-To: <51C4C097.7010707@isi.edu> References: <51C492DE.7070705@isi.edu> <51C4BAB7.2050602@isi.edu> <51C4C097.7010707@isi.edu> Date: Fri, 21 Jun 2013 14:44:53 -0700 Message-ID: From: Andy Bierman To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b339cef1f563004dfb0f9bd X-Gm-Message-State: ALoCoQn/23jHCiuwntT1NQWuNIkoVYU/+oHXZjXBMddtLh1I1sszCNHpj72yJXJKkq1uTZqDSdGt Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:44:59 -0000 --047d7b339cef1f563004dfb0f9bd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 2:07 PM, Joe Touch wrote: > > > On 6/21/2013 2:02 PM, Andy Bierman wrote: > >> >> >> On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch > > wrote: >> >> On 6/21/2013 12:35 PM, Andy Bierman wrote: >> >> I don't think the WG is using a port is for convenience in this >> case. >> We need a standard way for a managed device to poke a manager >> and say "start a NM session to me for app X". >> >> >> Having a port for NETCONF over SSH is fine - but that's already done >> (RFC6264), and a port for that is already available: 830. >> >> That same port can and should be used for reverse SSH for Netconf. >> >> >> How do we have a NETCONF server and a NETCONF client listening >> to be poked on the same IP address if we re-use port 830? >> > > If they're different *services*, they warrant different ports. > > What is the different service each are offering? Is it just who initiates > the connection, or who initiates the certificate exchange (that's not a new > service). > > They are different services -- NETCONF server and NETCONF client offering the Call-home service. When a NETCONF client connects to a server on port 830, the server waits for the client to send it messages. When a NETCONF server connects to a Callhome Client, the client will be sending messages to the NETCONF server. If both services are listening on the same port, which one is supposed to run when a TCP connection is made? Joe > > > Andy --047d7b339cef1f563004dfb0f9bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 21, 2013 at 2:07 PM, Joe Tou= ch <touch@isi.edu> wrote:


On 6/21/2013 2:02 PM, Andy Bierman wrote:


On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch <touch@isi.edu
<mailto:touch@isi.edu= >> wrote:

=A0 =A0 On 6/21/2013 12:35 PM, Andy Bierman wrote:

=A0 =A0 =A0 =A0 I don't think the WG is using a port is for convenience= in this
=A0 =A0 =A0 =A0 case.
=A0 =A0 =A0 =A0 We need a standard way for a managed device to poke a manag= er
=A0 =A0 =A0 =A0 and say "start a NM session to me for app X".


=A0 =A0 Having a port for NETCONF over SSH is fine - but that's already= done
=A0 =A0 (RFC6264), and a port for that is already available: 830.

=A0 =A0 That same port can and should be used for reverse SSH for Netconf.<= br>

How do we have a NETCONF server and a NETCONF client listening
to be poked on the same IP address if we re-use port 830?

If they're different *services*, they warrant different ports.

What is the different service each are offering? Is it just who initiates t= he connection, or who initiates the certificate exchange (that's not a = new service).


They are different servi= ces -- NETCONF server and NETCONF client
offering the Call-home s= ervice.

When a NETCONF client connects to a server= on port 830, the server
waits for the client to send it <rpc> messages.

When a NETCONF server connects to a Callhome Client, the client
will be sending <rpc> messages to the NETCONF server.

If both services are listening on the same port,
<= div>which one is supposed to run when a TCP connection is made?
<= br>

Joe



Andy

--047d7b339cef1f563004dfb0f9bd-- From andy@yumaworks.com Fri Jun 21 14:50:49 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756CB21F9E55 for ; Fri, 21 Jun 2013 14:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6cIkYODTaRA for ; Fri, 21 Jun 2013 14:50:49 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8821F9E4E for ; Fri, 21 Jun 2013 14:50:48 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so8394933pad.33 for ; Fri, 21 Jun 2013 14:50:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nr9arV3n0PWfixVdTcWlep2NVRL3hXLzSymLtG3vLK8=; b=YfMUdEVK3guwaqca1h4Al/MmI35C56u4AOFiddpcKPajsKex2lxr3hc3PXPW9E9Oj/ fRy+ZSF+k2lL1IvDXvQ2dRFn/aNlP/pyYclrLN8Z8f581RZhP7mp4qdXCYD3YzPbDIgv WBuw6GGJB5F4VB4FizxJGOhgL/SaivMVg9a8mLaz5s+nMpmGHxgkLjN9pjUPWP8YI1Vb tA/+YmdM6uKUuvbQxBCThWzpCP0sgbUVIsj3XM/t4q3gm1lVT/9taGV+c2hT3YazZJdC 8SLi09inMLq0Fp36jIpNWukyRxaLikoRXDf1pZNzDO/ijOj/glcZULM8Mc8EUz/RR8Lt IYKg== MIME-Version: 1.0 X-Received: by 10.66.248.228 with SMTP id yp4mr18003205pac.158.1371851447964; Fri, 21 Jun 2013 14:50:47 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 21 Jun 2013 14:50:47 -0700 (PDT) In-Reply-To: <51C4C097.7010707@isi.edu> References: <51C492DE.7070705@isi.edu> <51C4BAB7.2050602@isi.edu> <51C4C097.7010707@isi.edu> Date: Fri, 21 Jun 2013 14:50:47 -0700 Message-ID: From: Andy Bierman To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b15b2bd3db06004dfb10e39 X-Gm-Message-State: ALoCoQnXnZV7nKO6MaZVKpp3pdb1S0jxPdVeIWI9aIc+zEOFyAjisMitCZbHigt9pnFn9uzHdx+n Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:50:49 -0000 --047d7b15b2bd3db06004dfb10e39 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 2:07 PM, Joe Touch wrote: > > > On 6/21/2013 2:02 PM, Andy Bierman wrote: > >> >> >> On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch > > wrote: >> >> On 6/21/2013 12:35 PM, Andy Bierman wrote: >> >> I don't think the WG is using a port is for convenience in this >> case. >> We need a standard way for a managed device to poke a manager >> and say "start a NM session to me for app X". >> >> >> Having a port for NETCONF over SSH is fine - but that's already done >> (RFC6264), and a port for that is already available: 830. >> >> That same port can and should be used for reverse SSH for Netconf. >> >> >> How do we have a NETCONF server and a NETCONF client listening >> to be poked on the same IP address if we re-use port 830? >> > > If they're different *services*, they warrant different ports. > > Could this be done with different subsystem names instead of port numbers? E.g.: * port 830, subsystem "netconf" is a NETCONF server * port 830, subsystem "netconf-client" is a Callhome NETCONF client This is SSH-specific, but the charter is SSH specific. Andy > What is the different service each are offering? Is it just who initiates > the connection, or who initiates the certificate exchange (that's not a new > service). > > Joe > > > --047d7b15b2bd3db06004dfb10e39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 21, 2013 at 2:07 PM, Joe Tou= ch <touch@isi.edu> wrote:


On 6/21/2013 2:02 PM, Andy Bierman wrote:


On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch <touch@isi.edu
<mailto:touch@isi.edu= >> wrote:

=A0 =A0 On 6/21/2013 12:35 PM, Andy Bierman wrote:

=A0 =A0 =A0 =A0 I don't think the WG is using a port is for convenience= in this
=A0 =A0 =A0 =A0 case.
=A0 =A0 =A0 =A0 We need a standard way for a managed device to poke a manag= er
=A0 =A0 =A0 =A0 and say "start a NM session to me for app X".


=A0 =A0 Having a port for NETCONF over SSH is fine - but that's already= done
=A0 =A0 (RFC6264), and a port for that is already available: 830.

=A0 =A0 That same port can and should be used for reverse SSH for Netconf.<= br>

How do we have a NETCONF server and a NETCONF client listening
to be poked on the same IP address if we re-use port 830?

If they're different *services*, they warrant different ports.


Could this be done with different subs= ystem names instead of port numbers?
E.g.:=A0
=A0 =A0* = port 830, subsystem "netconf" is a NETCONF server
=A0 = =A0* port 830, subsystem "netconf-client" is a Callhome NETCONF c= lient

This is SSH-specific, but the charter is SSH specific.<= /div>

Andy

=A0
What is the different service each are offering? Is it just who initiates t= he connection, or who initiates the certificate exchange (that's not a = new service).

Joe



--047d7b15b2bd3db06004dfb10e39-- From touch@isi.edu Fri Jun 21 15:04:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0915221F9ADA for ; Fri, 21 Jun 2013 15:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.984 X-Spam-Level: X-Spam-Status: No, score=-104.984 tagged_above=-999 required=5 tests=[AWL=1.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxlAxj-flxfj for ; Fri, 21 Jun 2013 15:04:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4BC21F9962 for ; Fri, 21 Jun 2013 15:04:50 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5LM4LYu007075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 15:04:21 -0700 (PDT) Message-ID: <51C4CDE5.3030201@isi.edu> Date: Fri, 21 Jun 2013 15:04:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Bierman References: <51C492DE.7070705@isi.edu> <51C4BAB7.2050602@isi.edu> <51C4C097.7010707@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 22:04:56 -0000 On 6/21/2013 2:44 PM, Andy Bierman wrote: > > > On Fri, Jun 21, 2013 at 2:07 PM, Joe Touch > wrote: > > > > On 6/21/2013 2:02 PM, Andy Bierman wrote: > > > > On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch > >> wrote: > > On 6/21/2013 12:35 PM, Andy Bierman wrote: > > I don't think the WG is using a port is for convenience > in this > case. > We need a standard way for a managed device to poke a > manager > and say "start a NM session to me for app X". > > > Having a port for NETCONF over SSH is fine - but that's > already done > (RFC6264), and a port for that is already available: 830. > > That same port can and should be used for reverse SSH for > Netconf. > > > How do we have a NETCONF server and a NETCONF client listening > to be poked on the same IP address if we re-use port 830? > > > If they're different *services*, they warrant different ports. > > What is the different service each are offering? Is it just who > initiates the connection, or who initiates the certificate exchange > (that's not a new service). > > > They are different services -- NETCONF server and NETCONF client > offering the Call-home service. > > When a NETCONF client connects to a server on port 830, the server > waits for the client to send it messages. > > When a NETCONF server connects to a Callhome Client, the client > will be sending messages to the NETCONF server. > > If both services are listening on the same port, > which one is supposed to run when a TCP connection is made? FTP solved this years ago with the command. You either rewrite your legacy implementation to embed both directions, or you rewrite your legacy implementation to listen to a 'dispatch' service that listens on port 830. Since you're extending netconf, there's no reason to expect not to rewrite or recompile legacy code to support this. Joe From kwatsen@juniper.net Fri Jun 21 15:26:01 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E25D21F9E68 for ; Fri, 21 Jun 2013 15:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmyrVyyf-ynW for ; Fri, 21 Jun 2013 15:25:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52C21F9E11 for ; Fri, 21 Jun 2013 15:25:55 -0700 (PDT) Received: from mail95-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 22:25:54 +0000 Received: from mail95-ch1 (localhost [127.0.0.1]) by mail95-ch1-R.bigfish.com (Postfix) with ESMTP id 5C1AB4801A6 for ; Fri, 21 Jun 2013 22:25:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: PS-5(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah8275bhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail95-ch1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=kwatsen@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail95-ch1 (localhost.localdomain [127.0.0.1]) by mail95-ch1 (MessageSwitch) id 1371853552369547_26869; Fri, 21 Jun 2013 22:25:52 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail95-ch1.bigfish.com (Postfix) with ESMTP id 4EB5E4E004C for ; Fri, 21 Jun 2013 22:25:52 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 22:25:52 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 15:25:51 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 15:25:50 -0700 Received: from CO9EHSOBE027.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 15:37:47 -0700 Received: from mail37-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 22:25:49 +0000 Received: from mail37-co9 (localhost [127.0.0.1]) by mail37-co9-R.bigfish.com (Postfix) with ESMTP id 71992E4042B for ; Fri, 21 Jun 2013 22:25:49 +0000 (UTC) Received: from mail37-co9 (localhost.localdomain [127.0.0.1]) by mail37-co9 (MessageSwitch) id 1371853547552092_26746; Fri, 21 Jun 2013 22:25:47 +0000 (UTC) Received: from CO9EHSMHS029.bigfish.com (unknown [10.236.132.231]) by mail37-co9.bigfish.com (Postfix) with ESMTP id 848DF680062; Fri, 21 Jun 2013 22:25:47 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS029.bigfish.com (10.236.130.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 22:25:47 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 22:25:47 +0000 From: Kent Watsen To: Joe Touch , Andy Bierman Thread-Topic: [Netconf] reverse ssh recommendation Thread-Index: AQHObqg7LGEz7Pg9q0aFwSCqa9bVYplAj6cAgAASu4CAAAWGgIAAAXuAgAAKbICAAAVxgP//wusA Date: Fri, 21 Jun 2013 22:25:46 +0000 Message-ID: In-Reply-To: <51C4CDE5.3030201@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ISI.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 22:26:01 -0000 On 6/21/13 6:04 PM, "Joe Touch" wrote: >FTP solved this years ago with the command. > >You either rewrite your legacy implementation to embed both directions, >or you rewrite your legacy implementation to listen to a 'dispatch' >service that listens on port 830. > >Since you're extending netconf, there's no reason to expect not to >rewrite or recompile legacy code to support this. But we're not extending the NETCONF protocol. There is no modification we can make to it that would affect: - which side presents its host key (4253) - which side logs into the other (4252) - which side gets to open/close subsystems (4254) That NETCONF is lunched as a SSH subsystem is inconsequential. If there is to be a change to any RFC, it would be to 4253, to enable the protocol itself to negotiate the direction. This is one of options listed on the survey (http://www.surveymonkey.com/s/MWVNT7M) Thanks, Kent From kwatsen@juniper.net Fri Jun 21 15:55:46 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE69721F9E17 for ; Fri, 21 Jun 2013 15:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWj2ufk4qms8 for ; Fri, 21 Jun 2013 15:55:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 91C3B21F9DA3 for ; Fri, 21 Jun 2013 15:55:41 -0700 (PDT) Received: from mail225-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 22:55:40 +0000 Received: from mail225-va3 (localhost [127.0.0.1]) by mail225-va3-R.bigfish.com (Postfix) with ESMTP id A849C1C013A for ; Fri, 21 Jun 2013 22:55:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail225-va3: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=kwatsen@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail225-va3 (localhost.localdomain [127.0.0.1]) by mail225-va3 (MessageSwitch) id 1371855338939696_19076; Fri, 21 Jun 2013 22:55:38 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.239]) by mail225-va3.bigfish.com (Postfix) with ESMTP id E398AB40049 for ; Fri, 21 Jun 2013 22:55:38 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.54) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 22:55:38 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 15:55:36 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 15:55:36 -0700 Received: from CO9EHSOBE033.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 16:07:33 -0700 Received: from mail135-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE033.bigfish.com (10.236.130.96) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 22:55:35 +0000 Received: from mail135-co9 (localhost [127.0.0.1]) by mail135-co9-R.bigfish.com (Postfix) with ESMTP id CBFFB5A0349 for ; Fri, 21 Jun 2013 22:55:35 +0000 (UTC) Received: from mail135-co9 (localhost.localdomain [127.0.0.1]) by mail135-co9 (MessageSwitch) id 1371855333922176_10772; Fri, 21 Jun 2013 22:55:33 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.230]) by mail135-co9.bigfish.com (Postfix) with ESMTP id D4BA9D00059; Fri, 21 Jun 2013 22:55:33 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 22:55:33 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 22:55:32 +0000 From: Kent Watsen To: Joe Touch , Andy Bierman Thread-Topic: [Netconf] reverse ssh recommendation Thread-Index: AQHObqg7LGEz7Pg9q0aFwSCqa9bVYplAj6cAgAASu4CAAAWGgIAAAXuAgAAKbICAAAVxgP//wusAgAAIUIA= Date: Fri, 21 Jun 2013 22:55:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <5ABAF1C9F5A3434AA13F9125DCF734F4@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ISI.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 22:55:47 -0000 Let me clarify, since I'm unsure if you're aware, NETCONF over SSH is implemented as an SSH server, listening on port 830, and supporting a subsystem called "netconf". If NETCONF defined the transport protocol, than I'd agree with you that a change to NETCONF is needed. But NETCONF is more like middleware, relying on other protocols to provide its transport. NETCONF's mapping to the SSH protocol (RFC 6242) is the one that defines port 830. Ideally we could make some backwards compatible change to it to give port 830 a different meaning, but we can't. As soon as a connection to 830 happens, the SSH Server protocol happens immediately, at which point it's too late to change the direction (for the reasons listed below). We need something lower level. The only options are to either modify the SSH Transport protocol itself or change the way it's started. I hope that makes more sense. Thanks, Kent On 6/21/13 6:25 PM, "Kent Watsen" wrote: > > >On 6/21/13 6:04 PM, "Joe Touch" wrote: > >>FTP solved this years ago with the command. >> >>You either rewrite your legacy implementation to embed both directions, >>or you rewrite your legacy implementation to listen to a 'dispatch' >>service that listens on port 830. >> >>Since you're extending netconf, there's no reason to expect not to >>rewrite or recompile legacy code to support this. > > >But we're not extending the NETCONF protocol. There is no modification we >can make to it that would affect: > > - which side presents its host key (4253) > - which side logs into the other (4252) > - which side gets to open/close subsystems (4254) > >That NETCONF is lunched as a SSH subsystem is inconsequential. > >If there is to be a change to any RFC, it would be to 4253, to enable the >protocol itself to negotiate the direction. This is one of options listed >on the survey (http://www.surveymonkey.com/s/MWVNT7M) > > >Thanks, >Kent > > > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From mouse@Chip.Rodents-Montreal.ORG Wed Jun 19 13:17:55 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388A921E80CC for ; Wed, 19 Jun 2013 13:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF50g++l2TDj for ; Wed, 19 Jun 2013 13:17:37 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A721E80C5 for ; Wed, 19 Jun 2013 13:17:36 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA29603; Wed, 19 Jun 2013 16:17:33 -0400 (EDT) Date: Wed, 19 Jun 2013 16:17:33 -0400 (EDT) From: Mouse Message-Id: <201306192017.QAA29603@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 19 Jun 2013 16:09:08 -0400 (EDT) To: jhutz@cmu.edu In-Reply-To: <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> References: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> X-Mailman-Approved-At: Sat, 22 Jun 2013 05:17:49 -0700 Cc: draft-ietf-netconf-reverse-ssh@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 20:17:55 -0000 [Feel free to forward to lists - or anywhere else you think fit - if you like; saag@ietf.org has decided it doesn't like me, sending broken challenges in response to my list mail now.] > There was [...] relatively little discussion of the security aspects > of running SSH "in reverse" like this. My own reaction is that I think it does less violence to ssh's security properties for the netconf client to be the ssh server, with the "netconf" subsystem being special in that its protocol recognizes that the netconf roles are reversed from the ssh roles: the ssh server is the netconf client and vice versa. If the netconf subsystem is too standardized for that already, then I'd suggest using a new subsystem name for the purpose. Note that, for these purposes, a netconf client's ssh server need not be prepared to act as a normal ssh server; it could, for example, refuse all shell and exec requests. It also need not accept connections at all from other than the netconf server. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From jhutz@cmu.edu Wed Jun 19 10:22:11 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9921F9E4C; Wed, 19 Jun 2013 10:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKsYf4aUvxbl; Wed, 19 Jun 2013 10:22:02 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 300FE21F9E46; Wed, 19 Jun 2013 10:22:01 -0700 (PDT) Received: from [192.168.202.142] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r5JHLvBo018732 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 13:21:58 -0400 (EDT) Message-ID: <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: ietfdbh Date: Wed, 19 Jun 2013 13:21:56 -0400 In-Reply-To: <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> References: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 X-Mailman-Approved-At: Sat, 22 Jun 2013 05:18:13 -0700 Cc: saag@ietf.org, draft-ietf-netconf-reverse-ssh@tools.ietf.org, netconf@ietf.org, jhutz@cmu.edu Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:22:12 -0000 On Wed, 2013-06-19 at 10:02 -0400, ietfdbh wrote: > Hi Kent, > > I think your draft needs to target two different audiences - the security > audience for SSH security considerations, and application designers that > want to use reverse-SSH, such as Netconf. This was discussed two years ago on the ietf-ssh mailing list, which is the appropriate forum for discussion of SSH extensions and protocol changes. There was much discussion about what port number things should run on, but unfortunately relatively little discussion of the security aspects of running SSH "in reverse" like this. I haven't read this recent document, but when this came up in 2011, I was concerned about the security aspects of running SSH "in reverse" like this; it's really not designed for that. I expressed concerns about the new hmac-* host key algorithms defined in that version, about the layering violations inherent in using them for negotiation, and commented that they don't really provide any operational advantage over using X.509 certificates or pre-shared RSA keys. Those comments were never really addressed. The SECSH WG concluded some time ago, but its mailing list is still somewhat active and regularly discusses SSH protocol extensions. I would be very concerned if the NETCONF WG were to send the IESG an SSH protocol document without the involvement of that group. I will note that the 2011 discussion included approaches that did not require this level of protocol change, or indeed any. I'm fine with NETCONF not having chosen one of those approaches, but this really does need to involve people with SSH expertise. -- Jeff From jhutz@cmu.edu Wed Jun 19 12:38:02 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10BA21F9B85; Wed, 19 Jun 2013 12:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS7SHbR882Fe; Wed, 19 Jun 2013 12:37:57 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1B63421F9E3C; Wed, 19 Jun 2013 12:37:55 -0700 (PDT) Received: from [192.168.202.142] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r5JJboxd023654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 15:37:51 -0400 (EDT) Message-ID: <1371670670.23088.59.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: ietfdbh Date: Wed, 19 Jun 2013 15:37:50 -0400 In-Reply-To: <0b9e01ce6d21$fcf24fd0$f6d6ef70$@comcast.net> References: <20130619080054.9246.47628.idtracker@ietfa.amsl.com> <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> <0b9e01ce6d21$fcf24fd0$f6d6ef70$@comcast.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 X-Mailman-Approved-At: Sat, 22 Jun 2013 05:18:13 -0700 Cc: saag@ietf.org, draft-ietf-netconf-reverse-ssh@tools.ietf.org, netconf@ietf.org, jhutz@cmu.edu Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 19:38:02 -0000 On Wed, 2013-06-19 at 21:19 +0200, ietfdbh wrote: > For anyone who wishes to access/subscribe to the secsh mailing list, > See http://www.ietf.org/wg/concluded/secsh.html > > Jeff, I assume that is the list you refer to?? Yes, that's the group, and ietf-ssh@netbsd.org is/was the mailing list. The IETF archives are still subscribed, last time I checked. -- Jeff From mbj@tail-f.com Sun Jun 23 22:40:23 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE92B21E80A9 for ; Sun, 23 Jun 2013 22:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zffRY-yffOVZ for ; Sun, 23 Jun 2013 22:40:15 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EF16721F9D52 for ; Sun, 23 Jun 2013 22:40:14 -0700 (PDT) Received: from localhost (109.58.94.228.bredband.tre.se [109.58.94.228]) by mail.tail-f.com (Postfix) with ESMTPSA id 953A61200043; Mon, 24 Jun 2013 07:40:12 +0200 (CEST) Date: Mon, 24 Jun 2013 07:40:11 +0200 (CEST) Message-Id: <20130624.074011.07682844.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 05:40:23 -0000 Kent Watsen wrote: > However, in order to realize implementations in the near-term, this > draft doesn't alter the SSH protocol at all, it merely bootstraps it > differently, using an IANA-assigned port. Assuming our WG agrees this > is the right strategy, can we ask the SAAG folks to not try to change > the design and just analyze the security of the existing draft? Yes, I think we need clear statements re. the security impacts of this design. Other feedback is of course also appreciated, but it would be helpful to have it separated from any security concerns. /martin From mbj@tail-f.com Sun Jun 23 22:43:57 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903DE21E8091 for ; Sun, 23 Jun 2013 22:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npWSOsncaZKy for ; Sun, 23 Jun 2013 22:43:51 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66511E8121 for ; Sun, 23 Jun 2013 22:43:51 -0700 (PDT) Received: from localhost (109.58.94.228.bredband.tre.se [109.58.94.228]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F7E71200043; Mon, 24 Jun 2013 07:43:50 +0200 (CEST) Date: Mon, 24 Jun 2013 07:43:49 +0200 (CEST) Message-Id: <20130624.074349.183781874.mbj@tail-f.com> To: mouse@Rodents-Montreal.ORG From: Martin Bjorklund In-Reply-To: <201306192017.QAA29603@Chip.Rodents-Montreal.ORG> References: <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> <201306192017.QAA29603@Chip.Rodents-Montreal.ORG> X-Mailer: Mew version 6.5rc2 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: draft-ietf-netconf-reverse-ssh@tools.ietf.org, netconf@ietf.org, jhutz@cmu.edu Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 05:43:57 -0000 Hi, Mouse wrote: > My own reaction is that I think it does less violence to ssh's > security > properties for the netconf client to be the ssh server, with the > "netconf" subsystem being special in that its protocol recognizes that > the netconf roles are reversed from the ssh roles: the ssh server is > the netconf client and vice versa. Can you elaborate on the security concerns of the design in draft-ietf-netconf-reverse-ssh? /martin From mehmet.ersue@nsn.com Mon Jun 24 04:58:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497D311E812B for ; Mon, 24 Jun 2013 04:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N58WCl8eFUId for ; Mon, 24 Jun 2013 04:58:32 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7111E8129 for ; Mon, 24 Jun 2013 04:58:31 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5OBwUiq017787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jun 2013 13:58:30 +0200 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5OBwT1Y029548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 13:58:29 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 24 Jun 2013 13:58:29 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.149]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Mon, 24 Jun 2013 13:58:29 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Martin Bjorklund , "kwatsen@juniper.net" Thread-Topic: [Netconf] reverse ssh recommendation Thread-Index: AQHOcJ1YrLbaARndxkGB886GGbqisZlEwgJg Date: Mon, 24 Jun 2013 11:58:28 +0000 Message-ID: References: <20130624.074011.07682844.mbj@tail-f.com> In-Reply-To: <20130624.074011.07682844.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1461 X-purgate-ID: 151667::1372075110-00002EAE-FC263F54/0-0/0-0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh recommendation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:58:36 -0000 > Yes, I think we need clear statements re. the security impacts of this > design. Other feedback is of course also appreciated, but it would be > helpful to have it separated from any security concerns. Yes, this would be indeed our preference. I also think that saag does not need to worry on whether a Netconf draft ne= eds a new port number. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Martin Bjorklund > Sent: Monday, June 24, 2013 7:40 AM > To: kwatsen@juniper.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] reverse ssh recommendation >=20 > Kent Watsen wrote: > > However, in order to realize implementations in the near-term, this > > draft doesn't alter the SSH protocol at all, it merely bootstraps it > > differently, using an IANA-assigned port. Assuming our WG agrees this > > is the right strategy, can we ask the SAAG folks to not try to change > > the design and just analyze the security of the existing draft? >=20 > Yes, I think we need clear statements re. the security impacts of this > design. Other feedback is of course also appreciated, but it would be > helpful to have it separated from any security concerns. >=20 >=20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From jhutz@cmu.edu Mon Jun 24 08:40:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B2511E814C for ; Mon, 24 Jun 2013 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+dm7po93hhc for ; Mon, 24 Jun 2013 08:40:49 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0684E21E8104 for ; Mon, 24 Jun 2013 08:40:44 -0700 (PDT) Received: from [192.168.202.142] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r5OFefJ0018362 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 11:40:42 -0400 (EDT) Message-ID: <1372088440.7516.119.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Mouse Date: Mon, 24 Jun 2013 11:40:40 -0400 In-Reply-To: <201306241441.KAA12625@Chip.Rodents-Montreal.ORG> References: <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> <201306192017.QAA29603@Chip.Rodents-Montreal.ORG> <20130624.074349.183781874.mbj@tail-f.com> <201306241441.KAA12625@Chip.Rodents-Montreal.ORG> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: draft-ietf-netconf-reverse-ssh@tools.ietf.org, netconf@ietf.org, jhutz@cmu.edu Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:40:56 -0000 On Mon, 2013-06-24 at 10:41 -0400, Mouse wrote: > My major point is that the initial claim > > > 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". > > is wrong. (Well, technically it's not wrong as worded, but it assumes > something which does strike me as wrong: it assumes that the NETCONF > client must be the one to initiate the subsystem open.) That's what I > was addressing in writing that it seems to me, from an ssh perspective, > to be better to keep the ssh protocol as defined and let the netconf > subsystem's protocol understand that the netconf server is the ssh > client and vice versa. I'm trying to stay out of this discussion for now, but I think you're somehow missing a rather large and important point. This isn't modifying SSH to be used this way all the time by this new netconf thing they're designing. Netconf already exists and already runs over SSH. The present work is about enabling the "call home" case, where the device being managed connects to the user doing the managing, rather than the other way around. Back in 2006, the ISMS working group considered a "reverse SSH" approach similar in concept to what is being discussed today. We ended up deciding against it, in part because of the security implications of a protocol that is basically a device opening a connection and saying "Hi, I am a server, please tell me your password". > While only tengentially related, I also note > > o The managed device may be deployed behind a firewall that doesn't > allow SSH access to the internal network. > > If you are behind a firewall that doesn't allow ssh access, you should > not be subverting that firewall by arranging to allow ssh access. If > the network administrator doesn't want you to do something, you should > not be doing it, even if you can manage to end-run around the > implementation of that intent. While it's possible the restrictions do > not actually express the admin's intent, it is not the device's place > to make that decision. No, we're generally talking about _managed network devices_. They're likely being deployed by the same person who set up the firewall. And the firewall rule is likely not "SSH is evil, no one should be allowed to use SSH"; its probably "I don't want the entire Internet banging on the SSH servers on my users' machines". Using a reverse connection allows the connection to be set up as an outgoing connection made by the managed device to a known management system. That's a much smaller exposure than allowing incoming connections, even from a narrow set of sources, and it aligns with the end-to-end principle by putting the knowledge of where the trusted management system is in the managed endpoint instead of in some "smart" device in the middle of the network. -- Jeff From touch@isi.edu Mon Jun 24 09:44:03 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1121E812F for ; Mon, 24 Jun 2013 09:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.023 X-Spam-Level: X-Spam-Status: No, score=-105.023 tagged_above=-999 required=5 tests=[AWL=1.576, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxYNIia9Suh1 for ; Mon, 24 Jun 2013 09:43:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B3B4E21E812D for ; Mon, 24 Jun 2013 09:43:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5OGhNZL001228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jun 2013 09:43:23 -0700 (PDT) Message-ID: <51C87714.8050907@isi.edu> Date: Mon, 24 Jun 2013 09:43:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <25492_1371654090_r5JF1SHh022730_011901ce6cf5$9e7b4870$db71d950$@comcast.net> <1371662516.23088.44.camel@destiny.pc.cs.cmu.edu> <201306192017.QAA29603@Chip.Rodents-Montreal.ORG> <20130624.074349.183781874.mbj@tail-f.com> <201306241441.KAA12625@Chip.Rodents-Montreal.ORG> <1372088440.7516.119.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1372088440.7516.119.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-netconf-reverse-ssh@tools.ietf.org, Mouse , netconf@ietf.org Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:44:03 -0000 +1. The primary reason for including SAAG in this was because they had already considered a similar directionality issue with SSH, not specifically because this service was asking for a new port. IMO, the port considerations for SSH in general apply to NetConf over SSH as well. Joe On 6/24/2013 8:40 AM, Jeffrey Hutzelman wrote: > On Mon, 2013-06-24 at 10:41 -0400, Mouse wrote: > >> My major point is that the initial claim >> >>> 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". >> >> is wrong. (Well, technically it's not wrong as worded, but it assumes >> something which does strike me as wrong: it assumes that the NETCONF >> client must be the one to initiate the subsystem open.) That's what I >> was addressing in writing that it seems to me, from an ssh perspective, >> to be better to keep the ssh protocol as defined and let the netconf >> subsystem's protocol understand that the netconf server is the ssh >> client and vice versa. > > I'm trying to stay out of this discussion for now, but I think you're > somehow missing a rather large and important point. > > This isn't modifying SSH to be used this way all the time by this new > netconf thing they're designing. Netconf already exists and already > runs over SSH. The present work is about enabling the "call home" case, > where the device being managed connects to the user doing the managing, > rather than the other way around. > > Back in 2006, the ISMS working group considered a "reverse SSH" approach > similar in concept to what is being discussed today. We ended up > deciding against it, in part because of the security implications of a > protocol that is basically a device opening a connection and saying "Hi, > I am a server, please tell me your password". > > > > >> While only tengentially related, I also note >> >> o The managed device may be deployed behind a firewall that doesn't >> allow SSH access to the internal network. >> >> If you are behind a firewall that doesn't allow ssh access, you should >> not be subverting that firewall by arranging to allow ssh access. If >> the network administrator doesn't want you to do something, you should >> not be doing it, even if you can manage to end-run around the >> implementation of that intent. While it's possible the restrictions do >> not actually express the admin's intent, it is not the device's place >> to make that decision. > > No, we're generally talking about _managed network devices_. They're > likely being deployed by the same person who set up the firewall. And > the firewall rule is likely not "SSH is evil, no one should be allowed > to use SSH"; its probably "I don't want the entire Internet banging on > the SSH servers on my users' machines". Using a reverse connection > allows the connection to be set up as an outgoing connection made by the > managed device to a known management system. That's a much smaller > exposure than allowing incoming connections, even from a narrow set of > sources, and it aligns with the end-to-end principle by putting the > knowledge of where the trusted management system is in the managed > endpoint instead of in some "smart" device in the middle of the network. > > -- Jeff > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From kwatsen@juniper.net Mon Jun 24 12:56:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D051821F9BF0 for ; Mon, 24 Jun 2013 12:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-1.577, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGfnQ3+P+3dW for ; Mon, 24 Jun 2013 12:56:20 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id C76C621E80EF for ; Mon, 24 Jun 2013 12:56:19 -0700 (PDT) Received: from mail173-db9-R.bigfish.com (10.174.16.235) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 19:56:18 +0000 Received: from mail173-db9 (localhost [127.0.0.1]) by mail173-db9-R.bigfish.com (Postfix) with ESMTP id A560680089 for ; Mon, 24 Jun 2013 19:56:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371Id772h4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail173-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=kwatsen@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail173-db9 (localhost.localdomain [127.0.0.1]) by mail173-db9 (MessageSwitch) id 1372103776148346_32441; Mon, 24 Jun 2013 19:56:16 +0000 (UTC) Received: from DB9EHSMHS017.bigfish.com (unknown [10.174.16.250]) by mail173-db9.bigfish.com (Postfix) with ESMTP id 1EDF6460031 for ; Mon, 24 Jun 2013 19:56:16 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by DB9EHSMHS017.bigfish.com (10.174.14.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 19:56:16 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 12:55:52 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 12:55:51 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 12:59:10 -0700 Received: from mail119-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 19:55:51 +0000 Received: from mail119-tx2 (localhost [127.0.0.1]) by mail119-tx2-R.bigfish.com (Postfix) with ESMTP id 03AC83600D4 for ; Mon, 24 Jun 2013 19:55:51 +0000 (UTC) Received: from mail119-tx2 (localhost.localdomain [127.0.0.1]) by mail119-tx2 (MessageSwitch) id 1372103749420094_3838; Mon, 24 Jun 2013 19:55:49 +0000 (UTC) Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.238]) by mail119-tx2.bigfish.com (Postfix) with ESMTP id 6268240BE0; Mon, 24 Jun 2013 19:55:49 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 19:55:49 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 19:55:48 +0000 From: Kent Watsen To: Jeffrey Hutzelman , Mouse Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHOcRTSVLNZ5bG3CkeqP19tE7+OCQ== Date: Mon, 24 Jun 2013 19:55:47 +0000 Message-ID: In-Reply-To: <1372088440.7516.119.camel@destiny.pc.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RODENTS-MONTREAL.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:56:26 -0000 On 6/24/13 11:40 AM, "Jeffrey Hutzelman" wrote: >Back in 2006, the ISMS working group considered a "reverse SSH" approach >similar in concept to what is being discussed today. We ended up >deciding against it, in part because of the security implications of a >protocol that is basically a device opening a connection and saying "Hi, >I am a server, please tell me your password". ...after verifying the devices host key - we certainly wouldn't expect the client to try logging into any server. Further, we recommend the host-key be a certificate containing the server's identity, though When it was looked at before, did anyone find an attack? - I can't think of one that doesn't involve spoofing the device's private key, but all bets are off already in that case Thanks, Kent From ietfc@btconnect.com Tue Jun 25 07:46:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D66A21F9E39 for ; Tue, 25 Jun 2013 07:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.666 X-Spam-Level: X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=1.933, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVtvcMKM0vWG for ; Tue, 25 Jun 2013 07:46:29 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4421F9D7F for ; Tue, 25 Jun 2013 07:46:29 -0700 (PDT) Received: from mail198-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 14:46:28 +0000 Received: from mail198-co9 (localhost [127.0.0.1]) by mail198-co9-R.bigfish.com (Postfix) with ESMTP id 7C7FBC4015F; Tue, 25 Jun 2013 14:46:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371Id772h542I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1033IL8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail198-co9 (localhost.localdomain [127.0.0.1]) by mail198-co9 (MessageSwitch) id 1372171504147174_23315; Tue, 25 Jun 2013 14:45:04 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.246]) by mail198-co9.bigfish.com (Postfix) with ESMTP id 210DB64011D; Tue, 25 Jun 2013 14:45:04 +0000 (UTC) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 14:45:02 +0000 Received: from DB3PRD0411HT001.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 25 Jun 2013 14:44:49 +0000 Message-ID: <001d01ce71b2$9e9b0540$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Jeffrey Hutzelman References: Date: Tue, 25 Jun 2013 15:44:21 +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.53] X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:46:36 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Jeffrey Hutzelman" ; "Mouse" Cc: ; Sent: Monday, June 24, 2013 8:55 PM > > On 6/24/13 11:40 AM, "Jeffrey Hutzelman" wrote: > >Back in 2006, the ISMS working group considered a "reverse SSH" approach > >similar in concept to what is being discussed today. We ended up > >deciding against it, in part because of the security implications of a > >protocol that is basically a device opening a connection and saying "Hi, > >I am a server, please tell me your password". > > ...after verifying the devices host key - we certainly wouldn't expect the > client to try logging into any server. Further, we recommend the host-key > be a certificate containing the server's identity, though > > When it was looked at before, did anyone find an attack? - I can't think > of one that doesn't involve spoofing the device's private key, but all > bets are off already in that case It seems to me that call home needs a Signal, like an answerphone message (Please Call) and that that signal can be any PDU over any protocol but must specify the protocols to be used for the call - Netconf over SSH, SNMP over TLS, etc. Here the signal seems to be a 3-way handshake, in which case the destination port would have to differentiate between the protocol combinations and so this cannot be a generic mechanism. The security consideration that then comes first to me is a DoS attack via the 3-way handshake, nothing to do with SAAG but rather TCPM territory. It would seem from the I-D that whether the TCP connection is reused, or whether the Netconf client fires up a fresh connection is unspecified; I would assume the latter, to the regular port on the Netconf server. Tom Petch > Thanks, > Kent > From kwatsen@juniper.net Tue Jun 25 14:54:49 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC6721E80E3 for ; Tue, 25 Jun 2013 14:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m40ZULT+5GyR for ; Tue, 25 Jun 2013 14:54:32 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8124D21E80E0 for ; Tue, 25 Jun 2013 14:54:30 -0700 (PDT) Received: from mail142-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 21:54:28 +0000 Received: from mail142-tx2 (localhost [127.0.0.1]) by mail142-tx2-R.bigfish.com (Postfix) with ESMTP id 4E3242400B2 for ; Tue, 25 Jun 2013 21:54:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -10 X-BigFish: VPS-10(zzbb2dI98dI9371I936eI146fId772h1432I1418I111aI11fbIfb6Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah8275bhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail142-tx2: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=kwatsen@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail142-tx2 (localhost.localdomain [127.0.0.1]) by mail142-tx2 (MessageSwitch) id 1372197265621290_18158; Tue, 25 Jun 2013 21:54:25 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.244]) by mail142-tx2.bigfish.com (Postfix) with ESMTP id 8A4D9440050 for ; Tue, 25 Jun 2013 21:54:25 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.51) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 21:54:25 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 25 Jun 2013 14:54:24 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 25 Jun 2013 14:54:23 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.248) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 25 Jun 2013 15:06:15 -0700 Received: from mail172-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 21:54:19 +0000 Received: from mail172-db9 (localhost [127.0.0.1]) by mail172-db9-R.bigfish.com (Postfix) with ESMTP id DD64F6014E for ; Tue, 25 Jun 2013 21:54:19 +0000 (UTC) Received: from mail172-db9 (localhost.localdomain [127.0.0.1]) by mail172-db9 (MessageSwitch) id 1372197256802996_25791; Tue, 25 Jun 2013 21:54:16 +0000 (UTC) Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.241]) by mail172-db9.bigfish.com (Postfix) with ESMTP id BD665100041; Tue, 25 Jun 2013 21:54:16 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Jun 2013 21:54:14 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0324.000; Tue, 25 Jun 2013 21:54:08 +0000 From: Kent Watsen To: Jeffrey Hutzelman , Mouse Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHOcRTSVLNZ5bG3CkeqP19tE7+OCZlFWhKAgAFdvAA= Date: Tue, 25 Jun 2013 21:54:08 +0000 Message-ID: In-Reply-To: <1372107741.17600.25.camel@minbar.fac.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <91B0B4765083E3419E7EDB7EBB6654F6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RODENTS-MONTREAL.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 21:54:49 -0000 [Jeff accidentally didn't send his response to the list, so it's in full below] On 6/24/13 5:02 PM, "Jeffrey Hutzelman" wrote: >On Mon, 2013-06-24 at 19:55 +0000, Kent Watsen wrote: >>=20 >> On 6/24/13 11:40 AM, "Jeffrey Hutzelman" wrote: >> >Back in 2006, the ISMS working group considered a "reverse SSH" >>approach >> >similar in concept to what is being discussed today. We ended up >> >deciding against it, in part because of the security implications of a >> >protocol that is basically a device opening a connection and saying >>"Hi, >> >I am a server, please tell me your password". >>=20 >> ...after verifying the devices host key - we certainly wouldn't expect >>the >> client to try logging into any server. Further, we recommend the >>host-key >> be a certificate containing the server's identity, though > >... against what? >ssh clients know a priori what host they're going to connect to, and >thus know which keys are valid (or what name to use, depending on the >keyex method in use). I'm assuming you mean the first-time connection, since every time thereafter the host-key accepted before can be used for the lookup and verification. For first-time connection, Network Management apps can be preconfigured to know which IP addresses or FQDNs they're expecting. They may even let the end-user input the device's host-key manually. If using certificates, we especially like the idea of putting the device's serial-number into the Common Name field, and assume the app is preconfigured to know which serial numbers to expect (as well as the CA's cert) >> When it was looked at before, did anyone find an attack? > >That is the wrong question. When we looked at it before, people with a >strong understanding of how SSH works, myself included, did not manage >to convince themselves it was safe. Further, we discovered a number of >issues such as the host naming problem described above, which made that >sort of "reverse SSH" impractical, and some of which would likely apply >to netconf as well. It's not wrong, per se, as a single attack would prove insecurity; though I'll grant you that it doesn't prove security either. I was hoping that we could construct a proof now. I think that it would be fine even if the solution only supported certificate-oriented host-keys - this case should be easier to prove secure as no reference to the TCP-layer is needed, and therefore its directionality inconsequential - yes? For what it's worth, I FIPS-certified a similar strategy a few years back - a device-initiated transport with a certificate proving identity and providing a trust root. It was fairly rigorous given the EAL level we were going for. I'll grant you that this isn't a proof either, but it seemed good enough for the DoD... >Instead, we went with a model in which a device >"calling home" is the SSH client. Such a device may need to be >provisioned with credentials, but this is generally true anyway, and >usually the sorts of credentials that would be required to operate as an >SSH server can also be used to operate as a client. I see. I just read RFC 5592, the last paragraph of section 8 (Operational Considerations) is relevant. It basically says the device initiates the ssh connection when needing to push traps. The makes perfect sense, of course. I take it that you didn't need to manage devices (set/get) behind firewalls and thus the applications could always initiate connections to the devices? We started supporting device-initiated connections primarily to support devices behind firewalls. I get the impression that others have this need as well. >In the case of SNMP, the layers of the protocol just above SSH are >fairly symmetric, so once the connection is established, the subsystem >can be started by the SSH client, and then communication can run in >either direction. This will likely be somewhat different for netconf, >but should still be mostly doable. You may end up needing to use a >different subsystem in the case where the SSH client is the managed >device, if the next layer is not sufficiently symmetric. You're right about NETCONF being fairly symmetric, but we really want the applications to the able to open the SSH channels, since they know how many channels want and when they want them. For instance, an application may open one SSH channel for NETCONF, another to receive SNMP traps via ISMS another for `sftp`, and another to tunnel a CLI console shell. Notice that the sftp/cli uses would be user/demand-driven - i.e. the device wouldn't know a priori that channels for those would be needed. You're also right that the auth could be flipped. That is, the device could be configured with the app's host-key, and the app could be preconfigured to trust a CA (assuming x509 client auth). But if we go this route then, somehow, between the Auth Protocol (4252) and Connection Protocol (4254), we'd need to reverse the Connection Protocol to enable to "server" to open subsystems on the "client". This falls into the "I want the device to be the SSH client (standard SSH)" question on the virtual-hum survey[1], for which currently there is 0% support for...likely because it's not immediately implementable, but that's just my guess, it could also be because folks like idea of being able to preserve all their key-distibution infrastructure... [1] http://www.surveymonkey.com/s/MWVNT7M Thanks again, Kent From kwatsen@juniper.net Tue Jun 25 15:07:29 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F31A11E814D for ; Tue, 25 Jun 2013 15:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvaLLHzENWHP for ; Tue, 25 Jun 2013 15:07:22 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id E5E6111E8165 for ; Tue, 25 Jun 2013 15:07:18 -0700 (PDT) Received: from mail131-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE013.bigfish.com (10.236.130.76) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 22:07:18 +0000 Received: from mail131-co9 (localhost [127.0.0.1]) by mail131-co9-R.bigfish.com (Postfix) with ESMTP id 500863C014C for ; Tue, 25 Jun 2013 22:07:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: PS-5(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275bhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail131-co9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=kwatsen@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail131-co9 (localhost.localdomain [127.0.0.1]) by mail131-co9 (MessageSwitch) id 1372198036489646_15587; Tue, 25 Jun 2013 22:07:16 +0000 (UTC) Received: from CO9EHSMHS019.bigfish.com (unknown [10.236.132.236]) by mail131-co9.bigfish.com (Postfix) with ESMTP id 7456034005F for ; Tue, 25 Jun 2013 22:07:16 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.54) by CO9EHSMHS019.bigfish.com (10.236.130.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 22:07:12 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 25 Jun 2013 15:07:11 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 25 Jun 2013 15:07:11 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.253) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 25 Jun 2013 15:11:28 -0700 Received: from mail39-db9-R.bigfish.com (10.174.16.231) by DB9EHSOBE020.bigfish.com (10.174.14.83) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 22:07:09 +0000 Received: from mail39-db9 (localhost [127.0.0.1]) by mail39-db9-R.bigfish.com (Postfix) with ESMTP id 46A91200EA for ; Tue, 25 Jun 2013 22:07:09 +0000 (UTC) Received: from mail39-db9 (localhost.localdomain [127.0.0.1]) by mail39-db9 (MessageSwitch) id 1372198027135943_25138; Tue, 25 Jun 2013 22:07:07 +0000 (UTC) Received: from DB9EHSMHS025.bigfish.com (unknown [10.174.16.235]) by mail39-db9.bigfish.com (Postfix) with ESMTP id 12BD2C00049; Tue, 25 Jun 2013 22:07:07 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by DB9EHSMHS025.bigfish.com (10.174.14.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Jun 2013 22:07:06 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0324.000; Tue, 25 Jun 2013 22:06:59 +0000 From: Kent Watsen To: t.petch , Jeffrey Hutzelman Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHOcRTSVLNZ5bG3CkeqP19tE7+OCZlGg4QogAA34AA= Date: Tue, 25 Jun 2013 22:06:58 +0000 Message-ID: In-Reply-To: <001d01ce71b2$9e9b0540$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.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <520A1DCFB167514E8947DC97CF3435FD@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BTCONNECT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 22:07:29 -0000 On 6/25/13 10:44 AM, "t.petch" wrote: >It seems to me that call home needs a Signal, like an answerphone >message (Please Call) and that that signal can be any PDU over any >protocol but must specify the protocols to be used for the call - >Netconf over SSH, SNMP over TLS, etc. > >Here the signal seems to be a 3-way handshake, in which case the >destination port would have to differentiate between the protocol >combinations and so this cannot be a generic mechanism. The security >consideration that then comes first to me is a DoS attack via the 3-way >handshake, nothing to do with SAAG but rather TCPM territory. I'm not following your analogy, but I agree that there is a DoS attack, as there is with any open TCP port, perhaps worse because it can start expensive asymmetric key algs. Of course, many people I know claim that they'd rather see the app get DoS-ed over the device, since it can more easily overcome such an event. >It would seem from the I-D that whether the TCP connection is reused, or >whether the Netconf client fires up a fresh connection is unspecified; I >would assume the latter, to the regular port on the Netconf server. We (Juniper) have also explored this - using SNMP Traps actually. It works fairly well for automating the discovery of devices with static IPs on a reachable network, but not at all when the devices are behind a firewall that won't allow inbound SSH connections. Thanks, Kent From ietfc@btconnect.com Wed Jun 26 02:48:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEFE21E8126 for ; Wed, 26 Jun 2013 02:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UWaEYnuO1Lk for ; Wed, 26 Jun 2013 02:48:50 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 024C711E81A6 for ; Wed, 26 Jun 2013 02:48:43 -0700 (PDT) Received: from mail121-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 09:48:42 +0000 Received: from mail121-co1 (localhost [127.0.0.1]) by mail121-co1-R.bigfish.com (Postfix) with ESMTP id 84D597C00A5; Wed, 26 Jun 2013 09:48:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail121-co1 (localhost.localdomain [127.0.0.1]) by mail121-co1 (MessageSwitch) id 1372240120244991_8209; Wed, 26 Jun 2013 09:48:40 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.231]) by mail121-co1.bigfish.com (Postfix) with ESMTP id 2EE7AA40055; Wed, 26 Jun 2013 09:48:40 +0000 (UTC) Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 09:48:40 +0000 Received: from DBXPRD0411HT001.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.324.0; Wed, 26 Jun 2013 09:48:33 +0000 Message-ID: <022c01ce7252$65dead60$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Jeffrey Hutzelman References: Date: Wed, 26 Jun 2013 10:44:05 +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.165] X-OriginatorOrg: btconnect.com Cc: ietf-ssh@NetBSD.org, netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 09:48:56 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Jeffrey Hutzelman" Cc: Sent: Tuesday, June 25, 2013 11:06 PM On 6/25/13 10:44 AM, "t.petch" wrote: >It seems to me that call home needs a Signal, like an answerphone >message (Please Call) and that that signal can be any PDU over any >protocol but must specify the protocols to be used for the call - >Netconf over SSH, SNMP over TLS, etc. > >Here the signal seems to be a 3-way handshake, in which case the >destination port would have to differentiate between the protocol >combinations and so this cannot be a generic mechanism. The security >consideration that then comes first to me is a DoS attack via the 3-way >handshake, nothing to do with SAAG but rather TCPM territory. I'm not following your analogy, but I agree that there is a DoS attack, as there is with any open TCP port, perhaps worse because it can start expensive asymmetric key algs. Of course, many people I know claim that they'd rather see the app get DoS-ed over the device, since it can more easily overcome such an event. >It would seem from the I-D that whether the TCP connection is reused, or >whether the Netconf client fires up a fresh connection is unspecified; I >would assume the latter, to the regular port on the Netconf server. We (Juniper) have also explored this - using SNMP Traps actually. It works fairly well for automating the discovery of devices with static IPs on a reachable network, but not at all when the devices are behind a firewall that won't allow inbound SSH connections. I am really confused. If the device/netconf server will not allow inbound SSH connections, then I cannot see how your I-D can work. It has the device setting up a TCP connection on a port which signals to the Netconf client/NMS to make an SSH connection to the Netconf server/device - which cannot succeed because the devices are behind a firewall which won't allow inbound SSH connections. So as I understand the design it cannot meet what I understand to be the requirements. Tom Petch Thanks, Kent From mbj@tail-f.com Wed Jun 26 03:09:00 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16D21E80D7 for ; Wed, 26 Jun 2013 03:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+m7jXGtHAkr for ; Wed, 26 Jun 2013 03:08:54 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7951021E80B9 for ; Wed, 26 Jun 2013 03:08:54 -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 8E3771200D00; Wed, 26 Jun 2013 12:08:52 +0200 (CEST) Date: Wed, 26 Jun 2013 12:08:52 +0200 (CEST) Message-Id: <20130626.120852.1934986189444174338.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <022c01ce7252$65dead60$4001a8c0@gateway.2wire.net> References: <022c01ce7252$65dead60$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ietf-ssh@NetBSD.org, netconf@ietf.org, jhutz@cmu.edu Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:09:00 -0000 Hi, t.petch wrote: > I am really confused. If the device/netconf server will not allow > inbound SSH connections, then I cannot see how your I-D can work. It > has the device setting up a TCP connection on a port which signals to > the Netconf client/NMS to make an SSH connection to the Netconf > server/device No, the device sets up the TCP connection, and then the SSH protocol is run on this connection. o The NETCONF client accepts an incoming TCP connection and immediately starts the SSH client protocol. This can probably be made more clear in the text... /martin From ietfc@btconnect.com Wed Jun 26 06:08:53 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE9211E81CD for ; Wed, 26 Jun 2013 06:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybi6IIs2L2Eg for ; Wed, 26 Jun 2013 06:08:47 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD811E81BB for ; Wed, 26 Jun 2013 06:08:46 -0700 (PDT) Received: from mail34-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 13:08:46 +0000 Received: from mail34-va3 (localhost [127.0.0.1]) by mail34-va3-R.bigfish.com (Postfix) with ESMTP id 39EC32A0122; Wed, 26 Jun 2013 13:08:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail34-va3 (localhost.localdomain [127.0.0.1]) by mail34-va3 (MessageSwitch) id 1372252124584119_4487; Wed, 26 Jun 2013 13:08:44 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.238]) by mail34-va3.bigfish.com (Postfix) with ESMTP id 89C871E0063; Wed, 26 Jun 2013 13:08:44 +0000 (UTC) Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 13:08:36 +0000 Received: from DBXPRD0411HT005.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.324.0; Wed, 26 Jun 2013 13:08:34 +0000 Message-ID: <02bd01ce726e$56c45700$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <022c01ce7252$65dead60$4001a8c0@gateway.2wire.net> <20130626.120852.1934986189444174338.mbj@tail-f.com> Date: Wed, 26 Jun 2013 14:09:00 +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.165] X-OriginatorOrg: btconnect.com Cc: ietf-ssh@NetBSD.org, netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:08:53 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; ; Sent: Wednesday, June 26, 2013 11:08 AM > t.petch wrote: > > I am really confused. If the device/netconf server will not allow > > inbound SSH connections, then I cannot see how your I-D can work. It > > has the device setting up a TCP connection on a port which signals to > > the Netconf client/NMS to make an SSH connection to the Netconf > > server/device > > No, the device sets up the TCP connection, and then the SSH protocol > is run on this connection. > > o The NETCONF client accepts an incoming TCP connection and > immediately starts the SSH client protocol. > > This can probably be made more clear in the text... Martin Yes! That is exactly what I said. But what I also said is that Kent says " It works fairly well for automating the discovery of devices with static IPs on a reachable network, but not at all when the devices are behind a firewall that won't allow inbound SSH connections." Works not at all .. when the devices are behind a firewall. So if devices behind a firewall is a requirement, then the design fails to meet it. If that is not a requirement, why has Kent raised it (and it has been raised before)? This should confuse everyone (not just me:-) Tom Petch > > > /martin > From kwatsen@juniper.net Wed Jun 26 09:38:32 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCEF11E80EC for ; Wed, 26 Jun 2013 09:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO+AXLTEnez6 for ; Wed, 26 Jun 2013 09:38:26 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 14DB721F9F77 for ; Wed, 26 Jun 2013 09:38:25 -0700 (PDT) Received: from mail86-tx2-R.bigfish.com (10.9.14.225) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 16:38:25 +0000 Received: from mail86-tx2 (localhost [127.0.0.1]) by mail86-tx2-R.bigfish.com (Postfix) with ESMTP id 033712E0144 for ; Wed, 26 Jun 2013 16:38:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275bhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail86-tx2: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=kwatsen@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail86-tx2 (localhost.localdomain [127.0.0.1]) by mail86-tx2 (MessageSwitch) id 1372264703568662_22935; Wed, 26 Jun 2013 16:38:23 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.240]) by mail86-tx2.bigfish.com (Postfix) with ESMTP id 86691120048 for ; Wed, 26 Jun 2013 16:38:23 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.54) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 16:38:19 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Jun 2013 09:38:18 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 26 Jun 2013 09:38:17 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 26 Jun 2013 09:50:11 -0700 Received: from mail4-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 16:38:17 +0000 Received: from mail4-ch1 (localhost [127.0.0.1]) by mail4-ch1-R.bigfish.com (Postfix) with ESMTP id 5BCA04E010F for ; Wed, 26 Jun 2013 16:38:17 +0000 (UTC) Received: from mail4-ch1 (localhost.localdomain [127.0.0.1]) by mail4-ch1 (MessageSwitch) id 1372264695732506_29144; Wed, 26 Jun 2013 16:38:15 +0000 (UTC) Received: from CH1EHSMHS036.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail4-ch1.bigfish.com (Postfix) with ESMTP id A5FF5A084C; Wed, 26 Jun 2013 16:38:15 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS036.bigfish.com (10.43.69.245) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 16:38:14 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0324.000; Wed, 26 Jun 2013 16:38:13 +0000 From: Kent Watsen To: t.petch , Martin Bjorklund Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHOcRTSVLNZ5bG3CkeqP19tE7+OCZlGg4QogAA34ACAAQdCEYAABYEAgAAyU13///dpAA== Date: Wed, 26 Jun 2013 16:38:13 +0000 Message-ID: In-Reply-To: <02bd01ce726e$56c45700$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.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BTCONNECT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TAIL-F.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NETBSD.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ietf-ssh@NetBSD.org" , "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 16:38:33 -0000 On 6/26/13 9:09 AM, "t.petch" wrote: > >Yes! That is exactly what I said. But what I also said is that Kent >says >" It works fairly well for automating the discovery of devices with >static IPs >on a reachable network, but not at all when the devices are behind a >firewall that won't allow inbound SSH connections." > >Works not at all .. when the devices are behind a firewall. > >So if devices behind a firewall is a requirement, then the design fails >to meet it. > >If that is not a requirement, why has Kent raised it (and it has been >raised before)? > >This should confuse everyone (not just me:-) Hi Tom, By saying a firewall wouldn't allow inbound SSH connections, let's simplify and assume the firewall doesn't allow any inbound TCP connections, but outbound TCP-connections are fine. The proposed solution is to repurpose the TCP connection initiated from behind the firewall. Once the network management application accepts the TCP connection, it can pass the accepted TCP socket into its SSH client of choice (e.g. a SSH library like J2SSH or even using OpenSSH's "ControlPath" parameter). On the "device" side, the accepted TCP connection can be passed into an SSH server - for instance using `sshd -i` exactly like `inetd` would do when listening on port 22. Does it make sense now? [Martin is right that this section of the draft could be clearer] Thanks, Kent From andy@yumaworks.com Wed Jun 26 10:14:00 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728B111E80F5 for ; Wed, 26 Jun 2013 10:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0nVSO+oLa1b for ; Wed, 26 Jun 2013 10:13:59 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D075611E8104 for ; Wed, 26 Jun 2013 10:13:59 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so14375688pad.5 for ; Wed, 26 Jun 2013 10:13:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vPb4lrjSIrVgoEixH5cIZAcxtpaqE6qYb2X3FeOj0Tg=; b=JK66ClwcSAD1VSiIlz3bUfSytLsJNHYVhMizzo57WdwADh3Wu2smhehZ3jjwAWjHqW k8fiXrFcbyJnfMTYRs/gkZPXSiY7n4YC3NUQ9LB4gT7xzfe8emSTbennYXNJHWnWMmhr PEo/c1yVkMYX822Kh3+787cKqg74nkXb67wGhlZRPs6G7DPMyBilOVekLdgZ7/8gVa5w ibgCoEf6W1HFBtU/pm/jEtjapl1dTM4bIioggMHIGEHXd3IIYgR6sH5x4zrqCGjV20cW 0DXnWpLhw36rymC6xvjSRqW3lE6dpAU3RzGhxFY8tBPfC+xWYzd6JAwYlIEdycsXsOml rp7Q== MIME-Version: 1.0 X-Received: by 10.68.111.228 with SMTP id il4mr1693507pbb.134.1372266839561; Wed, 26 Jun 2013 10:13:59 -0700 (PDT) Received: by 10.70.48.233 with HTTP; Wed, 26 Jun 2013 10:13:59 -0700 (PDT) In-Reply-To: References: <02bd01ce726e$56c45700$4001a8c0@gateway.2wire.net> Date: Wed, 26 Jun 2013 10:13:59 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=047d7b67201a8268d804e011c56b X-Gm-Message-State: ALoCoQkYnx312jbGwiCh//gDNRmUXX37TXBxWN6Px8pWUh7ae0Bp9vEQfUGwfl0KxBhEVKDWl/Xy Cc: "ietf-ssh@NetBSD.org" , "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:14:00 -0000 --047d7b67201a8268d804e011c56b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 26, 2013 at 9:38 AM, Kent Watsen wrote: > > > On 6/26/13 9:09 AM, "t.petch" wrote: > > > > >Yes! That is exactly what I said. But what I also said is that Kent > >says > >" It works fairly well for automating the discovery of devices with > >static IPs > >on a reachable network, but not at all when the devices are behind a > >firewall that won't allow inbound SSH connections." > > > >Works not at all .. when the devices are behind a firewall. > > > >So if devices behind a firewall is a requirement, then the design fails > >to meet it. > > > >If that is not a requirement, why has Kent raised it (and it has been > >raised before)? > > > >This should confuse everyone (not just me:-) > > > Hi Tom, > > By saying a firewall wouldn't allow inbound SSH connections, let's > simplify and assume the firewall doesn't allow any inbound TCP > connections, but outbound TCP-connections are fine. > > The proposed solution is to repurpose the TCP connection initiated from > behind the firewall. Once the network management application accepts the > TCP connection, it can pass the accepted TCP socket into its SSH client of > choice (e.g. a SSH library like J2SSH or even using OpenSSH's > "ControlPath" parameter). On the "device" side, the accepted TCP > connection can be passed into an SSH server - for instance using `sshd -i` > exactly like `inetd` would do when listening on port 22. > > Does it make sense now? [Martin is right that this section of the draft > could be clearer] > > There are valid use-cases (e.g, SOHO) for wanting a manageable device to connect to its manager from behind a firewall. IMO it's up to the Security Area to figure out how to do that, not NETCONF, but as long as the proper reviewers are found, that is not too important. Does the client have to be pre-configured with all the keys of the servers it will accept these connections from in advance? How does the client decide to start an SSH session on the open connection or just drop it? Thanks, > Kent > > Andy --047d7b67201a8268d804e011c56b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 26, 2013 at 9:38 AM, Kent Wa= tsen <kwatsen@juniper.net> wrote:


On 6/26/13 9:09 AM, "t.petch" <ietfc@btconnect.com> wrote:

>
>Yes! =A0That is exactly what I said. =A0But what I also said is that Ke= nt
>says
>" It works fairly well for automating the discovery of devices wit= h
>static IPs
>on a reachable network, but not at all when the devices are behind a >firewall that won't allow inbound SSH connections."
>
>Works not at all .. =A0when the devices are behind a firewall.
>
>So if devices behind a firewall is a requirement, then the design fails=
>to meet it.
>
>If that is not a requirement, why has Kent raised it (and it has been >raised before)?
>
>This should confuse everyone (not just me:-)


Hi Tom,

By saying a firewall wouldn't allow inbound SSH connections, let's<= br> simplify and assume the firewall doesn't allow any inbound TCP
connections, but outbound TCP-connections are fine.

The proposed solution is to repurpose the TCP connection initiated from
behind the firewall. =A0Once the network management application accepts the=
TCP connection, it can pass the accepted TCP socket into its SSH client of<= br> choice (e.g. a SSH library like J2SSH or even using OpenSSH's
"ControlPath" parameter). =A0On the "device" side, the = accepted TCP
connection can be passed into an SSH server - for instance using `sshd -i`<= br> exactly like `inetd` would do when listening on port 22.

Does it make sense now? =A0 [Martin is right that this section of the draft=
could be clearer]


There are valid use-cases (e.g, SOHO) = for wanting a manageable device
to connect to its manager from be= hind a firewall. IMO it's up to the Security Area
to figure o= ut how to do that, not NETCONF, but as long as the proper reviewers
are found, that is not too important.

Does th= e client have to be pre-configured with all the keys of the servers
it will accept these connections from in advance? =A0How does the client= decide
to start an SSH session on the open connection or just drop it?
<= div>

Thanks,
Kent

=A0


Andy

<= /div>
--047d7b67201a8268d804e011c56b-- From ietfc@btconnect.com Wed Jun 26 10:37:17 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8011E8113 for ; Wed, 26 Jun 2013 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=-1.941, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6D55BjysNo3 for ; Wed, 26 Jun 2013 10:37:11 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id AC8EB11E80F5 for ; Wed, 26 Jun 2013 10:37:09 -0700 (PDT) Received: from mail60-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE010.bigfish.com (10.174.4.73) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 17:37:07 +0000 Received: from mail60-db8 (localhost [127.0.0.1]) by mail60-db8-R.bigfish.com (Postfix) with ESMTP id D7B8C3003FE; Wed, 26 Jun 2013 17:37:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail60-db8 (localhost.localdomain [127.0.0.1]) by mail60-db8 (MessageSwitch) id 1372268225640768_15823; Wed, 26 Jun 2013 17:37:05 +0000 (UTC) Received: from DB8EHSMHS028.bigfish.com (unknown [10.174.8.235]) by mail60-db8.bigfish.com (Postfix) with ESMTP id 7A555B8004E; Wed, 26 Jun 2013 17:37:05 +0000 (UTC) Received: from AMSPRD0711HT003.eurprd07.prod.outlook.com (157.56.250.181) by DB8EHSMHS028.bigfish.com (10.174.4.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Jun 2013 17:37:04 +0000 Received: from DBXPRD0411HT004.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.242.14.164) with Microsoft SMTP Server (TLS) id 14.16.324.0; Wed, 26 Jun 2013 17:37:04 +0000 Message-ID: <035301ce7293$d8bac1c0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Martin Bjorklund References: Date: Wed, 26 Jun 2013 18:36:25 +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.165] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Cc: ietf-ssh@NetBSD.org, netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:37:17 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Martin Bjorklund" Cc: ; Sent: Wednesday, June 26, 2013 5:38 PM On 6/26/13 9:09 AM, "t.petch" wrote: > >Yes! That is exactly what I said. But what I also said is that Kent >says >" It works fairly well for automating the discovery of devices with >static IPs >on a reachable network, but not at all when the devices are behind a >firewall that won't allow inbound SSH connections." > >Works not at all .. when the devices are behind a firewall. > >So if devices behind a firewall is a requirement, then the design fails >to meet it. > >If that is not a requirement, why has Kent raised it (and it has been >raised before)? > >This should confuse everyone (not just me:-) Hi Tom, By saying a firewall wouldn't allow inbound SSH connections, let's simplify and assume the firewall doesn't allow any inbound TCP connections, but outbound TCP-connections are fine. The proposed solution is to repurpose the TCP connection initiated from behind the firewall. Once the network management application accepts the TCP connection, it can pass the accepted TCP socket into its SSH client of choice (e.g. a SSH library like J2SSH or even using OpenSSH's "ControlPath" parameter). On the "device" side, the accepted TCP connection can be passed into an SSH server - for instance using `sshd -i` exactly like `inetd` would do when listening on port 22. Does it make sense now? [Martin is right that this section of the draft could be clearer] Yes, that I understand. But ... the firewalls I know, at least the better ones, can look for and reject PDU of protocols such as SSH, regardless of which ports the TCP connection is using. So in that sense, a device behind a firewall that filters SSH connections still cannot be accessed. Is this an acceptable limitation? My other point is that I cannot see how this is a generic solution as the I-D claims. You need something to signal that this three-way TCP handshake is for Netconf over SSH and the only parameter I can see is the port number, so this I-D cannot be used for anything else over anything else; each combination of protocols will need a different port number. Tom Petch Thanks, Kent From jhutz@cmu.edu Wed Jun 26 12:04:21 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1E221F8900 for ; Wed, 26 Jun 2013 12:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmMnXbzXQeTF for ; Wed, 26 Jun 2013 12:04:15 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id EFF2321F85B4 for ; Wed, 26 Jun 2013 12:04:14 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r5QJ4Ctb024452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 15:04:12 -0400 (EDT) Message-ID: <1372273452.23365.49.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Kent Watsen Date: Wed, 26 Jun 2013 15:04:12 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: "netconf@ietf.org" , "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , Mouse , jhutz@cmu.edu Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 19:04:21 -0000 On Tue, 2013-06-25 at 21:54 +0000, Kent Watsen wrote: > [Jeff accidentally didn't send his response to the list, so it's in full > below] > > > > On 6/24/13 5:02 PM, "Jeffrey Hutzelman" wrote: > > >On Mon, 2013-06-24 at 19:55 +0000, Kent Watsen wrote: > >> > >> On 6/24/13 11:40 AM, "Jeffrey Hutzelman" wrote: > >> >Back in 2006, the ISMS working group considered a "reverse SSH" > >>approach > >> >similar in concept to what is being discussed today. We ended up > >> >deciding against it, in part because of the security implications of a > >> >protocol that is basically a device opening a connection and saying > >>"Hi, > >> >I am a server, please tell me your password". > >> > >> ...after verifying the devices host key - we certainly wouldn't expect > >>the > >> client to try logging into any server. Further, we recommend the > >>host-key > >> be a certificate containing the server's identity, though > > > >... against what? > >ssh clients know a priori what host they're going to connect to, and > >thus know which keys are valid (or what name to use, depending on the > >keyex method in use). > > > I'm assuming you mean the first-time connection, since every time > thereafter the host-key accepted before can be used for the lookup and > verification. No. The point is that before _any_ connection is ever started, an SSH client knows who the host is supposed to be. It uses that as a key into its database of host keys, if you're using a keyex method that uses host keys. It may get used in other ways for other keyex methods (and you cannot assume that everything will involve public keys; it's common for enterprises to want to do something else). You cannot discover the host's identity from anything that appears as part of the connection; you need to know in advance what it is supposed to be. > For first-time connection, Network Management apps can be preconfigured to > know which IP addresses or FQDNs they're expecting. They may even let the > end-user input the device's host-key manually. If using certificates, we > especially like the idea of putting the device's serial-number into the > Common Name field, and assume the app is preconfigured to know which > serial numbers to expect (as well as the CA's cert) Except an SSH _client_ doesn't work that way. It doesn't open a connection randomly out into the internet and see if whoever answers is a host it knows about. It opens a connection to a _specific_ host and then verify's the server's credentials against what it is expecting for that host. This is why it's fairly important, in SSH, for the endpoint that originated the connection to be the one that is the SSH client. The connection originator knows in advance who it thinks it is going to talk to, which SSH requires, whereas the endpoint accepting the connection does not -- it needs to decide whether whoever did connect is authorized. > > > >That is the wrong question. When we looked at it before, people with a > >strong understanding of how SSH works, myself included, did not manage > >to convince themselves it was safe. Further, we discovered a number of > >issues such as the host naming problem described above, which made that > >sort of "reverse SSH" impractical, and some of which would likely apply > >to netconf as well. > > It's not wrong, per se, as a single attack would prove insecurity; though > I'll grant you that it doesn't prove security either. I was hoping that > we could construct a proof now. I think that it would be fine even if the > solution only supported certificate-oriented host-keys - this case should > be easier to prove secure as no reference to the TCP-layer is needed, and > therefore its directionality inconsequential - yes? SSH really doesn't contemplate a model where you connect to a host, do a key exchange, and then figure out which host you connected to based on its certificate. Among other things, SSH's default/mandatory algorithms don't use certificates. But yes, if you were to restrict yourselves to non-standardized certificate-based methods, you could probably bash an implementation into letting you do this. I think deciding whether that is safe would require some additional analysis. However, I would strongly caution against specifying use of SSH only with non-IETF algorithms. Not supporting standard algorithms such as RSA public keys, GSS-API, and so on will severely limit the deployability of the resulting protocol beyond the narrow scenario you're envisioning. > For what it's worth, I FIPS-certified a similar strategy a few years back > - a device-initiated transport with a certificate proving identity and > providing a trust root. It was fairly rigorous given the EAL level we > were going for. I'll grant you that this isn't a proof either, but it > seemed good enough for the DoD... I'm not saying you can't have a device-initiated connection where the device identifies itself with a certificate. I'm saying that for SSH, the right way to do that is for the device to act as an SSH client and use SSH public key userauth, not to run the SSH protocol in reverse, which has unknown security properties. > I see. I just read RFC 5592, the last paragraph of section 8 (Operational > Considerations) is relevant. It basically says the device initiates the > ssh connection when needing to push traps. The makes perfect sense, of > course. I take it that you didn't need to manage devices (set/get) behind > firewalls and thus the applications could always initiate connections to > the devices? We started supporting device-initiated connections > primarily to support devices behind firewalls. I get the impression that > others have this need as well. I'm pretty sure we didn't specifically consider the scenario of a device initiating a connection to a management station for the purpose of receiving commands, no. However, SNMP is basically a symmetric protocol and we do permit reuse of SSH connections in both directions, provided the endpoints are right. So, while my memory on this is a bit hazy, I believe it would work to have a device set up a connection and then have the other end start sending it commands. > You're right about NETCONF being fairly symmetric, but we really want the > applications to the able to open the SSH channels, since they know how > many channels want and when they want them. For instance, an application > may open one SSH channel for NETCONF, another to receive SNMP traps via > ISMS another for `sftp`, and another to tunnel a CLI console shell. > Notice that the sftp/cli uses would be user/demand-driven - i.e. the > device wouldn't know a priori that channels for those would be needed. Once an ssh connection is established, _channels_ can be opened by either end, at will. In practice it generally only makes sense to open some kinds of channels in one direction or the other, but the protocol imposes no constraints here. -- Jeff From mehmet.ersue@nsn.com Fri Jun 28 09:16:10 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D93421F9BC8 for ; Fri, 28 Jun 2013 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.289 X-Spam-Level: X-Spam-Status: No, score=-105.289 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0Dl-fN8BtY0 for ; Fri, 28 Jun 2013 09:16:05 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C897A21F9AE9 for ; Fri, 28 Jun 2013 09:16:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5SGFtug008639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Jun 2013 18:15:55 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5SGFrje002919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Jun 2013 18:15:55 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.45]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Fri, 28 Jun 2013 18:15:53 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: netconf - Requested session has been scheduled for IETF 87 Thread-Index: AQHOc3KjSY/J2/RBYUGk9JAJq23A2plLThhA Date: Fri, 28 Jun 2013 16:15:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 400 X-purgate-ID: 151667::1372436155-00002EAE-9923DD8E/0-0/0-0 Subject: [Netconf] netconf - Requested session has been scheduled for IETF 87 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:16:10 -0000 SGkgQWxsLA0KDQp0aGUgTmV0Y29uZiBzZXNzaW9ucyBoYXZlIGJlZW4gc2NoZWR1bGVkIGFzIHNo b3duIGJlbG93Og0KDQpuZXRjb25mIFNlc3Npb24gMSsyICgyOjAwOjAwKQ0KDQogICAgV2VkbmVz ZGF5LCBBZnRlcm5vb24gU2Vzc2lvbiBJSUkgMTYyMC0xNzIwDQogICAgUm9vbSBOYW1lOiBDaGFy bG90dGVuYnVyZyAxDQoNCiAgICBXZWRuZXNkYXksIEFmdGVybm9vbiBTZXNzaW9uIElJSSAxNjIw LTE3MjANCiAgICBSb29tIE5hbWU6IENoYXJsb3R0ZW5idXJnIDENCg0KQ2hlZXJzLA0KTWVobWV0 DQoNCg== From kwatsen@juniper.net Fri Jun 28 14:26:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542E821F9D27 for ; Fri, 28 Jun 2013 14:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+BpXP0xi0o4 for ; Fri, 28 Jun 2013 14:26:49 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6825621F9D23 for ; Fri, 28 Jun 2013 14:26:47 -0700 (PDT) Received: from mail52-db8-R.bigfish.com (10.174.8.245) by DB8EHSOBE017.bigfish.com (10.174.4.80) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Jun 2013 21:26:46 +0000 Received: from mail52-db8 (localhost [127.0.0.1]) by mail52-db8-R.bigfish.com (Postfix) with ESMTP id 31CD89E0145 for ; Fri, 28 Jun 2013 21:26:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275bhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail52-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=kwatsen@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail52-db8 (localhost.localdomain [127.0.0.1]) by mail52-db8 (MessageSwitch) id 1372454804242092_22530; Fri, 28 Jun 2013 21:26:44 +0000 (UTC) Received: from DB8EHSMHS014.bigfish.com (unknown [10.174.8.225]) by mail52-db8.bigfish.com (Postfix) with ESMTP id 36A97580047 for ; Fri, 28 Jun 2013 21:26:44 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by DB8EHSMHS014.bigfish.com (10.174.4.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Jun 2013 21:26:38 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Jun 2013 14:26:16 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 28 Jun 2013 14:26:16 -0700 Received: from CH1EHSOBE007.bigfish.com (216.32.181.183) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 28 Jun 2013 14:38:06 -0700 Received: from mail141-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Jun 2013 21:26:14 +0000 Received: from mail141-ch1 (localhost [127.0.0.1]) by mail141-ch1-R.bigfish.com (Postfix) with ESMTP id B6EBB40014D for ; Fri, 28 Jun 2013 21:26:14 +0000 (UTC) Received: from mail141-ch1 (localhost.localdomain [127.0.0.1]) by mail141-ch1 (MessageSwitch) id 1372454771541203_18307; Fri, 28 Jun 2013 21:26:11 +0000 (UTC) Received: from CH1EHSMHS042.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail141-ch1.bigfish.com (Postfix) with ESMTP id 771641A004D; Fri, 28 Jun 2013 21:26:11 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS042.bigfish.com (10.43.69.251) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Jun 2013 21:26:11 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0324.000; Fri, 28 Jun 2013 21:26:10 +0000 From: Kent Watsen To: t.petch , Martin Bjorklund Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHOcRTSVLNZ5bG3CkeqP19tE7+OCZlGg4QogAA34ACAAQdCEYAABYEAgAAyU13///dpAIAAU5X3gAMhhQA= Date: Fri, 28 Jun 2013 21:26:10 +0000 Message-ID: In-Reply-To: <035301ce7293$d8bac1c0$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.5.130515 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <41262053C6FBD841869DBBB7A3C4B7D1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BTCONNECT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TAIL-F.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NETBSD.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ietf-ssh@NetBSD.org" , "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 21:26:56 -0000 On 6/26/13 1:36 PM, "t.petch" wrote: >Yes, that I understand. > >But ... the firewalls I know, at least the better ones, can look for and >reject PDU of protocols such as SSH, regardless of which ports the TCP >connection is using. So in that sense, a device behind a firewall that >filters SSH connections still cannot be accessed. Is this an acceptable >limitation? I would think so - this is what Juniper has been doing for almost a decade now and I've never heard this raised as an issue before. >My other point is that I cannot see how this is a generic solution as >the I-D claims. You need something to signal that this three-way TCP >handshake is for Netconf over SSH and the only parameter I can see is >the port number, so this I-D cannot be used for anything else over >anything else; each combination of protocols will need a different port >number. By "generic", the draft is trying to say that the solution applied to solve this problem can equally well be applied to other protocols that use SSH for their transport. That said, I'll just add that the port number does not have to be bound to how the application might use the SSH connection. For instance, when a Junos device connects to our management server, yes, it knows it can open the "netconf" subsystem, but it also knows all the other subsystems it can start...and it does! For instance, it will open additional SSH channels for SFTP, notifications, packet captures, etc. It would've been easier if SSH defined a subsystem-discovery mechanism, but we worked around that too. Thanks, Kent From kwatsen@juniper.net Fri Jun 28 16:55:43 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E002421F93B9 for ; Fri, 28 Jun 2013 16:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wpsmbPUO3Rg for ; Fri, 28 Jun 2013 16:55:30 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1A85721F9A03 for ; Fri, 28 Jun 2013 16:55:30 -0700 (PDT) Received: from mail99-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Jun 2013 23:55:28 +0000 Received: from mail99-co9 (localhost [127.0.0.1]) by mail99-co9-R.bigfish.com (Postfix) with ESMTP id 5B6E64A02F8 for ; Fri, 28 Jun 2013 23:55:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zzbb2dI98dI9371I4015I168aJdb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail99-co9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=kwatsen@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail99-co9 (localhost.localdomain [127.0.0.1]) by mail99-co9 (MessageSwitch) id 1372463725927315_10041; Fri, 28 Jun 2013 23:55:25 +0000 (UTC) Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.239]) by mail99-co9.bigfish.com (Postfix) with ESMTP id 8BDF9E008F for ; Fri, 28 Jun 2013 23:55:25 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Jun 2013 23:55:21 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Jun 2013 16:55:20 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 28 Jun 2013 16:55:20 -0700 Received: from CO9EHSOBE031.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 28 Jun 2013 17:07:10 -0700 Received: from mail101-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Jun 2013 23:55:19 +0000 Received: from mail101-co9 (localhost [127.0.0.1]) by mail101-co9-R.bigfish.com (Postfix) with ESMTP id EDD562202A6 for ; Fri, 28 Jun 2013 23:55:18 +0000 (UTC) Received: from mail101-co9 (localhost.localdomain [127.0.0.1]) by mail101-co9 (MessageSwitch) id 1372463716656191_19206; Fri, 28 Jun 2013 23:55:16 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.230]) by mail101-co9.bigfish.com (Postfix) with ESMTP id 93D304E006F; Fri, 28 Jun 2013 23:55:16 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Jun 2013 23:55:16 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.216]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0324.000; Fri, 28 Jun 2013 23:55:15 +0000 From: Kent Watsen To: Jeffrey Hutzelman Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt Thread-Index: AQHOcRTSVLNZ5bG3CkeqP19tE7+OCZlFWhKAgAFdvACAAaXrAIADMuuA Date: Fri, 28 Jun 2013 23:55:15 +0000 Message-ID: In-Reply-To: <1372273452.23365.49.camel@minbar.fac.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CMU.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RODENTS-MONTREAL.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "draft-ietf-netconf-reverse-ssh@tools.ietf.org" , Mouse , "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 23:55:43 -0000 On 6/26/13 3:04 PM, "Jeffrey Hutzelman" wrote: >No. The point is that before _any_ connection is ever started, an SSH >client knows who the host is supposed to be. It uses that as a key into >its database of host keys, if you're using a keyex method that uses host >keys. It may get used in other ways for other keyex methods (and you >cannot assume that everything will involve public keys; it's common for >enterprises to want to do something else). You cannot discover the >host's identity from anything that appears as part of the connection; >you need to know in advance what it is supposed to be. The SSH RFCs don't say this. RFC 4253, section 4 just says "The client initiates the connection.", but they could be referring to the SSH-client (not the TCP-client). Likewise, RFC 4251, section 9.3.4 describes man-in-the-middle attacks, but simply says that the client should verify the association between the server host key and the server host name - it doesn't say anything about what inputs the client can use to derive the host name. Just saying... ;) Of course, TLS has much stronger language and I think it's fair to apply it to SSH, as you have. Specifically, RFC 6125, section 6.2.1 defines rules for constructing reference identifiers. The language here provides little wiggle-room but, at the same time, still doesn't provide rational for why that must be the case. For all I know, the authors felt it common-sense it codified it. What is particularly interesting is that, in the case of TLS, earlier RFCs explicitly allowed this. For instance, both RFC 2818 (section 3.1) and RFC 5539 (section 3.1) say "If the client has external information as to the expected identity of the server, the hostname check MAY be omitted.". >Except an SSH _client_ doesn't work that way. It doesn't open a >connection randomly out into the internet and see if whoever answers is >a host it knows about. It opens a connection to a _specific_ host and >then verify's the server's credentials against what it is expecting for >that host. True, but that's doesn't prove that this proposal insecure either. >This is why it's fairly important, in SSH, for the endpoint that >originated the connection to be the one that is the SSH client. The >connection originator knows in advance who it thinks it is going to talk >to, which SSH requires, whereas the endpoint accepting the connection >does not -- it needs to decide whether whoever did connect is >authorized. I think here you come closest to putting a finger on it, but I keep coming back to that no one can show an attack. If it's so important, then wouldn't it be easy to show an attack? I'll even make it easy, assume the bad-device is behind the same NAT as a good device: The only attack I can envision is one where it's a first-time connection for that device AND the device isn't using a certificate-based hostkey AND the application blindly accepts the presented hostkey. But even this pathological case doesn't prove anything because it's already known that blindly accepting host keys is insecure... >SSH really doesn't contemplate a model where you connect to a host, do a >key exchange, and then figure out which host you connected to based on >its certificate. Among other things, SSH's default/mandatory algorithms >don't use certificates. But yes, if you were to restrict yourselves to >non-standardized certificate-based methods, you could probably bash an >implementation into letting you do this. I think deciding whether that >is safe would require some additional analysis. Minor clarification - we're expecting to figure out the host *during* key-exchange (not after). All the SSH client libraries I've tested provid a callback function for hostkey verification. This function gets executed during the diffie-hellman exchange, as soon as the SSH-client receives the server's SSH_MSG_KEXDH_REPLY message - this is, for instance, the same time openssh would check the known_hosts file. >However, I would strongly caution against specifying use of SSH only >with non-IETF algorithms. Not supporting standard algorithms such as >RSA public keys, GSS-API, and so on will severely limit the >deployability of the resulting protocol beyond the narrow scenario >you're envisioning. Agreed - the draft merely RECOMMENDS using certificate-based algorithms, as the certificates very nicely provide a trust-root and a certifiable identity. Ultimately, the device had to have been configured to know which IP addr/port to connect to and, at the same time, can be configured to know what host keys algs to present. This just shows that it's a deployment-specific configuration to decide, not an IETF requirement. >I'm not saying you can't have a device-initiated connection where the >device identifies itself with a certificate. I'm saying that for SSH, >the right way to do that is for the device to act as an SSH client and >use SSH public key userauth, not to run the SSH protocol in reverse, >which has unknown security properties. I understand perfectly. I saw Mouse (I think) post this idea (to let the "server" open subsystems on the "client") to the ietf-ssh list but, for some reason, I stopped receiving messages from that list in April - and that list's archives are practically inaccessible, so I'm not following what's going on there (anything?). Nonetheless, as I wrote before, I accept that this is a viable solution - the only thing I don't like about it is that it could be years until SSH implementations would support it, if ever. It's simply a case of having an immediately-implemenatable solution with unknown security properties versus an not-implementable-for-awhile solution with known security properties. What do we need to do to "know" the security properties with the current proposal? - is it a paper exercise or soak time required? >Once an ssh connection is established, _channels_ can be opened by >either end, at will. In practice it generally only makes sense to open >some kinds of channels in one direction or the other, but the protocol >imposes no constraints here. True, current protocol says that either side can open a "channels" - this is in RFC 4254, section 5.1: "When either side wishes to open a new channel, ... But to open a subsystem, we need a "session" and section 6.1 says: "Client implementations SHOULD reject any session channel open requests to make it more difficult for a corrupt server to attack the client." Now, I'll grant you that it's a SHOULD (not a MUST), but existing implementations don't support it, and that's the key difference we're spinning on here. Thanks, Kent From ietfc@btconnect.com Sat Jun 29 04:26:54 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9842A21F9FCF for ; Sat, 29 Jun 2013 04:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzOhpXEjuUv7 for ; Sat, 29 Jun 2013 04:26:48 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5821F9FD8 for ; Sat, 29 Jun 2013 04:26:47 -0700 (PDT) Received: from mail120-db9-R.bigfish.com (10.174.16.253) by DB9EHSOBE028.bigfish.com (10.174.14.91) with Microsoft SMTP Server id 14.1.225.23; Sat, 29 Jun 2013 11:26:45 +0000 Received: from mail120-db9 (localhost [127.0.0.1]) by mail120-db9-R.bigfish.com (Postfix) with ESMTP id 921954001EE; Sat, 29 Jun 2013 11:26:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail120-db9 (localhost.localdomain [127.0.0.1]) by mail120-db9 (MessageSwitch) id 1372505204384834_4533; Sat, 29 Jun 2013 11:26:44 +0000 (UTC) Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.230]) by mail120-db9.bigfish.com (Postfix) with ESMTP id 4F6C918004B; Sat, 29 Jun 2013 11:26:44 +0000 (UTC) Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 29 Jun 2013 11:26:43 +0000 Received: from DB3PRD0511HT003.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.324.0; Sat, 29 Jun 2013 11:26:33 +0000 Message-ID: <00bd01ce74bb$934e1f40$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen References: Date: Sat, 29 Jun 2013 12:23: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.254.213] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Cc: ietf-ssh@NetBSD.org, netconf@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 11:26:54 -0000 ---- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Martin Bjorklund" Cc: ; Sent: Friday, June 28, 2013 10:26 PM On 6/26/13 1:36 PM, "t.petch" wrote: >Yes, that I understand. > >But ... the firewalls I know, at least the better ones, can look for and >reject PDU of protocols such as SSH, regardless of which ports the TCP >connection is using. So in that sense, a device behind a firewall that >filters SSH connections still cannot be accessed. Is this an acceptable >limitation? I would think so - this is what Juniper has been doing for almost a decade now and I've never heard this raised as an issue before. >My other point is that I cannot see how this is a generic solution as >the I-D claims. You need something to signal that this three-way TCP >handshake is for Netconf over SSH and the only parameter I can see is >the port number, so this I-D cannot be used for anything else over >anything else; each combination of protocols will need a different port >number. By "generic", the draft is trying to say that the solution applied to solve this problem can equally well be applied to other protocols that use SSH for their transport. OK, so it is limited to reverse SSH (as opposed to a generic call home) and that is what the I-D says, so that is ok. But ... I would like to see a note added that the server/device must be prepared to receive any SSH PDU and act appropriately and not just assume it is netconf. I am wondering if there is a Security Consideration in there somewhere but cannot put my finger on one. Tom Petch That said, I'll just add that the port number does not have to be bound to how the application might use the SSH connection. For instance, when a Junos device connects to our management server, yes, it knows it can open the "netconf" subsystem, but it also knows all the other subsystems it can start...and it does! For instance, it will open additional SSH channels for SFTP, notifications, packet captures, etc. It would've been easier if SSH defined a subsystem-discovery mechanism, but we worked around that too. Thanks, Kent From andy@yumaworks.com Sat Jun 29 09:40:54 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B92911E8198 for ; Sat, 29 Jun 2013 09:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFvwJ6kL+Yfo for ; Sat, 29 Jun 2013 09:40:49 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3276A11E8197 for ; Sat, 29 Jun 2013 09:40:49 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so3507140pab.11 for ; Sat, 29 Jun 2013 09:40:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=Y/QwdpZovughruAGZs6aiZ3CkLgMal0voKLdoNel7L0=; b=fxW2OQTSPOgSU22//p5U5JAM5xF7VaJ9Dzf+OjBaL8zX1qDoPwjnOEM9cHHPDVW7u8 ezWCWen8ka07U6RsaiT11H6guYLp5Ki203PfOMnd5DGbPRcPSVe2PpWNyYjkfsW3gj57 dxGIKv/rqbHkmIZ+o0EM2aRtNKfrisPpvCXN4dM+muhwZJBrg+Ix38Xy3pzeVSMsO2sh RXQxOIH6WB5+AL/pM8K/3L9ONyoszEexoJMp4M+2Ip65ey2/SbaQor+RBGnnRM3VnkuP 2bX3okQUpZXgXCIo/bbKbSJLLagpCieRRIPLFPuGJYXlqzc90szyVs3mp0L2Tbeovpra wnDg== MIME-Version: 1.0 X-Received: by 10.68.113.194 with SMTP id ja2mr16496855pbb.65.1372524048815; Sat, 29 Jun 2013 09:40:48 -0700 (PDT) Received: by 10.70.58.196 with HTTP; Sat, 29 Jun 2013 09:40:48 -0700 (PDT) Date: Sat, 29 Jun 2013 09:40:48 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkGbeWvPJyjEEuqu7Kegrff/J6PH8UN9mOD+lvQ+ok23yM4k0OV/EiyYdcHzrOCofrGfD7O Subject: [Netconf] comments on draft-ietf-netconf-rfc5539bis-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 16:40:54 -0000 Hi, The YANG module in this draft has been split into 3 YANG files: 1) module (ietf-netconf-config) 2) submodule ietf-netconf-common 3) submodule ietf-netconf-tls The main module has nothing but boilerplate and include-stmts for the 2 sub-modules. The first sub-module has 1 container (/netconf) and the 2nd sub-module has some TLS objects. Besides the triple boilerplate, it seems strange that we will have to update the NETCONF over TLS transport mapping RFC every time we want to add another sub-module to the ietf-netconf-config module. I like YANG modules much better than sub-modules because new functionality can be published in just 1 RFC instead of 2 RFCs. I don't think putting all new NETCONF config objects under 1 /netconf element (same local name as /netconf in RFC 5277) is that important, but if the WG wants to do that, then I strongly suggest creating a place-holder RFC with just the /netconf container in it. Other RFCs can augment from their own YANG module instead of a submodule. This way, new config modules will have a normative reference to the 100% stable /netconf container RFC instead of a normative reference to the potentially unstable NETCONF over TLS RFC. The reference is more clear to readers as well, since no NETCONF config RFC will ever be related to TLS except 5539bis. Andy From mbj@tail-f.com Sat Jun 29 11:40:14 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A050E21F9F8A for ; Sat, 29 Jun 2013 11:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9n4xzEiAmi5 for ; Sat, 29 Jun 2013 11:40:06 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3147F21F9F86 for ; Sat, 29 Jun 2013 11:40:05 -0700 (PDT) Received: from localhost (213-65-182-102-no181.tbcn.telia.com [213.65.182.102]) by mail.tail-f.com (Postfix) with ESMTPSA id C8B8B1200D95; Sat, 29 Jun 2013 20:40:02 +0200 (CEST) Date: Sat, 29 Jun 2013 20:40:01 +0200 (CEST) Message-Id: <20130629.204001.103214868.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-ietf-netconf-rfc5539bis-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 18:40:14 -0000 Hi, Andy Bierman wrote: > Hi, > > The YANG module in this draft has been split into 3 YANG files: > > 1) module (ietf-netconf-config) > 2) submodule ietf-netconf-common > 3) submodule ietf-netconf-tls > > The main module has nothing but boilerplate and include-stmts > for the 2 sub-modules. The first sub-module has 1 container > (/netconf) > and the 2nd sub-module has some TLS objects. > > Besides the triple boilerplate, it seems strange that we will have > to update the NETCONF over TLS transport mapping RFC every time > we want to add another sub-module to the ietf-netconf-config module. That is not what the document says. It says: If new definitions need to be added to the NETCONF configuration data model, either an existing YANG submodule can be updated or a new YANG submodule can be written. In both cases, the new document will carry an updated version of the "ietf-netconf-config" module importing the submodules. So, if you add a new submodule, you would update the ietf-netconf-config module, but not NETCONF over TLS. > I don't think putting all new NETCONF config objects under 1 /netconf > element > (same local name as /netconf in RFC 5277) is that important, but if > the WG wants > to do that, then I strongly suggest creating a place-holder RFC with > just > the /netconf container in it. Other RFCs can augment from their own > YANG module instead of a submodule. This adds namespaces. I prefer the current submodule design. > This way, new config modules will have a normative reference to the > 100% stable > /netconf container RFC instead of a normative reference to the > potentially unstable > NETCONF over TLS RFC. But a new config submodule would NOT have a reference to NETCONF over TLS. /martin From andy@yumaworks.com Sat Jun 29 13:07:45 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4641321F9FFF for ; Sat, 29 Jun 2013 13:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpdGFbAXoXAu for ; Sat, 29 Jun 2013 13:07:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2FD11E8187 for ; Sat, 29 Jun 2013 13:07:39 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so3420529pbc.3 for ; Sat, 29 Jun 2013 13:07:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=X9NfvFvE+Jiaj8KXiy8slBs2UoeDCw/J6damiyoxNlg=; b=BmPuYppsTzBxPDIXSyGKZE9GwUOE/ZPpz50SyTwBuabkuwsX0UtlxluH9veNmefHlV Co29xjoZtJ+9Y9FtdjLDBMUeFIwWotjtX6T9j6Qsoeuf/fT7bJYEVHVngOtLr266amNH pGl17HLmTeoq9HVsxeJOX0St2vWagX5EbfvOXG5vIy1j4T2JbaaNA1npKU6Fjsraob3G EoyKCIVMjnS05av+7kVfbVuZg2jza67D0PLU7sB2Su9u7367P6oW0/QIfVwUmQFTc/+A crkEKBqm1W8SkYqWrlk9ramFzmxMvzXNz5r+LMTS9TIzXpumYzvB00u7SXaCiMTYLNWl UgGQ== MIME-Version: 1.0 X-Received: by 10.68.113.194 with SMTP id ja2mr17053432pbb.65.1372536459685; Sat, 29 Jun 2013 13:07:39 -0700 (PDT) Received: by 10.70.58.196 with HTTP; Sat, 29 Jun 2013 13:07:39 -0700 (PDT) In-Reply-To: <20130629.204001.103214868.mbj@tail-f.com> References: <20130629.204001.103214868.mbj@tail-f.com> Date: Sat, 29 Jun 2013 13:07:39 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnmmhKQsr4S6XhRW1gBqY9jHM163sSMwWW6QH3LamtK+iBGYEIMHY6bOXTBLqlX+0OaKqLb Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-ietf-netconf-rfc5539bis-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 20:07:45 -0000 On Sat, Jun 29, 2013 at 11:40 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> The YANG module in this draft has been split into 3 YANG files: >> >> 1) module (ietf-netconf-config) >> 2) submodule ietf-netconf-common >> 3) submodule ietf-netconf-tls >> >> The main module has nothing but boilerplate and include-stmts >> for the 2 sub-modules. The first sub-module has 1 container >> (/netconf) >> and the 2nd sub-module has some TLS objects. >> >> Besides the triple boilerplate, it seems strange that we will have >> to update the NETCONF over TLS transport mapping RFC every time >> we want to add another sub-module to the ietf-netconf-config module. > > That is not what the document says. It says: > > If new definitions need to be added to the NETCONF configuration > data model, either an existing YANG submodule can be updated or a > new YANG submodule can be written. In both cases, the new document > will carry an updated version of the "ietf-netconf-config" module > importing the submodules. > > So, if you add a new submodule, you would update the > ietf-netconf-config module, but not NETCONF over TLS. > I like this even worse -- so the ietf-netconf-config module would end up being defined in lots of RFCs. I prefer a YANG module to stay in RFCnnnn, then RFCnnnn-bis obsoletes RFCnnnn and it is clear which is the newest version. I don't see any point to having a /netconf container that is this much trouble to maintain. It doesn't really matter if there are 4 top-level NETCONF nodes or 8 or 20. The server advertises all the modules it implements (but not submodules). The client knows where the data lives from parsing the YANG module. Each module has its own revision date and RFC history. This is easy to maintain. Andy >> I don't think putting all new NETCONF config objects under 1 /netconf >> element >> (same local name as /netconf in RFC 5277) is that important, but if >> the WG wants >> to do that, then I strongly suggest creating a place-holder RFC with >> just >> the /netconf container in it. Other RFCs can augment from their own >> YANG module instead of a submodule. > > This adds namespaces. I prefer the current submodule design. > So what -- what does a namespace cost? A server doesn't advertise submodules and the schemas list in ietf-netconf-monitoring is optional to implement. >> This way, new config modules will have a normative reference to the >> 100% stable >> /netconf container RFC instead of a normative reference to the >> potentially unstable >> NETCONF over TLS RFC. > > But a new config submodule would NOT have a reference to NETCONF over > TLS. > Worse -- ietf-netconf-config is spread over multiple RFCs. > > /martin Andy