Hi, Thomas Narten <nar...@us.ibm.com> writes:
>> IPsec and IKE have seen limited deployment on IPv4 networks due to the >> lack of E2E there, caused by NAT (client/server model and deployment of >> TLS for protecting *applications*). > > I think there is more to lack of deployment than the above. There are > many reasons why IKEv1 and IPsec are not more widely deployed than > they are. What other reasons not listed in my email? ;-) >> Additionally, I also agree that IKEv1 specification documents (RFC >> 2407, 2408 and 2409) were a pain. PKI were not deployed and this was >> a problem too. > >> Today, IPv6 provides E2E connectivity between end hosts. The work >> performed by ipsecme WG on IKEv2 specification to merge previous IKEv1 >> documents into something consistent (RFC 4306, RFC 4718 and now ikev2bis >> document) is impressive. PKI are now widely deployed, even if we still >> miss some global credential services. Now, most stacks (windows, linux, >> mac os x, ...) have IPv6 and IPsec available. Basically, IPv6, IPsec and >> IKE are already available on all devices which can and have any interest >> to run those. > > This is way over stated. IKEv2 is just now starting to see > implementations. Usage is even further behind. > > I just went to the IPv6 ready logo site and searched for IKEv2 on the > list of devices that have acheived Phase II certification. I didn't > find a single entry. (http://cf.v6pc.jp/logo_db/approved_list_ph2.php) > > IKEv2 simply is not ready yet for usage on a significant scale. If you > look at the deployed based of IP devices (or even focussing on those > that support IPv6), very few of them support IKEv2 today. In the discussion, I was considering IKE in general. I don't really care if it is v2 or v1 because I consider the functionality it provides. Sure, IKEv2 is not already available on all platforms but IKEv1 is and you should consider the trend for major platforms: Linux has strongSwan, which interoperates with Windows 7 IKEv2 implementation. Do you know the pain is was (and still is) to make IKEv1 implementations interoperate in IPv4 environments? And for the certification argument, it would be ok to me if there were equivalent certification program for concurrent solutions (TLS or whatever). In fact, I would say that the availability of such certification programs is already an argument that the solution is worth considering. Additionally: http://www.vpnc.org/testing.html#IPv6Interop http://www.vpnc.org/testing.html#IKEv2BasicInterop >> Now, the (IMHO only) remaining problems with IPsec and IKE on IPv6 >> networks are the following: > >> - lack of global credential services (if some @google reads this ...). >> - ability for end user to configure things easily, i.e. simple and >> *usable* management interfaces > > If there are still significant gaps in our ability to use IPsec and > IKEv2, that again suggests to me that it is premature to mandate it in > all devices. It is simply premature to do so, from an overall > readiness perspective. Those gaps do not prevent the use of IPsec/IKE or the usefulness of the protocols, they just make it more difficult for real end user. The same is true on some aspects of IPv6: DNS provisioning, IPv4/IPv6 transition, availability. The IPsec/IKE aspects are being worked on: https://mice.cs.columbia.edu/getTechreport.php?techreportID=1433 The way I see it is that we have security building blocks (IPsec/IKE) that already work for many and which could easily be provided to many others, all the more if it is globally deployed. It seems the argument you have is that it is not ready to ship. I think some successful companies have previously shipped successful products in "beta" state and it just increased the use and the work on the products. And I think IPsec/IKE is now more than in a beta state. >> > A range of security technologies and approaches proliferate today >> > (e.g., IPsec, TLS, SSL, SSH, HTTPS, etc.) No one approach has > >> - I don't understand why you make a difference between SSL, TLS and >> HTTPS. It's simply TLS. > > OK, I need to clean this up. I could also mention SASL here, HTTP > digest, etc. > >> - Except for advanced users, SSH serves a single purpose: remote >> connections for administration. I don't know if it should be kept >> here. > > But it is an example of a security technology that is being used to > secure a class of applications, for which IPsec could also be used, > but is not. And I suspect that IPsec will not displace such usage. I use both daily. For different things. ssh to get a shell on remote devices. And IPsec/IKE to protect all kinds of traffic to remote devices. I will never argue on the usefulness of specific application security protocols. But their existence is simply not a counterargument for not having an IP security solution. >> In the end, you basically have IPsec at layer 3 and TLS at layer 4. I >> should also add the following: we use TLS in a very restricted way on >> the Internet today, for client/server communications and in fact mainly >> for browser/server communications. Mutual authentication is seldom, >> logic and configuration is per apps, ... > >> > emerged as an ideal technology for all needs. It seems clear that >> > for the foresable future, that situation will not change. Moreover, >> > IPsec is not viewed as the ideal security technology for all >> > approaches and is unlikely to displace the others. That is, IPsec >> > is not viewed as a good choice for all security needs. > >> IMHO, the thing is not to mandate the *use* of an *IP security* solution >> in people' architectures and products, but to provide the guarantee that >> such a compatible IP security solution is available on the different >> systems we buy and deploy. > >> AFAICT, IPsec/IKE is the only IP security solution we have. We know it >> works. It's mainly a matter of guaranteed availability, like for >> IPv6. If one has the guarantee to find that on all common IPv6 devices, >> then you get interoperability and deployment. > > I agree with this. But I've also come to the conclusion that for a > class of devices, mostly characterized by small footprint and limited > functionality, there are cheaper alternatives to providing security > than requiring the use of IPsec and IKEv2. > > E.g., should home gateways be required to support IKEv2 in order for > you to configure it? To configure it from the inside, no. To access your internal LAN from the outside, what do you think? Then, making them MIPv6 Home Agents would simply allow you to be at home everywhere ... >> A "MUST support IPsec and IKE" would be a step in the good > direction. > > Well, that is the question for this thread! > >> > Previously, IPv6 mandated implementation of IPsec and recommended >> > the key management approach of IKE. This document updates that >> > recommendation by making support of both IPsec and IKEv2 a SHOULD >> > for IPv6 nodes. In particular, it is recognized that there are a >> > range of device types and environments where other approaches to >> > security than IPsec can be more appropriate. This is particularly >> > the case for smaller specialized, single-purpose devices that >> > support only very limited applications or run on constrained >> > hardware. In other environments, support for IPsec and IKEv2 should >> > be considered a very strong SHOULD, if not a MUST. > >> I think the text is well written and captures the main issue, which is >> IMHO related to RFC 2119: small devices that cannot run TLS or IPsec/IKE >> due to their hardware limitations prevent the use of a "MUST". Because >> we do not have another keyword in the context of RFC documents, "SHOULD" >> is the only solution if we keep those devices in the global scope of >> "IPv6 nodes". > >> To me, the problem with the "strong SHOULD" is that it will not prevent >> anyone to ship an IPv6 system with TLS-enabled apps (i.e. no hardware >> limitations) and not IPsec/IKE at all while still claim compatibility >> with the standard. > > That is the balancing act we are trying to achieve. > > Note though that there are other profiles being developed outside of > the IETF that are focussed on specific deployments or > environments. They are free to mandate IKE even if we do not. E.g, in > the US, the DoD and the USGv6 profiles mandate IPsec and IKEv2. 3GPP > is another example. > > But for an IETF recommendation, we have a broader class of devices to > make recommendations for, and a wider range of potential usages. I understand your arguments. If people in the working group are ok to set the security requirements for IPv6 nodes to support the whole scope of devices (i.e. don't want to make an exception for constrained devices), then I think your text is the best we can have. Thanks for your time, Thomas. Cheers, a+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
