Hi Thomas, Thomas Narten <nar...@us.ibm.com> writes:
> Thoughts? 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*). 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. 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 > Proposed new text: > > 10. Security > > This section describes the specification of IPsec for IPv6 nodes. > > Achieving security in practice is a complex undertaking. > Operational procedures, protocols, key distribution mechanisms, > certificate management approaches, etc. are all components that > impact whether security is actually achieved in practice. More > importantly, deficiencies or a poor fit in any one individual > component can significantly reduce the overall effectiveness of an > particular security approach. > > IPsec provides channel security at the Internet layer, making it > possible to provide secure communication for communication flows > between pairs of internet hosts. IPsec provides sufficient > flexibility and granularity that individual TCP connections can > (selectively) be protected, etc. > > IKEv2 is the key management protocol for IPsec. Although manual > keying can be used with IPsec in some cases, the overall > applicability of statically configured keys is limited. Thus, IPsec > without IKEv2 has only limited value. > > 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. - Except for advanced users, SSH serves a single purpose: remote connections for administration. I don't know if it should be kept here. 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. A "MUST support IPsec and IKE" would be a step in the good direction. > 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. Cheers, a+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
