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

Re: Specification of tunnel/transport attribute in IKEv2



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

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.

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.

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.

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.

In above my policy selector is just "local-port=80", but if I have
additional requirement that each connection should use own SA, then
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).