Subject: [Ipsec] IPv6 Configuration in IKEv2

From: Kimihiro OHKI <[email-masked]>
Date: Wed, 28 Jun 2006 11:06:32 +0900

Hi All,

I would like to clarify IKEv2 specification regarding IPv6 configuration.

Assumptions:
  - Host A is an IKEv2 initiator.
  - Gateway B is an IKEv2 responder.
  - The Gateway B has policy to allocate a globally unique /64 prefix
    to each host (per IKE_SA).
  - The Host A wants to use multiple interface identifiers under the
    assigned /64 prefix. The Host A itself may use them (e.g. using
    privacy extensions), or other hosts which connect to the Host A
    may use some of them.
  - The Host A wants to use common IPsec_SA for the multiple interface
    identifiers.

Clarifications:
I would like to know if the following example scenarios comply with
IKEv2 specification. To be more precise, it is not clear for me how to
configure (add/change/delete) inner IP addresses on the existing IPsec_SA.

[Scenario-1]
In case that the following exchange is performed during initial
(IKE_AUTH) negotiation,

  CP(CFG_REQUEST) =
    INTERNAL_IP6_ADDRESS(::2:3:4:5/64)
  TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

  CP(CFG_REPLY) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

Note: The negotiated TSi is identical to the authorized
INTERNAL_IP6_ADDRESS in this scenario.

If the Host A wants to use additional interface identifiers, is it OK
for the Host A to activates INFORMATIONAL exchange as follows?

  CP(CFG_REQUEST) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64)
  TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

  CP(CFG_REPLY) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64)
  TSi = ((0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5),
         (0, 0-65535, 2001:DB8:0:1:6:7:8:9 - 2001:DB8:0:1:6:7:8:9))
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

Then the Host A wants to change the secondary interface identifier.
Is it OK for the Host A to activates INFORMATIONAL exchange as follows?
Although the Host A may needs to delete the identifier after creating
the new identifier in practice, this is just an example for
clarification if the exchange complies the standard.

  CP(CFG_REQUEST) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:A:B:C:D/64)
  TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

  CP(CFG_REPLY) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:A:B:C:D/64)
  TSi = ((0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5),
         (0, 0-65535, 2001:DB8:0:1:A:B:C:D - 2001:DB8:0:1:A:B:C:D))
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

And then, the Host A activates another INFORMATIONAL exchange if the
Host A wants to delete the secondary interface identifier.

  CP(CFG_REQUEST) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

  CP(CFG_REPLY) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

What I want to clarify here is,

- Can such configuration (add/change/delete) negotiation can be
performed using INFORMATIONAL exchanges like above?
- Is CP in INFORMATIONAL exchanges well defined? For example, if
Configuration payloads are contained in INFORMATIONAL exchanges, is
there any definition or guideline how to set or interpret the contents
of the payloads?

[Scenario-2]
In case that the following exchange is performed during initial
(IKE_AUTH) negotiation,

  CP(CFG_REQUEST) =
    INTERNAL_IP6_ADDRESS(::2:3:4:5/64)
  TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

  CP(CFG_REPLY) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  TSi = (0, 0-65535, 2001:DB8:0:1:: -
         2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF)
  TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

Note: TSi in CFG_REPLY shows the /64 prefix range in this scenario.

Can The Host A use any interface identifiers in the range of the
negotiated TSi without any exchanges over the IKE_SA?

What I want to clarify here is, if the above understanding is correct
or the Host A must activate some exchanges to use interface
identifiers other than ::1:2:3:4.

Best Regards,
Kimihiro Ohki

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

---

From: <[email-masked]>
Date: Wed, 28 Jun 2006 11:18:43 +0300

> configure (add/change/delete) inner IP addresses on the

IKEv2 does not allow modifying the traffic selectors ("inner IP
addresses") of an existing IPsec SA: instead, you have to create a new
IPsec SA (using CREATE_CHILD_SA exchange) and delete the old one.

Moreover, your scenario really requires two operations to be carried
out: assigning an IP address to the host (giving permission to
configure the host's TCP/IP stack with the address and use it as
source address for traffic), and creating IPsec SAs that allow traffic
with that address to be properly protected.

In IKEv2, the former is done with configuration payloads, and the
latter with CREATE_CHILD_SA exchange. These are quite separate
operations, since it's possible that a host is assigned an IP address
but does not currently have IPsec SAs that match that address, and
it's possible to have IPsec SAs that match addresses that are not
assigned to the host.

> INTERNAL_IP6_ADDRESS in this scenario.

Looks OK so far.

>   TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

The new IPsec SA has to be created using the CREATE_CHILD_SA exchange;
after that, a separate INFORMATIONAL exchange can be used to delete
the old IPsec SA pair.

Furthermore, IKEv2 does not really support releasing addresses
assigned via configuration payloads (except by closing the whole SA),
and usually it's not even necessary. Thus, it's not necessary
to list the existing address (the one ending :4:5) in the
CFG_REQUEST/REPLY.

<snip>

> negotiated TSi without any exchanges over the IKE_SA?

No. The INTERNAL_IP6_ADDRESS attribute CFG_REPLY assigns host A _one_
IPv6 address, not the whole /64 block. Although TSi/TSr specifies that
traffic within the whole block can be protected with this SA, TSi/TSr
do not give Host A the permission to actually use the whole block.

(But it would be possible to define a new configuration attribute, say,
INTERNAL_IP6_ADDRESS_BLOCK, to allow assigning a whole block...)

In general, the IKEv2 configuration payloads for IPv6 are a bit
messy, since the remote access IPsec tunnels created with IKEv2 are 
not fully-featured "interfaces" in the IPv6 addressing architecture
sense (although they could have been designed that way, an in hindsight,
maybe should have been...).

Best regards,
Pasi

---

From: Kimihiro OHKI <[email-masked]>
Date: Thu, 29 Jun 2006 14:33:34 +0900

Thanks for your reply.
Excuse me for some educational questions.

> IPsec SA (using CREATE_CHILD_SA exchange) and delete the old one.

OK. I've understood that the traffic selectors negotiated at creating 
the CHILD_SA are valid until the CHILD_SA is expired or deleted, but 
can not be changed (i.e. TS must not be included in INFORMATIONAL 
exchanges).

> it's possible to have IPsec SAs that match addresses that are not

I'd like to clarify this meaning below. However I've understood that 
negotiation of configuration payloads and traffic selectors are entire 
separate operations.

> after that, a separate INFORMATIONAL exchange can be used to delete

I've understood this exchange is wrong because this includes traffic 
selectors' negotiation in an INFORMATIONAL exchange.
Meanwhile from the point of view of configuration payloads, can 
INFORMATIONAL exchanges be used to request additional inner IP 
addresses if the traffic selectors are NOT necessary to be modified?

> to list the existing address (the one ending :4:5) in the

Some clarifications on this statement:

- Are all configurations via configuration payloads commonly related 
to all CHILD_SAs regardless of the CHILD_SA which has carried the 
configuration payloads, although traffic selectors are related to each 
specific (associated) CHILD_SA? In other words, configuration payloads 
works on not the CHILD_SA but the IKE_SA?
For example,

   Inner IP address A is configured via a configuration payload over
     CHILD_SA(1).
   Inner IP address B is configured via a configuration payload over
     CHILD_SA(2).
   TS1 is negotiated for CHILD_SA(1).
   TS2 is negotiated for CHILD_SA(2).

In this case, when CHILD_SA(1) is deleted, TS2 and both IP addresses A 
and B are valid on CHILD_SA(2). Is this understanding correct?

- With regards to your statement "IKEv2 does not really support 
releasing addresses assigned via configuration payloads (except by 
closing the whole SA)", does INTERNAL_ADDRESS_EXPIRY attribute also 
work for releasing addresses? In other words, does this attribute work 
for releasing some specific addresses or releasing IKE_SA?

> do not give Host A the permission to actually use the whole block.

I assumed that inner IP address assignment on IKEv2 is optional 
behavior (i.e. static address configuration and using other protocols 
such as DHCP are also acceptable). Then my understanding was, although 
CFG_REQUEST/REPLY just works for providing useful information to the 
initiator, how to configure the routing table at both the initiator 
and the responder is implementation specific, outside of the scope of 
rfc4306 specification or necessary to rely on other specifications/ 
guidelines. So I guessed this scenario works from the point of view of 
rfc4306 if both the initiator and the responder have prior agreement.

In rfc4306, section 2.9 (Traffic Selector Negotiation) says "For 
example, if the original initiator request the creation of a CHILD_SA 
pair, and wishes to tunnel all traffic from subnet 192.0.1.* on the 
initiator's side to subnet 192.0.2.* on the responder's side, the 
initiator would include a single traffic selector in each TS payload. 
  TSi would specify the address range (192.0.1.0 - 192.0.1.255) and 
TSr would specify the address range (192.0.2.0 - 192.0.2.255)."
In this case for example, if configuration via configuration payloads 
is mandatory to effect on the routing table at the responder, all 
addresses in the subnet of the initiator side are necessary to be 
included in the configuration payloads?

> INTERNAL_IP6_ADDRESS_BLOCK, to allow assigning a whole block...)

I've understood that the INTERNAL_IP6_ADDRESS is not enough to assign 
/64 prefix or some block.

Best Regards,
Kimihiro Ohki

---

From: <[email-masked]>
Date: Thu, 29 Jun 2006 16:42:34 +0300

Kimihiro OHKI wrote:
> > The new IPsec SA has to be created using the CREATE_CHILD_SA
> > exchange; after that, a separate INFORMATIONAL exchange can be
> > used to delete the old IPsec SA pair.
> 

> addresses if the traffic selectors are NOT necessary to be modified?

Yes, CFG_REQUEST/REPLY can be sent in INFORMATIONAL exchanges.

> > assigned via configuration payloads (except by closing the whole
> > SA), and usually it's not even necessary. Thus, it's not necessary
> configuration payloads, although traffic selectors are 
> related to each specific (associated) CHILD_SA? In other words,
> configuration payloads works on not the CHILD_SA but the IKE_SA?

