Subject: [Netconf] regarding reducing number of future call-home ports

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Nov 2013 20:52:58 +0000

Here's an idea addressing Joe Touch's concern for port-proliferation:

1. Assume there is a defined TCP-port called the "call-home" port

2. The NMS accepts TCP connections from devices on this port

3. As soon as a TCP connection is established, the device sends a
cleartext message indicated which protocol it wants to run in reverse
(e.g. START_REVERSE_TLS, START_REVERSE_SSH, etc)

4. The NMS immediately starts the client-side of the protocol, the device
immediately starts the server-side of the protocol

5. We ensure all protocols have a "connection" layer.  SSH already has one
defined (rfc4254) that allows the NMS to start any subsystem it wants.
For instance, instead of starting the "netconf" subsystem, the NMS could
just as easily start an "snmp" or any other subsystem.

6. Thus, only one port would ever be needed regardless the number of
TCP-based transports or transport-tunneled protocols.

Discussing putting the SSH connection protocol on top of TLS with the Joe
Saloway, co-chair of the TLS WG, he said:  1) the idea has come up in the
past, 2) no has has done it yet because they always fall back to using a
port, and 3) if they were doing TLS from scratch, they would do it this
way.

OK, so that's that idea, the primary issues are:

  - do we have enough of a driver to make it happen?  - to define

    a connection protocol on top of TLS?  (mostly just repurposing
    rfc4254)

  - the NMS may be running more than one application and hence
    need more than call-home port.  This seems like a corner-case
    and solvable by the NMS by using explicitly assigned ports
    (so let's not worry about it)

What do you think?

PS: I also think using ports is OK, but I wanted to throw out this option
before we get any further...

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Nov 2013 00:04:50 +0100

>     (so let's not worry about it)

If you want to redo TLS, you likely have to do it in the TLS working
group. My understanding is that NETCONF is _using_ TLS and SSH and not
supposed to change or reinvent these security protocols.

At some point in time, you will need to clarify what 'application'
means. The RFCs I think only know NETCONF clients and servers.

/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: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Nov 2013 09:15:51 +0100

Hi Kent,

this might open another can of worms. I'd suggest to go forward without registering a well-known port. After all, a port number is just one extra item in the device's initial configuration.

Lada

Kent Watsen <[email-masked]> writes:

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Nov 2013 22:09:00 +0000

>supposed to change or reinvent these security protocols.

I'm unclear if it would be a built into TLS or a layer on top of it.
Either way, I agree that it wouldn't be for this WG to do.

Overall, there doesn't seem to be much interest in this proposal, so I
guess that we'll proceed without it - requesting 2 ports, one each for TLS
and SSH

Thanks,
Kent