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

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 25 Feb 2014 12:31:35 +0100

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: [email-masked], [email-masked],, [email-masked], [email-masked], [email-masked]
Date: Mon, 20 Jan 2014 15:58:52 +0100
From: Benoit Claise <[email-masked]>
CC: Joe Touch <[email-masked]>,        "[email-masked]" <[email-masked]>,        "Romascanu, Dan (Dan)" 
<[email-masked]>,        Lemon Ted <[email-masked]>,        "[email-masked]" <[email-masked]>, 
Kent Watsen <[email-masked]>

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-names-port-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-names-port-numbers.xhtml
>>
>> is not explicit
>>
>> Regards, Benoit (OPS AD)
> .
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Feb 2014 15:41:43 +0000

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.

Cheers!
Kent

On 2/25/14 6:31 AM, "Bert Wijnen (IETF)" <[email-masked]> wrote:

>Resent-To: [email-masked], [email-masked],,
>[email-masked], [email-masked], [email-masked]
>CC: Joe Touch <[email-masked]>,        "[email-masked]"
><[email-masked]>,        "Romascanu, Dan (Dan)"
><[email-masked]>,        Lemon Ted <[email-masked]>,
>"[email-masked]" <[email-masked]>,
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 25 Feb 2014 16:48:11 +0100

> 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

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 17:06:25 +0000

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)" <[email-masked]> wrote:

>>>http://www.iana.org/assignments/service-names-port-numbers/service-names
>>>-p
>>> ort-numbers.xhtml
>>> an
>>>      RFC 6335
>>>
>>>>>http://www.iana.org/assignments/service-names-port-numbers/service-nam
>>>>>es
>>>>> -port-numbers.xhtml
>>>>>
>>>>> is not explicit
>>>>>
>>>>> Regards, Benoit (OPS AD)
>>>> .
>>>>
>>>
>>>
>>>
>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Feb 2014 19:44:42 +0100

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
while the NMS is not. This is the problem we are solving.

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

-- 
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/>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 19:11:51 +0000

>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). 

>> >>>>> Regarding the "NETCONF call home and new port assignment"
>>discussion
>> >>>>>on
>> >>>>> Note: I contacted it you directly, because I'm not sure how to
>>reach
>> >>>>> all

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Feb 2014 20:27:10 +0100

> but reverse connections are normally not allowed.

In this case, standard NETCONF transports just work fine and you do
not need the call-home mechanism.

The call-home work is solving a different problem (where the device is
in a private network and hence the NMS can't connect to the device).
See for example section 2.1 of draft-ietf-netconf-rfc5539bis-05.txt
for a more detailed explanation.

/js

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 19:40:51 +0000

On 2/25/14, 11:27 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> I think the term ³behind² is confusing. I¹m assuming device (router,

That does not seem the intention of the draft at all. Are we talking about
http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01?

My expectation of a call home mechanism is about solving the important
problem of discovery decentralization.

A new device is installed on the network, all it needs is to download a
configuration file from a server and then connect to NMS (Netconf client).
Netconf client does not need to be configured with IP address of every new
device that comes in the network.

My expectation seems to match those of the draft which goes into the
benefits of such mechanism and problems it solves.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Feb 2014 21:45:45 +0100

> benefits of such mechanism and problems it solves.

Sorry, the subject line did not make it clear which I-D you are
referring to. One of the motivations for call home is to enable
management of devices that can be reached in the normal way because
they are behind a NAT (assuming you will figure out what behind means
in this context).

/js