Subject: 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

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Jan 2011 17:12:44 -0700

I'm really glad to see this draft in LC at long last and it is a great improvement to the current situation - thank you to all the people that put work into this. I have two significant problems with it that I think should be resolved before being published 

Big Issues 1: I don't like mandating one port for secure and not secure versions of a protocol 

I don't think this reflects IETF consensus given the number of protocols that deliberately choses to use two ports. I also don't think that it is a good idea in all cases. I believe the decision should be left to the people designing the protocol if they want one port or two. Let me give some examples

Imagine a client server protocol that runs over UDP and uses DTLS for security. The server will simultaneously serve requests over both DTLS and UDP. When the server receives a packet, it needs to be able to demux if it is a UDP packet or a DTLS packet. The obvious demux code point is the port. Yes, one might be able to reinvent a concept of a stream along with a 5 tuple and something like STARTTLS but this has many other problems. It means the client needs to use a different SRC port for each different "session" to the same server. This uses up NAT ports and complicates NAT traversal. It also adds additional latency to set up a small session. People just aren't going to do it. The other approach is demux based on the first byte inside the UDP packet. The CoAP protocol  being developed in the CORE WG has taken that approach. The CORE WG proposed to the TLS chairs that over half the remaining code space for the TLS code point in the first byte be assigned to CoAP. The TLS chairs, more or less told the CORE guys to get stuffed (politely of course). Two ports is the obvious answer. 

Lets consider another example. As the draft mentions, firewalls help apply policy, and catch configuration errors. Take an organization (like my house) that has a policy of no email over unencrypted protocols. It's really easy to set up a firewall policy that allows the encrypted ports and blocks the non encrypted ports that are typically used for email and does not require the firewall to do DPI. No doubt my daughter could figure out to circumvent this and sent unencrypted email via an VPN tunneled over DNS or ICMP or something but thats not the point - the point is to catch accidental misconfiguration, like the type that happen during software upgrades. You can agree or disagree about using firewalls this way but the fact remains, lots of people do use firewalls this way. 

I strongly urge this draft not to take on mandating one port - leave the decision with the designers of the protocol. If draft does mandate one port, you will end up with a port registered for protocol foo and a port for a proprietary protocol with no description called foo-secure.  As I mentioned before, I also do not believe there is IETF consensus for one port. 

Big Issue #2: The draft has close to no review advice for the expert reviewer. 

I have been involved with several port registrations and they all left me grumpy and irritated and very frustrated at the expert review process. I'm sure the expert reviewer involved felt the same way and I know others have had similar experiences. We need concrete actionable advice for when the review says yes or no. 

This draft provides no guidance on what the expert review would approve or deny. If all they are doing is checking the requirements of this draft have been satisfied, then I am fine with that but the draft needs to say that something like any denial by an expert review should include which MUST in this draft was not complied with. 

I would like the draft to say that when IANA sends a response from an expert review to the applicant, the name of the reviewer (and perhaps email address) should be included. 

Lets take some specific points of never ending confusion about what is "good enough" to say yes. 

The reference to the doc describing the protocol. Is this a one line description? Is it a overview of the high level way this works, deals with congestion, security etc? Is it a full protocol specification. I have no idea. I also have no idea on what grounds the expert reviews can say no based on this. 

What protocols use Anycast. Does STUN? Does ping? what about DNS? Who knows - who cares. I  do not believe discussion of if a protocol uses anycast or not has much relevance to deciding to allocate a port. 

Next lets talk about the whole topic of what is or is not appropriate for dynamic range. Let's take web browsing for example. You start with a URL like www.example.com but the protocol could have required a port like www.example.com:55123 in the URL and only used dynamic ports. Is http a protocol that should be forced into the dynamic range? Clearly the answer is no but if not http, then what protocol should? This draft offers no advice to the expert reviewer on what to do. Next lets consider a protocol like FTP data transport - first FTP does some signaling and it can pass the ports to be used for the data transport connection so you might think the dynamic range is fine for the transport part - but policy on firewalls has resulted in people wanting to have a well known port for that FTP uses for the data connection. Most FTP now supports PASV and things like that to meet this well known port requirement.  You need to do this to make NAT port forwarding work. 

I think this draft need specific actionable advice on what grounds the expert review can say No. Obviously violating any of the MUST in this draft is fine reason to say no - but beyond that it is just too vague. 

Next we come to the issue of if a new protocols is allowed or not. Cisco developed a new protocol - the retransmission and flow control part of it was stollen from another protocol that is an RFC. I viewed this as a good thing as it ensured that we did not reinvent something new that was broken. The IANA expert review felt that we should not make a new protocol and should instead extend the old one and would not approve the port. Eventually sanity prevailed and the port was allocated but it worth noting that when the port was approved, the product had already shipped and the port was fixed. Had IANA not allocated the port, Cisco would have just kept using the port anyways. I'll note most other vendors feel about the same way - if they need to build a product that needs a port, they will take a port, or more than one,  if one is not allocated. This does not make me happy but I think we need to be realistic about what our grounds are for saying no and the probable result of saying no. 

Along these lines, I have no idea what review guidelines the expert would use to decide if something was OK to be in the System port range instead of User. What would be an appropriate argument for System instead of User? 

Along these lines, I think the draft should contain an example registration for a protocol in the port range where the description of the protocol is not a reference to a document but is provided in this example - using an existing protocol such as HTTP might make it easier for everyone to read. Similarly be nice to have example for something in the System range. 

Anyways, my meta point is the draft need to give enough advice to the expert review that they know what to do. Of course the expert applies human intelligence but the review and applicants have to be on the same page about what is expected here. 

Small Issue #3: I object to anonymous review

The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several emails with an expert reviewer relayed via IANA where the conversation was going no where - once I knew the name of the reviewer, the whole conversation changed and stuff quickly came back to the realm of sane. I'm not willing to forward these emails to the list as that would just not be kind to anyone but I am happy to forward them to the IESG if they think looking at them is really critical. 

On Jan 18, 2011, at 14:26 , The IESG wrote:

> 
> The IESG has received a request from the Transport Area Working Group WG
> (tsvwg) to consider the following document:
> - 'Internet Assigned Numbers Authority (IANA) Procedures for the
>   Management of the Service Name and Transport Protocol Port Number
>   Registry'
>  <draft-ietf-tsvwg-iana-ports-09.txt> as a BCP
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-02-01. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Jan 2011 10:52:55 +0200

Hi

> I don't think this reflects IETF consensus given the number of protocols that deliberately choses to use two ports. I also don't think that it is a good idea in all cases. I believe the decision sh…

Paul Hoffman raised this issue as well (email from Nov 4 to this list.)

There was some discussion that lead to Paul suggesting specific edit to this document. (Which are not reflected in -09; us editors may have dropped the ball here). I'm attaching Paul's proposed changes below, could you check if you'd agree with them?

> Big Issue #2: The draft has close to no review advice for the expert reviewer.

Joe Touch (who leads the expert review team for ports) is working on a separate document (draft-touch-tsvwg-port-use). The first version of that draft was issued on the same day as the -09 version of iana-ports, which is why we don't refer to it. 

Does draft-touch-tsvwg-port-use have the content you are looking for? If so, we should refer to it. (We should probably refer to it anyway, in a "you may also want to read this" kind-of way.)

> The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several…

I can see your point, and I personally have no problem with disclosing the reviewer identity. What do others think?

Lars

PS: Paul's proposed changes re item #1:

Begin forwarded message:
> From: Paul Hoffman <[email-masked]>
> Date: November 15, 2010 21:44:24 GMT+02:00
> To: <[email-masked]>
> Subject: Proposed resolution for security issues with 	draft-ietf-tsvwg-iana-ports-08
> 
> As this list and the TLS has seen, there is a wide variety of views on how to deal with fallback-to-insecure in protocols. I believe that the security community has no consensus on what this means, much less how to do it. My earlier proposal (continue to allow registration of two ports) was popular with some, unpopular with others; similarly, so was "force all protocols to use one port".
> 
> Therefore, I retract my proposal to allow two-port registrations for fallback-to-insecure. However, I still recommend some changes to the text to reflect the view that STARTTLS is not the only way to have such a feature on one port.
> 
> This will be an interesting IETF Last Call discussion.
> 
> I propose the following changes to draft-ietf-tsvwg-iana-ports:
> 
> Section 7.2 current:
> o  IANA will allocate only one assigned port number for all versions
>   of a service (e.g., running the service with or without a security
>   mechanism, or for updated variants of a service)
> 
> Section 7.2 current:
[in the line above s/current/proposed/, I think]
> o  IANA will normally allocate only one assigned port number for all versions
>   of a service (e.g., running the service with or without a security
>   mechanism, or for updated variants of a service). This policy can
>   be overridden by the expert reviewer.
> 
> Section 7.2 current:
>   Further,
>   previous separation of protocol variants based on security
>   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
>   not recommended for new protocols, because all new protocols should
>   be security-capable and capable of negotiating the use of security
>   in-band.
> 
> Section 7.2 proposed:
>   Further,
>   previous separation of protocol variants based on security
>   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
>   not recommended for new protocols, because all new protocols should
>   be security-capable.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Jan 2011 10:17:27 +0100

Cullen Jennings skrev 2011-01-27 01:12:
>
> I'm really glad to see this draft in LC at long last and it is a great
improvement to the current situation - thank you to all the people that
put work into this. I have two significant problems with it that I think
should be resolved before being published
> I don't think this reflects IETF consensus given the number of
protocols that deliberately choses to use two ports. I also don't think
that it is a good idea in all cases. I believe the decision should be
left to the people designing the protocol if they want one port or two.
Let me give some examples

We have extensive discussion on this in the WG last call. There was no
consensus for having two ports. At the same time we did also have no
consensus on mandating one port for any future protocol. Thus we
adjusted the text to say in Section 7.2:

IANA strives to assign only one assigned port number per service or
application

To my knowledge "strive" is not a binding RFC2119 term. I also think it
is a good trade-off with the intention of preserving the space as well
as possible with only assigning one port, and still allow for more than
one if it really is needed.

Is it the above text that triggered your comment or some other text?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Jan 2011 10:20:35 +0100

On Jan 27, 2011, at 09:52, Lars Eggert wrote:

>> all new protocols should
>>  be security-capable

Sure.

How is this relevant?

In some protocols, there is value to use them without communication security (think TLS) for some applications, and with communication security for others.
We used to distinguish these two cases using two ports, now we use a single port plus per-connection negotiation like STARTLS.
I think the draft is trying to encourage this conversion, and I agree with this, at least where latency is less relevant.

With UDP-based protocols, it is harder to do this.
Please look at section 7.3 of

	http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3

and tell us whether this is how you would like this to be handled for UDP-based protocols in the future.
If not, we may want to add to the guidance in the (tsvwg) draft.

Gruesse, Carsten

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Jan 2011 11:26:11 +0200

> If not, we may want to add to the guidance in the (tsvwg) draft.

This looks like a totally reasonable way to to this in-band using a single port.

Lars

---

From: IETF Chair <[email-masked]>
Date: Thu, 27 Jan 2011 11:12:37 -0500

> I strongly urge this draft not to take on mandating one port - leave the decision with the designers of the protocol. If draft does mandate one port, you will end up with a port registered for prot…

Originally, two ports were assigned for plain and over-TLS, which for HTTP mapped to two different URL schemes: http and https.

Many people thought that this was a waste of a port, and the STARTTLS approach was developed.  You say that it does not work in some cases, and you seem to be suggesting that we go back to the original way.

Maybe it works in some cases and not others.  Can we say which is which?

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jan 2011 08:41:18 -0800

> Maybe it works in some cases and not others.  Can we say which is which?

In a word: no. We have very little operational experience, and where we 
do, it gives conflicting results. Some mail client developers say that 
POP and IMAP STARTTLS works fine, some say that it is unreliable and so 
they just use the alternate ports.

Note that Cullen's example for where it almost certainly would not work 
is for non-stream UDP. Making UDP developers have to come up with a 
stream-like capability to do a STARTTLS-style single port solution 
defeats the purpose of using UDP. The benefit of "we saved another 
port!" over "we forced someone to make UDP more like TCP!" seems like a 
false one.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 27 Jan 2011 09:33:30 -0800

On 1/27/11 8:41 AM, Paul Hoffman wrote:
>> Originally, two ports were assigned for plain and over-TLS, which for
>> HTTP mapped to two different URL schemes: http and https.
>>
>> Many people thought that this was a waste of a port, and the STARTTLS
>> approach was developed.  You say that it does not work in some cases,
>> and you seem to be suggesting that we go back to the original way.
>>

So I can say that having provided a large scale mail-service in a former
life that we made it work for our customers.

On the SMTP side on the virtually everyone has this working except those
people that use 465, because the service you're talking to on 587 is
fundamentaly the same one that's on 25.

joelja-mac:tmp joelja$ telnet nagasaki.bogus.com 25
Trying 147.28.0.81...
Connected to nagasaki.bogus.com.
Escape character is '^]'.
220 nagasaki.bogus.com ESMTP Sendmail 8.14.4/8.14.4; Thu, 27 Jan 2011
17:28:24 GMT
ehlo jaeggli
250-nagasaki.bogus.com Hello adsl-99-173-15-226.dsl.pltn13.sbcglobal.net
[99.173.15.226], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP

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

---

From: "t.petch" <[email-masked]>
Date: Thu, 27 Jan 2011 17:58:43 +0100

And what happens when we have ProtocolX over SSH and ProtocolX over TLS?

Must they share a port, with ProtocolX, which has been quietly using its
assigned port for
20 years?

Tom Petch

----- Original Message -----
From: "Lars Eggert" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>; "Paul Hoffman" <[email-masked]>
Cc: "IESG IESG" <[email-masked]>; "IETF discussion list" <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 27, 2011 9:52 AM
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (InternetAssigned
Numbers Authority (IANA) Procedures for the Managementof the Service Name and
Transport Protocol Port NumberRegistry) to BCP

On 2011-1-27, at 2:12, Cullen Jennings wrote:
> I don't think this reflects IETF consensus given the number of protocols that
deliberately choses to use two ports. I also don't think that it is a good idea
in all cases. I believe the decision should be left to the people designing the
protocol if they want one port or two. Let me give some examples

There was some discussion that lead to Paul suggesting specific edit to this
document. (Which are not reflected in -09; us editors may have dropped the ball
here). I'm attaching Paul's proposed changes below, could you check if you'd
agree with them?

> Big Issue #2: The draft has close to no review advice for the expert reviewer.

Joe Touch (who leads the expert review team for ports) is working on a separate
document (draft-touch-tsvwg-port-use). The first version of that draft was
issued on the same day as the -09 version of iana-ports, which is why we don't
refer to it.

Does draft-touch-tsvwg-port-use have the content you are looking for? If so, we
should refer to it. (We should probably refer to it anyway, in a "you may also
want to read this" kind-of way.)

> The current review is anonymous and this draft does not seem to change that. I
don't like anonymous review - it's not how we do things at IETF and it
encourages really bad behavior. I have several emails with an expert reviewer
relayed via IANA where the conversation was going no where - once I knew the
name of the reviewer, the whole conversation changed and stuff quickly came back
to the realm of sane. I'm not willing to forward these emails to the list as
that would just not be kind to anyone but I am happy to forward them to the IESG
if they think looking at them is really critical.

I can see your point, and I personally have no problem with disclosing the
reviewer identity. What do others think?

Lars

Begin forwarded message:
> As this list and the TLS has seen, there is a wide variety of views on how to
deal with fallback-to-insecure in protocols. I believe that the security
community has no consensus on what this means, much less how to do it. My
earlier proposal (continue to allow registration of two ports) was popular with
some, unpopular with others; similarly, so was "force all protocols to use one
port".
>
> Therefore, I retract my proposal to allow two-port registrations for
fallback-to-insecure. However, I still recommend some changes to the text to
reflect the view that STARTTLS is not the only way to have such a feature on one
port.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Jan 2011 20:11:27 +0200

> Must they share a port, with ProtocolX, which has been quietly using its

No. The expert reviewer can obviously assign a second port in that case (if ProtocolX doesn't have a feature negotiation capability built in so that the port could be shared.)

But we don't want to allocate multiple ports for the different security flavors of *new* protocols. At least we want this to be the exception.

The expert team is (from what I hear) seeing frequent applications that look like "Hi, we're company X and our foo protocol runs on TCP. We'd like a port for that, and one for when we run foo over TLS."

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jan 2011 17:10:45 -0800

On 1/27/2011 12:52 AM, Lars Eggert wrote:
...
> I can see your point, and I personally have no problem with disclosing the reviewer identity. What do others think?

AFAICT, the experts team reports to IANA. We make recommendations to 
them. They are the ones who have the conversation with the applicant. 
They can take our advice or not - that's their decision.

I.e., we are advisors to IANA.

Further, many requests are handled my multiple reviewers.

Many of us do have specific conversations with applicants, and identify 
ourselves when that happens, but it doesn't seem important to codify 
that in this doc.

Again, this doc is about the unification of the registries. It is NOT 
about all the other policies that govern them. The info that's there is 
advisory ONLY (it is not binding to IANA).

Joe

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 27 Jan 2011 17:29:34 -0800

We are changing that process right now.  We have begun to report the
reviewer (with the review) in the email to the requester.

We just need to make sure this small change is communicated to those experts
that are part of review "teams" as their individual names are not published
on the main list of registries.

I don't think it needs to go in this document as this is already in
progress.

Let me know if you have any questions.

--Michelle

On 1/27/11 5:10 PM, "Joe Touch" <[email-masked]> wrote:

>>> The current review is anonymous and this draft does not seem to change that.
>>> I don't like anonymous review - it's not how we do things at IETF and it
>>> encourages really bad behavior. I have several emails with an expert
>>> reviewer relayed via IANA where the conversation was going no where - once I
>>> knew the name of the reviewer, the whole conversation changed and stuff
>>> quickly came back to the realm of sane. I'm not willing to forward these
>>> emails to the list as that would just not be kind to anyone but I am happy
>>> to forward them to the IESG if they think looking at them is really
>>> critical.
>>

---

From: [email-masked]
Date: Thu, 27 Jan 2011 17:43:16 -0800 (PST)

> Big Issues 1: I don't like mandating one port for secure and not secure

I don't either, so it's good that the document doesn't do that. It says:

   Services are expected to include support for security, either as
   default or dynamically negotiated in-band.  The use of separate
   service name or port number assignments for secure and insecure
   variants of the same service is to be avoided in order to discourage
   the deployment of insecure services.

"is to be avoided" != "forbidden". There are legitimate use-cases for
two port approaches - not many, but some - so they should be avoided but not
banned. And the main reason for this isn't to encourage optional use of
negotiated in-band security, but rather because deployment of insecure
service variants no matter what the protocol details are bad idea.

> Imagine a client server protocol that runs over UDP and uses DTLS for
> security. The server will simultaneously serve requests over both DTLS and UDP.
> When the server receives a packet, it needs to be able to demux if it is a UDP
> packet or a DTLS packet. The obvious demux code point is the port. Yes, one
> might be able to reinvent a concept of a stream along with a 5 tuple and
> something like STARTTLS but this has many other problems. It means the client
> needs to use a different SRC port for each different "session" to the same
> server. This uses up NAT ports and complicates NAT traversal. It also adds
> additional latency to set up a small session. People just aren't going to do
> it. The other approach is demux based on the first byte inside the UDP packet.

> The CoAP protocol  being developed in the CORE WG has taken that approach. The
> CORE WG proposed to the TLS chairs that over half the remaining code space for
> the TLS code point in the first byte be assigned to CoAP. The TLS chairs,
> more or less told the CORE guys to get stuffed (politely of course). Two
> ports is the obvious answer.

And nothing in this document would prevent such an assignment from being
made as long as there are compelling reasons to do so.

> Lets consider another example. As the draft mentions, firewalls help apply
> policy, and catch configuration errors. Take an organization (like my house)
> that has a policy of no email over unencrypted protocols.

I have to say that that policy must be pretty tricky to implement given
the widespread lack of encryption support in SMTP relay scenarios.

> It's really easy to set up a firewall policy that allows the encrypted ports
> and blocks the non encrypted ports that are typically used for email and does
> not require the firewall to do DPI.

But this doesn't address the bad configuration problem at all - all it does is
change the location where the problem would have to be, from the mail server
configuration (which, if it was compliant with the relevant email standards,
should have been fairly secure by default) to the firewall (which doesn't 
really have a means of being secure by default without DPI). Now, perhaps
you'll argue that firewalls configs are less likely to be grinched than those
of an email server. If so, all I can say is that doesn't jibe with my
experience.

> No doubt my daughter could figure out to circumvent this and sent unencrypted
> email via an VPN tunneled over DNS or ICMP or something but thats not the point
> - the point is to catch accidental misconfiguration, like the type that happen
> during software upgrades. You can agree or disagree about using firewalls this
> way but the fact remains, lots of people do use firewalls this way.

And lots of people screw up their firewall configurations in the process. 

> I strongly urge this draft not to take on mandating one port - leave the
> decision with the designers of the protocol. If draft does mandate one port,
> you will end up with a port registered for protocol foo and a port for a
> proprietary protocol with no description called foo-secure.  As I mentioned
> before, I also do not believe there is IETF consensus for one port.

Actually, I suspect there is rough consensus on the one port approach, in the
TCP space at least. A few exceptions don't invalidate that.

As for two registrations versus one, I would not object for there to be some
cleaner mechanism for two port assignments. But any such mechanism needs to
jibe with the reality that the best solution for production services is not to
have an insecure variant at all, either on a separate port or negotiated
in-band.

				Ned

---

From: "t.petch" <[email-masked]>
Date: Fri, 28 Jan 2011 16:02:52 +0100

----- Original Message -----
From: "Lars Eggert" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; "IESG IESG" <[email-masked]>; "IETF
discussion list" <[email-masked]>
Sent: Thursday, January 27, 2011 7:11 PM

> Must they share a port, with ProtocolX, which has been quietly using its

No. The expert reviewer can obviously assign a second port in that case (if
ProtocolX doesn't have a feature negotiation capability built in so that the
port could be shared.)

But we don't want to allocate multiple ports for the different security flavors
of *new* protocols. At least we want this to be the exception.

The expert team is (from what I hear) seeing frequent applications that look
like "Hi, we're company X and our foo protocol runs on TCP. We'd like a port for
that, and one for when we run foo over TLS."

</tp>
Right.  What I had not noticed, although I have read several versions of this
I-D, is that it says
a lot about new applications, and not much - if anything - about old.  I have
never been involved in
a new application, only with retrofitting security to old, TLS or SSH, and so my
views are coloured by
that.  The expectation of WGs seems to be to expect a new port when adding
either TLS or SSH
to something that has been happily chugging along for decades without it, and I
expect in future,
the same to apply when adding SSH or TLS support to a protocol with TLS or SSH
support
respectively, and would not want this I-D to make that much more difficult.

Is there any text about this, old protocol, situation, for I cannot see any?  Or
are we at the mercy
of the expert reviewer?

Tom Petch
</tp>

Lars=

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 28 Jan 2011 09:46:42 -0800

> This looks like a totally reasonable way to to this in-band using a single port.

How is the COAP working stepping on top of TLS code points any different that the ITU-T stepping on MPLS code points?

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Jan 2011 10:46:15 -0800

Hi, Tom,

> Is there any text about this, old protocol, situation, for I cannot see any?  Or

See Sec 7.2:

    ...IANA has flexibility beyond these principles when handling
    assignment requests; other factors may come into play, and exceptions
    may be made to best serve the needs of the Internet.

and

    ...In particular, the principles form a goal that IANA strives
    to achieve for new applications (with exceptions as deemed
    appropriate, especially as for extensions to legacy services) as
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    follows:

Joe

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Jan 2011 20:53:55 -0800

> Let me know if you have any questions.

As long as we agree that is the process, it's not a big deal to me if it is in or out of the document but I don't see any reason not to put it into the document.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Jan 2011 20:54:19 -0800

> They can take our advice or not - that's their decision.

I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Jan 2011 20:55:36 -0800

> Maybe it works in some cases and not others.  Can we say which is which?

I did misread the draft as saying that 2 ports were not allowed when clearly that was not what people meant but ...

I'm mostly concerned about cases where latency or bandwidth are an issue - basically protocols for real time protocols for internet of things. For things like email I'm less concerned. However, I think we can make some observation about which works best. Consider some of the most successful protocols on the internet

http, 2 ports

email, pop, imap, and smtp, -  more use on multi ports than STARTLS though many deployment support both 

sip, 2 ports

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Jan 2011 20:56:07 -0800

I read the draft to say that there would only be one port allocated - I took strive to mean that Joe would deny my port requests for two ports. If the intention is actually for the draft to say that it strives for one port but allows assignment of two where the that is what the protocol design desire, then I have no problem. Perhaps we just need to clarify what "strive" means. This definition of "strive" leads into exactly my other complain that this draft provides no guidance on what the expert will or will not approve. 

We probably need to adjust text like 

o  IANA strives to encourage the deployment of secure protocols, and
     so strives to avoid separate assignments for non-secure variants

and 

 The use of separate

and 

 Services are expected to include support for security, either as
  default or dynamically negotiated in-band.

In band negotiation of security is applicable for some cases, but it adds latency, bandwidth, and complicated multiplexing in non session based transports. I think this is a bad idea in many cases. I also view separation even for stream based protocols as something that helps management and debugging as well as policy. 

Cullen Jennings

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 Jan 2011 21:31:13 -0800

On 1/29/2011 8:53 PM, Cullen Jennings wrote:
> As long as we agree that is the process, it's not a big deal to me if
> it is in or out of the document but I don't see any reason not to put
> it into the document.

The reason is that this document isn't about the IANA process for 
reviewing ports; it's about unifying the port registries.

RFC2780 specifies Expert Review as *one* of the viable means by which 
IANA can decide on transport protocol port assignments:

    Both the Source and Destination Port fields use the same namespace.
    Values in this namespace are assigned following a Specification
    Required, Expert Review, IESG Approval, IETF Consensus, or Standards
    Action process.

The term "Expert Review" is defined in RFC 2434. Neither document 
mandates that IANA either act on the advice such a review, nor that the 
reviewer identity be disclosed as part of that process.

Further, the list of such experts is known by IANA and the IESG:

    Designated experts are appointed by the relevant Area Director of the
    IESG. They are typically named at the time a document that creates a
    new numbering space is published as an RFC, but as experts originally
    appointed may later become unavailable, the relevant Area Director
    will appoint replacements if necessary.

If you want to codify this process further, you would need to revise 
RFC2434 - e.g., to require the disclosure of the expert reviewer. 
However, that is not in the scope of this document.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 Jan 2011 21:34:21 -0800

...
> I think you are pretty misrepresenting the situation. My impression
> of the reality of the situation is that if the IANA did not like the
> advice of the expert reviewer, they might ask the AD to override but
> short of that they pretty much do whatever the expert says.

As per my other note:
RFC2780 specifies Expert Review as *one* of the viable means by which 
IANA can decide on transport protocol port assignments. The term "Expert 
Review" is defined in RFC 2434.

Neither document binds IANA to use the advice of a reviewer.

Further, there is no single reviewer - we have a team, consulting each 
other on occasion, and all decisions are seen by multiple reviewers. 
However, none of that is worth codifying. If IANA or the IESG doesn't 
like how we serve them, they can replace us - at any time, for any 
reason, and there is an appeals process for decisions of the expert team:

    Any decisions made by the designated expert can be appealed using the
    normal IETF appeals process as outlined in Section 6.5 of [IETF-
    PROCESS].

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Jan 2011 07:12:25 -0800

> normal IETF appeals process as outlined in Section 6.5 of [IETF-

Now that this has been made clear to me, I am *much* more worried about 
the wording in the current draft. The above emphatic statements means 
that IANA can reject a request for an IETF-approved protocol that needs 
two ports without recourse. As Cullen and others have pointed out, there 
are sometimes very good technical reasons for a particular protocol to 
need to have two ports.

The document should be amended to say that protocols with IETF consensus 
should get as many ports as it needs, regardless of what IANA or the 
expert reviewer thinks. This makes it the responsibility of the IETF 
consensus process to follow the guidelines in this document.

---

From: Joe Touch <[email-masked]>
Date: Sun, 30 Jan 2011 09:33:57 -0800

Paul (et al.),

See below.

Note that IANA can't just make its own decisions either and ignore IETF 
process *AND* expert review.

I wasn't trying to imply that, but it appears to have been inferred from 
my claim that "neither document binds IANA to the advice of a reviewer". 
IANA is bound by the "OR" of basic IETF process and Expert Review. The 
former can override the latter (or vice versa), but there is an appeal 
process - through the IETF - as well.

If you have issue with these processes, then RFC 2434 and RFC 2780 are 
your targets, not this doc.

Joe

...
> two ports without recourse.

Repeating myself:

a) this document is NOT proscribing IANA processes for expert review of 
port requests

b) RFC 2790 describes MANY ways IANA decides how to allocate ports:

    Action.

Note the word *OR* above. Expert review doesn't override IETF process here.

> The document should be amended to say that protocols with IETF
> consensus should get as many ports as it needs, regardless of what
> IANA or the expert reviewer thinks.

The above section already allows for that.

> This makes it the responsibility
> of the IETF consensus process to follow the guidelines in this
> document.

This document says, quite clearly, at the front of Section 7.2:

    This section summarizes the current principles by which IANA handles
    the Service Name and Transport Protocol Port Number Registry and
    attempts to conserve the port number space.  This description is
    intended to inform applicants requesting service names and port
    numbers.  IANA has flexibility beyond these principles when handling
    assignment requests; other factors may come into play, and exceptions
    may be made to best serve the needs of the Internet.

It never says that this is a process that the IESG or IETF is required 
to follow. The language of the section has wiggle words throughout, and 
does not use RFC 2119 language. Thus nobody anywhere is bound by it.

c) RFC 2434 notes how expert reviewers are selected:

d) there is already a process to appeal decisions that are based on 
Expert Review:

    Any decisions made by the designated expert can be appealed using the
    normal IETF appeals process as outlined in Section 6.5 of [IETF-
    PROCESS]. Since the designated experts are appointed by the IESG,
    they may be removed by the IESG.

------

---

From: David Conrad <[email-masked]>
Date: Sun, 30 Jan 2011 10:52:13 -0800

Cullen,

> I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to over…

Joe is closer.  

In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services.  As such, they rely on technical experts to provide input/advice/recommendations.  In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input.  However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed.

Regards,
-drc

---

From: Michelle Cotton <[email-masked]>
Date: Sun, 30 Jan 2011 11:09:54 -0800

David has said this well.  Thank you.

Please let me know if there are any other questions.

--Michelle

On 1/30/11 10:52 AM, "David Conrad" <[email-masked]> wrote:

>> I think you are pretty misrepresenting the situation. My impression of the
>> reality of the situation is that if the IANA did not like the advice of the
>> expert reviewer, they might ask the AD to override but short of that they
>> pretty much do whatever the expert says.
> 
> 
> Joe is closer.  
> 
> In general, IANA staff are not technical experts in any of the wide variety of
> areas for which they are asked to provide registry services.  As such, they
> rely on technical experts to provide input/advice/recommendations.  In the
> past, there were some very rare cases in which the advice provided by the
> technical experts was deemed insufficient and IANA staff looked to the ADs or
> the IESG for additional input.  However, at least historically, IANA staff
> viewed the maintenance of the registries as their responsibility (at the
> direction of the IESG), not the technical experts' responsibility. I would be
> surprised if this had changed.
> 
> Regards,
> -drc
>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 Jan 2011 10:23:43 +0200

On 2011-1-30, at 17:12, Paul Hoffman wrote:
> The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse.

I don't follow. Assignments through IETF-stream documents do not go through expert review. And I've never witnessed IANA rejecting requests coming through the IETF. But even if they did, there is an appeals procedure.

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Jan 2011 14:06:01 +0100

> In band negotiation of security is applicable for some cases, but it adds latency, bandwidth, and complicated multiplexing in non session based transports. I think this is a bad idea in many cases.…

Well, the high level goal is to preserve a limited resource. We can't do
that without making the preference clear. But I think you have forgotten
to consider those statements trying to make clear that this is up to
review.

The review criterias can be expected to change overtime. They are also
hard to codify. Especially for this case, how do we measure
architectural uncleanness, implementation issues, and performance impact
to make a rule that judges if one or more port is allowed?

We clearly can't, this will be up to human judgment.

I also think it is important that we separate the basic registry rules
from the review guidelines, as they will change. Thus this is a separate
document. One that we should make clear is going to exist.

And as pointed out in other parts of this discussion there are several
ways of challenging the reviewers recommendation resulting in an IANA
decision. First of all is the appeal process. Secondly, is to take it
through the IETF approval process where IETF makes the decision, not IANA.

As I see it, we either leave these high level goals in this document, or
we remove the completely and put everything in a separate document.

I rather leave them in, because I don't seem them changing. Only be
acted up in varying ways over the coming years.

Cheers

Magnus Westerlund

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Jan 2011 06:51:14 -0800

On 1/31/11 12:23 AM, Lars Eggert wrote:
> I don't follow. Assignments through IETF-stream documents do not go
> through expert review.

Then this should be made *much* clearer in the document. In fact, the 
document says:

    A key element of the procedural streamlining specified in this
    document is to establish identical assignment procedures for all IETF
    transport protocols.

I assumed that "all" meant "all", not "all except those through 
IETF-stream documents"; others might have read it the same way I did. 
Further, the wording throughout the template description in 8.1 makes it 
sound like that the restrictions in this document apply to everything 
that needs a template, which clearly includes IETF-stream documents.

> And I've never witnessed IANA rejecting requests coming through the
> IETF.

This document is about new restrictions for the future, not what has 
happened in the past.

> But even if they did, there is an appeals procedure.

That is slim comfort to a WG that has designed a protocol that has good 
design reasons for needing two ports and, at the last minute is told 
that they either have to re-design from scratch or go through an appeals 
process to justify their design to IANA. It's fine that they have to 
justify it to the IESG (well, fine to me; other greybeards seem to not 
like that so much these days), but there should be no way that IANA can 
say "you cannot get ports assigned because this new RFC says that you 
designed your protocol wrong". If what you say above about "Assignments 
through IETF-stream documents do not go through expert review." is true, 
it should be plainly stated in the introduction to the document.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 Jan 2011 17:06:23 +0200

Hi,

On 2011-1-31, at 16:51, Paul Hoffman wrote:
> Then this should be made *much* clearer in the document. In fact, the document says:
> 
> I assumed that "all" meant "all", not "all except those through IETF-stream documents"; others might have read it the same way I did.

The sentence you quote isn't related to the issue we're discussing. It is intended to say "a goal is that the procedures to get ports and service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it would be clearer by explicitly naming these protocols in the document.)

But I see the point you're raising. The document should somewhere say that "Expert Review" is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, "IETF Consensus" is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent.

Did I get that right?

> That is slim comfort to a WG that has designed a protocol that has good design reasons for needing two ports and, at the last minute is told that they either have to re-design from scratch or go through an appeals process to justify their design to IANA. It's fine that they have to justify it to the IESG (well, fine to me; other greybeards seem to not like that so much these days), but there should be no way that IANA can say "you cannot get ports assigned because this new RFC says that you designed your protocol wrong". If what you say above about "Assignments through IETF-stream documents do not go through expert review." is true, it should be plainly stated in the introduction to the document.

Right. I think the change I outlined above would address this.

Thanks!

Lars

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Jan 2011 07:14:27 -0800

On 1/31/11 7:06 AM, Lars Eggert wrote:
> But I see the point you're raising. The document should somewhere say
> that "Expert Review" is the procedure used for assignment requests
> made directly to IANA, whereas for documents on the IETF Stream,
> "IETF Consensus" is sufficient to make the assignment. In other
> words, no expert review doesn't really need to happen for those,
> since IETF Review and IESG Approval are at least equivalent.
>
> Did I get that right?

Yes, that would greatly reduce the concern about where and when (and how 
often!) the review would happen.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jan 2011 09:13:57 -0700

> often!) the review would happen.

Hmm ... I don't agree that solves the issue. 

Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. 

I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. 

I'm sure that some people believe the draft, by using the word "strives", actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that "strives" means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Jan 2011 17:27:43 +0100

> Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. 

Who, ultimately, is the steward of this precious resource?  If it is not
the IANA and it is not the IETF, then who?  To say that it is everyone's
responsibility is to avoid responsibility entirely.  Who gets to say
which standards organizations are stewards and which are not?

> I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consens…

This is a VERY VERY dangerous approach you propose, Cullen.  It is akin
to saying, "you can think about security later, because we'll have to
give you a port for it later."  We don't want to be saying that.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jan 2011 09:33:15 -0700

So IANA has a huge amount of technical expertise and takes maintaing the registries very seriously. I've seen them catch technical mistakes that made all the way through WG and IESG review. I've got huge respect for technical competence of IANA and in particular Michelle. So I'm not questions that but  I don't recall seeing them override an expert on a technical issue. I'd be happy to hear of examples but lets consider the example I am actually concerned about here. 
 
I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, that will not meet the latency goals of the protocol. Joe does not agree. 

So Michelle, in that case, would you be willing to override Joe? I'm sure you would be willing to help facilitate any conversations, bring in other people such as ADs that can help etc. I was sort of working on the assumption that you would not override Joe in this case and the the only path forward would be an appeal to Lars but perhaps that is just a bad assumption on my part. Appeals are really the worst way possible to resolve things. I have a hard time imagining that IANA would want to engage in a technical discussion to resolve this and instead relies on the expert reviewer. I'll note that the expert review may report to IANA but they are selected by and replaced by the IESG. 

The important point here is that I really don't care if it is Joe or IANA that is saying no - I think this document should be clear that this BCP can not be used as grounds for rejecting the request for a second port for security. 

Cullen Jennings

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Jan 2011 08:40:31 -0800

On 1/31/11 8:13 AM, Cullen Jennings wrote:
> Well lets say the request was coming from 3GPP for a protocol they
> designed - why should IANA be able to tell them no but IETF yes.

Because IANA is responsible for maintaining the usefulness of the 
registry. Part of that is "don't hand out ports unnecessarily", and part 
of that is "hand out ports without hassle to those who are trusted to 
ask for them wisely". If 3GPP can show it belongs in the latter 
category, great. Until then, the only body that is there is "IETF 
consensus" plus maybe "IESG pressure".

> I think the policy issue here is fairly clear. We do not have
> consensus that in all cases that one should not have a second port
> for security (I'm basing this assertion on Magnus read of WG
> consensus and my read of IETF LC consensus). Therefore that should
> not be a ground for the expert reviewer (or IANA) to reject the
> registration. The document needs to be updated to make that clear or
> it does not reflect consensus. If the authors of the draft want to
> propose text for conditions when it would be ok to reject a second
> port for security purposes and see if they can get consensus for that
> text, that seems perfectly reasonable.
>
> I'm sure that some people believe the draft, by using the word
> "strives", actually means that this is not a grounds for rejection
> but given the push back from Lars and Joe, I believe that "strives"
> means that the decision is up to Joe. Given things could be read
> either ways, I think it's fair to ask for the draft to clarify this.

Fully agree.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Jan 2011 17:41:07 +0100

> Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. 

I am not certain I understand what your issue is here. Is it that they
can come to different conclusions, and that IETF can decided to override
the expert review team? I think that is the logical conclusion, as the
IETF's decision will have gone through a consensus process. One which
the expert can provide their view into this.

> I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consens…

My reading of the WG last call consensus is that nobody is disagreeing
with the goal of trying minimize the port consumption. My interpretation
is that we do need to state that goal in the document. And the only way
of achieving this is to try to minimize the consumption by each protocol
that requires a registration. That includes trying to get all
multiplexing into that single socket, or at least use it for agreeing on
dynamic range port for this protocol.

> I'm sure that some people believe the draft, by using the word "strives", actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that "strives"…

It is a high level goal to minimize the port space consumption. I do
believe there is strong consensus for this. And I believe that the only
way of ensuring that this goal is meet is to take a pretty hard stance
against frivolous use of ports.

Thus, I still think there is clear grounds for rejecting requests for
multiple ports based on not sufficiently motivating why it is impossible
to not use one port. I do agree that these guidelines should be
documented, and that is the plans as far as I know.

Cheers

Magnus Westerlund

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 31 Jan 2011 08:55:53 -0800

Cullen,

We do have some technical expertise within the IANA staff, however our
expertise is more aligned with the process of creating and maintaining
registries.  Part of that includes relying on the experts that the IESG
designates to make the decisions for requests that utilize the "Expert
Review" policy in RFC 5226.

In the past, if there is strong disagreement from an expert and the
requester disagrees, we have brought the Transport Area Directors into the
communications to see if all parties can come to an agreement.  In almost
all cases, this is where a final decision is made.  If that set of folks can
not come to a conclusion, we then would default to going to the IESG.  With
all requests, if there is any uncertainty as to what decision should be
made, we go to the IESG for guidance.

We do rely on the technical expertise of the appointed experts for all
registries, but we ALWAYS have the possibility to seek guidance form the
IESG.

I don't believe we have ever had an official appeals with ports (Knocking on
wood really hard!).

Does that help?

--Michelle

On 1/31/11 8:33 AM, "Cullen Jennings" <[email-masked]> wrote:

> 
> So IANA has a huge amount of technical expertise and takes maintaing the
> registries very seriously. I've seen them catch technical mistakes that made
> all the way through WG and IESG review. I've got huge respect for technical
> competence of IANA and in particular Michelle. So I'm not questions that but
> I don't recall seeing them override an expert on a technical issue. I'd be
> happy to hear of examples but lets consider the example I am actually
> concerned about here.
>  
> I put in a request for a latency sensitive protocol that uses DTLS and request
> a different port for the secure version. Joe as expert review says we should
> redesign the protocol to use something like STARTLS and run on one port. I
> assert, with very little evidence, that will not meet the latency goals of the
> protocol. Joe does not agree.
> 
> So Michelle, in that case, would you be willing to override Joe? I'm sure you
> would be willing to help facilitate any conversations, bring in other people
> such as ADs that can help etc. I was sort of working on the assumption that
> you would not override Joe in this case and the the only path forward would be
> an appeal to Lars but perhaps that is just a bad assumption on my part.
> Appeals are really the worst way possible to resolve things. I have a hard
> time imagining that IANA would want to engage in a technical discussion to
> resolve this and instead relies on the expert reviewer. I'll note that the
> expert review may report to IANA but they are selected by and replaced by the
> IESG. 
> 
> The important point here is that I really don't care if it is Joe or IANA that
> is saying no - I think this document should be clear that this BCP can not be
> used as grounds for rejecting the request for a second port for security.
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 31 Jan 2011 09:16:48 -0800

Lars,

> But I see the point you're raising. The document should somewhere say that "Expert Review" is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Str…

RFC2434 already gives IANA these options.

Perhaps - at best - we should include a ref to that.

However, this document is not focused at changing what RFC2434 says, and 
the above statement, IMO, does.

That's another can of worms, and should be reserved for a different 
document.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 31 Jan 2011 09:18:46 -0800

The procedures that are specified - for ALL assignments - are the 
PROCEDURES - the word itself is used specifically in the heading of 
section 8.

That does not refer to the "principles" - again for which there are more 
than sufficient wiggle words, and which already cite existing RFCs that 
have provisions that already limit the role of Expert Review and allow 
for appeals.

Again - this document is NOT focused on those principles. IANA - and 
more specifically its review team - is NOT required to publish any such 
principles (as per RFC 5226). If they continue to be a source of 
contention, then section 7 should be removed.

Joe

On 1/31/2011 6:51 AM, Paul Hoffman wrote:
>>> The above emphatic statements means that IANA can reject a request
>>> for an IETF-approved protocol that needs two ports without recourse.
>>

