Subject: [IPsec] Review of draft-eronen-ipsec-ikev2-ipv6-config-04.txt

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Jul 2008 16:20:58 +0300

Here is some comments for the
draft-eronen-ipsec-ikev2-ipv6-config-04.txt. Nothing major there just
some small comments:

>                       IPv6 Configuration in IKEv2
>               draft-eronen-ipsec-ikev2-ipv6-config-04.txt
>
> ...
>
> 5.  Solution Discussion
>
>    Assigning a new IPv6 address to the client creates a new "virtual
>    IPv6 interface", and "virtual link" between the client and the
>    gateway.  We will assume that the virtual link has the following
>    properties:
>
>    o  The link and its interfaces are created by IKEv2 messages, and are
>       destroyed once they are no longer used by any IKE SA.

Actually quite often you need to keep the interface there even when
the link and the IKE SA is not up. This provides nice way to allow
kicking up the virtual interface, i.e. you just take the vipsec0
virtual interface and say "ifconfig vipsec0 up" and that will be
detected by the IPsec and it will start negotiations to the remote
host and then get addresses and assign them to interface. Even when
the IKE link might go down for some reason, you can keep the interface
up so that TCP sessions you have active do not get immediately
destroyed when there is temporary problem with the connection. If the
interface is there and up and still has addresses, while IPsec tries
to reconnect to the gateway, then those connections do not immediately
die. When the connection regained, and if the IPsec gw allows using
same prefix and addresses, then those running TCP sessions will
continue using same IP addresses and will not be broken at all.

Currently most of the IPsec clients will start the IKE negotiation
when someone first tries to use the network, i.e. when user opens web
page that tries to connect to some site that should have IPsec
protection. This means that this first packet that is used to trigger
the negotiation, is normally using wrong IP-address as it is using the
external IP-address as we do not have internal address yet. Some
implementations makes "connect" button to act like that, i.e. they
just send some dummy packet to trigger the negotiation. Those methods
do have their problems, so creating the virtual interface(s) when the
machine starts and only doing the configuration of those interfaces
when the IKE is finished is somewhat better approach (altought it too
has some problems).

The things above is about same for both IPv4 and IPv6, so this is not
really IPv6 specific problem, but if we define here that interfaces
are created by IKEv2 then that will limit some useful implementation
methods.

> 6.  Solution Sketch
> 6.1.  Initial Exchanges
>
>    1) During IKE_AUTH, the client sends a new configuration attribute,
>    INTERNAL_IP6_LINK, which requests a virtual link to be created.  The
>    attribute contains the client's interface ID for link-local address
>    (other addresses may use other interface IDs).  Typically, the client
>    would also ask for DHCPv6 server address; this is used only for
>    configuration, not address assignment.
>
...
>
>    (To be determined: is it necessary to include the gateway's link-
>    local interface ID?  Probably the client does not need it.)

I do not think clinet needs the gateway's link-local interface ID, and
in that case we can change the INTERNAL_IP6_LINK attribute to follow
the standard rule almost all other attributes use, i.e. client
proposes something, and server replies with the acceptable value. I.e.
client would send its own link-local interface ID (and optionally
IKEv2 Link ID) to the server in INTERNAL_IP6_LINK and server would
reply with that same link-local interface ID to verify that client is
allowed to use that address (and the IKEv2 link ID).

...
>    The prefixes remain valid through the lifetime of the IKE SA (and its
>    continuations via rekeying).  If the VPN gateway needs to remove a
>    prefix it has previously assigned, or assign a new prefix, it can do
>    so by triggering reauthentication.

Add reference to the reauth draft here.

> 7.  Payload Formats
>
> 7.1.  INTERNAL_IP6_LINK Configuration Attribute
>
>    o  Link-Local Interface ID (8 octets) - The Interface ID used for
>       link-local address (by the party that sent this attribute).

As most of the IPsec implementators do not really know that much of
the IPv6 specific things like Link Local Interface IDs, it would be
good idea to give example or similar here, and whether the gateway for
example is supposed to verify that the clients address it gives here
is really a link local interface id or not.

>    o  IKEv2 Link ID (variable length) - The link ID (may be empty when
>       the client does not yet know the link ID).
...
> 7.2.  INTERNAL_IP6_PREFIX Configuration Attribute
...
>    o  Prefix (16 octets) - An IPv6 prefix assigned to the virtual link.

Should we explicitly mandate that all bits of the prefix that are not
part of the prefix MUST be 0?

> 8.  IANA Considerations
...
>    This document also defines one new IKEv2 notification, whose value is
>    to be allocated (has been allocated) from the "IKEv2 Notify Message
>    Types" namespace [IKEv2]:

The registry is called "IKEv2 Notify Message Types - Status Types".
Better use that so IANA can allocate it from the correct number range
(16384-40959).

> A.1.  Version -00 Sketch
>
>    Comments: This was changed in -01 draft based on feedback from VPN
>    vendors: while the solution looks nice on paper, it is claimed to be
>    unneccessarily complex to implement when the IKE implementation and
>    IPv6 stack are from different companies.  Furthermore, enforcing
>    access control outside IPsec is a significant architectural change
>    compared to current IPv4 solutions.

This approach would normally require the IPsec engine to find all
router solicitations and advertisement messages going inside the IPsec
tunnel, send them user mode policymanager so it can get that
information too, and the policymanager would then need to parse those
router solicitations and advertesements too in addition to normal
stack doing it, and most likely modify the in kernel SPD tables etc.
It might even need to do this before the system stack has possibility
to see the RA as otherwise stack might immediately send packets which
would be dropped as SPD is not yet updated etc. The information could
also be available from the operating system stack, but in some cases
OS stack for example does not give that informationt out before it has
finished duplicate address detection or similar.

This is doable, but it adds quite a lot of complexity and duplicates
the RA parsing code to the IPsec module too.

> A.5.  Sketch Based on RFC 3456
>
>    For completeness: a solution modeled after [RFC3456] would combine
>    (1) router aggregation link model, (2) prefix information
>    distribution and unique address allocation with DHCPv6, and (3)
>    access control enforced by IPsec SAD/SPD.

We did have implementation of that earlier, and that was one of those
things where you had to do similar tricks than for version -00 Sketch.
In here we actually had to reimplement dhcp as we could not use the OS
dhcp in general case.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec