Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"...

From: "Michael Roe" <[email-masked]>
Date: Wed, 16 Feb 2005 17:37:16 -0000

Steve Kent writes:
> Under 2401bis and IKE v2:
> 	- decorrelation is an option, though not mandated. let's start
> 	  the analysis w/o assuming use of decorrelation
 ...
> 	- given this new feature, the receiver should match the 
> selected SPD
> 	  entry against the proposal sent by the initiator, and "narrow"
the
> 	  response. the narrowed response should be the intersection of
the
> 	  local and remote SPD entries, thus ensuring that traffic sent
in both
> 	  directions will be accepted at each end.

The problem is that it doesn't ensure that traffic sent on the SA
will be accepted by the other end. If the initiator sends one of its
(ordered, correlated) SPD entries in its traffic selectors, and
the responder intersects this with one of its (ordered, correlated)
SPD entries and sends the result back in its traffic selectors, then:
a) AH or ESP packets sent by the IKE initiator may be dropped on
receipt,
   because the IKE responder has higher-precedence SPD entries that the
   initiator doesn't know about.
b) AH or ESP packets sent by the IKE responder may be dropped on
receipt,
   because the IKE initiator has higher-precedence SPD entries that the
   responder doesn't know about.

> so, to avoid creation of extra SAs, we ought not send just a 
> decorrelated entry as a proposal, but we could choose to send the set 
> of linked, decorrelated entries to a peer to help in the narrowing 
> process, especially if the peer has a decorrelated SPD.

Yes, what I meant was that the traffic seelctors ought to represent the
set of linked, decorrelated entries that correspond to a single entry
in the (ordered, correlated) SPD. The second problem is that you can't
always do this. Sometimes the set of linked, decorrelated entries can't
be represented in a single CREATE_CHILD_SA.

Even when it can be represented, we sometimes have the problem that
it can't be represented efficiently. Policies often have a BYPASS
entry for ICMP, because otherwise you can't bootstrap. So you will
often have entries in the decorrelated SPD for "all protocols except
ICMP". To represent this, you need 254 traffic selectors in TSI
and TSR.
(A possible implementation approach would be to split such an SA into
an SA for TCP+UDP, plus a separate SA for each protocol. In the common
case, only the SA for TCP+UDP would be used).

Mike

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec