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

From: Thomas Narten <[email-masked]>
Date: Wed, 25 Aug 2010 09:20:57 -0400

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?

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.

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Aug 2010 12:55:27 -0700

Hi, Tom,

> This text would go into draft-ietf-ipv6-node-requirements, which

First, this seems to override Sec 10 of RFC4301, so it would need to 
update RFC4301 as well.

Some other comments below.

Joe

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

>     (e.g., IPsec, TLS, SSH, etc.)

It might be useful to add TCP-AO here.

 >     No one approach has emerged as an

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.

>     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: Joe Touch <[email-masked]>
Date: Wed, 25 Aug 2010 13:20:09 -0700

On 8/25/2010 1:16 PM, Michael Richardson wrote:
>>>>>> "Joe" == Joe Touch<[email-masked]>  writes:
>      Joe>  I feel it is important to indicate the following:
>
>      Joe>  ---
>
>      Joe>  Any device that acts like a host (i.e., sources packets with IP
>      Joe>  addresses assigned to their own interfaces) and implements
>      Joe>  IPsec MUST implement transport mode. All devices (hosts and
>      Joe>  gateways) that implement IPsec MUST implement tunnel
>      Joe>  mode. Because gateways always act as hosts for some protocols
>      Joe>  (as noted in RFC 1812), the conclusion is that all devices that
>      Joe>  implement IPsec MUST implement both tunnel and transport mode.
>
> I agree.
>
>      Joe>     In summary,
>
>      Joe>     a) A host implementation of IPsec MUST support both
>      Joe>  transport and tunnel mode.  This is true for native, BITS, and
>      Joe>  BITW implementations for hosts.
>
> But, I think that this is too much detail.
> This is a requirement for IPv6 *native* *host* implementations.

Yes, for 6man it might be unnecessary to do this in this doc.

(is there any plan to update 4301? if so, would it be preferable to say 
most of this in that doc?)

Joe

---

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: Michael Richardson <[email-masked]>
Date: Wed, 25 Aug 2010 17:51:55 -0400

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> ---

I agree.

    Joe>    In summary,

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Aug 2010 17:52:02 -0400

Thomas, 

I agree with your text, and I agree with the reasoning for doing this.

I am sad that we have to write it, that we still have no useful key
distribution system.  I'm also sad that we still have no published API
for IPsec.  

I think that the get-out-of-jail-free last paragraph:

needs some refinement.  What I want to have stated is that an IPsec
system SHOULD be available on all general purpose *HOSTS*
(and that should include tunnel mode, and automatic keying).
I do not want to dilute the message we have had about IPsec, to the
audience of operating system vendors (*BSDs, Linux distros, Microsoft,
Wind River, QNX, etc...), and general purpose network protocol stacks.

Having said that, I think the right "out" is that while IPsec SHOULD be
available on the *platform*, it does not need to be shipped in the
resulting binary image if there is no application actually invokes it. 
I don't know really how to write this.

- --

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 17:01:40 -0500

> I don't know really how to write this.

If we're going to have "get-out-of-jail-free" text, might as well
"require" or "recommend" connection latching [RFC5660] for hosts' native
IPsec, while we're at it.

Nico
--

---

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