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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
