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

Re: Q about SA bundles




> OK, so everyone knows from ARCH sec 4.1 that:
>  "Security services are afforeded to an SA by the use of AH, or  ESP, but
> not both. IF both AH and ESP prtection is applied to a traffic stream, then
> two (or more) SAs are created to afford protection to the traffic stream."
> 
> 	Why is this? What was the original thinking that went into this
> "seperation of SAs" requirement. One could envision a standardized
> architecture which called for bundeling ordered security services under a
> single SA. Then the SA managemnet construct would have modled very closly
> the virtual link. That would have been an nice modle for VPN management. 

I'm not quite sure what you ask, as there are two separate issues here

  1) AH and ESP? Do we really need both or would just one IPSEC
     protocol have served better?

  2) "the SA bundle issue"

For the first (1) issue I don't have much opininions. It might have
been possible to do with a single, but somewhat more complex IP
protocol instead of AH and ESP. But, I don't see much problems with
the current ones either.

The second appears to relate to issue about which I have written here
before, and people seem to have very differing views (something like
Complex vs. Reduced Instruction Set issue). I prefer the "RISC"
approach in IPSEC and bundles: standard defines the basic "RISC"
operations and implementations can build more "complex and optimized
programs" from using these "instructions". In my RISC view each
unidirectional/monopole SA is totally independent of every other SA.

The basic IPSEC Key management transaction with PFKEY v2 between H1
and H2 starts when H1 needs to send a packet to H2:


                 H1                                H2
    ------------------------               ---------------------- 
(0) IP:H1->H2 ->SA0 -> SA1 ==================> SA1
     \                  ^                       ^
      \                 |                       |
       \                |                       |
(1) ACQUIRE SA: H1->H2  |  <-- Key Mgmnt -->    |
         \              |
          ------------------------------> (2) GETSPI: dst=H2
                        |                     UPDATE SA: dst=H2
                        |                          /
                                                  /
          (3) ADD SA: dst=H2 <--------------------



0) The security policy catches the packet H1->H2, no SA exists, so it
   generates the ACQUIRE REQUEST for the key management.

   - the only information about the security policy that applies to
     the packet and connection, is present in the PFKEY ACQUIRE
     MESSAGE.

1) The key management contacts the other end (H2) and passess the
   proposals from the ACQUIRE message to the other end.

   - note specially that there is *no* information about the possible
     SA going from H2 -> H1! Any key management that negotiates both
     SA's at same time, is making some out of band assumptions about
     the policies (for example, assuming they are symmetric).


2) Having chosen one combination of the proposed parameters, the H2
   Key Management allocates an SPI (GETSPI) and then completes the SA
   with all necessary parameters using UPDATE.

3) The agreed on combination and chosen SPI is comminucated back to H1
   and it can complete the negotiation by adding the other end of the
   SA to the IPSEC kernel (this could be seen as a reply, in PFKEY
   sense, to the original ACQUIRE request--use PID=0 and SEQ from
   ACQUIRE).


This is from single AH or ESP in a bundle specified by the policy. If
the bundle has more elements, each of them repeats the above
independently (with tunnels present, some of them can involve other
end points than H2).

The association from H2 -> H1 is negotiated and created, if it is ever
needed, when H2 tries to send a packet to H1. Above is repeated,
except that H2 is the initiator.

All I am asking/hoping that, the all key managements provide this
basic primitive: negotiating a monopole SA. Then, there will be no
limitations for the policy writer. He can specify any combination of
tunnels and ESP/AH in a bundle.

This doesn't prevent the keymanagement imlplementations from trying to
"second guess" the other necessary SA's using some out of band
information. In such case, it can "pre-load" more SA's than the
originaly requested monopole.

>From the discussions, it seems that the ISAKMP implementations are
monolithic and don't allow "RISC approach". The monolithic approach is
the root of all these questions and interoperability problems relating
to the ordering of transforms etc..

-- 
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/


References: