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

[Yoav Nir <[e-mail]>]

Hi all

This might be of interest to the group. Joe is suggesting here (and in the next messages on the thread) to update RFC 4301.

Begin forwarded message:

> From: Joe Touch <[e-mail]>
> Date: August 25, 2010 10:55:27 PM GMT+03:00
> To: Thomas Narten <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text
> 
> 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.
> 
> 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]
> 
>>    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.
> 
>>    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.
> 
>>    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. 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.
> 
> ---
>