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

[Joe Touch <[e-mail]>]

On 8/25/2010 2:35 PM, Paul Hoffman wrote:
> 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:
>> 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.
>
> 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.

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

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

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.

...
>> 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).
...
>>    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.
>
> Joe: what has changed since the IPsec WG decided the other way years
 > 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