[MEXT] Clarifications on dynamic HoA assignment by IKE (RFC 4877 and 5026)

[arno at natisbad.org (Arnaud Ebalard)]

Hi,

I just read again RFC 4877 and RFC 5026 (and related sections of RFC
4306) and I have questions. IPsec WG is in Cc; sorry if you receive the
mail twice and also for its length.

In RFC 4877, it is written that "the home agent and the mobile node MAY
support remote configuration of the home address". This is specifically
covered in Section 9 but there are related notes in other parts of the
document.

Simply put, my questions would be: "What are the *detailed* steps by
which IKE negotiation will be *triggered* on the Mobile Node in the
process of getting a HoA dynamically assigned? How is the address
provided to the MIPv6 module?".

More precisely, I'd like to clarify the following points:

SPD entries provided in section 7.2.1 make use of home_address_1 which
might not be available yet (at least on the mobile node). This is
commented after the SPD entries: "In the examples shown above, the
home address of the mobile node might not be available all the time.
For instance, the mobile node might not have configured a home address
yet.  When the mobile node acquires a new home address, it must either
add the address to the corresponding SPD entries or create the SPD
entries for the home address." Associated questions are:

 o Which address should be used meanwhile (in the SPD entries on the
   MN, for instance)?
 o how will the IKE negotiation be triggered, i.e. by which packet?
 o how can the SPD entries be added afterwhile if they are supposed to
   trigger IKE negotiation?

I think I have missed something in the reference documents because I am
under the impression that *something* makes IKE start a negotiation
without any SPD related event (like a packet matching a SP and asking
for protection) to get a HoA, but I am unable to find what. Is it
implicitly expected that the IKE daemon starts an IKE_AUTH exchange to
grab a HoA on its own? What is controlled by MIPv6 / what is not? How?
I'll appreciate some feedback on that.


Now, regarding RFC 5026, there are 7 references to RFC 4877: the use
of previous HoA assignement is also listed based on content of RFC 4877
and another mechanism (section 5.3.2, HoA Auto-Configuration by the
Mobile Node) which allows the MN to get the prefix it should use to
autoconfigure an address it will then send back to the HA. Like previous
HoA assignment, the prefix is obtained using IKEv2 during IKE_AUTH
exchange. Basically, I have the same questions as for dynamic HoA
assignement above. How are things triggered? Who controls what? How is
the synchronization between IKE and MIPv6 performed?


In the end, after reading those 2 documents, I am under the impression
(do not hesitate to correct me) that the MIPv6 process on the MN has the
ability to *trigger* an IKE negotiation with the IKE daemon on its HA
for the purpose of configuring its HoA. I am also under the impression
that this neogiation is not the result of an SPD lookup indicating that
a queued packet requires protection. 

Then I looked at RFC 4306 to find some answers. There are some elements
on the topic in Section 1.1.3, at the end of section 2.9, in section
2.19 and in section 3.15 but the scenario where IKE starts negotiation
and gets the HoA on its own just looks odd.

In RFC 3776 (for static and dynamic keying) and for statically assigned
HoA in RFC 4877, MIPv6 module handles HoA, and IKE acts accordingly
(yes, it needs some modification to bootstrap) but in the dynamic
assignment case, the scenario is reversed and IKE starts and
"configures" MIPv6 (at least for the HoA part). This is not explicitly
stated (if my understanding and descriptions are correct) and the
details are missing in associated document (AFAICT).  

When reading RFC 4877 and RFC 5026, I was under the impression that
MIPv6 and IKE are expected to be one unique entity. I wonder how it will
be possible in that context to have separate IKEv2 and MIPv6
implementations interoperate on the same MN, HA or MR.

If I missed some documents, don't hesitate to tell.

Thanks,

a+

Attachment: pgpBfhugXC7VZ.pgp
Description: PGP signature

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext