[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: interpretation of SA bundle.
> > > 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: