Subject: Security issues with draft-ietf-tsvwg-iana-ports-08

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Nov 2010 19:06:16 -0700

Greetings again. There is a new restriction in draft-ietf-tsvwg-iana-ports that will have a negative effect on the overall security of the Internet. Two restrictions in section 7.2 and the related one in section 9 prevent protocol designers from getting a second port for a secure (likely TLS-wrapped) version of their protocol based on wishful thinking that does not represent extensive reality in deploymet. I propose alternate wording below.

First, I should probably apologize. I am the author of RFC 2487 (updated by RFC 3207), the now-infamous "STARTTLS" option for SMTP. It seemed like a good idea at the time, it really did. No need for a second port and possible delays due to port-probing: just do an in-band security upgrade. And it could work with other common application protocols like POP and IMAP as well (RFC 2595)!

History has shown us wrong, but draft-ietf-tsvwg-iana-ports ignores that history. In short:

- There are serious security drawbacks to doing in-band upgrades within SMTP. Notice the large number of new attack descriptions and warnings in RFC 3207.

- The processing model for how to change state after the STARTTLS command was more complicated than what we thought, whereas it is completely clear what it means for applications over TLS on a second port.

- POP and IMAP have well-known upgrade semantics as well as each having a second port for TLS. Nearly all implementations use the second port, and interoperability for the upgrade mechanism was not widespread when it was last tested.

- SIP's two-port scheme has worked incredibly well.

- Having multiple code paths for "now you are in the clear" and "now you are under TLS" has proven to expose some serious security risks that do not exist for when a second port is used.

- Attempts to create TLS-like encryption and/or integrity protection without actually doing TLS usually ends up with security holes not in TLS.

- The number of new application protocols created over the past decade is significantly lower than was expected.

Given this, and recognizing that the resource scarcity of port numbers is a real concern for the long term, 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 proposed:
o  IANA will allow the allocation of one additional assigned port number 
   for a service that runs without security and with security if the
   second port is used for running that service under TLS. The
   application definition MUST say which version of TLS is to be run on
   the additional port, SHOULD use the most current version of TLS, and
   MUST say if there are cryptographic requirements beyond those in the
   TLS version used.

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
   allowed for new protocols as long as they meet the requirements above.

Section 9 current:
   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.

Section 9 proposed:
   Services are expected to include support for security, either as
   default, through a separate port using TLS, or dynamically
   negotiated in-band.  The use of non-protected variants of services
   (that is, clear text with no encryption or integrity assurance)
   continues to be discouraged in IETF standards, although it is still
   unfortunately a common occurrence even in new protocols.

Proposed new section 10.4:
   IANA will reserve 50 port numbers, 21850-21899, to be allocated for
   secure versions of new or revised protocols. Future IETF standards
   actions and/or BCPs may recover unused values in this range, or they
   may reserve more port numbers specifically for additional ports
   for security.

That last proposal should cover the port-scarcity concerns, and a future IESG will have a much better idea of the run rate on ports-for-security if they are all taken from one place starting now.

I am happy to discuss this more at the TSVWG meeting in Beijing if people want.

--Paul Hoffman, Director
--VPN Consortium

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 04 Nov 2010 08:21:47 +0000

Thanks Paul,

We should discuss this on the list because this is in WGLC - since this 
is a busy time of year for many, here is what I recall of the context:

This issue is being first noted in an I-D in draft-ports, but I do not 
recall anybody raised it as a point of discussion. I understood that it 
has been the recommendation of the ports review team, whose input is not 
binding to IANA nor based on a specific IANA policy.

The general principle is that all new port reservations should support 
security, either required or optional (negotiated in-band). I.e., if a 
port has significant potential security issues, or if security is 
required for firewall traversal, we expect that it will be required. I 
understood that the general intent is not so much to prohibit additional 
ports for secure variants, but not to recommend ports where security is 
an issue and security is NOT supported (i.e., try to avoid the insecure 
ones).

I think the intention was that additional ports for secure variants of 
existing services would still be endorsed by the ports review team.

(further comments in line).

On 04/11/2010 02:06, Paul Hoffman wrote:
> Greetings again. There is a new restriction in draft-ietf-tsvwg
 > -iana-ports that will have a negative effect on the overall
 > security of the Internet. Two restrictions in section 7.2 and
 > the related one in section 9 prevent protocol designers from
 > getting a second port for a secure (likely TLS-wrapped) version
 > of their protocol based on wishful thinking that does not
 > represent extensive reality in deploymet.
 >
That wasn't the reason I recall. I think the principle may
have been to encourage negotiation within a protocol rather
than requiring a dedicated port for each protocol variant
- there are of course lots of existing port assignments some
of which are to protocols that don't behave this way.

 > I propose alternate wording below.
>
> First, I should probably apologize. I am the author of RFC 2487
 > (updated by RFC 3207), the now-infamous "STARTTLS" option for SMTP.
 > It seemed like a good idea at the time, it really did. No need for
 > a second port and possible delays due to port-probing: just do an
 > in-band security upgrade. And it could work with other common
 > application protocols like POP and IMAP as well (RFC 2595)!
>
> - There are serious security drawbacks to doing in-band upgrades
 > within SMTP. Notice the large number of new attack descriptions
 > and warnings in RFC 3207.
>
> - The processing model for how to change state after the
 > STARTTLS command was more complicated than what we thought,
 > whereas it is completely clear what it means for applications
 > over TLS on a second port.
>
> - POP and IMAP have well-known upgrade semantics as well as
 > each having a second port for TLS. Nearly all implementations
 > use the second port, and interoperability for the upgrade
 > mechanism was not widespread when it was last tested.
>
> - Having multiple code paths for "now you are in the clear"
 > and "now you are under TLS" has proven to expose some serious
 > security risks that do not exist for when a second port is used.
>
> - Attempts to create TLS-like encryption and/or integrity
 > protection without actually doing TLS usually ends up with
 > security holes not in TLS.
>
> - The number of new application protocols created over the
 > past decade is significantly lower than was expected.
>
> Given this, and recognizing that the resource scarcity of
 > port numbers is a real concern for the long term, I propose
 > the following changes to draft-ietf-tsvwg-iana-ports:
>
> Section 7.2 current:
> That last proposal should cover the port-scarcity concerns, and a
 > future IESG will have a much better idea of the run rate on
 > ports-for-security if they are all taken from one place starting now.
>

I would encourage people to discuss this, now it has been raised,
but please do keep in mind that the actual IANA decisions are informed
by input from the ports review team.

The new proposal for text in section 10.4 also needs specific comments 
from the editors.

Hope that helps, and I assume that others will now follow this up,

best wishes,

Gorry

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Nov 2010 10:37:19 +0100

Paul,

Thanks for taking the time to review the document.  A few thoughts,
which may seem somewhat discombobulated at first, but bear with me:
> History has shown us wrong, but draft-ietf-tsvwg-iana-ports ignores that history. 

History hasn't entirely shown you were wrong.  I think history has shown
that getting certificates in place is a difficult administrative task
for mail, and in general.  I don't think port separation has anything to
do with it.  I think you ought not apologize for the work you have
done.  Rather it was very useful to highlight the difficulties of
configuring the application, quite frankly, and that HAS improved over
time (using sendmail as my benchmark).

> In short:

One thing I note is that it may be time for an update to 3207.  In
particular, you wrote:
> A publicly-referenced SMTP server MUST NOT require use of the
>    STARTTLS extension in order to deliver mail locally.  This rule
>    prevents the STARTTLS extension from damaging the interoperability of
>    the Internet's SMTP infrastructure.

That should be a deployment choice, right?  If I choose to reject your
mail because I don't want to receive unencrypted mail over the Internet,
that is my choice.  Otherwise you are actually encouraging a downgrade
attack.

But to this end, I would also suggest that when viewed in the light of
what has gone on with DKIM, some of your security analysis provides for
an interesting path forward.  You write, for instance:
>    A man-in-the-middle attack can be launched by deleting the "250
>    STARTTLS" response from the server.  This would cause the client not
>    to try to start a TLS session.  Another man-in-the-middle attack is
>    to allow the server to announce its STARTTLS capability, but to alter
>    the client's request to start TLS and the server's response.  In
>    order to defend against such attacks both clients and servers MUST be
>    able to be configured to require successful TLS negotiation of an
>    appropriate cipher suite for selected hosts before messages can be
>    successfully transferred.  The additional option of using TLS when
>    possible SHOULD also be provided.  An implementation MAY provide the
>    ability to record that TLS was used in communicating with a given
>    peer and generating a warning if it is not used in a later session.

As we have seen with DKIM it is now possible to express policies out of
band.  I wonder whether we should generalize this approach, and would be
interested in your views.  I'll note that in the case of SMTP and
publicly facing servers, for instance, there really is no alternative
for a second port at the moment because there is no way to express the
security desire in an MX record.  Food for thought. 

This is less the case, of course, through the common use of "s" or
".tls" or the like in a URI schema, but the reason that Joe, Magnus, and
others have taken the position they have is not simply one of
stewardship (although in my opinion that is good enough), but also
simply because time has passed, our capabilities have evolved, and we
really ought to be able to get this right.

> - SIP's two-port scheme has worked incredibly well.

The above two statements ring true to the point of concern for me with
regard to the current draft.  Do we have sufficient infrastructure in
place to provide a best practice for those future services such that the
2nd port isn't needed?  And this is where I think we tie the above point
together.  Should we have better generalized OOB mechanisms like ADSP
for instance to indicate security policy FIRST?  And this relates of
course to another problem we have with port allocation, which is
discovery.  That chews up even more ports.  Do we have infrastructure in
place to put an end to that, and should we before proceeding further?

> - Having multiple code paths for "now you are in the clear" and "now you are under TLS" has proven to expose some serious security risks that do not exist for when a second port is used.

I think you will agree that multiple code paths exist, no matter whether
a separate port is used, but perhaps you could say more about the threat
here.

> - Attempts to create TLS-like encryption and/or integrity protection without actually doing TLS usually ends up with security holes not in TLS.

+1 but I don't see how it relates to your other points.

> - The number of new application protocols created over the past decade is significantly lower than was expected.

By whose measure?

Thanks,

Eliot

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Nov 2010 09:13:53 -0700

>time (using sendmail as my benchmark).

The still-difficult task of getting certificates in place is orthogonal to whether protocols should be restricted to a single port. History has shown that foo-over-TLS does work, and can be done securely.

>that is my choice.  Otherwise you are actually encouraging a downgrade

Correct. But this argues for a two-port solution, not an inline-upgrade requirement.

>really ought to be able to get this right.

This brings to the fore the question of launch-by-URI vs. launch-by-app-configuration. Today, it is very rare for someone to retrieve their email by double-clicking on a pop or pops URI: it is done in a POP client application that has some configuration about security preferences.

>2nd port isn't needed?

Given that the only well-deployed protocol that does *not* have two ports is SMTP, and given how poorly that has gone, the best practice seems like a second port. I don't believe that will always be true; I can envision an IESG that says "you cannot run that without TLS, you only get one port and you have to define how to use TLS", but that has not happened yet.

>  And this is where I think we tie the above point

We do not have any such infrastrucure yet (although we will be discussing getting that started in the websec WG next week). Thus, this draft in WG LC cannot assume that such infrastructure will be in place in time to prevent security issues from its requirements. That's why I put in the "reserve a bunch of ports that are easy to watch and allow that reservation to change later" section of my proposal.

>a separate port is used, but perhaps you could say more about the threat

The code path for foo-on-a-second-port is "Start TLS; if it returns true, go forwards; otherwise stop". The code path for foo-with-upgrade has significantly more branches, as RFC 3207 shows.

>+1 but I don't see how it relates to your other points.

