[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: interpretation of SA bundle.
Wasn't this issue resolved and phrased somewhere? Son-of-ike perhaps?
As I think Tim pointed out, the list had a rough consensus that only
sane (useful) ordering should be applied to the packets, no matter
what ordering the protocols have in the IKE SA payload. The reason
being that limiting flexibility and thus complexity of IKE will
improve interoperability. Besides, people not knowing exactly what
they are doing, will not be able to do useless bundles, like
compression of encrypted data (if the encryption is at least
semik-good its output will look random, thus not compress well). or
put AH inside ESP, thus wasting processing time on decryption before
detecting that the packet was bad and needs to be dropped.
Hence, the only sane ordering is (in outbound processing order):
IPCOMP, ESP, AH. And since only one order is sane, it does not matter
what order it is in the IKE SA payload. The only drawback I can see
with this approach is that, when someday a fourth protocol enters hte
picture, things might not be clear at all anymore. But... does anyone
expect a fourth protocol?
Wrt tunnel and transport, same thing there, reduce complexity by
limiting the wire format to the useful variants, i.e. make tunnel mode
just have one extra IP header even if two or more IPsec protocols are
applied to it. Essentially this means that the encapsulation mode is
really an attribute of the suite, or bundle, rather than each
individual ly negotiated niklas. As mixed encapsulation modes in
IKE's negotiation creates confusion as to what mode to chose for the
bundle, requuire all to be the same.
Niklas
> Date: Wed, 8 Dec 1999 08:23:24 +0900 (JST)
> From: Shoichi Sakane <sakane@ydc.co.jp>
>
> > > > Node A sends a proposal including AH tunnel mode followed by ESP
> > > tunnel
> > > > mode. In this case, we should interpreted to be created IP
> > > payload by
> > > > using this SA,
> > > > 1. [outer IP][AH][ESP][inner IP][ULP]
> > > > 2. [outer IP][ESP][AH][inner IP][ULP]
> > > > 3. [outer IP][AH][inner IP][ESP][inner IP'][ULP]
> > > > 4. [outer IP][ESP][inner IP][AH][inner IP'][ULP]
> > > Assuming the proposal order as you stated: 4 (e.g. first apply
> > > tunnel+AH, then tunnel+ESP). Note, in (1) AH and in (2) ESP is
> > > transport mode, so they don't match your proposal anyway.
>
> My interpretation is #3. I think the order of proposal and transform
> means the order of security protocal header in IP packet.
>
> > > The result should depend on the ordering in the proposal? I don't know
> > > about IKE, but I can express all of the above combinations in my
> > > policy file, and the kernel IPSEC machinery can do them.
>
> I can do that. On IKE negotiation, it is only thing that the order of
> proposal express local policy file that you say. So I clarify the
> interpretation of the order.
>
> > First, let's be explicit about how this was proposed. If this was
> > proposed as a single SA payload with multiple proposal payloads
> > with the same number, then:
>
> I assumed what you say. Additionally, there are encapsulation mode
> in each attributes. That is like below:
>
> SA payload
> Proposal: #1 AH
> Transform: #1 HMAC-SHA
> Attributes: Tunnel
> Proposal: #1 ESP
> Transform: #1 ES_3DES
> Attributes: Tunnel
>
> > We discussed this and tested this at a bake-offs quite some time ago and
> > the concensus seemed to be that the order of application was not as
> > proposed, but as to what made sense. That order was (outbound processing)
> > IPCOMP before ESP before AH, no matter what the order of proposal.
>
> > Secondly, the attributes across the proposals are to be consistent,
> > and that they must apply to the bundle as a whole. [Aside: this is
> > specifically called an SA suite in the MIBs.] This means that a
> > bundle (of this type) is all transport mode or all tunnel mode.
>
> Do you say that each attributes of multiple proposal with same number
> MUST have same transport mode ?
>
> > This means that the correct answer for the above questions is 1.
>
> #1 is first applyed ESP tunnel, then second AH transport. Am I missing ?
>
> > > > Another case, Node A sends a proposal including AH transport mode
> > > followed
> > > > by ESP tunnel mode.
> > > >
> > > > 1. [outer IP][AH][ESP][inner IP][ULP]
> > > > 2. [outer IP][ESP][inner IP][AH][ULP]
> > > >
> > > > I think there is not these rules of interpretation in any drafts.
> > >
> > > The case 2 (e.g. first apply AH, then tunnel+ESP). I guess the rule
> > > should just state: apply strictly in proposed order.
>
> > Again, with the same assumptions, the second case is inconsistent.
> > However, our implementation will convert the transport mode to
> > tunnel, and apply tunnel to the whole thing. Therefore, the answer
> > is 1.
>
> Regarding to what you say, the correct answer is not to be accepted
> the proposal of mixed both transport and tunnel mode ?
>
> > I third the suggestion that this needs to be clearer. Our implementation
> > originally did what Markku's did. It no longer does.
>
> Our kernel can do any combination and many nesting, but I don't know
> the currect way to express these combination and nesting on IKE.
>
> Regards,
>
> /Shoichi `NE' Sakane @ KAME project/
>
Follow-Ups:
References: