Subject: [Ipsec] configuration payload usage

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 17 May 2005 00:25:48 -0400

I have the following questions about the usage of Configuration
Payload (CP).  

- When two (or more) IPsec SAs are to be established under a single
IKE_SA, does IKEv2 allow the first IPsec SA to be established with CP
exchange in IKE_AUTH exchange, but the configuration parameters (e.g.,
an IPv6 prefix) carried in the CP is used by the second IPsec SA for
e.g., an initiator to auto-configure an IPsec tunnel inner address by
combining the assigned IPv6 prefix with its own interface ID?

- Maybe the first question is confusing, so more general question
would be: Does IKEv2 allow an initiator's inner address to be
auto-configured by combining an IPv6 prefix carried in CP with an
initiator's interface ID?  If yes, how?  This general question is not
only for the case where there are two (or more) IPsec SAs but also for
the case where there is only one IPsec SA.

Note that an assumption in the above questions is that the initiator
does not even know the prefix length before running IKEv2.

Best regards,
Yoshihiro Ohba

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 May 2005 09:56:31 +0300

The way I read the draft, CP is orthogonal to traffic selectors.  It 
does make sense to use the assigned IP address in the traffic selectors 
of all Child SAs, but the protocol does not dictate this in any way.

It is perfectly acceptable (by the protocol) for the Responder to 
assign an IP address to the Initiator, and then for the initiator to 
establish Child SAs with traffic selectors that are different from the 
assigned IP address.

So IMHO the answer to your questions is yes.  Specific implementations 
may of course have a policy to not allow this.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 May 2005 13:58:14 +0300

> combining the assigned IPv6 prefix with its own interface ID?

Yes, and no. CP does not send IPv6 prefix, it sends full IPv6
addresses.

On the other hand it is completely valid for the responder to send
both IPv4 and IPv6 address inside the CP payload to the initiator, but
create the IPsec SA only for the IPv4 address. And then initiator can
create new IPsec SA for the IPv6 address it received from the
responder.

I.e.

HDR, SAi1, KEi, Ni ->

		<-- HDR, SAr1, KEr, Nr

HDR, SK { IDi, AUTH, CP(CFG_REQUEST),
	  SAi2, TSi1, TSr1 } -->

		<-- HDR, SK { IDr,AUTH, CP(CFG_REPLY),
			      SAr2, TSi2, TSr2}

where the

CP(CFG_REQUEST) =
	INTERNAL_IP4_ADDRESS(0.0.0.0),
	INTERNAL_IP6_ADDRESS(::2d0:b7ff:fe83:21a0),
TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255)
TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255)

and the replies will be:

CP(CFG_REPLY) =
	INTERNAL_IP4_ADDRESS(192.0.2.202),
	INTERNAL_IP6_ADDRESS(2001:4f8:4:7:2d0:b7ff:fe83:21a0),
Tsi2 = (0, 0-65535, 192.0.2.202 - 192.0.2.202)
Tsr2 = (0, 0-65535, 192.0.2.0 - 192.0.2.255)

Then the client can do CREATE_CHILD_SA:

HDR, SK{ SA, Ni, TSi3, TSr3} -->

		<-- HDR, SK{ SA, Nr, TSi4, TSr4}

where

TSi3 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 -
		    2001:4f8:4:7:2d0:b7ff:fe83:21a0)
TSr3 = (0, 0-65535, :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)

TSi4 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 -
		    2001:4f8:4:7:2d0:b7ff:fe83:21a0)
TSr4 = (0, 0-65535, 2001:4f8:4:7:: - 2001:4f8:4:7:ffff:ffff:ffff:ffff)

and so on. 

> the case where there is only one IPsec SA.

The CP payload does not send prefix, but instead full IPv6 address.
The initiator can request INTERNAL_IP6_ADDRESS so that it fills in the
address it wants to get. The server will then mostly likely replace
the prefix part to be suitable for him, but keep the interface ID of
the address it returns. 
-- 
[email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 00:14:05 -0400

Thanks for the reponse.  It is a great news for me to know that CP and
traffic selectors are orthogonal.  

BTW, another question has came up by reading your response:

- Does IKEv2 also allow CP to be carried not only in IKE_AUTH exchange
but also in CREATE_CHILD_SA exchange, i.e., a distinct CP exchange to
be performed per CHILD_SA pair?

Regards,
Yoshihiro Ohba

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 May 2005 07:27:43 +0300

Since they are orthogonal, there is no point in doing this in the 
CREATE_CHILD_SA.  It can be done is a separate Informational exchange. 
This may be necessary if you use the INTERNAL_ADDRESS_EXPIRY attribute 
that says that the address expires after some time. If the Responder 
uses that, then after some time the Initiator needs to renew the 
address with a new CFG payload carried in an Informational exchange.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 00:21:00 -0400

Thanks for the response with detailed example.

BTW, the specification says that:

"
         INTERNAL_IP6_ADDRESS is made up of two fields; the first
         being a 16 octet IPv6 address and the second being a one octet
         prefix-length as defined in [ADDRIPV6].
"

"
      o  INTERNAL_IP6_SUBNET - The protected sub-networks that this
         edge-device protects.  This attribute is made up of two fields;
         the first being a 16 octet IPv6 address the second being a one
         octet prefix-length as defined in [ADDRIPV6].  Multiple
         sub-networks MAY be requested.  The responder MAY respond with
         zero or more sub-network attributes.
"

So I think that not only a full IPv6 address but also a prefix length is 
sent in CP.  So can we say prefix is sent in CP?

Regards,
Yoshihiro Ohba

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 May 2005 13:57:54 +0300

Yoshihiro Ohba writes:
> sent in CP.

It sends full IPv6 address and the prefix length associated with the
address. 

> So can we say prefix is sent in CP?

In a way yes, as you can calculate the prefix from the full IPv6
address and prefix length, but the receiver is not allowed to change
the lower order bits of the address it receives from the server, so in
that sense it is not a prefix that is sent, but full IPv6 address.

The reason is that the server needs to know the full IPv6 address when
it narrows the traffic selectors, and fills in the information which
address is behind which tunnel. So the server allocates the full IPv6
address based on the hints from the client (filled in the to the
configuration payload request (typically interface ID)).

The description of the INTERNAL_IP6_ADDRESS is quite clear about that,
it says that the returned data is an address on the internal network,
i.e. not prefix, but address. It also says that the first part of the
item is the IPv6 address (not prefix, but full address), and the
second part is the prefix-length:

----------------------------------------------------------------------
       o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
         internal network, sometimes called a red node address or
         private address and MAY be a private address on the Internet.
         In a request message, the address specified is a requested
         address (or zero if no specific address is requested). If a
         specific address is requested, it likely indicates that a
         previous connection existed with this address and the requestor
         would like to reuse that address. With IPv6, a requestor
         MAY supply the low order address bytes it wants to use.
         Multiple internal addresses MAY be requested by requesting
         multiple internal address attributes.  The responder MAY only
         send up to the number of addresses requested. The
         INTERNAL_IP6_ADDRESS is made up of two fields; the first
         being a 16 octet IPv6 address and the second being a one octet
         prefix-length as defined in [ADDRIPV6].
-- 
[email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 19:45:56 -0400

> 		<-- HDR, SK{ SA, Nr, TSi4, TSr4}

I think this kind of CP usage for IPv6 address auto-configuration is
important for some deployment scenarios, but the IKEv2 specification
does not seem to explicitly describe this usage.  So I am a bit afraid
that there may be some interoperability issue unless it is explicitly
described it in IKEv2 or some other document.  Any opinion on this?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 20:01:55 -0400

> second part is the prefix-length:

OK.

Also, the above sentence seems to indicate IPv6 address
auto-configuration support.  I have overlooked this.  Please ignore my
question I made in another mail.

Yoshihiro Ohba