If a protocol developer is forced to use one port but doesn't want to do TLS, they pretty much have to reinvent it. It is much easier to say "no security on port x, just do TLS on port y".

> > - The number of new application protocols created over the past decade is significantly lower than was expected.

Hallway wisdom. Non-scientific scanning for "IANA" and "port" in the past 3000 RFCs. Reports at Apps Area meetings. In the heady days of 2000, many people thought at apps would bloom like wildflowers; turns out nearly all of those are running on port 80.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Nov 2010 08:56:15 -0700

At 8:21 AM +0000 11/4/10, Gorry Fairhurst wrote:
>This issue is being first noted in an I-D in draft-ports, but I do not recall anybody raised it as a point of discussion. I understood that it has been the recommendation of the ports review team, whose input is not binding to IANA nor based on a specific IANA policy.
>
>The general principle is that all new port reservations should support security, either required or optional (negotiated in-band). I.e., if a port has significant potential security issues, or if security is required for firewall traversal, we expect that it will be required. I understood that the general intent is not so much to prohibit additional ports for secure variants, but not to recommend ports where security is an issue and security is NOT supported (i.e., try to avoid the insecure ones).

That's a fine suggestion, but it is not reflected in reality. That is, (nearly?) every modern application protocol of merit has been dual-port, insecure and under-TLS. The IESG has approved these. Why should an IANA policy be the one that dictates the type of security that a protocol designer wants include?

>I think the intention was that additional ports for secure variants of existing services would still be endorsed by the ports review team.

That is not what the draft says. There is no differentiation between existing services and new ones, and given the way that protocols get forked, it is not clear that such a differentiation makes sense.

I assumed that the new rules for security evolved from the emphasis on conservation of ports for the future, as described in 7.2. If that's wrong, and the new rules were there to state a new IETF policy, I think that a different and longer document, sourced by the Security Area, might be more appropriate.

>of which are to protocols that don't behave this way.

As I described in my list, negotiation within a protocol has lots of security faults and has not been embraced. We thought it was a grand idea, and we were shown to be wrong.

>by input from the ports review team.

This is the first I have heard of such a team, and it is mentioned nowhere in this draft; that in and of itself should be fixed. The idea of having new applications work their way all the way through WG consensus and then discover that a ports review team says that their security design is wrong, please start over, does not seem like a good process model.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Nov 2010 19:26:51 +0100

Hi Paul,

I think you've raised some really good points, but I am still concerned
about one issue, and I'm not sure this draft is the place to fix it: if
applicants are left with the impression that IANA won't allocate another
port for additional security, perhaps they get to think about it NOW. 
If on the other hand, they think they can always apply later, they will
think about it LATER.  I would rather they think about it NOW.  In
practice I don't know that they actually will think about it NOW, but
rather simply reserve a means to STARTTLS (or the like), and so again, I
don't if we can fix this one.  That just leaves stewardship.

Eliot

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 06 Nov 2010 02:33:07 +0100

> don't if we can fix this one.  That just leaves stewardship.

Paul and Eliot,

I have to agree with Eliot here. I clearly can understand your view on
how things has been and are. I would like to start with pointing out
that most ports allocated to protocols each years are not done by IETF,
nor discussed in IETF at all.

We also know that if considered from start there is little issue with
doing TLS and non TLS on the same port. I agree that retrofitting an old
protocol is not necessarily as easy nor deployable. I do expect the port
review team will actually approve a request for a second port if there
is shown need.

I think the issue here is to strike a balance in the text so that it is
clear that for existing protocol it might be possible to get a second
port, but we really do expect new protocols to have support from the
start to do TLS on that single port.

I also think reserving ports for old protocols is a bad idea. We have no
immediate shortage of ports, if I remember Joe's calculations correctly
our current consumption rate would result in run out for TCP in around
50 years. Thus reserving for this purpose seems strange, as the
protocols that do truly need a second port can get one. So to avoid
sending a message, that I don't want to send nor reserve ports when not
needed I think this idea should be skipped.

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: Paul Hoffman <[email-masked]>
Date: Sat, 6 Nov 2010 10:00:17 -0700

>nor discussed in IETF at all.

Understood. That is one of the reasons I wanted to do the "reserve 50 ports for 'second port for security' and see what happens to them. We would have much better data about where those assignments are coming from. I also purposely picked an oddball set of ports so that people who said "we want n for the protocol and n+1 for protocol-over-TLS" would instead get n and something inconvenient to type.

>doing TLS and non TLS on the same port.

Which "we" are you talking about here? :-) I have not seen any protocols that considered it from the start that don't have essentially all of the problems of SMTP with STARTTLS, as described in RFC 3207, but I could have missed them.

>I agree that retrofitting an old

The current wording would prohibit that; thus, my proposed change.

>start to do TLS on that single port.

Same question: who is the "we" here? I suspect that in this case you mean the IESG, and if you are actually going to enforce that, I'm happy. I'm also skeptical, and my skepticism isn't helped by the fact that this significant security protocol design guideline is buried in an IANA document that came from TSV, not Security.

>needed I think this idea should be skipped.

We fully agree here. If there is anything in my proposed wording that suggested that all old protocols get a second port without asking, I am happy to change it. To date, I haven't heard of anyone in the Apps area who wanted this.

--Paul Hoffman, Director
--VPN Consortium

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 10:48:17 +0800

> Understood. That is one of the reasons I wanted to do the "reserve 50 ports for 'second port for security' and see what happens to them. We would have much better data about where those assignments…

Ok, I don't know about that. I did a bit of looking on the number of
port numbers that includes TLS in their comments fields. It appears that
the number is around 55 ports assigned today for TCP (106 occurrences at
http://www.iana.org/assignments/port-numbers). Searching for SSL (184
hits), Secure (157 hits). Considering that most TCP based protocols also
got an UDP port, the actual number of services using TLS/SSL or being
for the secure version seems to be around 100.

This number is pretty low compared to the number of port assignments
every year that are around 400 per year.

> Which "we" are you talking about here? :-) I have not seen any protocols that considered it from the start that don't have essentially all of the problems of SMTP with STARTTLS, as described in RFC…

Sorry, I was probably way to loose with WE here.

Also, STARTTLS is not the only way of using TLS on a joint port. If you
can de-mux TLS requests and unsecured ones on the same port without
needing an initiation command then things would work differently.

Also, I don't see why the security considerations for STARTTLS like the
man in the middle isn't similar for operation over two ports. If you can
fiddle with the packet in flight, you can probably block or interfere
with the TLS setup also. Thus forcing fallback to unsecure.

> Same question: who is the "we" here? I suspect that in this case you mean the IESG, and if you are actually going to enforce that, I'm happy. I'm also skeptical, and my skepticism isn't helped by t…

Here I did mean the author team. I would appreciate some input from the
security area on this issue.

As I see it if we make using different ports for TLS and a non-secure
version we basically double the port usage for protocols that needs TLS
type security. Thus increasing the port usage significantly.

I don't want to ignore this issue, but the question here is how to do
the trade-off between getting more long lived usage out of the port
registry and have reasonable implementation burden and security properties.

So far I am personally leaning towards the custodian of the port space
view but are willing to convinced that the downsides are so bad that we
do need to consume more port space.

> We fully agree here. If there is anything in my proposed wording that suggested that all old protocols get a second port without asking, I am happy to change it. To date, I haven't heard of anyone…

No, I didn't mean to imply that they would get it without asking for it.
But I do know understand your intention with the reservation. I think we
can probably get the statistics without having a special range. If we
want a disincentive by using a range that is another question.

Cheers

Magnus Westerlund

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Nov 2010 17:18:53 +0800

>needing an initiation command then things would work differently.

True. Is that done in any IETF protocols? I know people thought about this, but I thought they all had rejected it, but I easily could have missed something.

>with the TLS setup also. Thus forcing fallback to unsecure.

Dang, I wish we had documented this decision tree in RFC 3207.

There is a *huge* difference here. If the protocol has an upgrade/downgrade option, the state machine needs to have at least one place for the server to decide whether or not it wants a downgrade as well as at least one "has this client upgrade it yet?" place. With two ports, you just don't turn on the unsecured port.

>want a disincentive by using a range that is another question.

If we can get statistics such as "number of second ports for application protocols in the past three years", that would be great.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eliot Lear <[email-masked]>
Date: Mon, 08 Nov 2010 13:51:16 +0100

> True. Is that done in any IETF protocols? I know people thought about this, but I thought they all had rejected it, but I easily could have missed something.

I think we may be making a mountain out of a mole hill on this one, to
be frank.  Any server multi-threaded server implementation should just
view all of this as another set of attributes on a descriptor.  That is
certainly the case, for example, with dovecot, sendmail, and apache. 
And so while, yes, I don't see as much demuxing INSIDE the application
protocol, roughly the same amount of complexity is there.

Eliot

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Nov 2010 11:45:44 -0800

> existing services would still be endorsed by the ports review team.

Yes; we didn't talk about that part.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Nov 2010 11:52:38 -0800

On 11/3/2010 7:06 PM, Paul Hoffman wrote:
> Greetings again. There is a new restriction in
> draft-ietf-tsvwg-iana-ports that will have a negative effect on the
> overall security of the Internet. Two restrictions in section 7.2 and
> the related one in section 9 prevent protocol designers from getting
> a second port for a secure (likely TLS-wrapped) version of their
> protocol based on wishful thinking that does not represent extensive
> reality in deploymet. I propose alternate wording below.

It's important to note that this is not a "restriction".

Sec 7.2 states:
    This section summarizes the basic 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 are not required to be bound by these principles when
    handling requests; other factors may come into play, and exceptions
    may occur where deemed in the best interest of the Internet.

I.e., the goal of 7.2 is to explain the basic principles of the 
approach, but it IS NOT BINDING.

The key point, IMO, should be:

> - POP and IMAP have well-known upgrade semantics as well as each
> having a second port for TLS. Nearly all implementations use the second
> port, and interoperability for the upgrade mechanism was not widespread
> when it was last tested.

History has shown many things -- I would argue that foremost among these 
is that port numbers are a horrible place to assume security.

In general, a port opens a service, and the service determines security 
anyway, so that's the model that makes most sense to me. In particular, 
the assumption is that security should be supported in all new 
assignments, and that when it is optional, that is a decision within the 
protocol.

...
>     MUST say if there are cryptographic requirements beyond those in the

This is a severe concern; it basically doubles the allocation rate.

Further, the new language includes 2119-level language; this isn't 
appropriate, since this document is not binding anyway.

>     may reserve more port numbers specifically for additional ports

First, all new protocols should support security, IMO (call that SHOULD 
if you want).

Second, as noted above, port numbers are a horrible place to assume 
security per se. It's trivial for services to override them.

I am not in Beijing, but can continue this discussion via email...

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Nov 2010 11:52:40 -0800

On 11/7/2010 6:48 PM, Magnus Westerlund wrote:
...
> for the secure version seems to be around 100.

FWIW, that last part hasn't been true for a few years now. IANA doesn't 
give both UDP and TCP; each protocol needs to be requested specifically 
and motivated individually.

We also recently started to label UDP ports used solely for discovery as 
-disc (this is a *suggestion* to applicants, not a hard requirement).

Old protocols are, FWIW, intended to be handled as per the wiggle words 
at the beginning of Sec 7.2. Again, this is NOT BINDING. It's intended 
to inform the public about the current view, which can (and will) change.

Perhaps those items shouldn't even be in this doc? (omit sec 7?)

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Nov 2010 11:54:29 -0800

> If we can get statistics such as "number of second ports for application protocols in the past three years", that would be great.

Recent allocations are listed with a date stamp in the ports list, i.e., 
this information can be extracted by anyone (and, FWIW, IANA doesn't 
keep a database that makes that extraction easier, AFAIK)

Joe