Hi, Tom,
On 11/30/2016 8:08 AM, Tom Herbert wrote: > On Tue, Nov 29, 2016 at 5:31 PM, Joe Touch <[email protected]> wrote: >> Hi, Tom, >> >> >> On 11/29/2016 12:56 PM, Tom Herbert wrote: >>> This is why we like DTLS as opposed to IPsec, to the network this just >>> looks like UDP which presumably is more palatable to some network >>> devices. >> Those devices might support "network connectivity", but they are NOT the >> Internet. The Internet is supposed to be agnostic to IP packet contents. >> > Joe, > > Sadly, what the Internet is supposed to be and what it is have > diverged. As much as we wish otherwise, there are still many devices > and networks on the Internet that are not agnostic to IP packet > contents. And those issued need to be addressed and called out. FWIW, this is my definition of "being on the Internet": http://www.isi.edu/touch/internet-rights/ > See draft-gont-v6ops-ipv6-ehs-in-real-world-02, > draft-byrne-opsec-udp-advisory-00, the difficulties of deploying SCTP, > or for that matter how any stateful firewall or stateful NAT works. We really should be pushing back on the notion that "what vendors deploy is what the Internet is". Vendors' interests focus on increased profit for decreased capability, which drives us towards the lowest common denominator. > Actually matters have been even worse, there are devices that are not > even agnostic to _transport_ layer payloads-- when we turned up TLS > several radio network operators complained that they could no longer > parse HTTP which they deemed was important to their operations. The > net result of all this is protocol ossification on the Internet. When > we deploy protocols on the Internet we have to consider what the real > effects are. The ossification is created by those who restrict protocols. It is pointless to try to endorse that ossification; all we end up with is the same problem at another layer. > Further, IPsec over UDP also exists (RFC3948). > >>> DTLS can also be implemented by an application (e.g. in >>> userspace). >> So can IPsec over UDP. >> > Yes, but there is no analogue for IPsec over TCP (and should not be!). This contradicts your argument above for two reasons: 1) it exists: http://www.cisco.com/c/en/us/support/docs/security/vpn-3000-series-concentrators/14370-vpn3k-ipsec-tcp.html 2) it is an example of "we had to do it this way to traverse TCP-only NAT" So if you agree this is incorrect, then so should other methods that do not provide a *real* Internet. > ... > One open question we have concerning tunnels in this area is how to > know when we need to apply security at lower layers. I agree, but I would note that you can remove "tunnels in this area". But that's because the role of security at these layers is very poorly understood. > For instance, if > an application has already encrypted payload using TLS then we > shouldn't need to encrypt over a tunnel, doing would be mostly > redundant and result in wasted resources and increased latency. TLS protects the application data, but not the headers (i.e., the "protocol control plane"). I.e., you might still want to use IPsec or TCP-AO to protect TCP from attacks. > If no > higher layer has encrypted the packet then we may want to do it for > tunneling over Internet to secure user's data. The only way a user can know their data is protected is to setup the protection. Otherwise, it has to assume the data is not protected. This is the whole point behind the E2E argument - you cannot delegate some responsibilities. > We expect the trend to > be more applications will implement their own security, however there > are still a significant number that benefit from tunnels with > security. The problem is there's no obvious way to detect that a > packet is already encrypted at tunnel ingress. Trying to deduce by > port number is too weak of a signal for security. TCP ENO has promise > but that would require connection tracking and more of intermediate > devices parsing TCP options... And you should NEVER do any of these things anyway. You protect the tunnel because you want the tunnel and its control to be protected. I agree - it's not useful to try to determine whether security is active at other layers, but it shouldn't be the deciding factor IMO either. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
