Subject: [Netconf] reverse ssh recommendation

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2013 17:26:16 +0000

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?

Can we get a virtual hum?    http://www.surveymonkey.com/s/MWVNT7M

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jun 2013 10:52:30 -0700

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

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2013 19:02: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 Bierman <[email-masked]>
Date: Fri, 21 Jun 2013 12:35:28 -0700

On Fri, Jun 21, 2013 at 10:52 AM, Joe Touch <[email-masked]> wrote:

> implementation complexity and organizational challenges (WG boundaries) for
> port consumption.
>

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<http://www.surveymonkey.com/s/MWVNT7M>
>>
>> Thanks,
>> Kent
>>
>>
>>
>> ______________________________**_________________
>> Netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>
>>
>>  ______________________________**_________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2013 20:24:52 +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 <[email-masked]>
Date:  Friday, June 21, 2013 3:35 PM
To:  Joe Touch <[email-masked]>
Cc:  Kent Watsen <[email-masked]>, NetConf <[email-masked]>
Subject:  Re: [Netconf] reverse ssh recommendation

On Fri, Jun 21, 2013 at 10:52 AM, Joe Touch
<[email-masked]> wrote:

Dear NETCONF WG,

SSH protocol itself, as that is *their* charterŠ

Joe

Andy

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jun 2013 13:42:31 -0700

> 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 Bierman <[email-masked]>
Date: Fri, 21 Jun 2013 14:02:17 -0700

> 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

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jun 2013 14:07:35 -0700

On 6/21/2013 2:02 PM, Andy Bierman wrote:
>
>
> On Fri, Jun 21, 2013 at 1:42 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>

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: Joe Touch <[email-masked]>
Date: Fri, 21 Jun 2013 14:18:58 -0700

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

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

> 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 Bierman <[email-masked]>
Date: Fri, 21 Jun 2013 14:44:53 -0700

On Fri, Jun 21, 2013 at 2:07 PM, Joe Touch <[email-masked]> wrote:

> 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 <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,
which one is supposed to run when a TCP connection is made?

Joe
Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Jun 2013 14:50:47 -0700

> 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

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jun 2013 15:04:21 -0700

On 6/21/2013 2:44 PM, Andy Bierman wrote:
>
>
> On Fri, Jun 21, 2013 at 2:07 PM, Joe Touch <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                  I don't think the WG is using a port is for convenience
>         in this
>                  case.

FTP solved this years ago with the <pasv> 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: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2013 22:25:46 +0000

>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: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2013 22:55:32 +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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Jun 2013 07:40:11 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 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: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Jun 2013 11:58:28 +0000

> 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 needs a new port number.

Cheers, 
Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
> Martin Bjorklund
> Sent: Monday, June 24, 2013 7:40 AM
> To: [email-masked]
> Cc: [email-masked]