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

Re: Q about SA bundles


> From: Mohan Parthasarathy <Mohan.Parthasarathy@eng.Sun.COM>
> Last time this was discussed, somebody replied 
> "While you are negotiating AH IPSEC SA, and the other end's policy
>  requirement is ESP + AH, how does the other end know you will
>  negotiate ESP after negotiating AH i.e should the other side
>  accept the negotiation assuming you will negotiate ESP in
>  a short while or reject assuming that you are not negotiating
>  ESP " ?

A short answer:

	While negotiating AH IPSEC SA, the responder site doesn't need
	to know or care whether it is associated with a AH+ESP bundle
	or not.

Longer answer:

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


The initiator (H1) only has the PFKEY ACQUIRE information to go with,
and it simply includes a list of algorithms from which to choose (the
other information is address and identity)

Thus assume, a policy saying

	dst=H2 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5)

then, the ACQUIRE for AH contains combinations
	1) md5
	2) sha1
	3) foo
all of these supported by the initiator side. This list is passed to
the responder (H2).

The responder host only supports md5 and sha1 (known to the key
management from the reply of the PFKEY REGISTER message).

	My claim and goal is: The responder side of the negotiation
	does not need to care about the policy.

It only selects the SPI and chooses the algorithm from the proposed
list (md5, sha1, foo), and as it only knows the first two, it can pick
either one, say sha1. It creates the end point SA and reports back to
the initiator the SA attributes, so that it can create the starting
point of the SA.

The ESP is handled exactly the same way, independently. and ending
with, for example, (3des,md5) for ESP. With SAs set

   SA1 (AH: sha1) --------------------> SA1 (AH: sha1)
   SA2 (ESP: 3des,md5) ----------------> SA2 (ESP: 3des,md5)

H1 is finally able to send a packet to the H2. H2 receives the packet
and successfully applies SA1 and SA2 to this. And, only *after* this
it needs to be checked whether the policy is matched. For example
 
	src=H1 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5)

Looking for a matching SA for AH(md5, sha1, foo) and packet, it should
return SA1, and for ESP(3des, idea, blowfish, md5) it should return
SA2. If this happens, the policy condition is filled and packet
passes, and otherwise not.

	[I admit that the above matching part is somewhat untraversed
	territory for me, as my policy defition doesn't (yet) have
	alternatives for the algorithm, policy just says use one or
	don't communicate. With multiple choices of algorithms, the
	search may(?) result with one SA per algorithm, and my guess
	is that if the applied SA is included in such result, the
	policy passes.]

My key premise here is still: policies on both ends must be same.

Note also, that I have included 'foo' in the policy of H2, even though
it does not support it. The idea is that, if the support for 'foo' is
added to the kernel IPSEC, then it becomes automatically available for
the negotiations. This allows gradual deployment of new algorithms.

                 ********************************

SOME OTHER COMMENTS:

 - assuming policy with bundle ESP+AH, there is nothing in PFKEY
   ACQUIRE (unless I missed something), that would tell the key
   management that these two ACQUIREs are actually from the same
   bundle. [And I think this is a good thing ]

 - with all this, I am only trying cut down the implementation work
   into manageable pieces, most important being the ability to
   describe the pieces of IPSEC in exact manner. These descriptions
   can be used to decide which implementation is correct, when
   problems surface.

 - there are many fuzzy areas, for example, how do ACQUIRE information
   and the resulting SA information relate to each other, specifically
   things like SRC_ADDRESS, PROXY_ADDRESS, IDENTITY etc. How much
   freedom the keymanagement really has? For example, my current
   implementation

	  if ACQUIRE has exlicit SRC_ADDRESS, and the resulting ADD SA
	  does not include the same source address extension, then my
	  SA locating does not find the SA. And vice versa, if ACQUIRE
	  does not have the SRC address, it should not be present in
	  the SA either (IADDR_ANY). [The presence of SRC and other
	  things in ACQUIRE is mostly controlled by the policy
	  definition, which is very delicately involved in the SA
	  locating, as can be deduced from my descriptions... ]

-- 
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/
Follow-Ups: References: