Subject: [sidr] rpki-rtr standard port

From: Randy Bush <[email-masked]>
Date: Wed, 09 Mar 2011 06:20:44 +0900

from a conversation with an rpki-rtr implementor

    >> is there a default TCP/SSH port that the servers are listening
    >> to?  i'll try to add those as defaults for the client piece when
    >> trying to establish a session.
    > no, we have not done this.  perhaps we should.

    it would make (debugging) life easier as i could also conveniently
    add proper printers for tcpdump and wireshark.

chairs, this may mean another round on the rpki-rtr draft

and then there is the question if there should be two ports, one ssh and
one unprotected.  this question opens a large hole, as i have been
resisting transport drift, e.g. "what about over tls?" and so forth.  no
one has asked for beep yet :)

so, i suggest asking the iana for a port number, one and only one.
objections?

randy

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 8 Mar 2011 16:26:52 -0500

On Tue, Mar 8, 2011 at 4:20 PM, Randy Bush <[email-masked]> wrote:
>    >> is there a default TCP/SSH port that the servers are listening
>    >> to?  i'll try to add those as defaults for the client piece when
>    >> trying to establish a session.
>    > no, we have not done this.  perhaps we should.
>

I'm personally a fan of keeping things simple .... what's the beef
with tcp/22 here?

---

From: Yann Berthier <[email-masked]>
Date: Tue, 8 Mar 2011 20:44:42 -0500

> I'm personally a fan of keeping things simple .... what's the beef

The set of source IPs needing access to tcp/22 for mgmt may not be the same as the set of IPs needing access to tcp/22 for the rpki service

A dedicated port for rpki seems a good idea

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 8 Mar 2011 21:39:39 -0500

> A dedicated port for rpki seems a good idea

don't disagree, just seeking some justification for the change. I came up with:
  o diff hosts need ssh vs rpki-rtr (potentially off-net things?)
  o ability to drop shields in case of problems but still maintain
management access
  o qos/debugging reasons
  o authentication requirements perhaps are different between user-ssh
&& rpki-rtr

randy came up with: 'maybe we don't trust the ssh code to do this
heavy lifting?' (or something similar)

just hunting for the reason to be different.

-chris

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 9 Mar 2011 09:30:45 -0700

Sharing: No permission required.
This is public share as desired.
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Tuesday, March 08, 2011 7:40 PM
> To: Yann Berthier
> Cc: sidr wg list
> Subject: Re: [sidr] rpki-rtr standard port
>
> > The set of source IPs needing access to tcp/22 for mgmt may not be
> the same as the set of IPs needing access to tcp/22 for the rpki
> service
> >
I think this is related to your "drop shields" statement but may be different enough to capture.

Standard ssh port (22) for any router or router support system should only be available from your trusted NOC ips.
So a "new" port should be used for rpki that has different filtering acls or no filtering acls.

In a perfect world NOBODY would use 22 for ssh that would slow down the brute force attacks by 64k times and make the scanners noisier.

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

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 Mar 2011 08:22:07 +0900

> The set of source IPs needing access to tcp/22 for mgmt may not be the
> same as the set of IPs needing access to tcp/22 for the rpki service

the router is the originator of the ssh connection, so there is no guess
as to the port the cache will use.  if you are a big fan of ip address
based acls, it is the cache you will be protecting, not the router.

i think the issues were
  o predictability and default config of router
  o other tools may want to reach server

on the ssh vs other transport issue, i am less happy.  the protocol
specifies ssh, and this discussion would lead to standardizing the port
on the cache/server to be used.  that the testbed currently provides a
few clear-text servers for implementors to test without ssh is merely a
test service, and, imiho, should not be standardized.  unless operators
would care to argue that they trust security services which use
clear-text.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 9 Mar 2011 22:26:28 -0500

> based acls, it is the cache you will be protecting, not the router.

apologies I reversed the info/pkt flow. Ok, so ideally in a sane world
I can already scp/ssh from a router to another router (maintenance
requirements + code moves + config loads ... last-resort 'ohshit'
configs.) Adding a few cache ips where the only thing running on the
ip/port combo is this service seems ok to me.

Ideally cache box has 'service' ip and 'maintenance' ip... with
different security policies and 'better' service separation than I can
get today in the world of routers.

I'm back to 'why complicate things?'

-Chris

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 Mar 2011 12:28:38 +0900

> I'm back to 'why complicate things?'

<my read of list so far>
config default implicity and wireshark and tcpdump templates in tension
with use of a limited pool of assigned port numbers.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 9 Mar 2011 22:33:03 -0500

> with use of a limited pool of assigned port numbers.

router points to cache on "cache-service-ip:port" (22 or other it's
not super important at this point, I think.) "port" is running ONLY
the cache-service, not regular/normal ssh, or an sshd configured to
only do the right thing for cache requests and NOT permit user
login/shell. I presume this all shows up in some nice package anyway.

that does argue for a 'not port 22' solution, I suppose, less
confusion and not subject to the daily dose of ssh scanners.

I think this still is a local implementation decision, you could say
it's simpler/easier to just pick a new port from IANA and use that for
this service. I'd support that as a path forward.

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 10 Mar 2011 13:42:52 +0200

On Mar 10, 2011, at 5:33 AM, Christopher Morrow wrote:
...
> this service. I'd support that as a path forward.

If "not subject to ssh scanners" is really the goal, surely a new well-known port would defeat it.  To get your daily dose of security-by-obscurity, you need obscurity.

--John

---

From: Ruediger Volk <[email-masked]>
Date: Thu, 10 Mar 2011 17:49:49 +0100

> > as to the port the cache will use. =A0if you are a big fan of ip address
I wonder whether that's how ssh designers intended to support selection of
application service; or: what the commonly used / most appropriate way 
to select one of several application services with access over ssh are.
I never had to use a separate host IP address for using scp for target hosts
that I also have ssh shell sessions with  (and I certainly have used scp
from certain routers targetting my usual Unix ssh accounts).

I'm no ssh expert; is one around and willing to provide some clue, please?

I suspect that if there is no predefined/commonly used  mechanism in place
something as simple as

	prepend to the protocol as piped into the ssh transport
	"originators sends 'this-magic-token-invokes-the-RPKI-cache-server\n'"

could do the job.

  > I'm back to 'why complicate things?'

Ruediger Volk

---

From: Rob Austein <[email-masked]>
Date: Thu, 10 Mar 2011 12:06:29 -0500

I'm not a hard-core ssh expert either, but keep in mind that we're
already using the ssh "subsystem" mechanism, ie, we are using an
assigned name for the specific service we're trying to reach.

Furthermore, while outside the network spec, implementations like
OpenSSH already have the concept of restricting a particular set set
of authentication credentials to running a command determined entirely
by the server.  That is: ie, it is not difficult to lock a particular
set of credentials into running only the specific command or subsystem
one wants to allow.  Small matter of configuration, but one would have
to configure credentials in any case, this is just a bit more config.

I think the port number thing is more about people who really just
want to be able to filter based on port numbers, full stop.  I don't,
particularly, because forcing encrypted traffic (content the filter
can't inspect, by definition) to use port A instead of port B has
never struck me as an effective policy enforcement mechanism.  YMMV.

---

From: Ruediger Volk <[email-masked]>
Date: Thu, 10 Mar 2011 18:50:41 +0100

Rob, thanks
  > assigned name for the specific service we're trying to reach.
sorry, I forgot/missed that use of ssh subsystem "rpki-rtr" is already
in the draft; that clearly does the selection of application service.

  > never struck me as an effective policy enforcement mechanism.  YMMV.
With application selection taken care of elsewhere using seperate addresses
for helping packet filters etc. seems perfectly appropriate;
using separate well defined port would be wasteful.

Ruediger Volk

---

From: Yann Berthier <[email-masked]>
Date: Thu, 10 Mar 2011 13:21:52 -0500

> never struck me as an effective policy enforcement mechanism.  YMMV.

the content being encrypted does not mean i don't want to restrict its accessibility to a set of ips-i-trust-more; like, my routers

similarly, it may not be the same set as the ones presumably used for management of the cache box

but whatever - i can use a separate ip for rpki-rtr vs mgmt of the cache, so no big deal either way

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 Mar 2011 06:40:34 +0900

> want to be able to filter based on port numbers, full stop.

not completely.  if i know the port number, i can hack tcpdump and
wireshark smarts.

randy

---

From: Rob Austein <[email-masked]>
Date: Thu, 10 Mar 2011 17:38:45 -0500

> not completely.  if i know the port number, i can hack tcpdump and

Unless you've got:

a) An unusually smart Wireshark decoder, and

b) A copy of the private key for at least one of the parties (or
   possibly you need both, I don't know the deep protocol details),

you are not going to see a whole heck of a lot besides the initial ssh
key exchange followed by a lot of encrypted glop.  Initial setup
debugging and traffic analysis, in other words.

Mind, I'm not actively opposed to using a separate port, I just don't
see the point (but then, I liked Chaosnet contact names too, back in
the day).

If somebody really needs this bikeshed to be hot pink, go for it.

---

From: "t.petch" <[email-masked]>
Date: Fri, 11 Mar 2011 11:04:38 +0100

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: "Yann Berthier" <[email-masked]>
Cc: "sidr wg list" <[email-masked]>
Sent: Wednesday, March 09, 2011 3:39 AM
> > The set of source IPs needing access to tcp/22 for mgmt may not be the same
as the set of IPs needing access to tcp/22 for the rpki service
>   o authentication requirements perhaps are different between user-ssh

I think that those are the reasons why a separate port is required.

susbsystem is the standard SSH way of differentiating traffic but that
is really the view of the implementer, of getting the end points of the
session to the right place.  Operationally, you need to be
able to track the different traffic for the life of a session.

RPKI is rather important, it should become critical to the Internet,
so being able to offer it the best in operations seems a no brainer.
As you say, filtering, performance, tracing for trouble shooting purposes,
letting it through or not through firewalls etc, ...
And I think it different to BGP in that it will span a wider network,
whereas much of BGP is just about immediate neighbours, so there are
likely to be more hops along the way where things could go wrong or
need to be made right.

With SNMP over SSH, there was a brief discussion about reusing
the existing SNMP ports but it gained no support, rather
that it was taken to be axiomatic that there would be a port, the
debate being rather system or not, and one port or two (commands
and notifications).

Tom Petch