Re: [IPsec] [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text

[Paul Hoffman <[e-mail]>]

First off, Thomas gave the wrong pointer. The draft under discussion is draft-ietf-6man-node-req-bis, not draft-ietf-ipv6-node-requirements; the latter became RFC 4294.

At 12:55 PM -0700 8/25/10, Joe Touch wrote:
>Hi, Tom,
>
>On 8/25/2010 6:20 AM, Thomas Narten wrote:
>>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.
>>
>>This text would go into draft-ietf-ipv6-node-requirements, which
>>updates RFC 4294.
>>
>>Comments?
>
>First, this seems to override Sec 10 of RFC4301, so it would need to update RFC4301 as well.

I am quite hesitant to have an Informational RFC update a Proposed Standard RFC. Further, it does not "override" anything: it is suggestions for developers.

>
>Some other comments below.
>
>Joe
>
>>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.
>
>IPsec can protect down to the socket pair (src addr/src port/dst addr/dst port) granularity, but there are two important issues. First, this is rarely done; it is more common to protect services (i.e., at least letting the src port of incoming SYNs float). Second, such granularity would reuse an SA for different TCP connections that reuse the port pair.
>
>I.e., there is no way I am aware of to ensure that IPsec changes SA keys for a socket pair for each TCP connection that reuses that socket. TCP-AO can achieve this, however.
>
>So it is not individual TCP connections that are protected; it is individual socket pairs (at best), and more likely all connections between two specific endpoints for a given service.
>
>[FWIW, this might be a good opportunity for the IPsec doc to crossref TCP-AO, and to have at least a short note as to when each is preferred, or to refer to that discussion in the TCP-AO document]

I would prefer that this sentence in draft-ietf-6man-node-req-bis be removed and not to confuse IPsec documents with TCP-AO.

>
>>    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.)
>
>It might be useful to add TCP-AO here.

Please don't: it could easily confuse readers into thinking that it does more than authentication.

>
> >     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.
>
>It's important to note, however, that although any of these protects the user data, only IPsec and TCP-AO protect TCP connections from disruption attacks.

...somewhat protect...

>
>>    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.
>
>This might also be a good opportunity to revisit the issue of recommendations for tunnel and transport mode inclusion. During the revision of RFC4301, IMO the recommendations on transport mode were vague with respect to routers (RFC4301, end of section 4.1).
>
>I feel it is important to indicate the following:
>
>---
>
>Any device that acts like a host (i.e., sources packets with IP addresses assigned to their own interfaces) and implements IPsec MUST implement transport mode.

Gateways "source packets with IP addresses assigned to their own interfaces". I would strongly object efforts to reverse the IPsec WG's decision to reduce the demands for transport mode.

>All devices (hosts and gateways) that implement IPsec MUST implement tunnel mode. Because gateways always act as hosts for some protocols (as noted in RFC 1812), the conclusion is that all devices that implement IPsec MUST implement both tunnel and transport mode.
>
>   In summary,
>
>   a) A host implementation of IPsec MUST support both transport and
>      tunnel mode.  This is true for native, BITS, and BITW
>      implementations for hosts.
>
>   b) A security gateway MUST support both transport and tunnel mode.
>      Transport mode should be used only when the security gateway
>      is acting as a host, e.g., for network management, or to
>      provide security between two intermediate systems along a path,
>      as to secure a tunnel whose encapsulation is not provided
>      by IPsec tunnel mode.

Joe: what has changed since the IPsec WG decided the other way years ago that would require this change?

--Paul Hoffman, Director
--VPN Consortium