Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2)

[Dan Harkins <dharkins@tibernian.com>]

On Tue, 19 Mar 2002 12:31:24 PST you wrote
> 
> RFC2401 says there are SPD selectors associated with each SA.  However, it
> should be local implemenation issue to bind them together.  Puting SPD in
> IKE is just dulplicating effort in key managment protocol without much
> benefit. 

Yes but there is no SA to bind to the selector. The TS payloads give an
indication on how to do such binding at SA creation time. Without passing
this information all you can say is, "I want to do IPsec with you". The
Initiator binds the selector to the SA which caused the whole negotiation
in the first place and the Responder does what? Panic, reboot (I ask only
half in jest)? Best guess? Choose one at random? Wait until some packets
arrive and then choose? What if he doesn't like what he sees when he does?
Tear down the SA or wait until he finds another thing he might like? How
long should he wait?

> Giving the difficulty to do TS right, I would propose to use a simple ID
> (e.g. sequence number) to identity the tunnel and leave all complexity of
> SPD out of IKE.

And then we need some new protocol to do "simple ID (e.g. sequence number)"
to "tunnel" matching-- not a good idea. Or we just assume that everyone has
been preconfigured with this information-- not a good assumption.

It's not that difficult. If you are the Responder you check your local SPD
to see whether the TS payloads are wholly contained by what you have (i.e.
they match or are a complete subset of the range, or if you're doing
address/mask you can ask yourself if your SPD entry was a routing table
entry whether you'd route that TS payload unambiguously through it). If it
is not then you send back the subset that is wholly contained. If that subset
is NULL you send back a rejection. 

  Dan.