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

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 10 Jun 2008 14:48:42 +0200

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Tue, 10 Jun 2008 15:29:05 -0700

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

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 11 Jun 2008 09:23:55 +0200

Hi,

"fan zhao" <[email-masked]> writes:

> the MIP is embedded into the IKE and their logical functions are
> tightly correlated.

If that is the case, this is IMHO a kind of regression compared to RFC
3776 which did not lead to such strong requirements. Of course, IKE
module requires some changes to support mobility but requiring IKE to be
implemented in MIPv6 module or the opposite looks like an issue.

Francis, Vijeay, Marcelo, Julien, can you comment our understanding of
RFC 4877 and RFC 5026 implications? In the end, can IKE module and MIPv6
module be implemented separately and how is that supposed to work?

I have left my initial analysis below.

a+

---

From: <[email-masked]>
Date: Wed, 11 Jun 2008 09:56:47 +0200

Some coordination between IKE and MIP is required, but in
my view, IKE and MIP can be implemented separately.

Assume a node has a single mobile application/process, which
requires uninterrupted IP connectivity.  As long as this 
application is not started, all other applications just
use the addresses as available, and have to give up/restart when
addresses
are removed.  When the mobile application is to be started,
whoever starts the mobile application has to ensure a
mobile address is available; if no mobile address is available,
it must be created (bootstrapping), namely by running IKE from one of
the available addresses on one of the interfaces towards
the home agent, and if from IKE is received an address
in a CFG payload which differs from the available address
used, then a BU/BA exchange to set up the tunnels.  Thus,
someone has to coordinate IKE and MIP, but they can be
implemented as separate modules.

Christian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Arnaud Ebalard
> Sent: 10. juni 2008 14:49
> To: IETF MEXT WG
> Cc: IETF IPsec WG
> Subject: [IPsec] Clarifications on dynamic HoA assignment by 
> IKE (RFC 4877and 5026)
> 
> Hi,
> 
> 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?".
> 
> 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:
> 
> 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?
> 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 
> 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).  
> 
> 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.
>