Subject: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec 3.15.3)

From: Dan McDonald <[email-masked]>
Date: Tue, 9 Sep 2008 16:24:10 -0400

Let me quote from section 3.15.3 of IKEv2bis:

	IPsec tunnels configured using IKEv2 are not fully-featured
	"interfaces" in the IPv6 addressing architecture sense [IPV6ADDR].
	In particular, they do not necessarily have link-local addresses, and
	this may complicate the use of protocols that assume them, such as
	[MLDV2].

My issue lies with the assertion that tunnels configured using IKEv2 (and its
CFG_* payloads) are not fully-featured interfaces.  What is to prevent an
implementation from creating a fully-formed network interface fro the result
of an IKEv2 Configuration exchange?  I grant that both sides (IRAC/IRAS) need
to cooperate in this regard, BUT I do not see any reason to exclude the
possibility.

Consider the fully private network with access points attached to the
Internet.  An IRAC and conspiring IRAS can have an agreement on how an IRAC
derives its link-local address.  E.g. we have a non-IKE-payload, but
IKE/IPsec-protected remote-access deployment that uses the
assigned-inner-IPv4 to derive the link-local IPv6, and then we run neighbor
discovery as if it were a PPP link.  Even if we didn't assign the client an
inner IPv4, we could have IKEv2's CFG_REPLY (or our equivalent thereof)
assign a link-local, and then let IPv6 neigbor discovery and addrconf take
over from there.

My point is, there may not be limitations in configuring IPv6 addresses -- at
least not from the POV of a spec.  Now implementations may have issues, but
that's not the concern of a spec, right?

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 10 Sep 2008 13:53:43 +0900

Hi Dan,

I'd like to clarify what you have in mind -- is it something like below:

client->gatweway:

    CP(CFG_REQUEST) =
      INTERNAL_IP6_ADDRESS()
    TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
    TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

gateway->client:

    CP(CFG_REPLY) =
      INTERNAL_IP6_ADDRESS(FE80::54A9:E436:2B82:DB81/64)
    TSi = (0, 0-65535, FE80::54A9:E436:2B82:DB81 -
                       FE80::54A9:E436:2B82:DB81)
    TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

followed by configuration of a global address based on an existing 
mechanism, e.g. router discovery over the IPsec tunnel to acquire an 
IPv6 prefix valid over that tunnel, and then SLAAC or DHCPv6.

Something more or less similar was present in earlier versions of 
draft-eronen-ipsec-ikev2-ipv6-config-04, now summarized in its Annex A.1.

One problem of such approaches is that it requires interfaces between 
address configuration function (as a result of e.g. SLAAC/NDP or 
DHCPv6) and IKEv2 because following configuration of an address or 
prefix, IKEv2 has to exchange traffic selectors that covers the IPv6 
prefix or address that the client will use.

And then do I interpret correctly your statement that "there may not be 
limitations in configuring IPv6 addresses -- at least not from the POV 
of a spec.  Now implementations may have issues, but that's not the 
concern of a spec, right?" as the fact that the requirement for the 
interfaces above is out-of-scope for an IKEv2 spec, i.e. it's up to the 
implementation to manage?

--julien

---

From: <[email-masked]>
Date: Wed, 10 Sep 2008 12:23:36 +0300

Well, certainly an IRAC and IRAS can conspire out-of-band to implement
functionality not described in RFC 4306, but that won't result in any
kind of interoperability.

The goal of the IPv6 work item is to write down the necessary details
(which the conspirators need to agree on) in an RFC, so different
vendors can interoperate.

Best regards,
Pasi

> -----Original Message-----
> From: Dan McDonald
> Sent: 09 September, 2008 23:24
> To: [email-masked]
> Subject: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec3.15.3)
> 
> 	"interfaces" in the IPv6 addressing architecture sense 
>       [IPV6ADDR]. In particular, they do not necessarily have 
>       link-local addresses, and this may complicate the use of 
>       protocols that assume them, such as [MLDV2].
> 
> My issue lies with the assertion that tunnels configured using IKEv2
> (and its CFG_* payloads) are not fully-featured interfaces.  What is
> to prevent an implementation from creating a fully-formed network
> interface fro the result of an IKEv2 Configuration exchange?  I
> grant that both sides (IRAC/IRAS) need to cooperate in this regard,
> BUT I do not see any reason to exclude the possibility.
> 
> Consider the fully private network with access points attached to
> the Internet.  An IRAC and conspiring IRAS can have an agreement on
> how an IRAC derives its link-local address.  E.g. we have a
> non-IKE-payload, but IKE/IPsec-protected remote-access deployment
> that uses the assigned-inner-IPv4 to derive the link-local IPv6, and
> then we run neighbor discovery as if it were a PPP link.  Even if we
> didn't assign the client an inner IPv4, we could have IKEv2's
> CFG_REPLY (or our equivalent thereof) assign a link-local, and then
> let IPv6 neigbor discovery and addrconf take over from there.
> 
> My point is, there may not be limitations in configuring IPv6
> addresses -- at least not from the POV of a spec.  Now
> implementations may have issues, but that's not the concern of a
> spec, right?
> 
> Dan

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 10 Sep 2008 15:22:56 +0300

> IPv6 prefix valid over that tunnel, and then SLAAC or DHCPv6.

This is essentially what RFC3456 did for IPv4 for IKEv1. Most of the
IKEv1 implementations never implemented that rfc, and used
non standardized configuration mode instead, as it was much easier to
implement. When IKEv2 configuration protocol was designed both DHCP
over IPsec, DHCP over IKE and configuration payloads were being
discussed and configuration payloads was selected as best option. 

> prefix or address that the client will use.

Actually it usually requires reimplementing IPv6 mechanisms (router
disovery etc) inside the IKE, as there usually is no way to use the
existing mechanisms in the system to do any work unless you are
talking about the native IPsec implementation built into the operating
system. For example our implementation of the RFC3456 did reimplement
DHCP client and server as there was not really general portable way
where we could cause the system's DHCP client to start its work when
we wanted (i.e. when the tunnel was up). Also as you said the IKE
still needed that information too, which meant it need to see all
those packets anyways to get the address information and so on, thus
it was easier not to use the system code at all.

I currently think that for basic IP-address configuration (i.e.
information that needs to be shared with IPsec and system) it is much
easier to make IKE code to do it, especially as there usually IS
standard mechanisms to install the received IP-addresses etc to the
system (ioctl/ifconfig etc). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Wed, 10 Sep 2008 10:29:48 -0400

> kind of interoperability.
<SNIP!>

Sorry for illustrating that poorly.  (We have a deployment of an
IPsec-protected user-auth/addrconf protocol that we hope would be obsoleted
by a full IKEv2 implementation.)

What Julien said earlier was what I was trying to indicate.

Sorry for the confusion,
Dan

---

From: Dan McDonald <[email-masked]>
Date: Wed, 10 Sep 2008 10:23:30 -0400

> IPv6 prefix valid over that tunnel, and then SLAAC or DHCPv6.

Yes.  That's EXACTLY what I had in mind.

> draft-eronen-ipsec-ikev2-ipv6-config-04, now summarized in its Annex A.1.

Okay...

> prefix or address that the client will use.

Yes... you would have to have any subsequent derived addresses added to the
SPD as traffic selectors.  I thought, however, that would be more of an
implementation issue than a spec issue.

> implementation to manage?

Yes.

Dan

---

From: Julien Laganier <[email-masked]>
Date: Thu, 11 Sep 2008 12:11:26 +0900

Tero,

Just to clarify my intent: I am perfectly fine with choices that were 
made w.r.t. address configuration for remote accesses based on tunnel 
mode IPsec. Just wanted to make sure I understood Dan's comment.

--julien