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

[[e-mail]]

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

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.

> 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.

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