Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Nov 2013 13:58:59 +0100

On Thu, Oct 31, 2013 at 11:17:40AM -0700, Joe Touch wrote:
> 
> 
> On 10/31/2013 11:14 AM, Martin Bjorklund wrote:
> >Kent Watsen <[email-masked]> wrote:
> >>
> >>
> >>On 10/31/13 1:46 PM, "Joe Touch" <[email-masked]> wrote:
> >>
> >>>
> >>>Why would (should) that not happen in-band, as part of the message type?
> >>
> >>Because it would require updating both the SSH and TLS protocols to enable
> >>reversal before the crypto tunnel is setup.  This is not likely to garner
> >>consensus given the Applicability Statements limiting the solution to just
> >>NETCONF, especially given the option to use a port instead.
> >
> >Agreed.  Also, I think these are fundamentally two different services;
> >one is a NETCONF server (e.g. some managed device) and the other a
> >NETCONF client (e.g. a NMS).
> 
> First, can any of that be explained in this doc?
> 
> In specific:
> 
> 	- how the services differ
> 
> 	- why reversing the existing netconf-ssh system
> 	isn't a useful way forward
> 
> 	- the specific use case where both a client and server
> 	would sit on the same device, and why those would be independent
> 
> All of these questions are begged by the name "reverse NETCONF". If
> that's not what you're really doing, this needs a better, more
> accurate description.

