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

[Joe Touch <[e-mail]>]

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.

---