Subject: [Ipsec] IKE, traffic selectors and policy selector, policy checking

From: Markku Savela <[email-masked]>
Date: Wed, 16 Feb 2005 12:46:37 +0200

My definitions:

policy selector = the selectors in Policy Data Base (= PS)
traffic seletor = the selectors associated with SA (= TS)

Claims:

1) IKE policy check (if done), is based on the packet information, not
   on TS

2) PS and TS are related, but not the same

Expanded explanations:

1) IKE policy check (if done), is based on the packet information
------------------------------------------------------------------

- IKEv2 includes the complete information about the packet that
  triggers the negotiation.

- this information can be used to check and choose one of the proposed
  security to use, or reject the proposal. TS is not needed at this
  stage.

- if this is the only SA between the negotiators, TS can be totally
  ignored. This is why IKEv1 mostly worked, even with complex policy
  selector, while not supporting any TS. IKEv1 got into
  interoperability trouble only when it needed to maintain multiple
  SA's between end points. How to negotiate the routing of specific
  traffic to specific SA was always fuzzy (although, identities,
  protocol and ports could were included in the negotiation and used
  for the purpose).

2) PS and TS are related, but not the quite same
------------------------------------------------

The previous policy check step already guarantees that the proposed
ipsec transforms and traffic is acceptable.

The TS negotiation is just fine tuning the use of multiple SA's with
equal security features.  It is a request from initiator: Can you
route traffic that matches this pattern to this SA? The narrowing is
just responder replying: Yes, but I want finer division using this
pattern.

And, this is where decorrelation steps in. If policies are not exactly
the same, the TS exchange must use decorrelated selectors. (This is
totally independent whether implementation uses decorrelation in PS or
as optimization for incoming SA policy matching).

Also, I rejecting negotiation because of the fine tuning cannot
be complied, is different from rejecting the negotiation based on the
policy check in (1).

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