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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
