[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: