Subject: [Ipsec] Matching ID_IPV4_ADDR and ID_IPV6_ADDR

From: <[email-masked]>
Date: Fri, 26 May 2006 18:13:09 +0300

Hi,

During the IESG evaluation of draft-eronen-ipsec-ikev2-clarifications, 
Sam Hartman raised a discuss about Section 7.1. Currently the text reads

as follows:

7.1.  Matching ID_IPV4_ADDR and ID_IPV6_ADDR

   When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in
   IDi/IDr payloads, IKEv2 does not require this address to match
   the address in the IP header (of IKEv2 packets), or anything in
   the TSi/TSr payloads.  The contents of IDi/IDr is used purely to
   fetch the policy and authentication data related to the other
   party.

Sam's comments (from the I-D Tracker):

   Discuss [2006-05-25]:
   Based on the most recent mail from Steve Kent, the text in 7.1 
   is inaccurate in the following way.

   If you are matching against the PAD using ip addresses, then
   these ip addresses must be used to look up policy in the SPD.
   That requires them to influence the traffic selectors.  So, the
   IP address you claim as an Id will indirectly appear in the
   traffic selectors.

   Comment [2006-05-24]:
   <snip>

   I'm not sure I agree with the text in 7.1 that claims the IP
   address ID payloads don't impact the traffic selectors.  As far
   as a direct implication, it is true.  However you do search the
   SPD based on the IP address payload and that does effect traffic
   selectors.  For example I don't see how to configure the SPD to
   allow someone claiming an Id of 10.0.0.6 to match a policy that
   doesn't have 10.0.0.6 in one of the traffic selectors.

The clarification text addresses two quite different issues, and to
better separate them, we propose to rewrite Section 7.1 as follows:

   When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in
   IDi/IDr payloads, IKEv2 does not require this address to match
   anything in the TSi/TSr payloads. For example, in a site-to-site
   VPN between two security gateways, the gateways could
   authenticate each other as ID_IPV4_ADDR(192.0.1.1) and
   ID_IPV4_ADDR(192.0.2.1), and then create a CHILD_SA for
   protecting traffic between 192.0.1.55/32 (a host behind the first
   security gateway) and 192.0.2.240/28 (a network behind the second
   security gateway). The authenticated identities (IDi/IDr) are
   linked to the authorized traffic selectors (TSi/TSr) using "Child
   SA Authorization Data" in the Peer Authorization Database (PAD).

   Furthermore, IKEv2 does not require that the addresses in
   ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of
   the IKE packets. However, other specifications may place
   additional requirements regarding this.  For example, [PKI4IPsec]
   requires that implementation must be capable of comparing the
   addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in
   the IP header of the IKE packets, and this comparison must be
   enabled by default.

However, this rewrite does not significantly change the meaning from
the original text, and thus Sam's comment still applies (to the
first paragraph). Thus, we'd like to get other opinions from IPsec 
experts on whether the text is correct or not.

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 May 2006 21:01:20 +0300

An IKE gateway will usually have at least two interfaces, an external  
interface (usually with a routable address), and an internal  
interface (which may have routable or non-routable addresses).

The traffic selectors will only be for addresses behind the gateway.  
The gateway's external interface will not be in any selector.  
However, since the gateway's external interface has a routable (and  
therefore unique) address, it makes sense to use that address to  
identify the gateway.

In that case the ID won't match anything in the SPD. It will,  
however, match the IP header of the IKE packets. You can easily find  
an example where it's the other way around.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 29 May 2006 16:28:29 +0300

> experts on whether the text is correct or not.

If I understood correctly Sam's comment was saying that as ID payloads
are used to search for the correct policy from the PAD and SPD they do
indirectly affect the traffic selectors. I think the

  The authenticated identities (IDi/IDr) are linked to the authorized
  traffic selectors (TSi/TSr) using "Child SA Authorization Data" in
  the Peer Authorization Database (PAD).

text takes care of that concern. I have no problem with the new (or
old) text. The new text is clearer and better, but both of them are
ok. 
-- 
[email-masked]