[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bundle or not in negotiation
I guess I am getting repetious and perhaps a pain in * for some, but I
still make this question once more, prompted by following
> From: Tim Jenkins <tjenkins@TimeStep.com>
> As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between
> two peers, and the ESP part expires first, it is likely that the entire
> SA will be torn down. I stated in the document that the assumption is
> that the SA bundle lives only as long as the shortest living service
> in the bundle.
Where does the requirement come that a bundle IPCOMP+ESP+AH needs to
be negotiated as a bunch? Assuming IPSEC architecture and PFKEYv2
interface to kernel (and ignoring the IPCOMP for a moment), the key
management gets TWO independent and unordered ACQUIRE messages (ESP
and AH), there is no need to connect them together, they can be
negotiated independentely, and they may even have a different
lifetimes.
I don't see any problems with this freedom. A while back I posted few
scenarios of how I see things to happen in negotiation. I hope that
someone could give me an example that actually requires treating them
as clump in negotiation phase.
The appliation order of IPCOM+ESP+AH is defined by the policy, which
*must* specify same order on both sides. The order is
non-negotiable.
IPCOMP is a problematic. It is not included in the PFKEYv2, there is
no way of IPSEC kernel to request IPCOMP in ACQUIRE, even if the
policy wanted it. I see only two tracks of solving this:
1) Make new SA type for IPCOMP => then you could negotiate IPCOMP
independently same way as AH and ESP
2) Make IPCOMP a new algorithm in SA => this would need a change in
PFKEYv2 message format, as a slot would have to alloated for the
compression algorithm (at similar to 'auth' and 'encrypt').
Maybe there are other ways, but those above are the first that come to
mind.
Follow-Ups:
References: