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

["fan zhao" <fanzhao828 at gmail.com>]

Hi Arnaud,

IMO, before the MN gets a HoA, the corresponding SPD entry does not have
the HoA. Such entry may contain the mobility header type or may be
even not created
until the HoA is allocated. The IKE can be triggered by the configuration/
selection of the mobility protocol to be used.
Your impression is correct and I agree with you: the initialization of
the MIP is
embedded into the IKE and their logical functions are tightly correlated.

Sincerely,
fan


On Tue, Jun 10, 2008 at 5:48 AM, Arnaud Ebalard <arno at natisbad.org> wrote:
> 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+
>
> _______________________________________________
> IPsec mailing list
> IPsec at ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext