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

From: [email-masked]
Date: Thu, 10 Feb 2005 18:13:43 +0200

In essence, mode A says that "a host must not propose 
something that violates its own policy". (This, of course, 
implies that the module sending the proposal must know 
what the policy is.)

Implementations that don't follow this are IMHO simply
broken, and I don't think IKEv2 should do anything
special for them.

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Markku Savela
> Sent: Thursday, February 10, 2005 2:49 PM
> To: [email-masked]
> Subject: [Ipsec] IKEv2 needs a "policy usage mode"...
> 
> 
> 
> 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
> 

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

---

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

> implies that the module sending the proposal must know 

Yes. I.e. host must only give such traffic selectors that it will
accept any traffic matching those selectors back from the negotiated
SA. If some parts of the traffic selectors are not allowed because of
the higher priority rule making hole to the lower priority rule, then
they must not be proposed (== in effect use decorrelated policy, there
is also another ways to do it). 

> broken, and I don't think IKEv2 should do anything

Agree. So I would say lets use A as a default and all others will
simply then result in either black holes or INVALID_SELECTORS
notifications in case there is policy mismatch

-- 
[email-masked]