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

From: Markku Savela <[email-masked]>
Date: Thu, 10 Feb 2005 14:49:24 +0200

I think it might be good if IKEv2 negotiated and operated in the
following 3 modes as far as policy checking goes:

A) Full policy checking, decorrelated policies on both ends. The only
mode where narrowing is allowed.

B) Full policy checking. No decorrelated policies in use, a proposed
policy must exactly match (no narrowing). Basicly, both sides must
have identical policies.

C) No policy checking (in IKE). The proposed SA's with indicated
traffic selectors are accepted as is. In this mode, a mismatch in
policies results a "black hole" (which in my opinion is easily
detected by other by dropped packets, and could be notified to the
other end).

The (C) is my preference. In this mode any complex policy I support,
would not depend on IKE capabilities of negotiating it. :-)

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2005 10:46:25 -0500

At 2:49 PM +0200 2/10/05, Markku Savela wrote:
>______

As I just said in a previous message, the intent of decorrelation is 
NOT to charge then policy expressed in the SPD.

I think IKEv2 included narrowing as a concept independent of use of 
decorrelation.

Thus I have heartburn with this characterization of different modes 
of policy checking.

I also think it is questionable to suggest (C) above, as it 
encourages expression of policies that IKE cannot negotiate. We 
worked hard in 2401bis to align what the SPD can express vs. what IKE 
can negotiate, to fix the mismatch from 2401.

Steve

---

From: Henry Spencer <[email-masked]>
Date: Thu, 10 Feb 2005 13:09:16 -0500 (EST)

On Thu, 10 Feb 2005, Stephen Kent wrote:
> >policies results a "black hole"...
> 

If memory serves, Markku has long taken the position that IKE ought to be
purely a key-exchange protocol -- without the slightest hint of policy
negotiation, because all policy negotiation ought to be done manually by
prearrangement -- and resisted all attempts to convince him that this is
based on an unrealistically narrow view of how IKE is used. 

What's surprising is not that he would suggest (C), but that his
suggestion actually included (A) and (B). :-)

                                                          Henry Spencer
                                                       [email-masked]

---

From: Markku Savela <[email-masked]>
Date: Thu, 10 Feb 2005 20:31:04 +0200

> From: Stephen Kent <[email-masked]>
> 

I will have to reread the 2401bis and try to find where it says that a
policy like

  (remoteport=1 and localport=1) or (remoteport=2 and localport=2)

is forbidden. Above is not negotiable in IKEv2.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2005 14:33:11 -0500

>is forbidden. Above is not negotiable in IKEv2.

2401bis, like most IETF standards, emphasizes what one MUST or SHOULD 
do, and spends less time trying to enumerate all the things one MUST 
NOT or SHOULD NOT do.

You can find the text that states that the SPD has been defined and 
structured to match what IKE v2 can negotiate. specifically, 4.4.1.2 
says:

This text describes the SPD in a fashion that maps directly into IKE
payloads to ensure that the policy required by SPD entries can be
negotiated through IKE.

Steve

---

From: Markku Savela <[email-masked]>
Date: Thu, 10 Feb 2005 22:20:42 +0200

> payloads to ensure that the policy required by SPD entries can be

Which is exactly the reason why so much dislike the IKE messing with
policy. It locks IPSec capabilities to particular keymanager
implementation that is the current fad.

Anyway, I'm somewhat shocked to learn how the IKEv2 limis the
policy. It really should cope with policy rules like:

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2005 15:59:38 -0500

>implementation that is the current fad.

Not sure I understand your comment above. One goal for 2401bis was to 
make sure that we didn't mandate support for SPD features that IKE 
could not negotiate, since that would suggest manual configuration of 
SAD entries to support such policies. 2401 did not meet this goal, 
due to poor coordination, and we hoped to not make the same mistake 
again.

>    (remoteport=1 and localport=1) or (remoteport=2 and localport=2)

Any complaints you have about what IKE v2 can or cannot negotiate 
should be directed to Charlie Kaufman, not me :-)

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 11 Feb 2005 10:54:58 +0200

> is forbidden. Above is not negotiable in IKEv2.

It is negotiable in IKE, but not as with one SA in single create child
sa exchange.
-- 
[email-masked]