That's right; the configuration information in CFG_REQUEST/REPLY is
not related to any particular CHILD_SA, but the IKE_SA as whole.

> In this case, when CHILD_SA(1) is deleted, TS2 and both IP 
> addresses A and B are valid on CHILD_SA(2). Is this understanding 
> correct?

Both IP addresses A and B are still valid, even when CHILD_SA(1) is
deleted. Whether the traffic can be actually sent with CHILD_SA(2)
depends on what TS2 contains 

> work for releasing addresses? In other words, does this attribute
> work for releasing some specific addresses or releasing IKE_SA?

INTERNAL_ADDRESS_EXPIRY allows the gateway to set a lifetime for
the addresses (after which they expire), but it does not allow the
client to request releasing some specific address.

<snip>
> > No. The INTERNAL_IP6_ADDRESS attribute CFG_REPLY assigns host A
> > _one_ IPv6 address, not the whole /64 block. Although TSi/TSr
> > specifies that traffic within the whole block can be protected
> > with this SA, TSi/TSr do not give Host A the permission to
> > actually use the whole block.
> 
> behavior (i.e. static address configuration and using other
> protocols such as DHCP are also acceptable). Then my understanding
> was, although CFG_REQUEST/REPLY just works for providing useful
> information to the initiator, how to configure the routing table at
> both the initiator and the responder is implementation specific,
> outside of the scope of rfc4306 specification or necessary to rely
> on other specifications/ guidelines. So I guessed this scenario
> works from the point of view of rfc4306 if both the initiator and
> the responder have prior agreement.

Yes, the scenario works if assigning the whole /64 block to host A 
is done by some other means (e.g. manual configuration).

> included in the configuration payloads?

Hmm... not really, since the routing table is not necessarily involved
at all: the IPsec architecture (RFC4301) does not consider IPsec
tunnels to be "interfaces"; rather, IPsec processing is applied to
packets that match entries in the SPD (and the SPD could be
interface-specific).

In the example above, the responder ("host B") would probably have SPD
entry saying that "traffic with local address 192.0.2.0/24 and remote
address 192.0.1.0/24" must be protected by IPsec", and PAD entry
saying "peer authenticated as host-a.example.com is authorized to
represent addresses 192.0.1.0/24".

Now when Host A requests the creation of a CHILD_SA pair as explained
above, host B would check the request against its PAD and SPD, and
since everything is OK, would create the SA and an entry in the SPD
cache containing 192.0.1.0/24,192.0.2.0/24 and a pointer to the SA.

When host B now has an outgoing packet from 192.0.2.0/24 to
192.0.1.0/24,
it would match this SPD cache entry, and would be processed as agreed
for the SA, and sent to host A.

(But it's good to note that actual IPsec implementations may use the
words "interface", "SPD", etc., to mean slightly different things than
RFC 4301. E.g. some operating systems might call every IPsec
tunnel-mode SA an "interface"; others might have a single global
"interface" called "ipsec", and so on. But these are implementation
details not covered in RFC 4301 or 4306.)

Best regards,
Pasi

---

From: Kimihiro OHKI <[email-masked]>
Date: Fri, 30 Jun 2006 10:32:49 +0900

> When host B now has an outgoing packet from 192.0.2.0/24 to

Actually my confusion on this whole discussion might be, it was not 
clear for me how the negotiation of configuration payloads / traffic 
selectors affects its SPD or routing to the "interface".
It seems, it is clearly defined that the negotiation of traffic 
selectors affects its SPD, on the other hand actual IPsec 
implementations may need to take care of any other details such as the 
difference between "SPD" and "interface" for the interoperability.

Best Regards,
Kimihiro Ohki

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Jun 2006 11:08:09 -0400

At 10:32 AM +0900 6/30/06, Kimihiro OHKI wrote:
>>...
>implementations may need to take care of any other details such as 
>the difference between "SPD" and "interface" for the 
>interoperability.
>
>Best Regards,
>Kimihiro Ohki

the SPD is not modified by IKE negotiation of traffic selectors.  The 
SPD controls the traffic selector negotiation process.  The SAD entry 
and SPD cache entry created for an SA are affected by the IKE 
negotiation.

Steve

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 30 Jun 2006 09:49:33 -0700 (PDT)

> and SPD cache entry created for an SA are affected
In the road warrior case, the IP address is assigned
by the security gateway and this would result in
SPD modification ("inner-address --> 0.0.0.0 PROTECT)
as this address is not known a priori. This
is a modification, right ?

The value in INTERNAL_IP*SUBNET tells the host
(initiator) that the traffic to these addresses
should be protected. As per 4301, SPD is the
only place that i can find suitable for adding this.
But then, this would result in source address
selection problems. Hence, as suggested in
Pasi's earlier mail, it normally affects the
routing table entry. These routes would point
to an interface where the address returned in
CFG-REPLY is assigned. With this, you have just
one SPD entry : "inner-address -> 0.0.0.0 PROTECT".

-mohan