[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SPD Syntax Example

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