---

From: Joe Touch <[email-masked]>
Date: Mon, 31 Jan 2011 09:25:23 -0800

On 1/31/2011 9:16 AM, Joe Touch wrote:
>> The sentence you quote isn't related to the issue we're discussing. It
>> is intended to say "a goal is that the procedures to get ports and
>> service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it
>> would be clearer by explicitly naming these protocols in the document.)
>>
>> made directly to IANA, whereas for documents on the IETF Stream, "IETF
>> Consensus" is sufficient to make the assignment. In other words, no
>> expert review doesn't really need to happen for those, since IETF
>> Review and IESG Approval are at least equivalent.
>

As does RFC 5226 - its update (there is no substantive change between 
the two in this regard, FWIW).

> Perhaps - at best - we should include a ref to that.

And 5226 is already clearly cited.

No further action should be required.

Joe

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jan 2011 10:39:48 -0700

Thanks - yes that makes it clear and I like the way IANA handles all of this.

Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jan 2011 10:44:28 -0700

> documented, and that is the plans as far as I know.

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.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jan 2011 10:51:51 -0700

So first, we already have a BCP that says  more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that - security. It's probably impacts design work in working groups more than any other BCP. It has IETF consensus. The IESG holds protocols to this. 

Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy.  Please do enlighten me.

And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design. 

Cullen Jennings

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Jan 2011 18:56:49 +0100

> So first, we already have a BCP that says  more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that -…

But this isn't only about IETF process.  You just asked about why the
IETF is special and why 3GPP shouldn't be treated on equal footing. 
Well, then what about ITU, ISO, W3C, and Joe's Standards Body?

> Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy.  Please do enlighten me.

The vast majority of the requests I see have 0 security built in until I
ask the question.  A few come back with a plan.  Take away that lever
and I don't even get to ask the question.
> And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design. 

I missed a step there?  CoAP?

---

From: Joe Touch <[email-masked]>
Date: Mon, 31 Jan 2011 10:42:03 -0800

Fwiw please see sec 8.1 of our doc which states which procedures of RFC 5226 are specified for each range, and already allows IESG approval as a path for user ports. 

Joe

On Jan 31, 2011, at 9:25 AM, Joe Touch <[email-masked]> wrote:

> As does RFC 5226 - its update (there is no substantive change between the two in this regard, FWIW).
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Jan 2011 11:53:00 -0800

> Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy.  Please do enlighten me.

I don't think it does.

At a high level, there are three ways in which insecure and secure
versions (by which I mostly mean channel security mechanisms such as
TLS) of the same protocol can coexist:

1. They can operate on totally different transport parameters (e.g., ports)
2. They can be demuxable by some indicator that's simply sent by one
side and accepted or rejected by the other side. (E.g., "If the first
byte is 20 this is TLS, else it's not)
3. It can be negotiated as in STARTTLS

In the first two of these, the client knows which version it wants
(secure or insecure) and there is no chance for the server to indicate
otherwise other than failing the connection. In the third, the sides
negotiate. So, I think the first question is which general design you
wish to have. Each of these have their merits: negotiation designs are
more complicated but allow for opportunistic security. Unfortunately,
they also allow for downgrade attack, as the experience with STARTTLS
for SMTP shows. By contrast, non-negotiation designs are easier to
implement and provide for referential integrity but not for
opportunistic security. IMO there is a place for both, though I
generally tend towards non-negotiated designs, in part out of a
feeling that the world would be better if people used encryption all
the time.

Clearly, if you're going to do a negotiation design you want a single port.
If you're going to do a non-negotiated design, then I don't see a huge
amount of value in using a single port. It's true that there is a port
consumption issue, but OTOH ports are there for protocol demuxing and
this is clearly another protocol. It's simply a lot easier to have
your TLS stack just start its thing rather than try to autodetect
whether you have TLS or some other protocol. So I would generally push
back on the claim that non-negotiated designs should have to have
demuxing in information in the dataflow rather than use the port.

> And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design.

I don't consider this an acceptable design and I've already told the
CoAP authors and chairs so. Speaking as chair, if the CoAP
authors/chairs wish to pursue this avenue they should bring it to the
TLS WG, which AFAIK they have not done.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Jan 2011 23:11:10 +0100

Eric,
> this is clearly another protocol.

Another way to look at this is that it's the same protocol running atop
a security layer.  Same protocol engine, perhaps in a slightly different
security context in terms of what is authorized.  And there's good
reason to look at it this way.  Aside from the leverage it gives
reviewers as I discussed previously, there's also the minor matter of
port consumption, which won't be so minor if we run short.  And don't
think that can't happen.  Additional ports are being approved for
reasons that are clearly architecture limitations.  I'm not even sure
this is an acceptable excuse.

For one, if we look at some of the examples that have been mooted, I
doubt that an additional port would have solved the downgrade problem. 
The case I have in mind is indeed SMTP.  The conditions that allow for
the downgrade attack have more to do with the realities of certificate
management than STARTTLS.

As I wrote in a different context there is also the draft that Paul has
written for HASTLS, which allows a server to express a policy without
having to require a port.  While some of us have some questions about
some of the choices Paul made in the design, on the whole I think
everyone agrees it's a good idea.  It may not, however, solve the entire
problem, because we now are forced to answer the question as to how host
policy should be conveyed.

>  It's simply a lot easier to have
> whether you have TLS or some other protocol.

Maybe so (wasn't so hard for me), but there now is a whole lot of free
code out there that does just this.

>  So I would generally push

There is a cost that extends beyond the protocol.  That has to be taken
into account.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Jan 2011 14:21:16 -0800

> this is an acceptable excuse.

Really? What fraction of the port space has been consumed?

> management than STARTTLS.

I didn't say it did, if you reread my message. What I said was that
not negotiating
addresses downgrade.

> everyone agrees it's a good idea.

Well, I'm not sure I see the relevance of this. The question is how
the server supports
both secure and insecure variants at once.

> Maybe so (wasn't so hard for me),

Well, I have no idea what protocol you're thinking of, but all of the
upward negotiation
protocols have a significantly more complicated state machine than does HTTPS.

>but there now is a whole lot of free

And it's generally all protocol specific, so we have this problem with
every new protocol.

> There is a cost that extends beyond the protocol.  That has to be taken

Of course. Which is why I'm not saying that you should ALWAYS do a
separate port.
But I don't agree there is consensus that it's bad either.