Subject: [Ipsec] draft-eronen-ipsec-ikev2-ipv6-config-00 Comment on section 5.4

From: <[email-masked]>
Date: Wed, 20 Jun 2007 10:49:28 +0200

I understand it the way, that client_link_local_interface_id,
link_id, and gateway_link_local_interface_id are interface identifiers,
where client_link_local_interface_id is the identifier the Initiator
suggests for itself, link_id is the identifier the Responder confirms
the Initiator should use (and so client_link_local_interface_id and
link_id may be different), and gateway_link_local_interface_id is the
identifier the Responder uses for its own interface.  To ensure 
uniqueness (omit duplicate address detection), the link_id and
the gateway_link_local_interface_id are guaranteed to be different.
I guess the Responder's interface id is returned, such that 
Neighbor Discovery protocol knows the link-local address of the peer.
Do other protocols rely on knowing the peer's link-local address?
 
Isn't it true, the INTERNAL_IP6_LINK is a new configuration payload
attribute type, and thus has to be assigned a number by IANA (in
section 6).
 
A link-local address is meant to remain unchanged across renumbering.
To enforce this, I don't think there is a need for a N(LINK_ID)
during rekeying.  Creating a new IKE SA should be sufficient to get
a new interface identifier.
 
Christian

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 21 Jun 2007 12:09:56 +0300

Thanks for your comments, Christian! See my replies below:

[email-masked] wrote:

> link_id, and gateway_link_local_interface_id are interface
> identifiers, where client_link_local_interface_id is the identifier
> the Initiator suggests for itself, link_id is the identifier the
> Responder confirms the Initiator should use (and so
> client_link_local_interface_id and link_id may be different), and
> gateway_link_local_interface_id is the identifier the Responder uses
> for its own interface.

Actually, link_id is not an interface identifier, but an identifier
for the "virtual link", chosen by the responder (and not necessarily
64 bits long). It's used to refer to the "same" link later (in
reauthentication and CREATE_CHILD_SA exchanges).

> To ensure uniqueness (omit duplicate address detection), the link_id
> and the gateway_link_local_interface_id are guaranteed to be
> different.  I guess the Responder's interface id is returned, such
> that Neighbor Discovery protocol knows the link-local address of the
> peer.  Do other protocols rely on knowing the peer's link-local
> address?

I'm not actually sure if returning the Responder's interface ID
is absolutely necessary, but I added it there for symmetry...  
(ND probably won't need it)

> attribute type, and thus has to be assigned a number by IANA (in

You're right; the IANA considerations section doesn't yet match
the solution text (I'm planning to update it when the solutions
gets more stable).

> A link-local address is meant to remain unchanged across
> renumbering.  To enforce this, I don't think there is a need for a
> N(LINK_ID) during rekeying.  Creating a new IKE SA should be
> sufficient to get a new interface identifier.

There's no need to have N(LINK_ID) during IKE_SA rekeying, but it
is necessary when doing reauthentication... (the responder has
to be able to distinguish between creating a new virtual link,
and continuing the same virtual link over the new IKE_SA).

Best regards,
Pasi