Subject: [Ipsec] SPD & IKE v2

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Feb 2005 18:43:47 -0500

Folks,

Thanks to a simple but complete example by Tero (and an equally valid 
although not so complete example by Markku), I agree that my second 
set of processing descriptions, the first to deal with IKE v2, was 
wrong. Unless one uses a decorrelated SPD, one cannot perform the 
required checks on inbound traffic using just SAD data.  Mike also 
noted this in a more general comment, w/o examples.

Tero suggested that the proliferation of SAs that motivated 2401bis 
to call for sending the original, correlated SPD entry will arise 
only when there are two or more (correlated) SPD entries in which the 
protocol field is non-trivial and overlaps.  I was thinking about the 
general case re this problem, but I believe Tero is correct here. 
So, my general comment was correct, but Tero's suggestion is that 
maybe, in practice, this will not be a big deal. Mike Roe suggested 
that a desire to bypass ICMP traffic might trigger a lot of 
decorrelated entries. I would expect that if one generally wants to 
protect traffic for a given S/D address range via one SA, then one 
may send the ICMP traffic over that SA as well. So, your actual 
decorrelation experience may vary ...

My last suggestion was that one could choose to send the set of 
linked, decorrelated entries as IKE proposals, which I thought would 
ensure that we don't create more SAs than intended. Tero agrees that 
this is a reasonable strategy, Mike indicated that this is what he 
envisioned as well. However, Mike points out that it might entail a 
lot of proposals, and that IKE would be unable to represent all of 
them in creating an SA. I have revised the 2401bis text to better 
explain this issue, making it a local choice as to whether to send a 
correlated or decorrelated SPD entry in IKE v2, with some discussion 
of the motivations and concerns in both cases.

This brings me to the issue Tero raised in this discussion. Tero, I 
think you suggested that there is a fundamental mismatch between what 
the SPD allows to be expressed and what IKE v2 can negotiate. 
Specifically, I think you indicated that the mismatch arises because 
IKE semantics  call for a "mix and match" approach to viewing TSi/TSr 
payloads. I looked at section 2.9 in IKE v2 and I don't see where it 
suggests this. For example, the text describes how to pass triggering 
packet header data as the FIRST selector set data in TSi and TSr 
payloads, implying that the order of elements in these payloads is 
important, and that one is expected to view them as pairs, matching 
the corresponding S/D address and port fields. So, I have to admit 
that I am confused by your comment. If I send a series of pairs of 
TSi/TSr payloads, I would interpret this to represent pairs of S/D 
data, with a common protocol, so that each matched pair represents 
one selector set from an SPD entry, if the entry has more than one 
selector set in it.

Can you cite the parts of IKEv2 that suggest the "mix and match" 
approach that you indicated? Such semantics make no sense in the 
access control context that the SPD represents. Also, I'd like to 
think that IKE should be trying to negotiate what the SPD specifies, 
to minimize the likelihood that SAs are established that later will 
not carry the intended traffic.

Steve

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