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

Re: Q about SA bundles



Policy on H1:

"dst=h2" -> ESP(blowfish,sha1) AH(md5) tunnel(SG) ESP(des3 md5) AH(sha1) 

generates
   ACQUIRE: h1->h2 ESP(blowfish,sha1)  -> SA1
   ACQUIRE: h1->h2 AH(md5)             -> SA2
   ACQUIRE: h1->SG ESP(des3,md5)       -> SA3
   ACQUIRE: h1->SG AH(sha1)            -> SA4

> SG can't have policy with selectors identifying traffic from h1 to h2
> because it won't be able to look into the packet to identify that
> traffic.

There appears to be some difference in thinking. I had the following
selector and policy in mind at SG:

"dst=h2,src=h1" -> tunnel(h1) ESP(des3,md5) AH(sha1)

	The selector works, as I explained earlier, because when the
	tunneled packet from h1->h2 arrives at SG, it has "AH ESP
	IP(h1->h2) AH ESP ...".  SG "unwraps" the layers addressed to
	it (AH, ESP, IP) *before* the policy check, and ends up with a
	packet from h1->h2. This is used to see what policy applies to
	it, fiding the above, SG notes that it matches the applied
	transforms and the packet can pass.

> Also there's no mechanism to inform SG of the SPI chosen by h2 to
> use to protect this traffic.

I don't have this problem, as H1 would negotiate the two latter SA's
directly with SG. H2 knows nothing about them.

On H2 I would just have the policy

"src=h1" -> ESP(blowfish,sha1) AH(md5)

Two comments

1) I've written the policy examples for h1->SG->h2 direction only, the
   reverse flow (h2->sg->h1) policies could be totally different, or
   derived automaticly from the ones shown here to get symmetric flow.

2) If SG is not on the default path of h2 -> h1 (if SG is not the
   router for h2), then there is the question of how H2 knows that
   traffic to h1 should be routed to SG. This could be handled by
   explicit non-IPSEC tunnel request in the policy, for example

	"dst=h1" -> ESP(blowfish,sha1) AH(md5) tunnel(SG)

   (the packet would be "h2->sg: IPIP(h2->h1) AH ESP"), or could just
   have asymmetric communication, and allow the return traffic h2->h1
   to go directly, without SG in between, resulting


     h1 ----------> SG
     ^                \
      \                \
       \                V
        <---------------h2

    h1 would have a different policy for the return traffic

	"dst=h1,src=h2" -> ESP(des3,md5) AH(sha1)


> Of course, we're not using PFKEYv2 and, therefore, are not
> restricted to individual, non-conjunctive, ACQUIREs.

More restrictive in respect to conjunctive ACQUIREs, but less
restrictive in other areas, as it allows asymmetric IPSEC, sharing of
SAs. And, could even do "conjunctive bundles", if there is some
outside-PFKEY method to modify the policy rules.

The conclusion appears to be, that the compatibility with ISAKMP
requires that I need to provide the key management with access to the
same policy information as the kernel has, so that it can decide on
which of the bundles to accept. And, it may need a way to modify the
policies in the kernel. I guess this is doable, if the need arises (I
will put IPSEC to rest for few months and after that re-evaluate the
situation).

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