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