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

[Thomas Narten <[e-mail]>]

Paul Hoffman <[e-mail]> 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...

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

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.

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

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

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

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

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

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

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

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

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