Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla <[e-mail]>]

On Tue, Feb 1, 2011 at 8:38 AM,  <[e-mail]> wrote:
> +1 to everything Magnus says here. THis is exactly how I view the multiple port
> issue.

I'll respond to this separately.


> I will also add that at least part of this fuss seems to be concern about how
> "human oversight is needed but what if the overseer misbehaves" issue. Speaking
> as someone who has been doing IANA reviews for well over a decade, it is
> absolutely the case that a reviwer's actions can screw up a registry. But the
> solution to this problem is not to overconstrain the review process - we've
> tried that approach and found it causes more problems than it solves - but
> rather to have proper checks and balances in the process itself. I believe the
> current specified process - once you understand the details, which
> unfortunately are a bit difficult to track through all the various
> specifications - is sufficient to deal with this.

Others may have that concern but it's not my concern.

My concern is rather that the reviewer get the correct guidance, and
in this case
that guidance appears to be that he ought to be pushing back on protocols which
desire to use one port for the insecure version and one port for the
secure version,
and I'm not really that comfortable with that.

-Ekr


>                                Ned
>
>> Cullen Jennings skrev 2011-01-31 18:44:
>> >
>> > Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that.
>
>> Well, frankly I don't know. I think it is something that can be avoided
>> going forward in many use cases, but not all. Simply by thinking of this
>> issue in the design phase. In addition there is clearly other solutions
>> there other considerations, like NAT traversal has said, yes
>> multiplexing is a must, thus live with even higher complexity costs.
>
>> The issue I have a problem with is that is we say on general basis that
>> due to negotiation of security protocols we are allowed to use different
>> ports for negotiation or simply usage of it. Then why is that different
>> from different versions of the protocol, or feature support. What is the
>> difference for a security protocol compared to these other issues?
>
>> What I am worried here is that we will see an increased port consumption
>> rather than a decreased one. At the current run rate I think the
>> estimate is 50 years+ before run out. That is something that I am
>> reasonably comfortable, but if the consumption rate increases four
>> times, then I am suddenly not comfortable. So I am pretty certain that
>> we need to aim at lowering the consumption rather than raising it.
>
>> As I see it there are only one way of doing it.
>
>> - State clearly that you really need to do everything reasonable so that
>> your application is only for one port.
>> - Be reasonably tough from the expert reviewer to ensure that applicants
>> has done this.
>
>> And from that perspective I don't think security is special in anyway.
>> It is only one of several things that could potentially require
>> additional registered ports. Yes security is important, but as
>> previously discussed it doesn't appear that the actual level of security
>> provided is different if you are forced to use one port or two. It might
>> affect the ease of implementation and deployment of security, which is
>> another aspect of impact.
>
>
>> Cheers
>
>> Magnus Westerlund
>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>> _______________________________________________
>> Ietf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>