Subject: Re: [IPsec] Update for ikev2-ipv6-config draft

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Mar 2008 10:53:22 +0100

On Wednesday 13 February 2008, [email-masked] wrote:
> Hi,
>
> I have posted a new version of the ikev2-ipv6-config draft
> (http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-ipv6-config)
> which incorporates some new ideas based on good discussions
> in Vancouver (Hemant and Dave, thanks!).
>
> In particular, Section 5 has new text discussing the most important
> design choices to be made, and Appendix A has additional solution
> sketches for several design choice combinations.
>
> Section 6 still proposes the same solution as in draft version -01;
> that is, point-to-point link model where prefixes are assigned in
> IKEv2 configuration payloads, and access control is enforced by
> IPsec (traffic selectors in SAD/SPD). To me this seems to be the
> simplest solution -- however, the additional sketches in Appendix A
> should make it easier to compare different alternatives; and
> comments about them would be especially welcome!

Hello Pasi,

Thanks for updating your draft. I think this is useful work.

I have some comments below:

3.2.  Link-Local Addresses

   The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6
   addresses of all types are assigned to interfaces, not nodes. [..]
   All interfaces are required to have at least one Link-Local unicast
   address".

   Currently, the virtual interface created by IKEv2 configuration
   payloads does not have link-local addresses.  This violates
   [IPv6Addr] and prevents the use of protocols that require link-local
   addresses, such as [MLDv2].

Here you could mention DHCPv6 as well (and you are in Section 3.5, with 
DHCPv6 PD). If one has a link-local address, it can use DHCPv6 to 
retrieve various configuration parameters from the DHCPv6 server, 
besides IPv6 address and DNS server address which are already handled 
via the CFG_* exchange. That would allow to decouple introduction of 
new configuration parameters from IKEv2 since only DHCPv6 support would 
be needed.

3.4.  Interface Identifier Selection

   In the message exchange shown in Figure 2, the gateway chooses the
   interface ID used by the client.  It is also possible for the client
   to request a specific interface ID; the gateway then chooses the
   prefix part.

   This approach complicates the use of Cryptographically Generates
   Addresses [CGA].  With CGAs, the interface ID cannot be calculated
   before the prefix is known.  The client could first obtain a non-CGA
   address to determine the prefix, and then send a separate CFG_REQUEST
   to obtain a CGA address with the same prefix.  However, this approach
   requires that the IKEv2 software component provides an interface the
   component managing CGAs; an ugly implementation dependency that would
   be best avoided.

nit: s/an interface the/an interface to the/

4.1.  Main Requirements

[...]

   o  A VPN client can be assigned multiple prefixes for use on the
      client-gateway link.  The client does not have to know beforehand
      how many prefixes are needed.

[...]

   o  It should be possible to share the VPN access over a local area
      network connection, without requiring anything special from other
      hosts in the local network (beyond minimal IPv6 node requirements
      specified in [RFC4294]).

These two requirements turn into the ability for client to be delegated 
prefixes while not assigning them to the client-gateway link. They 
could then be included in the negotiated TS's and routed appropriately 
by the gateway to the client.

The ability to do prefix delegation with DHCP within the IPsec tunnel 
interface could be useful for NEMO prefix delegation. Right now it is 
not possible to use DHCP PD out of the box for NEMO prefix delegation 
since multicast DHCP messages cannot be sent through an IPsec tunnel 
between the NEMO Mobile Router and the Home Agent.

--julien
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec