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