Re: SPD Syntax Example

[Stephen Kent <kent@bbn.com>]

At 4:00 -0500 1/27/04, Andrew Krywaniuk wrote:
>  > We've had this discussion before, and I'd rather not
>>  revisit it. 
>
>Right, we've had this discussion before, and it seemed
>that the change was always out of scope because
>changing the IPsec architecture was not allowed when
>we were redesigning IKE. However, now we are changing
>the IPsec architecture as well.

We have differing views of what is open for debate now. what we are 
doing is providing a more flexible capability re defining what 
traffic is mapped to a given SA, something that was clearly agreed 
upon when we decided, as a WG, to add the current set of traffic 
selector negotiation features to IKE v2.

>  > If
>>  peers do not negotiate the selectors for an SA,
>>  interoperability
>>  problems arise.
>
>Funny... my impression has been the exact opposite.
>It's hard to have an interoperability problem when you
>simply drop packets you do not allow (or send ICMP
>unreachable if that is your policy). It's very easy to
>have an interop problem when you need to negotiate
>selectors that have to be exactly synchronized on both
>sides.

maybe we just have different views of what interperability means. I 
don't think interop is achieved if one peer sends traffic that the 
other peer drops, without any advance notice. a major goal of the 
traffic selector negotiation is to determine in advance whether 
communication will be allowed for proposed traffic flows. that has 
always been the case.  we are not changing it in 2401bis.

>
>>  We have experience with this
>>  happening today,
>>  because IKE v1 did not do as well as IKE v2 in this
>>  regard.
>
>Correct. IKEv1 did an okay job of negotiating
>selectors between routers, but a lousy job of
>negotiating selectors between firewalls. IKEv2 is
>better, but it is still much more complicated than it
>needs to be. And it misses the model for matching
>policies. (that policy should be enforced/dictated,
>not negotiated)

Between IKE v2 and 2401bis we hope to provide a much better 
description of how to match traffic selector payload, and offered 
traffic, against SPD entries.

>
>>  For
>>  example, in IKE v2 the initiator sends the packet
>>  header info for the
>>  packet that triggers SA creation, to allow the
>>  responder more
>>  flexibility in finding a suitable SPD entry when
>>  peers have
>>  overlapping but not identical SPD entries.
>
>And then what happens when B needs to send a packet
>that matches B's selectors from B's policy for A's
>original packet, but not A's selectors from A's
>policy. And then what happens when it comes time for A
>to rekey?

I believe a goal of IKE v2 is to better allow A and B to determine 
where the policies overlap, to reduce the likelihood of the sort of 
potential problems you cite, which not requiring exact matches 
between the SPD entries for A & B.

Steve