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

Re: Question on SA Bundle



At 12:54 AM +0300 4/15/03, Markku Savela wrote:
>  > 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.

If one just sends over data from the packet that triggers creation of 
an SA, the responder does not know what range of traffic can be sent 
over the newly created SA. Only if both peers have identical SPD 
entries for the packet in question would this be sufficient. 
Otherwise, the responder, not knowing the initiator's policy, might 
either create unnecessary SAs for other traffic he wanst to send, 
(which is a waste of resources) or the responder may send traffic 
over the SA that will be rejected by the initiator (which causes 
trouble shooting problems, another form of wasted resources).

By sending over the SPD data relevant to the SA being created, the 
initiator avoids these problems. In the past, we insisted on 
perfectly matched SPD entries for SAs, and I am told that it creates 
lots of config management problems. So, the goal going forward is to 
allow communication to occur when there is an overlap in the 
acceptable traffic relative to a proposal, and to communicate that in 
the IKE exchange. This will alleviate some config management problems 
and yet not create any problems with the two forms of resource waste 
noted above.

I guess I don't really understand your motivation for not having IKE 
convey the policy info from the SPDs to avoid future problems. Do you 
envision other ways to convey this data, or do you not believe that 
it is worthwhile to avoid the sort of problems noted above?

Steve