Re: [Netconf] NETCONF call home and new port assignment

"Reinaldo Penno (repenno)" <repenno@cisco.com> Tue, 25 February 2014 19:12 UTC

Return-Path: <repenno@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D161A045D for <netconf@ietfa.amsl.com>; Tue, 25 Feb 2014 11:12:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.448
X-Spam-Level:
X-Spam-Status: No, score=-14.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3ENp1EptL6X for <netconf@ietfa.amsl.com>; Tue, 25 Feb 2014 11:12:04 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0B71A0293 for <netconf@ietf.org>; Tue, 25 Feb 2014 11:12:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11220; q=dns/txt; s=iport; t=1393355520; x=1394565120; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lVDgxItJk1pc1qI+VnC0NtZ/bsjWwaNsdmT9DjDaGzY=; b=G/kLDERvaGeYjOsFoqjjVAKXyWjXwCb1FSCnNsrANjmVBElFY3SId6Db bGsSe4MW+qr92BwgSlj69OUFvJcrOfmOLi6F4Vet/AgD4IGMG60ra4b2U yaG+djDFW9l7wc3vlnuaGUoyutyx3SBvCsafP9ftMRbpsGUw/Lr+QISzM k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAJnqDFOtJXG8/2dsb2JhbABWA4MGO1eDA71+TxiBARZ0giUBAQEEAQEBJA03AwsMAgQBCA4CAQMBAgEEKAQZDAsdCAIEDgUJEodqDYp2m3cGoSIXBIEfjFwBARwNCwsQBwYLgliBTwSYNpIogy2BcTk
X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="306421902"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 25 Feb 2014 19:12:00 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PJBqdv021500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 19:11:52 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 13:11:52 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [Netconf] NETCONF call home and new port assignment
Thread-Index: AQHPMh0sIMAEhPViDUCrzWQVqmFe/JrGgIWAgAABzoD//4++AIAAoZQA//+BeAA=
Date: Tue, 25 Feb 2014 19:11:51 +0000
Message-ID: <CF322A20.99BF%repenno@cisco.com>
In-Reply-To: <20140225184442.GB4469@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.74.73]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <97E5E4040E122345B4464FB6783594E3@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KgKcAD-3cHEdEW0uOSwPIFqlFYo
Cc: netconf <netconf@ietf.org>
Subject: Re: [Netconf] NETCONF call home and new port assignment
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 19:12:10 -0000


On 2/25/14, 10:44 AM, "Juergen Schoenwaelder"
<j.schoenwaelder@jacobs-university.de> wrote:

>Hi,
>
>I am somewhat confused. NETCONF so far assumes that the device can be
>contacted by opening a TCP connection from the NMS to the device. In
>case the NMS is behind a NAT, this works just fine.
>The call home work
>was started to deal with situations where the device is behind a NAT

I think the term “behind” is confusing. I’m assuming device (router,
switch, etc) is in the public network (outside the NAT) and NMS is in the
private network. NMS can open connections to any device without problems
but reverse connections are normally not allowed.

>while the NMS is not. This is the problem we are solving.

If there is a NAT in between, the device outside the NAT normally would
not be able to connect to the device inside the NAT (in the private
network). 


>
>The case of both the device behind a NAT and the NMS behind a NAT is
>somewhat esoteric - does someone deploying networks really expect that
>this would work? Are you saying this problem needs to be solved based
>on real deployment experience where this happens? (I would assume in
>such a setup pretty much everything stops working.)

>
>/js
>
>On Tue, Feb 25, 2014 at 05:06:25PM +0000, Reinaldo Penno (repenno) wrote:
>> I have some comments on this draft.
>> 
>> Since the draft proposes a ³cold² reverse connection I was expecting
>>some
>> discussion on the traversal of middleboxes. Given folks that have been
>> deploying NMS implicitly take for granted that connections are always
>> inside->out, with the exception of SNMP traps, such a draft should
>>assume
>> some pitfalls and suggest ways around them. In the case of SNMP for
>> example, the ³solution² is firewalls/NATs that implement SNMP ALG, but
>> even then, a first inside->outside connection is expected.
>> 
>> Some points to consider:
>> 
>> - The NMS IP address downloaded from config server can not be behind a
>> firewall unless there is some pinhole or traversal method the device can
>> use
>> - If NMS is behind a NAT, the IP:port should be the outside and stable.
>> - In the worst case maybe configuration server (which theoretically
>>could
>> be reached by both parties) could d server as a relay.
>> - If a NAT exists between NMS and device, one can not assume registered
>> ports will be available.  Therefore config server needs to be able to
>>send
>> port information.
>> - Device should be prepared to check with configuration server is
>>external
>> port has changed due to state being removed on the NAT.
>> 
>> Thanks,
>> 
>> -RP
>> 
>> 
>> On 2/25/14, 7:48 AM, "Bert Wijnen (IETF)" <bertietf@bwijnen.net> wrote:
>> 
>> >
>> >
>> >On 25/02/14 16:41, Kent Watsen wrote:
>> >>
>> >> I believe that is the case as well, but note that we need two port
>> >> assignments - one for reverse-SSH and another for reverse-TLS.
>> >>
>> >I think that is fine.
>> >It was/is the principle that we CAN ask for a port number if we have
>> >consecensus
>> >that that is what we want.
>> >
>> >Bert
>> >
>> >> Cheers!
>> >> Kent
>> >>
>> >>
>> >>
>> >> On 2/25/14 6:31 AM, "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
>>wrote:
>> >>
>> >>> NETCONF WG participants,
>> >>>
>> >>> there has been quite some discussion about this topic on our mailing
>> >>>list.
>> >>> We (WG chairs) have asked our AD (Benoit) to follow up in the IESG.
>> >>>
>> >>> Our current understanding is that if our WG has consensus on asking
>>for
>> >>> a new port, then we can do so and we should get one.
>> >>>
>> >>> We (WG chairs) belive we have (at least rough) consensus on this
>>matter
>> >>> and so we will ask for a new port.
>> >>>
>> >>> Bert and Mehmet
>> >>>
>> >>>
>> >>> -------- Original Message --------
>> >>> Subject: Re: NETCONF call home and new port assignment
>> >>> Resent-To: bertietf@bwijnen.net, mehmet.ersue@nsn.com,,
>> >>> bclaise@cisco.com, joelja@bogus.com, jjaeggli@zynga.com
>> >>> Date: Mon, 20 Jan 2014 15:58:52 +0100
>> >>> From: Benoit Claise <bclaise@cisco.com>
>> >>> CC: Joe Touch <touch@isi.edu>,
>>"netconf-chairs@tools.ietf.org"
>> >>> <netconf-chairs@tools.ietf.org>,        "Romascanu, Dan (Dan)"
>> >>> <dromasca@avaya.com>,        Lemon Ted <ted.lemon@nominum.com>,
>> >>> "ops-ads@tools.ietf.org" <ops-ads@tools.ietf.org>,
>> >>> Kent Watsen <kwatsen@juniper.net>
>> >>>
>> >>> Dear all,
>> >>>
>> >>> We discussed the issue of potentially allocating a new port for the
>> >>> NETCONF call home during our informal telechat last week.
>> >>> Personally, I wanted a confirmation on the procedure.
>> >>> Material:
>> >>> 
>> 
>>>>>http://www.iana.org/assignments/service-names-port-numbers/service-nam
>>>>>es
>> >>>-p
>> >>> ort-numbers.xhtml
>> >>> an
>> >>>      RFC 6335
>> >>>
>> >>> Bottom line: The review of the port assignment via IETF standards
>> >>> (consensus based) does not go to the port review
>> >>>
>> >>> There is strong consensus to allocate this port in the NETCONF WG.
>> >>> - http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf
>> >>>    30 in favor, 0 against
>> >>> - doublechecked on the mailing list
>> >>> http://www.ietf.org/mail-archive/web/netconf/current/msg08445.html
>> >>>
>> >>> So we're good here, let's proceed with the new port design
>> >>>
>> >>> Regards, Benoit
>> >>>
>> >>>> Hi, Benoit,
>> >>>>
>> >>>> On 11/4/2013 10:30 AM, Benoit Claise wrote:
>> >>>>> Hi Joe,
>> >>>>>
>> >>>>> Regarding the "NETCONF call home and new port assignment"
>>discussion
>> >>>>>on
>> >>>>> the NETCONF mailer, I'm wondering if your comments are made as the
>> >>>>>port
>> >>>>> expert reviewer or as a contributor.
>> >>>>
>> >>>> The ports review team doesn't participate in that role on these
>> >>>> discussions on the lists; we review requests and report directly to
>> >>>> IANA. So I'm speaking as a contributor, but it's with the ports
>>review
>> >>>> in the back of my mind.
>> >>>>
>> >>>>> In the NETCONF WG, there is strong consensus that the new port is
>>the
>> >>>>> preferred way. We checked that today: by a show of hand, everybody
>> >>>>> wanted a new port.
>> >>>>
>> >>>> Everyone always does.
>> >>>>
>> >>>>> I want to understand if there is a major flaw in requesting this
>> >>>>>port.
>> >>>>
>> >>>> There's often a case where the individual request makes sense, but
>>in
>> >>>> the broader context of "tragedy of the commons" it doesn't. That's
>>my
>> >>>> impression here. There should be other ways to accomplish this -
>>the
>> >>>> SYN attempt I recently saw looked like a good alternative that
>>would
>> >>>> scale to other assignments, e.g.
>> >>>>
>> >>>>> Note: I contacted it you directly, because I'm not sure how to
>>reach
>> >>>>> all
>> >>>>> the expert reviewers at the same time.
>> >>>>
>> >>>> There's no official way to do that. We respond to requests for
>>reviews
>> >>>> from IANA, and report back to IANA directly. There's no "official"
>> >>>> role for us in the IETF directly.
>> >>>>
>> >>>> Joe
>> >>>>
>> >>>>>
>> >>>>> 
>> 
>>>>>>>http://www.iana.org/assignments/service-names-port-numbers/service-n
>>>>>>>am
>> >>>>>es
>> >>>>> -port-numbers.xhtml
>> >>>>>
>> >>>>> is not explicit
>> >>>>>
>> >>>>> Regards, Benoit (OPS AD)
>> >>>> .
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> 
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>