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

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Aug 2010 23:43:56 +0300

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 <[email-masked]>
> Date: August 25, 2010 10:55:27 PM GMT+03:00
> To: Thomas Narten <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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.
> 
> ---
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Aug 2010 14:35:47 -0700

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:
>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.

>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.

>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.

>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...

>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).
>
>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,
>

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

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Aug 2010 15:10:53 -0700

> 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.

An suggestion for developers to ignore a standard (esp. using RFC2119 
language) necessarily updates that standard.

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

If you mean removing the sentence "IPsec provides sufficient flexibility 
and granularity that individual TCP connections can (selectively) be 
protected, etc.", that would be fine, however it requires removing the 
text below too.

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

In that case, TLS and SSH are inappropriate, as including them might 
confuse readers into thinking they protect the TCP connection (a common 
mistake already). If this is similarly removed, then that would make sense.

...
>> vague with respect to routers (RFC4301, end of section 4.1).
...
 > ago that would require this change?

Hopefully the appreciatoin of the security community that routers 
*always* act like hosts for at least some of their traffic ;-)

Joe

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 2010 09:04:15 -0400

Paul Hoffman <[email-masked]> writes:

> 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.

Thanks for clarifying...

> >to update RFC4301 as well.

Oddly enough, I did not receive Joe's message, so I'll respond to a
followup.

Section 10 of RFC 4301 says:

> 10.  Conformance Requirements
> 
>    All IPv4 IPsec implementations MUST comply with all requirements of
>    this document.  All IPv6 implementations MUST comply with all
>    requirements of this document.

Yes, this document is essentially updating that statement.

Note, however, that the RFC 4294 already does that, because it says
IKEv2 is a SHOULD, which contradicts this statement.

Also, I think we are recognizing that the above wording is too strong
and needs to be updated.

Finally, the node requirements document is essentially an
applicability statement. Whether it will be Informational or BCP is a
bit of a TBD, but in any case there are plenty of applicability
statements that are informational. On Applicability Statements, RFC
2026 says:

>    An AS identifies the relevant TSs and the specific way in which they
>    are to be combined, and may also specify particular values or ranges
>    of TS parameters or subfunctions of a TS protocol that must be
>    implemented.  An AS also specifies the circumstances in which the use
>    of a particular TS is required, recommended, or elective (see section
>    3.3).

My conclusion is that an AS can make take individual RFCs and say they
are required (or not), etc. And also add (or revoke) some requirements
that arguably update the spec. But (IMO) this should be done only at a
high level (i.e., requiring certain features or modes or profiles)
rather than making actual technical changes to a protocol.

So I do not believe there is any issue with having this document
override Section 10 of 4301.

> >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.

The point of my text was just to point out that there are filters that
can be applied that determine what (and how) sessions are covered by
IPsec. Without getting into a lot of detail. And I certainly don't
want to get into differences between what the specs allow and what the
common usages are.

If someone has better text to propose...

> >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. 
> >
> >[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] 

>  removed and not to confuse IPsec documents with TCP-AO.

Which specific sentence? I don't see how anything in the node-req-bis
document can be confused with TCP-A0.

>  does more than authentication.

I don't believe TCP-AO is relevant to the IPv6 Node Requirements
document.

> >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...

This is presumably covered in the IPSec/TCP-A0 documents, and doesn't
need to go into the nod-requirements doc..

> >>    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). 
> >
> >>    addresses assigned to their own interfaces) and implements
> >>    IPsec MUST implement transport mode.

IMO, this is for the IPsecME WG to figure out, not the IPv6 Node
Requirements doc.

One of the the things node requrirements will now do is just point to
the "IP Security Architecture" document and defer to it for all the
details.

Thomas