Does this help:

  A NC client and a NC server provide two different services. The NC
  server executes RPC requests and manipulates local datastores while
  the NC client invokes RPC requests. It is possible to have both an
  NC server and an NC client running on the same node (e.g., the node
  runs a NC server and the NC client on the same node manages the
  node's configuration via NC).

  The port number xyz is used by NC servers. NC clients connect	to the
  server on port xyz in order to execute RPC calls on the server.  The
  port number abc is used by NC clients if they support call-home.  An
  NC server using call-home will connect to an NC client in order to
  let the client subsequently initiate RPC calls. The NC client has
  the logic to manipulate configurations (e.g., executing network-wide
  configuration change transactions) while the NC server provides an
  interface to manage (edit) its local configuration maintained in
  configuration datastores.

/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: Joe Touch <[email-masked]>
Date: Fri, 01 Nov 2013 07:17:27 -0700

On 11/1/2013 5:58 AM, Juergen Schoenwaelder wrote:
...
>    configuration datastores.

It confirms what I said - that this is just the reverse initiation of an 
existing service. If that is justification for an assignment, then we 
would need to potentially double the existing assignments and the rate 
of assignments - which is why this is problematic and very likely untenable.

I'll continue this discussion with others off-list, but at the least the 
document needs to more clearly explain why a new port is being requested.

Joe

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 01 Nov 2013 15:40:26 +0100 (CET)

Joe Touch <[email-masked]> wrote:
> It confirms what I said - that this is just the reverse initiation of
> an existing service. If that is justification for an assignment, then
> we would need to potentially double the existing assignments and the
> rate of assignments - which is why this is problematic and very likely
> untenable.

I think we're going in circles.

I think that you suggest that a single port is used, and that some
signalling is used in-band before the SSH session is started.  This
would be fine, except that this is not how the existing protocol (on
port 830) works.   (I think there are other usability issues with this
approach as well, but that's not important now).

So this in-band signalling doesn't work; and we need a new port.

If this is not what you propose, could you explain what you mean?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Nov 2013 07:54:34 -0700

> I think we're going in circles.
Agreed

> approach as well, but that's not important now).

I think the usability issues are important.
Let's say there was only 1 shared port.
An "SSH dispatcher" would have to be rewritten so it could examine
the NETCONF <hello> message to decide if the session
was for the MLM or the server.  But this is too late, because SSH
has to be setup correctly first.  It is also possible that an operator would
want to block access on specific ports for 1 role but not the other.
This is not possible if they use the same port number.

> If this is not what you propose, could you explain what you mean?
Andy

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 1 Nov 2013 08:10:11 -0700

> If this is not what you propose, could you explain what you mean?

Here's the counterargument:

- if that's true for netconf, is it not true for every other service?

- would that not double the current allocation, and all future allocations?

- how would that impact the consumption of the port space?

That's the problem. You're talking about difficulty of a software implementation or complexity of management; I'm talking about burning port numbers in a way that isn't sustainable.

That's my concern. I'm not yet convinced that making an exception for this case doesn't open the floodgates to a problem that might render the port space full too quickly.

Joe

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 01 Nov 2013 16:17:13 +0100 (CET)

Joe Touch <[email-masked]> wrote:
> That's the problem. You're talking about difficulty of a software
> implementation or complexity of management;

No, it is not an implementation problem, it is a specification
problem.

If you have a solution that lets us reuse a single port, that's great!
Could you share this solution?

/martin

> I'm talking about burning
> port numbers in a way that isn't sustainable.
> 
> That's my concern. I'm not yet convinced that making an exception for
> this case doesn't open the floodgates to a problem that might render
> the port space full too quickly.
> 
> Joe

---

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Nov 2013 15:22:31 +0000

>- if that's true for netconf, is it not true for every other service?

No, because we're talking about reversing the crypto layer and not every
service has a crypto layer and, for those that do, none other has a need
to reverse its crypto layer.  This is currently a very unique situation
we're discussing for NETCONF.

>- would that not double the current allocation, and all future

If it were true, yes, but it's not true (see above)

>- how would that impact the consumption of the port space?

We're asking for a total of 2 new ports (one to reverse SSH and another to
reverse TLS)

>implementation or complexity of management; I'm talking about burning

No sustainability issue - this is a one-off.

>this case doesn't open the floodgates to a problem that might render the
>port space full too quickly.

I think this is unlikely to happen in our lifetimes.

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Nov 2013 09:42:03 -0700

...
> We're asking for a total of 2 new ports (one to reverse SSH and another to

Why would that not apply to every other service over SSH or TLS?

...
> No sustainability issue - this is a one-off.

For Netconf. I'm considering the impact in the broader context.

Joe

---

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Nov 2013 17:08:09 +0000

>Why would that not apply to every other service over SSH or TLS?

For one, the Applicability Statements on these drafts limit the proposed
solution to just NETCONF.

But to your point, it's possible that someday another management protocol
may need reversal, but I don't see why any protocol other than a
management protocol would want to do this.

FWIW, all SSH-based protocols that wanted to be reversed could share the
same port.  This is possible because the client could just as easily start
their subsystem instead of the "netconf" subsystem.  Only the
applicability statement in the reverse-ssh draft would need to be changed
to allow it.  So, even in the worst case scenario, no more than one port
would be needed to reverse SSH-based protocols.

TLS lacks any form of a session protocol enabling to client to select
which application-level protocol it wants to run, so a new port would be
needed for each TLS-based protocol needing reversal.  But as mentioned
before, it's not understood why any non-management protocol would need
reversal

>For Netconf. I'm considering the impact in the broader context.

I understand.  What I meant that that within all of the IETF this seems
like a one-off.  

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Nov 2013 11:22:47 -0700

> would be needed to reverse SSH-based protocols.

The same argument for Netconf-ssh reversal applies to all SSH extensions 
of services - none of which use SSH ports directly (they all have 
dedicated ports).

> before, it's not understood why any non-management protocol would need

Sure, but all the "TLS"-suffixed ports are generally management services 
with this property.

> I understand.  What I meant that that within all of the IETF this seems

If there's a case for that, I'd be glad to hear it, but so far 
everything (incluging the above) applies to every SSH and TLS extended 
service.

Joe

---

From: t.petch <[email-masked]>
Date: Fri, 1 Nov 2013 18:31:32 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Joe Touch" <[email-masked]>; "Andy Bierman" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Friday, November 01, 2013 5:08 PM
> >> We're asking for a total of 2 new ports (one to reverse SSH and
another
> >>to

Kent

I think that that is a spurious argument.  Just because TLS has not got
a session layer (some would say SSH hasn't but I know what you are
getting at) does not mean that there cannot be a session layer protocol
negotiating what happens next - I have proposed just such a one in the
past.  And there are plenty of such protocols in the early days of the
Internet (from where I got my inspiration).  We would be using far fewer
ports if such session layers were more widespread but I accept that they
are not.

I understand the other points you are making but I think it weakens your
case to argue that because TLS has no session layer then there cannot be
such a layer.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Nov 2013 11:57:44 -0700

Hi Tom,

If a server trying to call-home actually connects to a real NETCONF server
instead of a client, then (if the SSH session gets established) both
NETCONF servers will ignore the <session-id> in the other's <hello>
message and both will sit there waiting for <rpc> requests.

I am also concerned about ACL configuration.
It is very likely that an operator would block one role or the other,
but not both, based on the location of the NMS, MLMs, and devices
in the network.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Nov 2013 19:17:08 +0000

Good point, Tom.

Even good old tcpmux (port 1) defined by Jon Postel...

You're right that, if a session-layer were added between TLS and the
app-protocol, then the necessary indirection would be in place to allow
IETF to only use one port for all protocols.  I recall Joe Touch
mentioning working on such a thing as well.   [technically, we'd need two
ports, one for TLS and another for reverse-TLS]

To be honest, I don't know why we're still clinging to ports, given that
firewalls have long-past moved beyond port-based filtering.  I would
welcome IETF standardizing something in this area.  In the meanwhile, we
are where we are, hence the request for a port.

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Nov 2013 13:32:19 -0700

> ports, one for TLS and another for reverse-TLS]

