Re: Policy requirements in Son-Of-IKE

[Markku Savela <msa@burp.tkv.asdf.org>]

> There are two ways that we can do with this.
>       1) we can remove all policy from SOI. 
>       2) we can improve policy so that we can negotiate in SOI.

Naturally I'm for (1) [with caveat, that "policy" appears to be
understood differently by different implementors].

First, a repeat the fact:

(1) If you implement RFC-2401, then

(2) there is no need for any policy checks in key negotiation, it can
    accept any proposed SA, if it can do the proposed algorithms and the
    protocol (AH, ESP or IPCOMP).

However, this does not imply that TS (or something like it), is not
required. Key negotiation must include some qualifiers for the SA. If
there are none, then each host pair can have only one SA pair between
them.

Say we have policies on host A (and equivalent policy on host B):

 remote=X, protocol=UDP -> SA1: ESP(3DES,SHA1)
 remote=X, protocol=ICMP -> SA2: ESP(3DES,SHA1)

If both SA's are negotiated from A, without any TS-like information,
the host B can not have any idea which SA is to be associated with UDP
and which with ICMP (and thus cannot check the policy as required by
RFC-2401).

Thus, TS-like thing is required. The open question is: what gets
included. I'm quite happy with the original RFC-2401 set of
capabilies. Do we really need anything more complex?

- protocol (wild or specific)
- local port (wild or specific)
- remote port (wild or specific)

Then for tunnel mode, I'm a bit uncertain. Should it be possiblie to
"granularize" SA with two subnets if SA is between two SG's

   Subnet A -- SG ----- SG --- Subnet C
               /          \
   Subnet B --+            +-- Subnet D

e.g is it necessary, for example, to be able to specify 4 distinct
SA's between SG's?

   SA1 (A,C)
   SA2 (A,D)
   SA3 (B,C)
   SA4 (B,D)

If so, then we need both local and remote "proxy" infomation for
SA. Proxy information is one of any/none, specific address, subnet or
address range?

HOWEVER: Whatever is defined for the parameter that granularises SA,
then *EVERYONE* must implement this set. There cannot be any optional
variations.

------------------

IKEv1 negotiated implicitly another symmetric SA, by just assuming
that policies are symmetric. This is rather ugly assumption. I would
prefer a definite solution as follows:

Additional optional payload is added, which contain the relevant
selector values from the packet that triggered the negotiation (note:
TS does not have enough information, when it has wild cards and
ranges).

The presense of this payload indicates that the other side can
negotiate additional SA to the other direction (and this payload makes
it actually possible, even if policies are not symmetric!).