Subject: [mobile-ip] potential registration conflict when mutiple HAs on home network

From: "Ed Remmell" <[email-masked]>
Date: Mon, 25 Nov 2002 17:49:33 -0700

ALL -

I've run across a potential issue, here is the scenario (I have no idea how
to this fix this, it appears to be an MIPv6 architectural issue affecting
HAs):

1) MN is operating on foreign network, discovers a set of home agents using
DHAAD, successfully registers (S=0, L=1) its set of home addresses formed
from the IID with the first home agent (HA #1) in the list specifying an
infinite lifetime.

2) HA #1 performs DAD on the home network for the link-local address formed
from the IID, determines that no other node on the home network is using
that IID (i.e. DAD passes for the link-local scope address formed from the
IID), etc., then accepts the MN's registration and creates the MNs home
address bindings with the specified infinite lifetime.

3) MN powers down, does NOT save any of this information (i.e. home agent
address, registration state, etc.) to NVRAM.

4) MN powers up on foreign network. MN discovers a set of home agents using
DHAAD, however this time MN attempts to register its set of home addresses
formed from the IID with a different home agent (HA #2) on its home network.
Perhaps the HA list it receives in the DHAAD reply specifies a different HA
preference order, or more likely there is just a transient loss of
connectivity (i.e. the MN goes through a tunnel temporarily, i.e. RF null)
which causes the MN to not be able to register with HA #1 and instead to
register with HA #2.

5) HA #2 performs DAD on the home network for the link-local address formed
from the IID, HA #1 defends that address (the bindings were created in step
#2 above with an infinite lifetime), HA #2 fails DAD and then fails the
registration. MN is not able to register its home addresses. This is a
permanent failure for the MN (at least until the MN is power-cycled), per
section 11.7.1:

	"In the unlikely event that the mobile node's home address is
autoconfigured as the IPv6 address of another network node on the home
network, the home agent will reply to the mobile node's subsequent Binding
Update with a Binding Acknowledgement containing a Status of 134 (Duplicate
Address Detection failed).  In this case, the mobile node MUST NOT attempt
to re-use the same home address."

Note that the lifetime does not have to be infinite, it could be 2-3 days,
or even just a few hours and this scenario has a significant impact on MIPv6
usability.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 25 Nov 2002 18:00:07 -0700

BTW, this issue also occurs when the HA performs DAD for non-link-local
scope MN home addresses.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Monday, November 25, 2002 5:50 PM
> To: Mobile IPv6 mailling list
> Subject: [mobile-ip] potential registration conflict when mutiple HAs on
> home network
>
>
> ALL -
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Nov 2002 18:49:27 -0800

one simple fix. before powering down, the MN always sends a
deregistration BU to its current home agent. I dont know if this
works for you.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 25 Nov 2002 18:54:04 -0700

Vijay -

That is a reasonable suggestion. However, it doesn't cover all cases. But,
I'll keep it in mind when I do my design.

This can't really be fixed on the MN, it seems like it requires some kind of
coordination between HAs on the same home network.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Vijay Devarapalli
> Sent: Monday, November 25, 2002 7:49 PM
> To: Ed Remmell
> Cc: Mobile IPv6 mailling list
> Subject: Re: [mobile-ip] potential registration conflict when mutiple
> HAs on home network
>
>
>

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 26 Nov 2002 10:54:10 -0500

Vijay

> deregistration BU to its current home agent. I dont know if this

The proplem is that it's not always possible.  I'll give you an
example.  I droped my phone yesterday and the battery popped off.
If the my phone were a MN, this would simulate the filure Ed was
describing (suddent power down).  The phone did not have the time to
deregister since it has lost its power source.

There are ways out of this, but they seem to be harry so I don't
know if want to go down this path now.

-vlad

P.S One possible way of solving this is for HA2 (in Eds' scenario) to
realize that the DAD NA was a proxy advertisement (O bit was off)
and the source (possibly) matched a HA from a Home Agent List.
Then we could either treat the binding as successfull and do some
kind of forwarding to the right HA or provide a mechanism to "refer"
the MN to the correct HA.  This is just off the top of my head.

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 26 Nov 2002 12:08:38 -0700

Vlad -

A recommended solution for this issue (plus also for issue #168):

Abstract:
We (i.e. myself, and a couple of other Elmic engineers familiar with Mobile
IP and IPv6 and biased towards simplifying the MIPv6 MN implementation)
strongly recommend that you change the MIPv6 HA to not defend the MNs home
address, but instead to monitor for another node on the home network using
or attempting to use that home address, in which case the HA transitions the
MN home address binding into a "dormant" state, suspends tunneling packets
to the MN, and forces the MN to reregister by periodically retransmitting a
BRR to the MNs primary CoA (per the "dormant" binding) until either the MN
responds with a BU, or the binding lifetime expires, or the HA makes some
informed decision that the MN will not respond and deletes the binding. Note
that while the binding is in a "dormant" state, if a node on the home
network is using the MNs home address (i.e. responding to NS for that home
address), then packets sent to the MNs home address must be routed to that
other node on the home network.

--------------
Justification:
This is a significant architectural change we are proposing in the HA, but
it fixes this issue of "potential registration conflict when multiple HAs on
home network", plus it also nicely resolves the other issue #168 "L bit is
not worth the trouble" I reported earlier while still allowing the HA to
optimize DAD for MN home address bindings (i.e. HA still creates a binding
for the link-local scope home address formed from the IID, when L=1).

We see a HUGE advantage to making this change in the HA: it allows a MN to
return home and begin operating immediately using *ALL* of its home
addresses without needing to disable DAD and without needing to deregister.
The MN no longer needs to go through the clunky algorithm specified in
section 11.5.4 of draft 19 for returning home. The draft would then be
updated to state that the MN SHOULD deregister its home addresses upon
returning home if it knows the HA that it was previously registered with and
knows that its bindings are still active, however this is no longer required
for uninterrupted MN operation after returning home. This significantly
reduces complexity in the MN, reduces the latency involved in the MN
returning home, and also avoids a potential accidental DoS scenario where a
MN returns home but doesn't realize that it has active bindings, can't
enable its interface for IPv6 because DAD fails when it tries to
auto-configure its link-local scope address based on its globally unique IID
because the HA is defending all of its home addresses (and the bindings in
the HA have an infinite lifetime, so this is a persistent failure).

There is no greater potential for DoS attacks with these proposed HA changes
for home addresses formed using a globally unique interface ID (i.e. the L=1
case). There is, however, greater potential for unintentional DoS occurring
with home addresses generated using RFC-3041 (i.e. if another node on your
home network starts using the same random interface ID that you picked to
auto-configure your home address), but then we believe that it does not make
sense to use RFC-3041 home addresses with Mobile IPv6, since the two are at
conflicting purposes: Mobile IPv6 lets you keep a globally unique home
address so that you are permanently reachable at that home address no matter
where you travel, whereas RFC-3041 intends for your home address to be
constantly changing for privacy purposes so that someone monitoring your
network activity can't correlate it to you. In our opinion, if you want to
use RFC-3041 with Mobile IPv6, you should use it to auto-configure the CoA
on the foreign network, not to auto-configure the home address. Considering
the fact that these changes fix a number of different problems and
significantly improve MN operation in the returning home case, we are
willing to sacrifice robust Mobile IPv6 support for being able to use
RFC-3041 to auto-configure home addresses. On the other hand, if you are
absolutely unwilling to sacrifice any compatibility with RFC-3041, then you
could always implement these modifications just for the L=1 case, and that
would avoid the potential DoS for RFC-3041 home addresses while still
obtaining all of the benefits described above when a globally unique
interface ID is used to form home addresses (which is probably true for the
large majority of MIPv6 usages scenarios).

---------
Scenario:
Let's investigate the scenario I gave earlier for "potential registration
conflict when mutiple HAs on home network", now with HA #1 implementing this
new behavior:

steps 1-4) MN registers its set of home addresses (formed using a globally
unique interface ID: L=1, S=0) with HA #1, specifying an infinite binding
lifetime. HA #1 creates the MN bindings with the requested infinite
lifetime. MN powers down, powers back up on foreign network, doesn't
remember that it is still registered and doesn't remember the HA that it was
using (HA #1), does DHAAD, and starts trying to register with a different HA
(HA #2).

5.1) HA #2 performs DAD on the home network for the link-local scope address
formed from the IID.

5.2) HA #1 detects another node on home network is trying to use the MNs
home address, does not defend that address (new behavior):

HA #1 detects the DAD probe sent by HA #2 (which could actually be a DAD
probe sent by some other node attached to the home network that is
performing a DoS attack, however in most cases this will either be the MN
returning home or a different HA that the MN is registering with), and does
not respond with a NA in this case (this is different from Address
Resolution, in which case HA #1 would respond with the solicited NA as long
as the binding is still "active" and not "dormant"). So HA #1 is modified to
just act as a proxy for the home address, but not to defend that home
address (i.e. monitor DAD and proxy for home address but don't respond to
DAD probes).

5.3) HA #1 transitions state of MN binding to "dormant", stops responding to
NS for that home address, suspends tunneling packets to the MN, continues
reverse-tunneling packets from the MN:

HA #1 moves the state of the MN binding to "dormant", meaning that it no
longer acts as a proxy for that MN home address until the MN responds
appropriately to the BRR sent in step 5.4 (see below). While the binding is
"dormant", the HA does not respond to any Neighbor Solicitation messages
(DAD or Address Resolution) for this home address, but the HA may buffer
some number of packets that it would normally tunnel to the MN (i.e. hoping
for the best), and should also continue to accept reverse-tunneled packets
from the MN's home address and forward those as it would normally do if the
binding was still active. While the binding is in a "dormant" state, if a
node on the home network is using the MNs home address (i.e. responding to
NS for that home address), then packets sent to the MNs home address must be
routed to that other node on the home network.

5.4) HA #1 sends BRR to MN:

Immediately after transitioning the MN binding to the "dormant" state, HA #1
sends a BRR to the MN at its primary CoA (per the "dormant" binding), just
in case this DAD probe wasn't initiated by a MN initial registration with a
different HA or by the MN returning home. If the MN has selected and
registered with a different HA, but still has the same primary CoA as
before, then the MN will ignore/silently discard these BRR messages, since
they don't originate from its current HA (or, the MN could delete the
binding in the old HA, if that is possible to do on the foreign network). If
the MN has returned home, then the MN won't be able to receive these BRR
messages sent to its old primary CoA, so the MN won't respond.

5.5) HA #1 retransmits BRR to MN, until either MN responds or HA decides
that MN will not respond:

HA #1 continues to retransmit the BRR periodically for the remaining
lifetime of the binding, or at least until the MN responds (if the MN
registered with a different HA or has returned home, then the MN will never
respond). Exponential backoff is not recommended for these retransmissions
since it is very important to reactivate the MN's binding as soon as
possible and the MN could be experiencing dropped messages and other delays
in packet delivery due to the nature of wireless operation; however, if the
Binding Refresh Advice option was supplied to the MN in the registration
reply, then the HA could use that interval to make an informed decision that
the MN is no longer maintaining that binding (for example, HA #1 continues
retransmitting the BRR for 3.5 times the Binding Refresh Advice interval,
then after not receiving a BU from the MN, gives up and deletes the
binding). An infinite binding lifetime is not guaranteed, in this case.

5.6) HA #1 either deletes the "dormant" binding, or moves it back to the
"active" state:

If/when the MN responds to the BRR with a BU, HA #1 performs DAD on the
specified home address as it would normally do when creating a binding for
that home address. If DAD fails on the home network, then HA #1 fails the
registration and deletes the "dormant" binding. If DAD succeeds on the home
network, then HA #1 moves the binding from the "dormant" state back to the
"active" state, and tunnels any buffered packets to the MN (provided they
aren't old/stale), continuing business as usual for that active binding.

Note that HA #1 will still send DAD probes for MN home addresses that it is
creating a binding for, and should send DAD probes when the MN reregisters
those bindings.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: Vladislav Yasevich [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 8:54 AM
> To: Vijay Devarapalli
> Cc: Ed Remmell; Mobile IPv6 mailling list

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 26 Nov 2002 15:34:38 -0500

Ed

What you are poposing is a fairly large change in the architecture
and I havn't understood all the cases of the change yet.

 From the first glance though, it looks to me like the mobile none
will become a second class citizen when away from home.  I am thinking
of a network that has both stationary and mobile nodes.  Stationary nodes
will always defend their addresses, while mobile nodes loose that
capability when moving away.  A rogue node or anyone using 3041 address
(not necesarily another mobile) may render a mobile node unreachable
by simply sending out a DAD probe.  Without SEND solution, I would argue
that this is very risky change.

That was just my first thought.

Also, as far as 3041 addresses are concerned.  It's perfectly valid
for a mobile to use temporary addresses when at home.  It it wants to
browse the web a temporary address works perfectly fine.

-vlad

Ed Remmell wrote:
>>>>I've run across a potential issue, here is the scenario (I have
>>>
>>no idea how
>>
>>>>to this fix this, it appears to be an MIPv6 architectural issue
>>>
>>affecting
>>
>>>>HAs):
>>>>
>>>>1) MN is operating on foreign network, discovers a set of home
>>>
>>agents using
>>
>>>>DHAAD, successfully registers (S=0, L=1) its set of home
>>>
>>addresses formed
>>
>>>>2) HA #1 performs DAD on the home network for the link-local
>>>
>>address formed
>>
>>>>that IID (i.e. DAD passes for the link-local scope address
>>>
>>formed from the
>>
>>>>3) MN powers down, does NOT save any of this information (i.e.
>>>
>>home agent
>>
>>>>4) MN powers up on foreign network. MN discovers a set of home
>>>
>>agents using
>>
>>>>DHAAD, however this time MN attempts to register its set of
>>>
>>home addresses
>>
>>>>formed from the IID with a different home agent (HA #2) on its
>>>
>>home network.
>>
>>>>Perhaps the HA list it receives in the DHAAD reply specifies a
>>>
>>different HA
>>
>>>>connectivity (i.e. the MN goes through a tunnel temporarily,
>>>
>>i.e. RF null)
>>
>>>>5) HA #2 performs DAD on the home network for the link-local
>>>
>>address formed
>>
>>>>from the IID, HA #1 defends that address (the bindings were
>>
>>created in step
>>
>>>>permanent failure for the MN (at least until the MN is
>>>
>>power-cycled), per
>>
>>>>section 11.7.1:
>>>>
>>>>network, the home agent will reply to the mobile node's
>>>
>>subsequent Binding
>>
>>>>Update with a Binding Acknowledgement containing a Status of
>>>
>>134 (Duplicate
>>
>>>>Address Detection failed).  In this case, the mobile node MUST
>>>
>>NOT attempt
>>
>>>>Note that the lifetime does not have to be infinite, it could
>>>
>>be 2-3 days,
>>
>>>>or even just a few hours and this scenario has a significant
>>>
>>impact on MIPv6
>>
>>>>usability.
>>>>
>>>>Thanks.
>>>>- Ed Remmell
>>>>Elmic Systems, USA
>>>>http://www.elmic.com
>>>
>>>
>>>
>>
>>--

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Nov 2002 22:14:26 +0200

> coordination between HAs on the same home network.

I agree that the case described by Ed can happen. I'm not sure
I agree about the part that the MN is helpless to fix the problem.
MNs that use (a) long lifetimes (b) dynamic HA discovery and (c)
often go to sleep are most prone to this. Therefore, I'd like to
suggest adding a "warning" about this in Section 11.7.1 (Sending
Binding Updates to the Home Agent):

    Mobile nodes that use dynamic home agent address discovery should
    be careful with long lifetimes. If the mobile node loses the knowledge
    of its binding with a specific home agent, registering a new binding
    with another home agent may be impossible as the previous home agent
    is still defending the existing address. Therefore, mobile nodes
    that use home agent address discovery SHOULD ensure information
    about their bindings is not lost, de-register before losing this
    information, or use small lifetimes.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Nov 2002 22:31:09 +0200

> will become a second class citizen when away from home.  I am thinking

Ah, I responded on the original issue before seeing Ed's proposed
solution.

But I have to agree with Vlad; the proposal has its own problems as
well. I think it is sufficient for us to add the text I proposed
in my previous e-mail. (In the long term HA-to-HA sync protocol
might solve this better along a number of other things.)

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 26 Nov 2002 14:54:17 -0700

Jari -

sigh...

OK. I guess if you can't really change it to make it easier on the MN, at
least you can document the potential pitfalls better. It really appears like
it is a hard requirement for a MN implementation to maintain at least some
of this information (i.e. registration state, address of last HA registered
with) in NVRAM.

What we proposed actually does work quite well for globally unique interface
IDs (L=1). I think it is OK for optimization purposes to treat L=1
differently from L=0, since after all globally unique interface IDs are very
different from RFC-3041 randomly chosen interface IDs. The idea of a slick
low-to-no-latency "returning to home" MN algorithm (even if it is just for
the L=1 case) is very enticing/exciting for us, because the current
algorithm is difficult (and won't work well at all, if lot of this state
information isn't stored by the MN in NVRAM just in case it is powered off
before it returns home - even then, the current algorithm is very clunky and
has a number of hacks to normal IPv6 and Neighbor Discovery operation to get
it to work).

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 1:31 PM
> To: Vladislav Yasevich
> Cc: Ed Remmell; Vijay Devarapalli; Jason Schmidlapp; Bryan Xiangqian
> Wang; Mobile IPv6 mailling list
> Subject: Re: solution for: [mobile-ip] potential registration conflict
> when mutiple HAs on home network
>
>