Re: Specification of tunnel/transport attribute in IKEv2

[Markku Savela <msa@burp.tkv.asdf.org>]

> From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>

>    There is no need to ensure that policies on two ends match. As per
>    RFC-2401, policy is checked for each packet. IKE does not need to
>    check the policy.
>    
> => RFC 2401 says the SPD (it seems to make things even less clear that
> policy and SPD are different :-).

SPD is the policy, SAD and SPD are different.

> => RFC 2401 says in section 5 "If no policy is found in the SPD that
> matches the packet..." (this defines the default action). The whole
> RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree
> with you (note RFC 2401 doesn't say the opposite too, i.e. your objection
> is valid and IPsec implementors in trouble).

I was confusing the issue by using "unspecified terminology". In my
view we have two types of "selectors"

- policy selectors (the ones in SPD)

- traffic selectors (used in IKEv2 key negotiations and end up into
  SAD)

The latter are just qualifiers that are associated with the negotiated
SA's. And are *ONLY* needed to differentiate multiple SA's between
same endpoints. Instead of "traffic selector", should probably use
some other term to avoid confusion with the actual "traffic selectors"
in the policy. 

>    In above my policy selector is just "local-port=80", but if I have
>    additional requirement that each connection should use own SA, then
> 
> => this should be allowed according to RFC 2401 but it seems some
> implementations need a SPD entry by connection (?)...

Yes, they only partial implementations of rfc-2401, most likely due to
IKE limitations. RFC-2401 allows many things, which are not possible
with IKE(v1). I would like to have this mistake avoided by the next
IKEv2, and one way of achieving this result is to remove all policy
checking from the IKE.

> => KAME has the same symptom... The level "uniq" helps but its meaning
> is that to share a SA between two SPD entries is forbidden, i.e. not
> a solution to your problem (which IMHO is not the place of the TSs,
> but the fact a SPD entry can only point to zero or one SA (bundle)
> with a cache/lookup mechanism using only addresses and the "uniq" feature).

In my implementation, there is no pointers from policy selector to
SA. Any policy selector can be associated with any number of SA's and
vice versa.

Also, different bundles can share SA's (if only IKE could negotiate
such thing). Again, if I get policy (and bundle checking) off the IKE,
even SA sharing would start to work fine.

> PS: I believe this is a result of the incredible confusion in RFC 2401 & co
> about addresses in SAs. At the question how many addresses characterized
> a SA, you can answer zero, one, two, three or four and find a reference
> in a RFC or an I-D...

To me there is no confusion in the SA itself. You have a packet, you
extract the selector information from as defined in RFC-2401. There
are only 3 addresses: src, dst and possible IPSEC tunnel address (SG
address). If my policy says

   selector => protect by SG

then for incoming packets I must also check that the packet actually
came from SG (I'm not really sure whether this check is really giving
us anything). However, this only applies to tunnels that are specified
within the IPSEC itself.

There may be some confusion about what the src and dst actually are,
in presence of things like IPv6 home address option.