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

[Julien Laganier <julien.laganier.IETF at googlemail.com>]

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

Dan McDonald wrote:
> 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
> IPsec at ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec