To recap, I presented on the issue of updating the IPsec/IKEv2 text at the 6man meeting in Maastricht, as well as at the SAAG meeting. My sense of both of those discussions is that there is support for changing the general recommendation to a SHOULD.
I got some good feedback in SAAG about the wording (refer to the security architecture generally rather than IKEv2, etc.). New proposed text below. Comments? Thomas 10. Security This section describes the specification for security 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 the level of security actually achieved in practice. More importantly, deficiencies or a poor fit in any one individual component can significantly reduce the overall effectiveness of a particular security approach. IPsec provides channel security at the Internet layer, making it possible to provide secure communication for all (or a subset of) communication flows at the IP layer between pairs of internet nodes. IPsec provides sufficient flexibility and granularity that individual TCP connections can (selectively) be protected, etc. Although IPsec can be used with manual keying in some cases, such usage has limited applicability and is not recommended. A range of security technologies and approaches proliferate today (e.g., IPsec, TLS, SSH, etc.) No one approach has emerged as an ideal technology for all needs and environments. Moreover, IPsec is not viewed as the ideal security technology in all cases and is unlikely to displace the others. Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IP Security Architecture [RFC 4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently the default automated key management protocol to implement is IKEv2. This document recognizes that there exists a range of device types and environments where other approaches to security than IPsec can be justified. For example, special-purpose devices may support only a very limited number or type of applications and an application- specific security approach may be sufficient for limited management or configuration capabilities. Alternatively, some devices my run on extremely constrained hardware (e.g., sensors) where the full IP Security Architecture is not justified. 10.1. Requirements "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently the default automated key management protocol to implement is IKEv2. 10.2. Transforms and Algorithms The current set of mandatory-to-implement algorithms for the IP Security Architcture are defined in 'Cryptographic Algorithm Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes implementing the IP Security Architecture MUST conform to the requirements in [RFC4835]. Preferred cryptographic algorithms often change more frequently than security protocols. Therefore implementations MUST allow for migration into new algorithms, as RFC4835 is replaced or updated in the future. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
