From balazs.lengyel@ericsson.com Tue Dec 11 05:32:58 2012 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 7A48721F8496 for ; Tue, 11 Dec 2012 05:32:58 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBUP29o-m5Ws for ; Tue, 11 Dec 2012 05:32:58 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2221F84C4 for ; Tue, 11 Dec 2012 05:32:57 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-2b-50c7360878d1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0C.FD.24873.80637C05; Tue, 11 Dec 2012 14:32:56 +0100 (CET) Received: from [159.107.230.148] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 11 Dec 2012 14:32:56 +0100 Message-ID: <50C73607.8040706@ericsson.com> Date: Tue, 11 Dec 2012 14:32:55 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Netconf References: <20121130222344.14056.57485.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAJMWRmVeSWpSXmKPExsUyM+JvjS6H2fEAg7+LxS2mbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD2PNrAVzGSrODrhG1MD4wWWLkZODgkBE4nXcy6zQ9hiEhfu rWfrYuTiEBI4ySixecUOdghnLaPE6yVnmECqeAW0Jf5M2cIGYrMIqEr8OtkBZrMJGElM7T8P NlVUwFdiyvF/7BD1ghInZz4Bi4sIyEms3LscLC4soCKxf9ouqAVtjBI35jeCDeIUCJTYv+YO I4jNLGArcWHOdRYIW15i+9s5zCC2kICGxMMLf1knMArMQrJjFpKWWUhaFjAyr2Jkz03MzEkv N9rECAy1g1t+q+5gvHNO5BCjNAeLkjiv9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY Q1s0YsXCFiz2i1rsPS/2ZVFgcNxS5rRnEXsYiqe9vSj9+8KvM2zaV+fkmDo+ejgtJl3gnfWW +oMSp2bu+PzPf2Wv34//JjOZd0dfDRR55RGhsDV6RkBTvtKq1V5b2g+xvpw1i9Ntatayuz/Z 9i+MfBS8Z+4B/hOifA3C5luk9rVrRupOiz+doMRSnJFoqMVcVJwIAPQTnJQDAgAA Subject: [Netconf] Call Home for Notifications 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, 11 Dec 2012 13:32:58 -0000 Hello, On the last IETF the Call-Home feature (netconf session started by the managed node) was again raised. What is the situation with this. Way back there where at least two ideas: 1) Start the SSH session and the Hello exchange from the managed node. This could also be done via TLS now. 2) Send an SNMP notification to the Netconf client to ask it to start a Netconf notification session As I remember it was security problems that stopped call-home from happening. Does anyone remember details? Is there interest to restart this issue? 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 phil@juniper.net Tue Dec 11 05:56:20 2012 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 120C821F8778 for ; Tue, 11 Dec 2012 05:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmXWDz21LuHY for ; Tue, 11 Dec 2012 05:56:19 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5187021F8765 for ; Tue, 11 Dec 2012 05:56:17 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUMc7gQedeeGJE0Ul6VCBQ34TdnMNkb5J@postini.com; Tue, 11 Dec 2012 05:56:19 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 11 Dec 2012 05:52:38 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qBBDqa316369; Tue, 11 Dec 2012 05:52:37 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id qBBDqZkG082896; Tue, 11 Dec 2012 08:52:35 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201212111352.qBBDqZkG082896@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <50C73607.8040706@ericsson.com> Date: Tue, 11 Dec 2012 08:52:35 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Call Home for Notifications 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, 11 Dec 2012 13:56:20 -0000 Balazs Lengyel writes: >1) Start the SSH session and the Hello exchange from the managed node. >This could also be done via TLS now. >2) Send an SNMP notification to the Netconf client to ask it to start a >Netconf notification session The connection has to come from the managed node, since we want to be able to pass thru NAT and 6to4 gateways. >As I remember it was security problems that stopped call-home from >happening. >Does anyone remember details? Is there interest to restart this issue? Kent Watsen was persuing this with the SSH group, since it's a generic facility. Thanks, Phil From j.schoenwaelder@jacobs-university.de Tue Dec 11 06:22:59 2012 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 C084521F8801 for ; Tue, 11 Dec 2012 06:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uceNLioK7AmY for ; Tue, 11 Dec 2012 06:22:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8C21F87FA for ; Tue, 11 Dec 2012 06:22:55 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3B3020BF8; Tue, 11 Dec 2012 15:22:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id co2m50X6wgWE; Tue, 11 Dec 2012 15:22:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C38320BF6; Tue, 11 Dec 2012 15:22:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1B94223657F2; Tue, 11 Dec 2012 15:23:02 +0100 (CET) Date: Tue, 11 Dec 2012 15:23:02 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20121211142302.GA52721@elstar.local> Mail-Followup-To: Phil Shafer , Balazs Lengyel , Netconf References: <50C73607.8040706@ericsson.com> <201212111352.qBBDqZkG082896@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201212111352.qBBDqZkG082896@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Call Home for Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 14:22:59 -0000 On Tue, Dec 11, 2012 at 08:52:35AM -0500, Phil Shafer wrote: > Balazs Lengyel writes: > >1) Start the SSH session and the Hello exchange from the managed node. > >This could also be done via TLS now. The TLS update may provide an answer for the TLS transport. With TLS and certificates on both ends, it should not matter too much which side is initiating the connection. But of course, I am not a security expert, so this may need further checking. With SSH, the situation is complicated due to its two very different ways to authenticate the server and the client. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Wed Dec 12 09:22:27 2012 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 835D11F0CBE for ; Wed, 12 Dec 2012 09:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CfyvS1cyYbR for ; Wed, 12 Dec 2012 09:22:24 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 03A1E21E805A for ; Wed, 12 Dec 2012 09:22:03 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUMi9O8NDqVCEeZ2DmXYDL2CChGAl0owQ@postini.com; Wed, 12 Dec 2012 09:22:04 PST 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; Wed, 12 Dec 2012 09:21:17 -0800 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, 12 Dec 2012 09:21:16 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 09:28:50 -0800 Received: from mail73-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 17:21:16 +0000 Received: from mail73-co1 (localhost [127.0.0.1]) by mail73-co1-R.bigfish.com (Postfix) with ESMTP id B4862480214 for ; Wed, 12 Dec 2012 17:21:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I1432Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail73-co1 (localhost.localdomain [127.0.0.1]) by mail73-co1 (MessageSwitch) id 1355332872788823_2731; Wed, 12 Dec 2012 17:21:12 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.253]) by mail73-co1.bigfish.com (Postfix) with ESMTP id B211C58005B; Wed, 12 Dec 2012 17:21:12 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 17:20:02 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.104]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 17:19:54 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Phil Shafer Thread-Topic: [Netconf] Call Home for Notifications Thread-Index: AQHN16Q0tNon+hBUn0KjuKRoLf/9zZgTnkOAgAAIggCAAW/qgA== Date: Wed, 12 Dec 2012 17:19:53 +0000 Message-ID: In-Reply-To: <20121211142302.GA52721@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.131.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8311A7AC63ED58458CB92E043E996AD2@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%JACOBS-UNIVERSITY.DE$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 Cc: Netconf Subject: Re: [Netconf] Call Home for Notifications 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, 12 Dec 2012 17:22:27 -0000 Regrading the asymmetry in SSH client/server authentication, the crux of the Reverse SSH protocol is to ensure that the device is *always* the SSH-server and the NMS is *always* the SSH-client, regardless of which side initiats the underlying TCP connection. Thus there isn't any "complication" to be concerned about. To answer Balazs' original question, my plan is to publish a reference implementation of Reverse SSH to code.google or sourceforge . I should've done this long ago, but it keeps getting preempted. FWIW, I discussed this with my CTO a couple days ago, so he knows that it's pending... K. On 12/11/12 9:23 AM, "Juergen Schoenwaelder" wrote: >On Tue, Dec 11, 2012 at 08:52:35AM -0500, Phil Shafer wrote: >> Balazs Lengyel writes: >> >1) Start the SSH session and the Hello exchange from the managed node. >> >This could also be done via TLS now. > >The TLS update may provide an answer for the TLS transport. With TLS >and certificates on both ends, it should not matter too much which >side is initiating the connection. But of course, I am not a security >expert, so this may need further checking. > >With SSH, the situation is complicated due to its two very different >ways to authenticate the server and the client. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > From j.schoenwaelder@jacobs-university.de Wed Dec 12 12:20:50 2012 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 DDE461F0CC7 for ; Wed, 12 Dec 2012 12:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gB1evutPRFc4 for ; Wed, 12 Dec 2012 12:20:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7931F0CCF for ; Wed, 12 Dec 2012 12:20:45 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 034A320C1A; Wed, 12 Dec 2012 21:20:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n4KmVI345nNF; Wed, 12 Dec 2012 21:20:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E4F320C19; Wed, 12 Dec 2012 21:20:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1C9782369984; Wed, 12 Dec 2012 21:20:52 +0100 (CET) Date: Wed, 12 Dec 2012 21:20:52 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20121212202050.GA59469@elstar.local> Mail-Followup-To: Kent Watsen , Phil Shafer , Netconf References: <20121211142302.GA52721@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Call Home for Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:20:51 -0000 On Wed, Dec 12, 2012 at 05:19:53PM +0000, Kent Watsen wrote: > > Regrading the asymmetry in SSH client/server authentication, the crux of > the Reverse SSH protocol is to ensure that the device is *always* the > SSH-server and the NMS is *always* the SSH-client, regardless of which > side initiats the underlying TCP connection. Thus there isn't any > "complication" to be concerned about. > Back im ISMS days, some security folks argued that even then this is not the same. The reasoning, as far as I understood it and recall it, which may be completely wrong, was that in the normal case, the client has a clear idea to which host it wants to connect and then the client can check the discovered host key against what was expected. If you turn this around, the 'client' gets presented with a host connecting and since the initiative come from the remote entity, the client has a harder time to decide whether the host is meaningful to engage into a conversation with. This may sound like an artificial philosophical argument, perhaps it is, perhaps it is just my poor recollection and paraphrasing of it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Dec 12 12:28:01 2012 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 BFE6821F88D6 for ; Wed, 12 Dec 2012 12:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAFuffuwfJXa for ; Wed, 12 Dec 2012 12:27:54 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id A98DD21F88C1 for ; Wed, 12 Dec 2012 12:27:51 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUMjoxmvk0bHXOHrnG/rw8JcMZm/jfMC6@postini.com; Wed, 12 Dec 2012 12:27:53 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 12:24:18 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qBCKOG318361; Wed, 12 Dec 2012 12:24:17 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id qBCKOFJ9093061; Wed, 12 Dec 2012 15:24:15 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201212122024.qBCKOFJ9093061@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20121212202050.GA59469@elstar.local> Date: Wed, 12 Dec 2012 15:24:15 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Call Home for Notifications 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, 12 Dec 2012 20:28:01 -0000 Juergen Schoenwaelder writes: >Back im ISMS days, some security folks argued that even then this is >not the same. The reasoning, as far as I understood it and recall it, >which may be completely wrong, was that in the normal case, the client >has a clear idea to which host it wants to connect and then the client >can check the discovered host key against what was expected. If you >turn this around, the 'client' gets presented with a host connecting >and since the initiative come from the remote entity, the client has a >harder time to decide whether the host is meaningful to engage into a >conversation with. This may sound like an artificial philosophical >argument, perhaps it is, perhaps it is just my poor recollection and >paraphrasing of it. Does having the device pre-configured with the hostkey of the manager help? It then knows that the incoming connection is from someone that it's supposed to be talking with. Thanks, Phil From kwatsen@juniper.net Wed Dec 12 13:33:41 2012 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 DFBF121E805F for ; Wed, 12 Dec 2012 13:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol+zwybrKOQ7 for ; Wed, 12 Dec 2012 13:33:35 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9655021E8054 for ; Wed, 12 Dec 2012 13:33:35 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUMj4KDxjb2wCUJiH+bqL0CNtfH4qj/GC@postini.com; Wed, 12 Dec 2012 13:33:35 PST 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, 12 Dec 2012 13:31:02 -0800 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, 12 Dec 2012 13:31:02 -0800 Received: from CO9EHSOBE017.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, 12 Dec 2012 13:32:52 -0800 Received: from mail36-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 21:30:40 +0000 Received: from mail36-co9 (localhost [127.0.0.1]) by mail36-co9-R.bigfish.com (Postfix) with ESMTP id 1E812700128 for ; Wed, 12 Dec 2012 21:30:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I1432Izz1de0h1202h1e76h1d1ah1d2ahzz8275chz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail36-co9 (localhost.localdomain [127.0.0.1]) by mail36-co9 (MessageSwitch) id 1355347838164897_29122; Wed, 12 Dec 2012 21:30:38 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.254]) by mail36-co9.bigfish.com (Postfix) with ESMTP id 1B55E9000B0; Wed, 12 Dec 2012 21:30:38 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 21:30:30 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.104]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 21:30:26 +0000 From: Kent Watsen To: Phil Shafer , Juergen Schoenwaelder Thread-Topic: [Netconf] Call Home for Notifications Thread-Index: AQHN16Q0tNon+hBUn0KjuKRoLf/9zZgTnkOAgAAIggCAAW/qgIAAhmUAgAAA8oD//76pgA== Date: Wed, 12 Dec 2012 21:30:25 +0000 Message-ID: In-Reply-To: <201212122024.qBCKOFJ9093061@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.131.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <81FB3B1A3B42544FA8A5975FEA482E39@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%JACOBS-UNIVERSITY.DE$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 Cc: Netconf Subject: Re: [Netconf] Call Home for Notifications 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, 12 Dec 2012 21:33:42 -0000 On 12/12/12 3:24 PM, "Phil Shafer" wrote: >Juergen Schoenwaelder writes: >>Back im ISMS days, some security folks argued that even then this is >>not the same. The reasoning, as far as I understood it and recall it, >>which may be completely wrong, was that in the normal case, the client >>has a clear idea to which host it wants to connect and then the client >>can check the discovered host key against what was expected. If you >>turn this around, the 'client' gets presented with a host connecting >>and since the initiative come from the remote entity, the client has a >>harder time to decide whether the host is meaningful to engage into a >>conversation with. This may sound like an artificial philosophical >>argument, perhaps it is, perhaps it is just my poor recollection and >>paraphrasing of it. > >Does having the device pre-configured with the hostkey of the manager >help? It then knows that the incoming connection is from someone that >it's supposed to be talking with. Assuming you meant host key of the *device*, absolutely, but draft-kwatsen-reverse-ssh takes it a step further by enabling trust in the host-key to be learned, per it being cryptographically signed with something the manager trusts. Juergon, I'm familiar with the need for TLS clients to verify a certificate's subject matter matches expectations, as it is prudent to validate the identity your peer. In the case of device-initiated connection, there is still a desire to validate its identity, though it may take on other forms including serial-number, hash(serial-number), ip-address, and/or fqdn. Ideally the manager has some precognition of one of these, but this may not always be possible. This is why draft-kwatsen-reverse-ssh introduced the ability for a CA to sign the device's credentials, thus enabling a manager to extend its trust for the CA to the device, even if never seeing its identity before. FWIW, neither the IETF-SSH nor SAAG raised any security concerns when discussing draft-kwatsen-reverse-ssh, though this may be due to them being too preoccupied with protocol-purity and never getting to think about it ;) K. From rohit.pobbathi@huawei.com Wed Dec 12 20:31:53 2012 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 3706621F86A5 for ; Wed, 12 Dec 2012 20:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd1oYXHEmQFJ for ; Wed, 12 Dec 2012 20:31:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 36E3421F86A0 for ; Wed, 12 Dec 2012 20:31:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANU18095; Thu, 13 Dec 2012 04:31:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 04:30:55 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 04:31:46 +0000 Received: from blrprnc10ns (10.18.96.99) by szxeml413-hub.china.huawei.com (10.82.67.152) with Microsoft SMTP Server id 14.1.323.3; Thu, 13 Dec 2012 12:31:43 +0800 From: Rohit Pobbathi To: , Date: Thu, 13 Dec 2012 10:01:40 +0530 Organization: Htipl Message-ID: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CDD918.D98BC230" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3UhlJF93k5hrmgQcWGC8WVOKEdLAEY+iiQ Content-Language: en-us X-Originating-IP: [10.18.96.99] X-CFilter-Loop: Reflected Subject: [Netconf] Require clarification when NETCONF server receives Interleave Capability without Notification Capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rohit.pobbathi@huawei.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 04:31:53 -0000 ------=_NextPart_000_0031_01CDD918.D98BC230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, When NETCONF server receives Interleave capability from NETCONF client without notification capability what should be the behavior of NETCONF server ? Please let me know what expected behavior is. Here are my thoughts : Since notification capability is not exchanged, remove interleave capability in session supported capabilities and behave as if normal session i.e. receive, process and respond to requests on session without notification support. or Create session and don't allow any operations i.e. dead session because interleave capability is dependent on notification capability. or Don't create session since exchange of capabilities failed due to notification capability dependency. Rgds, Rohit ------=_NextPart_000_0031_01CDD918.D98BC230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When NETCONF = server receives Interleave capability from NETCONF client without = notification capability what should be the behavior of NETCONF server = ?

 

Please let me know what expected behavior = is.

 

Here are my thoughts :

         &= nbsp;      Since notification capability is not = exchanged, remove interleave capability in session supported = capabilities and behave as if normal session i.e. receive, process and respond to = requests on session without notification support.

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           = or

         &= nbsp;      Create session and don’t allow = any operations i.e. dead session because interleave capability is = dependent on notification capability.

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  =             &= nbsp;           &n= bsp;       or

   =    Don’t create session since exchange of = capabilities failed due to notification capability = dependency.

 

Rgds,

Rohit

------=_NextPart_000_0031_01CDD918.D98BC230-- From j.schoenwaelder@jacobs-university.de Wed Dec 12 23:32:30 2012 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 14F0121F8AA6 for ; Wed, 12 Dec 2012 23:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5jSyR6eEmDt for ; Wed, 12 Dec 2012 23:32:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 461F221F8A9D for ; Wed, 12 Dec 2012 23:32:28 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FD6020C67; Thu, 13 Dec 2012 08:32:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id l5bC0efT8RE8; Thu, 13 Dec 2012 08:32:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E51BC20C65; Thu, 13 Dec 2012 08:32:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9EDB7236A8C8; Thu, 13 Dec 2012 08:32:35 +0100 (CET) Date: Thu, 13 Dec 2012 08:32:35 +0100 From: Juergen Schoenwaelder To: Rohit Pobbathi Message-ID: <20121213073235.GB60374@elstar.local> Mail-Followup-To: Rohit Pobbathi , andy@yumaworks.com, netconf@ietf.org References: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Require clarification when NETCONF server receives Interleave Capability without Notification Capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 07:32:30 -0000 On Thu, Dec 13, 2012 at 10:01:40AM +0530, Rohit Pobbathi wrote: > Hi, > > When NETCONF server receives Interleave capability from NETCONF client > without notification capability what should be the behavior of NETCONF > server ? > > Please let me know what expected behavior is. > > Here are my thoughts : > > Since notification capability is not exchanged, remove > interleave capability in session supported capabilities and behave as if > normal session i.e. receive, process and respond to requests on session > without notification support. > > or > Create session and don't allow any operations i.e. dead > session because interleave capability is dependent on notification > capability. > > or > > Don't create session since exchange of capabilities failed due to > notification capability dependency. I think the Postel principle applies - your server should ignore it for the sake of interoperability. It may log this though. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Dec 13 00:25:43 2012 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 1089321F8AAC for ; Thu, 13 Dec 2012 00:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Caw4nStbCC-y for ; Thu, 13 Dec 2012 00:25:42 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 80A5021F8AAE for ; Thu, 13 Dec 2012 00:25:42 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 32C201200D10; Thu, 13 Dec 2012 09:25:40 +0100 (CET) Date: Thu, 13 Dec 2012 09:25:39 +0100 (CET) Message-Id: <20121213.092539.493947783057099860.mbj@tail-f.com> To: rohit.pobbathi@huawei.com From: Martin Bjorklund In-Reply-To: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> References: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Require clarification when NETCONF server receives Interleave Capability without Notification Capability 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, 13 Dec 2012 08:25:43 -0000 Hi, Rohit Pobbathi wrote: > Hi, > > > > When NETCONF server receives Interleave capability from NETCONF client > without notification capability what should be the behavior of NETCONF > server ? These capabilities are used for the *server* to inform the client about what operations it (the server) supports. A client that wants to create a notifcation or use interleave does not have to advertise anything to the server. So the server ignores these capabilities if they are sent from a client. /martin From jernej.tuljak@mg-soft.si Thu Dec 13 00:26:47 2012 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 CD9B321F8AAB for ; Thu, 13 Dec 2012 00:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDKZ4pdLnmmh for ; Thu, 13 Dec 2012 00:26:46 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id C3FEA21F8AAC for ; Thu, 13 Dec 2012 00:26:45 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id qBD8Qb0I021016; Thu, 13 Dec 2012 09:26:37 +0100 Message-ID: <50C9913A.5030406@mg-soft.com> Date: Thu, 13 Dec 2012 09:26:34 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rohit.pobbathi@huawei.com References: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> In-Reply-To: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> Content-Type: multipart/alternative; boundary="------------020902030409080209030502" Cc: netconf@ietf.org Subject: Re: [Netconf] Require clarification when NETCONF server receives Interleave Capability without Notification Capability 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, 13 Dec 2012 08:26:47 -0000 This is a multi-part message in MIME format. --------------020902030409080209030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Why would the server even care about what capabilities the client supports (except base NETCONF capabilities which indicate protocol version)? A client adapts to the server, not the other way around. This is only true while, when it comes to interaction between a client and a server, everything is initiated on the client side (currently the case). This came up during inter-ops too. I think it should be made clear whether the only negotiation done during hello exchange is for protocol version and if negotiating anything else is even standard. This is something individual capabilities appear to handle and since no NETCONF capability except base have text which would require both peers to advertise it, negotiating anything else is non-standard. Note that not clarifying this could lead to server implementations which require that a client advertises the exact same capabilities as the server did. We had at least one example of such an implementation during inter-ops which should have raised some flags. Jernej Dne 13.12.2012 5:31, pis(e Rohit Pobbathi: > > Hi, > > When NETCONF server receives Interleave capability from NETCONF client > without notification capability what should be the behavior of NETCONF > server ? > > Please let me know what expected behavior is. > > Here are my thoughts : > > Since notification capability is not exchanged, remove > interleave capability in session supported capabilities and behave as > if normal sessioni.e. receive, process and respond to requests on > session without notification support. > > or > > Create session and don't allow any operations i.e. > dead session because interleave capability is dependent on > notification capability. > > or > > Don't create session since exchange of capabilities failed due > to notification capability dependency. > > Rgds, > > Rohit > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------020902030409080209030502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Why would the server even care about what capabilities the client supports (except base NETCONF capabilities which indicate protocol version)? A client adapts to the server, not the other way around. This is only true while, when it comes to interaction between a client and a server, everything is initiated on the client side (currently the case).

This came up during inter-ops too. I think it should be made clear whether the only negotiation done during hello exchange is for protocol version and if negotiating anything else is even standard. This is something individual capabilities appear to handle and since no NETCONF capability except base have text which would require both peers to advertise it, negotiating anything else is non-standard.

Note that not clarifying this could lead to server implementations which require that a client advertises the exact same capabilities as the server did. We had at least one example of such an implementation during inter-ops which should have raised some flags.

Jernej

Dne 13.12.2012 5:31, piše Rohit Pobbathi:

Hi,

 

When NETCONF server receives Interleave capability from NETCONF client without notification capability what should be the behavior of NETCONF server ?

 

Please let me know what expected behavior is.

 

Here are my thoughts :

                Since notification capability is not exchanged, remove interleave capability in session supported capabilities and behave as if normal session i.e. receive, process and respond to requests on session without notification support.

                                                                                or

                Create session and don’t allow any operations i.e. dead session because interleave capability is dependent on notification capability.

                                                                                or

      Don’t create session since exchange of capabilities failed due to notification capability dependency.

 

Rgds,

Rohit



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

--------------020902030409080209030502-- From lhotka@nic.cz Thu Dec 13 01:30:22 2012 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 D5D4A21F895D for ; Thu, 13 Dec 2012 01:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZYREAljesfO for ; Thu, 13 Dec 2012 01:30:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4C62B21F87E1 for ; Thu, 13 Dec 2012 01:30:21 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BA0E213F69F; Thu, 13 Dec 2012 10:30:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355391019; bh=IVCU4CABEdDdbzcyT3ccxH2ItSuS8YUmxVVN1xLxVLw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YEMITC+EcsdPKOHqtHN8fjHqmzTrUYYgcz6tieHBiQFK+17+To0rPJRow3oR/00D4 sRKrR0X01Dcx0vew5NtA0QWB5JHeCNDjQ/YmH+kQmixs5SEu0tyq7GmPAa/9RmtoTi 9tGZ7/PMEFDzFPyuhOWX8NGSrfASKvVI5sv38aP0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121213.092539.493947783057099860.mbj@tail-f.com> Date: Thu, 13 Dec 2012 10:30:26 +0100 Content-Transfer-Encoding: 7bit Message-Id: <5B1C910B-FA27-4895-AA1F-2811E535E4F6@nic.cz> References: <003001cdd8ea$bfd38630$3f7a9290$@pobbathi@huawei.com> <20121213.092539.493947783057099860.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Require clarification when NETCONF server receives Interleave Capability without Notification Capability 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, 13 Dec 2012 09:30:22 -0000 On Dec 13, 2012, at 9:25 AM, Martin Bjorklund wrote: > Hi, > > Rohit Pobbathi wrote: >> Hi, >> >> >> >> When NETCONF server receives Interleave capability from NETCONF client >> without notification capability what should be the behavior of NETCONF >> server ? Maybe it is just the usual server versus client confusion? Lada > > These capabilities are used for the *server* to inform the client > about what operations it (the server) supports. > > A client that wants to create a notifcation or use interleave does not > have to advertise anything to the server. > > So the server ignores these capabilities if they are sent from a > client. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Dec 13 07:18:56 2012 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 D2AB221F8689 for ; Thu, 13 Dec 2012 07:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyzDioGZtozR for ; Thu, 13 Dec 2012 07:18:56 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C982521F8B73 for ; Thu, 13 Dec 2012 07:18:55 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2454440vcb.31 for ; Thu, 13 Dec 2012 07:18:50 -0800 (PST) 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=U13ZCRHT4qhurnwtZejhiWGNbN+PQDUo7LNDazXt5Uk=; b=mKU8Tq8mfeeXXtOkGbnhWXj3R8EFtJxLwlUYe37ZaTgDd3RJkcCx2LOXevxv+HQ1mi yP7jO1PGL8+WPElAs1tXgCD5OaNGREA+mWlNjwTl6MsSnmiF0983ajgPguVU3HJGeVBm FUguKqD+5ZR037uVGVVltFX6aEJfOno38RbpP2uBKmFZrT0yb676lDu0NZBwn4u1cepN j4bt41GIBrM7RUocnaVRqktQ6hiXzg/YMmRmIS5tbccrsqcAZIlzuLi3v+UZl0ctoFg/ uN7uSTdoGTPssvmYFDhyMGGiMzeEkai9FmuIqZ2fpGGyxCpT004hA5UEy3N7lQlYIO2G Axaw== MIME-Version: 1.0 Received: by 10.52.67.133 with SMTP id n5mr3426842vdt.24.1355411930224; Thu, 13 Dec 2012 07:18:50 -0800 (PST) Received: by 10.58.46.204 with HTTP; Thu, 13 Dec 2012 07:18:50 -0800 (PST) In-Reply-To: <5B1C910B-FA27-4895-AA1F-2811E535E4F6@nic.cz> References: <20121213.092539.493947783057099860.mbj@tail-f.com> <5B1C910B-FA27-4895-AA1F-2811E535E4F6@nic.cz> Date: Thu, 13 Dec 2012 07:18:50 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf307f397ca017ad04d0bd6e23 X-Gm-Message-State: ALoCoQlit4CMIYZ+QvhgR49YYy27qwTkAxEnHd5FH1NjjWkV6FZ51hmu5l7oRZ3ve8ruiVfrLhS9 Cc: netconf@ietf.org Subject: Re: [Netconf] Require clarification when NETCONF server receives Interleave Capability without Notification Capability 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, 13 Dec 2012 15:18:57 -0000 --20cf307f397ca017ad04d0bd6e23 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 1:30 AM, Ladislav Lhotka wrote: > > On Dec 13, 2012, at 9:25 AM, Martin Bjorklund wrote: > > > Hi, > > > > Rohit Pobbathi wrote: > >> Hi, > >> > >> > >> > >> When NETCONF server receives Interleave capability from NETCONF client > >> without notification capability what should be the behavior of NETCONF > >> server ? > > Maybe it is just the usual server versus client confusion? > > Yes -- the client can send whatever capabilities it wants, except the server only looks for base:1.0 and base:1.1. The server cannot send just :interleave: (see 6.2 below) 6.1. Description The :interleave capability indicates that the NETCONF peer supports the ability to interleave other NETCONF operations within a notification subscription. This means the NETCONF server MUST receive, process, and respond to NETCONF requests on a session with an active notification subscription. This capability helps scalability by reducing the total number of NETCONF sessions required by a given operator or management application. 6.2. Dependencies This capability is dependent on the notification capability being supported. > Lada > Andy > > > > > These capabilities are used for the *server* to inform the client > > about what operations it (the server) supports. > > > > A client that wants to create a notifcation or use interleave does not > > have to advertise anything to the server. > > > > So the server ignores these capabilities if they are sent from a > > client. > > > > > > /martin > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --20cf307f397ca017ad04d0bd6e23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 13, 2012 at 1:30 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
mbj@tail-f.com> wrote:

> Hi,
>
> Rohit Pobbathi <rohit.= pobbathi@huawei.com> wrote:
>> Hi,
>>
>>
>>
>> When NETCONF server receives Interleave capability from NETCONF cl= ient
>> without notification capability what should be the behavior of NET= CONF
>> server ?

Maybe it is just the usual server versus client confusion?


Yes -- the client can send whatever ca= pabilities it wants,
except the server only looks for base:1.0 an= d base:1.1.

The server cannot send just :interleav= e: (see 6.2 below)

6.1=
.  Description

   The :interleave capability indicates that the NETCONF peer supports
   the ability to interleave other NETCONF operations within a
   notification subscription.  This means the NETCONF server MUST
   receive, process, and respond to NETCONF requests on a session with
   an active notification subscription.  This capability helps
   scalability by reducing the total number of NETCONF sessions required
   by a given operator or management application.

6.2.  Dependencies

   This capability is dependent on the notification capability being
   supported.


=C2=A0
Lada


Andy
=C2= =A0

>
> These capabilities are used for the *server* to inform the client
> about what operations it (the server) supports.
>
> A client that wants to create a notifcation or use interleave does not=
> have to advertise anything to the server.
>
> So the server ignores these capabilities if they are sent from a
> client.
>
>
> /martin
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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




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

--20cf307f397ca017ad04d0bd6e23--