[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: interpretation of SA bundle.

> -----Original Message-----
> From: Shoichi Sakane [mailto:sakane@ydc.co.jp]
> Sent: December 7, 1999 6:23 PM
> To: tjenkins@TimeStep.com
> Cc: msa@hemuli.tte.vtt.fi; ipsec@lists.tislabs.com
> Subject: 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.

Number 3 has inserted an extra IP header. That implies a separation of the
SAs. This would have been negotiated by two separate quick modes, one that
said that ESP was needed for the ULP, and another that AH is needed for ESP.

Think about your SPDs and selectors if you do this, and also the policy
relationship. The selectors negotiated refer to the ULP, since they're not
part of the SA payload.

> 
> > > 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 ?

The encapsulation is applied to the SAs as a whole. So, yes.

See section 2.1 of RFC 2408. Here's what you're doing when you have multiple
proposal payloads with the same number in a single SA payload:

==>
   Protection Suite: A protection suite is a list of the security
   services that must be applied by various security protocols.  For
   example, a protection suite may consist of DES encryption in IP ESP,
   and keyed MD5 in IP AH. All of the protections in a suite must be
   treated as a single unit.  This is necessary because security
   services in different security protocols can have subtle
   interactions, and the effects of a suite must be analyzed and
   verified as a whole.
<==

"All of the protections in a suite must be treated as a single unit."

In other words, the group of SAs that make up the suite live and die
as a unit, and have encapulation applied as a single logical unit.


> 
> > 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 ?

That's a potential way to do the implementation in the kernal.

I don't dispute it's confusing, but that's what has evolved.

> 
> > > > 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 ?

What I intended to say was that if the proposals that our implementation
receives are mixed, we treat that as a request for tunnel mode. This is our
interpretation only. What it means is that there's a chance we'll get it
right if the peer proposes how they would implement the encapsulation.

What we send is tunnel mode for all, or transport for all, depending on how
we want the group as a whole to be applied.

> 
> > 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/
>