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

From: Julien Laganier <[email-masked]>
Date: Wed, 6 Aug 2008 09:05:39 +0200

Hi Tero,

On Monday 28 July 2008, Tero Kivinen wrote:
> > 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).

I'm understanding this as implying it's possible that the gateway 
replies with a different link-local interface ID which have to be used 
by the client. 

If that is a correct understanding, note that the client would in this 
case be prevented to use a link-local CGA it generated prior to 
initiating, and proposed in the IKE_AUTH.

If we are going with that configuration payload semantic (i.e., client 
proposes something, and server replies with the acceptable value) then 
we should specify that the gateway MUST reply with the link-local 
interface ID that the client "proposed", and MUST choose for itself a 
link-local address that doesn't collide with that of the client.

This would maintain the semantic of the configuration payloads, and 
avoid link-local address collisions.

Thoughts?

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Aug 2008 11:56:32 +0300

> replies with a different link-local interface ID which have to be used 

Yes, but I think we should have text there that gateway SHOULD NOT do
that.

> initiating, and proposed in the IKE_AUTH.

Yes, so thats why gateway should not change address, but on the other
hand if client proposes something that is not acceptable (for example
using non-link-local address there), then it gateway has two options,
either reject whole negotiation, or just reject the invalid address
proposed.

> link-local address that doesn't collide with that of the client.

The current semantic for all other configuration payloads is so that
client proposes value (or just send empty value if it does not care),
and server either accepts the value proposed or fills in acceptable
value. The current text is problematic as it changes this normal
behavior for just this one configuration parameter.

Is there any need for client to know the server's link-local interface
ID? We could put MUST there that server MUST either accept the
link-local address client proposed, or fail the whole IPv6
configuration if it is acceptable, but I think SHOULD would be enough
for that. 

> avoid link-local address collisions.

Current semantics of configuration payload is that client uses
CFG_REQUEST where it requests values to be used, and server using
CFG_REPLY to reply which parameters were given. Here is the text from
RFC4306 section 3.15:

   "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information
   from its peer.  If an attribute in the CFG_REQUEST Configuration
   Payload is not zero-length, it is taken as a suggestion for that
   attribute.  The CFG_REPLY Configuration Payload MAY return that
   value, or a new one.  It MAY also add new attributes and not include
   some requested ones.  Requestors MUST ignore returned attributes that
   they do not recognize.

I would like to keep IPv6 configuration so it keeps this same generic
guideline, so there is no need to change generic configuration payload
processing code when implementing this extension. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Julien Laganier <[email-masked]>
Date: Tue, 12 Aug 2008 12:57:31 +0200

On Tuesday 12 August 2008, Tero Kivinen wrote:
> > replies with a different link-local interface ID which have to be
> > used by the client.
>

I think we agree, this is what I had in mind as well, but with a 
stronger requirement level, i.e. MUST instead of SHOULD. More on the 
requirement level below.

> > If that is a correct understanding, note that the client would in
> > this case be prevented to use a link-local CGA it generated prior
> > to initiating, and proposed in the IKE_AUTH.
>

Right. But 'not acceptable' address should exclude a link local address 
the GW wanted to use for itself. IOW it's not acceptable to refuse a 
valid link-local addresss.

> > If we are going with that configuration payload semantic (i.e.,
> > client proposes something, and server replies with the acceptable
> > value) then we should specify that the gateway MUST reply with the
> > link-local interface ID that the client "proposed", and MUST choose
> > for itself a link-local address that doesn't collide with that of
> > the client.
>

Agree.

> Is there any need for client to know the server's link-local
> interface ID? We could put MUST there that server MUST either accept
> the link-local address client proposed, or fail the whole IPv6

Agree there's no need for the client to know's the server's link local 
as far as no collision occur.

How about:

The server SHOULD accept the link-local address the client proposed 
(which implies the server chooses for itself a link-local address that 
differs from that of the client). In case the server cannot accept the 
link-local address the client proposed, the server MUST fail the whole 
IPv6 configuration.

?

>    "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request
> information from its peer.  If an attribute in the CFG_REQUEST
> Configuration Payload is not zero-length, it is taken as a suggestion
> for that attribute.  The CFG_REPLY Configuration Payload MAY return
> that value, or a new one.  It MAY also add new attributes and not
> include some requested ones.  Requestors MUST ignore returned
> attributes that they do not recognize.
>
> guideline, so there is no need to change generic configuration
> payload processing code when implementing this extension.

Again, agree.

--julien

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Aug 2008 18:20:35 +0300

> link-local address the client proposed, the server MUST fail the whole 

Looks ok for me. Note, that failing IPv6 configuration DOES not cause
IKE SA creation to fail, but can cause the initial IPsec SA creation
to fail, if that wanted to use IPv6 addresses.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec