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

Re: Specification of tunnel/transport attribute in IKEv2



 In your previous mail you wrote:

   > From: Henry Spencer <henry@spsystems.net>
   > On Wed, 15 May 2002, Markku Savela wrote:
   > > There is no need for such other protocol. Assuming your implementation
   > > is conformant to RFC-2401, it already does the policy checking,
   > > whether IKE is present or not.
   > 
   > It does not do consistency checking to ensure that the policies on
   > the two ends match.  Nor does it have any way of selecting between
   > policy options, when the other end may not accept all choices.
   > These are practical issues of great importance, however trivial they
   > may seem in theory.
   
=> I agree with Henry even I use a very different system (KAME/racoon).

   There is no need to ensure that policies on two ends match. As per
   RFC-2401, policy is checked for each packet. IKE does not need to
   check the policy.
   
=> RFC 2401 says the SPD (it seems to make things even less clear that
policy and SPD are different :-).

   As I've said repeatedly, it is easy to detect policy mismatch during
   the normal and *required* policy checking on received packet: if it
   arrives and "decodes" properly with indicated SA(s) and then fails
   the policy check, you have a mismatched policy.
   
=> this is detected by the kernel a posteriori. The other opinion is
this should be detected by IKE at the SA establishment.

   There is no need and never should be any "policy negotiation" protocol
   within IKE. I view IPSEC policy as similar concept as firewall
   rules. Each host decides and specifies it's requirements outside
   IKE. There is no "firewall policy exchange protocol" either, and hosts
   manage to communicate over them.
   
   What are "policy options"? If you mean alternatives to the algorithms,
   then that is quite ok. My policy migth say
   
      local-port=80 -> ESP (DES3 | BLOWFISH)
   
   and it would accept both. Algorithm is part of the SA definition.
   
=> if I assume policy==SPD entry, this seems very classical
(key is a traffic selector, options are the "action". I agree algorithms
are in the SA definition).

   I think part of the confusion is due to fact that freeswan uses the
   SPD for storing the traffic selector information, which should really
   be attached to the SA.
   
=> RFC 2401 says in section 5 "If no policy is found in the SPD that
matches the packet..." (this defines the default action). The whole
RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree
with you (note RFC 2401 doesn't say the opposite too, i.e. your objection
is valid and IPsec implementors in trouble).

   In above my policy selector is just "local-port=80", but if I have
   additional requirement that each connection should use own SA, then

=> this should be allowed according to RFC 2401 but it seems some
implementations need a SPD entry by connection (?)...

   the traffic selectors in the generated negotiation will include both
   ports and addressess explicitly (and this information is stored into
   each SA directly, not into SPD like freeswan appears to do).
   
=> KAME has the same symptom... The level "uniq" helps but its meaning
is that to share a SA between two SPD entries is forbidden, i.e. not
a solution to your problem (which IMHO is not the place of the TSs,
but the fact a SPD entry can only point to zero or one SA (bundle)
with a cache/lookup mechanism using only addresses and the "uniq" feature).

Regards

Francis.Dupont@enst-bretagne.fr

PS: I believe this is a result of the incredible confusion in RFC 2401 & co
about addresses in SAs. At the question how many addresses characterized
a SA, you can answer zero, one, two, three or four and find a reference
in a RFC or an I-D...