(racoon2 47) racoon2 and proxy mode

Francis Dupont <[email protected]> Thu, 08 Dec 2005 15:50:25 +0100
Newsgroups gmane.network.ipv6.kame.racoon
Message-ID <[email protected]>
The proxy mode is to establish transport mode IPsec SAs using a different
address than the peer address, i.e., the address IKE runs over.
It is suggested by a text with an incredible wording in RFC 2409:

   The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode.  If ISAKMP is acting
   as a client negotiator on behalf of another party, the identities of
   the parties MUST be passed as IDci and then IDcr.  Local policy will
   dictate whether the proposals are acceptable for the identities
   specified.  If the client identities are not acceptable to the Quick
   Mode responder (due to policy or other reasons), a Notify payload
   with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.

but there is nothing about this in IKEv2 draft where the ID payloads
in phase 2 are replaced by Traffic Selectors which are not optional
for IPsec SAs. In the MIPv6 community where the topic was discussed
during a long time, the local policy stuff is named the authorization
issue.

Now what to do for racoon2? The proxy mode is already supported:
when a policy entry has my_sa_ipaddr/peers_sa_ipaddr directives
they are used in place of the peer addresses. So the support_proxy
in remote entries for KMPs should be removed as it should never
do something.

But we have still the authorization issue: the binding between
the policy and the remote entries should be checked. There is
no problem for the initiator side because the selector then
the policy are determined from the PF_KEY ACQUIRE message and
an assert fails if there is no remote_index...

There is something to do for the responder side, in
responder_ike_sa_auth_recv() the correct remote entry is got or checked
then the selector is found using ike_conf_find_ikev2sel_by_ts().
At this time it is possible to check if the remote_index in the policy
and the remote entry match. As a config can be used for both the
initiator and the responder roles, and as the initiator mandates
a remote_index, I propose to add a new directive for enabling the check
(off/disable by default as the proxy mode is not common).

The last point is about the check itself: it is simpler to do it
at the return of ike_conf_find_ikev2sel_by_ts() but if two selectors
match it will always eliminate the second. IMHO it is better to
give the remote_index to ike_conf_find_ikev2sel_by_ts() and to
perform a conditional pattern matching.

Regards

[email protected]

PS: so the actions are:
 - remove support_proxy everywhere
 - add a directive in policies for the check
 - either put the check at the return of ike_conf_find_ikev2sel_by_ts()
   or do a conditional pattern matching in this function.
BTW please log the return of ike_conf_find_ikev2sel_by_ts().