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

[Joe Touch <[e-mail]>]

Hi, Tom,

On 8/15/2011 2:13 AM, t.petch wrote:
...
> 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.

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

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.

> I also recall a TLS discussion as to whether two ports are better than one for
> 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.

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

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
> did SNMP over ssh.

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