Subject: Re: [sidr] draft-sidr-rpki-rtr

From: "t.petch" <[email-masked]>
Date: Fri, 12 Aug 2011 11:48:20 +0200

I notice that there is no mention of which range the port number should be from,
in section 12.

This has been a hot topic with TSVWG, so if guidance can be given - eg we do not
care - then that could forestall later debate.

Tom Petch

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Aug 2011 09:56:26 -0700

> care - then that could forestall later debate.

Hi, Tom,

The general issue of the difference in the "system" (privileged) and 
"user" (non-privileged) ports has been a topic on TSVWG, but not 
recently and not in this specific context AFAICT. There is a move afoot 
for many years to deprecate the difference between the ranges, but it 
doesn't appear to be going anywhere quickly.

If you can provide a pointer otherwise, let me know.

There have been very few recent assignments to the system range, notably 
netconf over ssh this past year.

IMO, this does belong in the system range, but it's your decision.

Joe

---

From: Randy Bush <[email-masked]>
Date: Sat, 13 Aug 2011 10:07:55 +0900

> I notice that there is no mention of which range the port number
> should be from, in section 12.

i had hoped that the iesg or some other guardian of port numbers would
sort this out with the iana if they felt they needed guidance.

which would you recommend and why?

randy

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 13 Aug 2011 09:01:41 +0100

On 12/08/2011 17:56, Joe Touch wrote:
> recently and not in this specific context AFAICT. There is a move 
> afoot for many years to deprecate the difference between the ranges, 
> but it doesn't appear to be going anywhere quickly.
>
> There have been very few recent assignments to the system range, 
> notably netconf over ssh this past year.
>

Yes from looking at the registry text on the two ranges this looks like 
it needs to be from the "well known port range" = 0..1023 where BGP 
itself is. I suggest that you put in a request for an allocation in that 
range and leave it to the transport area reviewers to tell us that we 
are wrong (and why).

Stewart

---

From: "t.petch" <[email-masked]>
Date: Mon, 15 Aug 2011 11:13:02 +0200

----- Original Message -----
From: "Joe Touch" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Christopher Morrow" <[email-masked]>; <[email-masked]>
Sent: Friday, August 12, 2011 6:56 PM
> If you can provide a pointer otherwise, let me know.

Joe,

I was thinking, as I am sure you know, of draft-ietf-tsvwg-iana-ports where my
recollection is that in WGLC, last December, the issue of unifying the two
ranges did get raised and was declared out of scope. Then in IETF LC, in
January, there were comments that the I-D did not give enough guidance to IANA
as to what to do when reviewing a request, the underlying concern being that
ports are a scarce resource and should be conserved.  At that time, the concern
was more that protocols should not be allowed a second port for security but
should be designed to negotiate security in-band:-(  but I read into that the
concern as also being that system ports are even more scarce and so the rules
should be tighter.

I also recall a TLS discussion as to whether two ports are better than one for
security, with no clear consensus emerging.

So I anticipate some more discussion along these lines at IETF LC and would like
us to have an answer ready.  Two system ports would seem to be the most
demanding request to make and so the one needing the most justification.

As you say, netconf over ssh went 'system', but netconf over TLS did not, nor
did SNMP over ssh.

Tom Petch.

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2011 09:51:07 -0700

Hi, Tom,

On 8/15/2011 2:13 AM, t.petch wrote:
...
> ranges did get raised and was declared out of scope.

For that doc. It will be addressed in the user port recommendations, 
though it's not clear yet whether it will be resolved or just the issues 
documented.

 > Then in IETF LC, in

The rate of port allocations hasn't changed in over a decade; recent 
reforms have served well to conserve the space. They've focused on 
avoiding gratuitous allocations of ranges of ports, not the security 
issue or the user/system issue.

> security, with no clear consensus emerging.

Yes. For other related protocol issues, the general consensus is "mux in 
band", i.e., that ports are scarce and that additional ports should 
never be allocated solely for performance or software complexity reasons.

Security has other issues - e.g., port filtering, for one. However, the 
primary argument in favor of separate secure/insecure ports appears to 
be focused solely on performance, AFAICT.

FWIW, there are already examples where multiple protocol 'stacks' 
require separate ports because the muxing can't happen in-band.

> demanding request to make and so the one needing the most justification.

For this service, the key question isn't whether there should be a 
secure port, but why there would ever be a need for an insecure one -- 
especially if these are in the system range.

> As you say, netconf over ssh went 'system', but netconf over TLS did not, nor

Whether a service goes into system or user is up to the protocol 
designer, and whether you all feel that this provides any benefit or not.

As to the hurdles once you pick a range, yes - there will be more for 
system ports than for user ports. One part you're already clean on - 
this being an IETF proposed standard. The allocations of ports aren't 
particularly more conservative for system vs user, except (as above) 
that the argument for purely non-secure ports is even more thin.

Joe