On Tue, Nov 29, 2016 at 5:31 PM, Joe Touch <to...@isi.edu> wrote: > Hi, Tom, > > > On 11/29/2016 12:56 PM, Tom Herbert wrote: >> On Tue, Nov 29, 2016 at 12:04 PM, Joe Touch <to...@isi.edu> wrote: >>> Hi Brian, >>> >>> >>> On 11/29/2016 11:43 AM, Brian E Carpenter wrote: >>> >>> >>>>>> I also don't really understand >>>>>> the security model. There is some discussion of IPsec tunnels and >>>>>> RFC3884. >>>>>> If we use IPsec tunnels, why would we need DTLS? For that matter, if we >>>>>> use >>>>>> TLS tunnels, why would we need DTLS? >>>>> TLS is a very bad idea. We should never try to tunnel IP over TCP. >>>> I agree it's a terrible idea, but pragmatically situations can arrive >>>> where it's >>>> the only real option. >>> Sure, but it's bad enough to try to avoid if there are other alternatives. >>> >> 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. 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. 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. > 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!). >> GUE with DTLS is nice because we can have both an >> extensible encapsulation header that might read readable by the >> network as well as a secured payload. > There are many tunnels that have extensible headers. Additionally, IPsec > can protect the tunnel header whereas DTLS cannot. > > However, I agree that there are many solutions. > > >> >>>>> DTLS might be available where IPsec isn't. >>>> If that is the case, it needs to be explained in more detail in the draft. >>> Agreed. >>> >>>> Anyway it needs to be a clear choice: IPsec or DTLS, but not both. >>>> (This is a point that has also come up in the Anima WG, as it happens.) >>> Agreed as well. >>> >> I'm not sure I understand why this is a binary choice. The draft isn't >> requiring any particular tunnel encapsulation and so security isn't be >> required (might depend on encapsulation). Or does this mean that we >> want to avoid using DTLS or TLS simultaneously on the same packets? >> (which does some like a bad idea...) > I think Brian was saying there might be little benefit to using both > IPsec and DTLS on the same packet, but I also think we're all in > agreement here. > One open question we have concerning tunnels in this area is how to know when we need to apply security at lower layers. 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. If no higher layer has encrypted the packet then we may want to do it for tunneling over Internet to secure user's data. 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... Tom > Joe > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