Not quite; I was working on a way to decouple the service name from the 
port number. That would not involve using a single port for all 
services; that would constrain the number of concurrent connections more 
than now, rather than relieve those constraints.

The original idea is here, though it's evolving and we should be issuing 
an update shortly, as we're implementing it in Linux and FreeBSD:
http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt

> are where we are, hence the request for a port.

To to be clear, I'm not talking about zeroconf, mDNS, tcpmux, or 
portnames as an alternative. Regardless of the utility of those 
mechanisms, there will always be requests for specific port numbers, 
e.g., to allow network administrators to (try to) identify services by 
port and manage access (e.g., firewalls) accordingly.

I do see the goal here, and the reason for the request. I appreciate 
that the floodgates have not yet opened, but I'm concerned that if 
netconf over SSH or SSL needs separate port numbers for each service 
when connections are initiated in reverse, that the same will be true 
for dozens of other services over SSH or SSL. So this problem isn't 
going away, and I am hoping those involved here can at least:

	- appreciate the problem
	- address it more carefully in this doc
	- explore alternatives, and at least explain why
	they don't currently work

At a minimum that would help us all figure out how to handle this for 
the next service that makes this request.

Joe

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 2 Nov 2013 20:01:25 +0000

Dear Joe, All,

We indeed are going in circles.

> and I am hoping those involved here can at least:
> 	- appreciate the problem

Thank you for your suggestions. We will.

At the end the decision will be taken in the NETCONF session based on the options available.

Cheers, 
Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
> Joe Touch
> Sent: Friday, November 01, 2013 9:32 PM
> To: Kent Watsen; t.petch
> Cc: Netconf
> Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
> 
> 
>

---

From: t.petch <[email-masked]>
Date: Sun, 3 Nov 2013 11:33:38 +0000

Andy

I think I understand what is being requested, that the Netconf server is
the SSH server but is the TCP client.  I note however the first line of
the I-D
  "This memo presents a technique for a NETCONF server to initiate a SSH
   connection to a NETCONF client."
It appears to me that that could be clearer, perhaps saying
"This memo presents a technique for a NETCONF server to request a
NETCONF client to initiate a SSH connection to a NETCONF server."

If I understand correctly, expressed thus, all is needed is a signal
from NETCONF server to NETCONF client to get on with it, and that signal
could be anything, any PDU, any option (a TCP Option? mmm perhaps not),
any alarm, alert etc.

Looking at it like that, I sympathise with those who think that this may
not be the best use of a Port, a resource limited in scope which one day
we will run out of.

The signal could even be a SYN; if I get a SYN from an address I am
configured to understand with a source port assigned for X over Y, then
assume that that address wants me to start X over Y as a client.  Works
for all protocols X and all protocols Y.

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Kent Watsen" <[email-masked]>; "Joe Touch" <[email-masked]>;
"Netconf" <[email-masked]>
Sent: Friday, November 01, 2013 6:57 PM
Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt

> > > FWIW, all SSH-based protocols that wanted to be reversed could
share
> > the
> > > same port.  This is possible because the client could just as
easily
> > start
> > > to allow it.  So, even in the worst case scenario, no more than
one
> > port
> > > which application-level protocol it wants to run, so a new port
would
> > be

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 3 Nov 2013 19:52:30 +0100

> for all protocols X and all protocols Y.

Sorry, this is really going into the very wrong direction from an
architectural point of view.

Such a negotiation needs to happen at the application layer and with
NC as it defined today, this implies that it happens _after_ the
secure transport has been established. Even with TLS (which uses certs
on both sides), I learned at the last IETF that this does not work
because even certs are not necessarily symmetric in their properties.
With SSH, it is clear that the security association is not symmetric.
As such, security people adviced us that the 'direction (who is client
and who is server)' must already be clear before the secure transport
is established. And this means we need separate ports.

/js

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Nov 2013 11:26:31 -0800

FWIW, this seems like an excellent alternative, given the goal of doc.

Joe

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Nov 2013 14:52:34 -0800 (PST)

Hi,

> > could be anything, any PDU, any option (a TCP Option? mmm perhaps not),

If the NETCONF server is behind a fw or nat, the NETCONF client might
not be able to connect to the NETCONF server.

> > configured to understand

The NETCONF client does not know the address of the NETCONF server in
advance.

/martin

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Nov 2013 15:04:19 -0800

> not be able to connect to the NETCONF server.

That seems like an intended consequence of putting a server behind a 
firewall or NAT.

> The NETCONF client does not know the address of the NETCONF server in

I'm confused about the case where a client doesn't know the server but 
the converse is true. Seems like you're begging for mDNS, at which point 
you could record the relevant port information there.

Joe

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Nov 2013 00:30:21 +0000

Hi Joe,

This issue was discussed in the NETCONF WG meeting.  Specifically, the
choices of:

  - having a default port
  - not having a default port (port has to be explicitly configured)
  - try to update the TLS and SSH protocols to support reversal

There was unanimous support in the room to have a default port (around 30
people).  No one raised their hand to support any other option.

Playing devil's advocate, I made a case for having NO default port.  That
is, for the ZeroTouch solution, the device is already learning so much
NMS-specific information, learning a port number also is easy.
Unfortunately, reverse-SSH and reverse-TLS can be used outside of
ZeroTouch and, for those cases, the port would then need to be manually
configured, which people didn't like.

As a quick recap, we initially took Reverse SSH to the SSH list, but it
died there due to this port issue.  Reverse SSH was resurrected after
receiving a lot of operator demand for it.  We decided to bring Reverse
SSH to NETCONF WG specifically to end the discussion of if it uses an
in-band or out-of-band mechanism to trigger the reversal.  The NETCONF WG
consensus was at that time and is still to use a port.

Thanks,
Kent

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Wed, 6 Nov 2013 18:11:05 +0000

Hi Kent,

>configured, which people didn't like.

Is there any reason that reverse-SSH cannot use the default SSH port 22?

And even if a default port is assigned for reverse-SSH/reverse-TLS,
ZeroTouch should allow a non-default port be provisioned, which seems
missed in current draft -- Actually, the mechanism to offer the port is
already built in the DNS with using SRV record.

Yi

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Nov 2013 01:02:26 +0000

>Is there any reason that reverse-SSH cannot use the default SSH port 22?

The only way we could use port 22 would be to update the SSH protocol
enabling in-band negotiation for reversal.  This may be technically
possible, but there is little support for this approach.

>missed in current draft

That is an omission.   The configuration model described in the Reverse
SSH draft enables a port to be specified and we would, of course, want it
to be configurable via ZeroTouch as well.  Thanks for pointing it out.

> Actually, the mechanism to offer the port is

Which DNS records ZeroConf uses is TBD, but this sounds viable.

Thanks,
Kent