---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Markku Savela [mailto:msa@anise.tte.vtt.fi]
> Sent: Wednesday, November 18, 1998 1:31 PM
> To: ipsec@tis.com
> Subject: 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.
Yes, they can. Nothing I said above intends to preclude that. But if
you do that, you'll create two *separate* tunnels: 1 with ESP and AH.
The SAs that create those tunnels will have been negotiated with
separate SA payloads, probably in separate quick modes.
The specific case I was referring to, and the implicit (I need to make
this explicit) assumption being made, is that the services are being
negotiated within the same SA payload, and each service is a
proposal with the same proposal number.
>
...
>
> 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.
Not according to earlier posts, which state that this issue came up
before. They stated that for multiple proposals in the same SA
payload, the order is (outbound) IPCOMP before ESP before AH,
regardless of the order in the IKE exchange.
See below for text from an earlier post from Daniel Harkins [dharkins@cisco.com]:
(The second sentence, specifically.)
=======
The order of offer in IKE shouldn't matter. If they're negotiated in
a bundle we do PCP before ESP before AH regardless of how they appear
in the offered bundle. If you negotiated ESP to protect AH traffic
between SGs (for traffic analysis protection for instance) and that AH
traffic protected some transient traffic to which PCP was also applied
you could get |IP|ESP|AH|PCP|IP|data| crossing the wire but then it's two
separate negotiations and the bundle is AH&PCP and you still do PCP
before AH.
Dan.
On Tue, 10 Nov 1998 16:09:06 +0530 you wrote
>
> On Mon, 9 Nov 1998, Michael C. Richardson wrote:
>
> > The only thing missing is whether the proposals that are in the same
> > mode are to be applied inside-out, or outside-in:
> >
> > "For ANDed proposals, the 'mode' MUST be the same, and the protocol header
>s
> > applied MUST be applied adjacent to each other. The first proposal describe
>s
> > the inner-most (first on encryption/authentication/compression, last on
> > decryption/checking/decompression) transform to be applied, with the last
> > proposal describing the outer most transform. If multiple proposals are
> > required to protect a packet, and they are to be applied in different modes
>,
> > this is achieved by using multiple Phase-2 negotiations, the
> > applicability/order of them to be determined the selectors used."
>
> What is the order currently implemented by most implementations? If you
> see the second example in the ISAKMP draft on pages 49-50, the first
> protocol is AH and the second ESP. This seemed to indicate that the order
> of the protocols is outer to inner rather than inner to outer, since the
> supported combination is AH ESP. It seems more intuitive to interpret the
> order in the way it appears in a processed packet - outer to inner.
>
> Anupama