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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf