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 chai
rs, 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 say
ing 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
ietf(_at_)ietf(_dot_)org mailing lists by 2011-02-01. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf