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

Re: Question on SA Bundle




> From: Stephen Kent <kent@bbn.com>

> BUT the WG will have to decide if the added complexity is something
> we want to impose on all IPsec implementations.

This exactly why I want to separate policy from IKE. Policy syntax and
features would be just local implementation choice. This is then
mapped into standard "SA+TS" construct. IKE should operate with
this, without knowing anything about the original policy.

> For example, in v2 the initiator sends SPD selector data showing the
> range of values associated with an SA that is being created, to
> enable the peer to know the range of traffic that can be carried on
> the SA.

I want the same, except that what is sent over is NOT the SPD selector
data, but something that is extracted from the packet triggering the
negotiation. I think we have "terminology problem". An example, I can
have a policy

  "protocol = tcp" -> "use different SA-pair for each connection"

In my terminology, from above it follows:

  SPD selector: "protocol = tcp"

  TS for SA: protocol=tcp, src_port=x, dst=port=y

My claim is just: IKE does not need the "SPD selector". It just needs
the "TS for SA" -part. And, that it should just negotiate this single
unidiretional SA, and let the other end trigger negotiation of the
other SA of the pair.

I think, TS as defined in IKEv2 is fine. Just don't equate it with SPD
policy selector.