Subject: RE: [mobile-ip] Resolution for issue #198

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jan 2003 09:09:48 -0000

There's still the question of the lost state. If the MN lost the HA
address (only has home prefix coded in), then upon the DAD failure, it
has to figure out whether this is a HA that it binded with in some past,
or a real duplication. Hopefully it's a HA so the optimistic behavior is
to send a bind update to deregister, and retry DAD afterwards. But then
what are the source/dest IPv6 addresses in the bind updates?

Suggestion 1) source is unspecified, target is home anycast, MAC layer
dest is LLA from DAD, no ACK.
Suggestion 2) source is unspecified, target is MN home address, MAC
layer dest is LLA from DAD, no ACK.
Suggestion 3) source is MN home address, target is MN home address, MAC
layer dest is LLA from DAD, ACK. The HA detects the duplication. Since
the duplication is associated with the deregistration, it removes the
address from its interface and gets rid of the binding cache. HA
installs the neighbor with the source LLA and the MN home address in the
ND cache as STALE and responds to the BU.

When the MN remembers the HA home address, there's still the question of
the source. I suspect the intent is:
Suggestion 4) source is MN home address, target is HA address, MAC layer
dest is LLA from DAD, ACK. The HA detects the duplication. Since the
duplication is associated with the deregistration, it removes the
address from its interface and gets rid of the binding cache. HA
installs the neighbor with the source LLA and the MN home address in the
ND cache as STALE and responds to the BU.

There's still the angle to prevent the problem so you do not need to fix
it:

Suggestion 0) Upon DAD on a MN home address that it defends, the HA
clears its binding cache right away and removes the address from its
interface. This covers the case where the MN lost its states, whether
it's at home or not. Whether the DAD comes from a different HA that the
remote MN now binds with, or whether it comes from the MN coming back
home, the DAD and the intended operation succeeds, as opposed to failing
for the wrong reasons.

You realize that my own taste goes to suggestion 0 :) I tried to sketch
how it works in more details in a previous mail. To save you the burden
to look it up, here's the excerpt from that mail:

"
version c) In the other hand, we may want to dig a bit deeper into DAD
and its purposes... As far as I understand it, DAD is intended to
preserve the address ownership to the node that has it assigned, as
opposed to newcomers autoconfiguring it, in order to preserve active
connections and application states. Now, in the case of MIP, is that
really what we want? The HA is not terminating any connection, and
denying the MN its own address actually breaks the active connections.
Also, a real case of duplicate address (misconfiguration) should be less
frequent than simple homecomings, shouldn't it?

If we are ready to tweak ND (we're doing it already with the new
proposal, right?), then maybe we could revisit the above rules for our
case.

Somehow, in MIP, the home address of the MN is "less then assigned" on
the HA after BU, and "more than tentative" on the MN since boot. A first
try to give semantics to these states:

"less then assigned": successfully performed DAD from tentative state.
Accepting unicast packets on that address. Node responds to DAD as if
the address was tentative and to address resolution as if it was
assigned. Override bit is never set. For a HA, a DAD coming from a
different node also causes a Binding cache cleanup for that address.

"more than tentative": node performs ND as if address was assigned. If
no NA is received from a different node for that address for a period of
time, the address goes assigned. Otherwise, drop the address as if DAD
failed.

Version c allows the MN to come back up faster and with less control
traffic. The proposal is in early stage, to test if it actually gets
some support, in which case we could refine...

"

> -----Original Message-----
> From: gabriel montenegro [mailto:[email-masked]] 
> Sent: mercredi 22 janvier 2003 01:56
> To: Ville Nuorvala
> Cc: Pascal Thubert (pthubert); Francis Dupont; Mobile IP Working Group
> Subject: Re: [mobile-ip] Resolution for issue #198
> 
> 
> Sure sounds like it'll work much better than previous 
> alternatives. The good news is that we now have 2 weeks or so 
> in which to really think it over and make sure this does work 
> (as it seems at first sight).
> 
> -gabriel
> 
> Ville Nuorvala wrote:
> > On Tue, 21 Jan 2003, Pascal Thubert (pthubert) wrote:
> > 
> > 
> >>Hi Ville,
> >>
> >>Note that the MN DAD'ing its own home address as opposed to 
> the HA's 
> >>also gets him the LLA of the HA, with no change in ND, and with the 
> >>additional value of checking the home address for a real 
> duplication.
> > 
> > 
> > Hey really, couldn't you come up with this yesterday? ;)
> > 
> > 
> >>There must be a reason why we did not do that way, but I cannot see 
> >>which one ???
> > 
> > 
> > I haven't at least been able to find any problems in your solution 
> > with my somewhat limited knowledge.
> > 
> > The simplest and most elegant solutions are often right before our 
> > eyes. All it takes is someone to notice them, I guess. :)
> 
>

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 22 Jan 2003 10:59:43 +0100

Pascal Thubert (pthubert) wrote:
> or a real duplication. 

I think this is the crux of the problem: we're overloading DAD
with new semantics. Totally ignoring politics and turf
jurisdictions for a moment (yes, Francis may have a point here),
the sensible thing is to always be very explicit about what you're doing.

So in the interest of avoiding ambiguity, perhaps we should
just own up to the fact that what the MN does when coming
back home is not DAD, but BED (binding entry detection).
And make sure a BED can't be confused for a DAD or anything else.

BED is not DAD. It's not better or worse. It doesn't replace
it, both have a time and a place. So for example, ICMP code=1 could be used
to effect this clear distinction on a packet otherwise equivalent
to the MN's DAD on its home address, with a similar code in the
HA's response. It would also aid monitoring the link for
sanity, etc.

Would this perhaps avoid the need for adding more states to address
configuration as you suggest?

-gabriel

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Jan 2003 11:25:02 +0100

=> you need security so the destination must be the HA address on the
home link (or you have to use routing headers :-). And the BA should
be received (so the MN home address should work). The last point
is that IPv6 and MAC must be either both multicast or both unicast.

=> s/target/destination/g

=> what is the "ACK"?

   

=> I am afraid this has a trivial DoS problem.

Regards

[email-masked]

---

From: Ville Nuorvala <[email-masked]>
Date: Wed, 22 Jan 2003 14:14:18 +0200 (EET)

> has to figure out whether this is a HA that it binded with in some past,

For a proxied address the Override flag SHOULD be set to zero in the NA.
If we can rely on all implementations doing this, we could probably use
this as a clue to the nature of the DAD failure.

> But then what are the source/dest IPv6 addresses in the bind updates?

How about if we have the HA reply to the DAD with the same home agent
address originally used by the MN for its home registration? If this
address is inserted into the source address field of the proxy NA, the MN
could extract both the LLA and the IPv6 address of the HA from it. This
way the MN would always have all the addresses it needs to deregister with
the old HA.

Actually, if we extrapolate a bit, we might have a HA-to-HA sync protocol
Jari mentioned in issue 172!

If the MN's HoA is already protected by another HA, the new HA could
actually record the source address from the proxy NA it receives.

It could then check the address against its Home Agents list to make sure
the sender is a HA. If the sender is a HA its address could be sent as a
suboption in its DAD failed ACK message to the MN.

With the help of this, the MN could then try to deregister with its old HA
before re-registering either with it or the new HA.

I'm not a security expert so I don't know if there are any IPSec/IKE
related problems with this, but perhaps someone with better knowledge in
this area could comment?

Just a thought...

Ville

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Jan 2003 11:08:14 -0800

"Pascal Thubert (pthubert)" wrote:
> address (only has home prefix coded in), 

it has the prefix stored, but lost the HA information? 
come on.....

> then upon the DAD failure, it

BUs from MN to HA have to have HoA and HA's address. IPsec SPD
uses these addresses and the HA drops unauthenticated BUs.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jan 2003 08:01:32 +0100 (CET)

> And make sure a BED can't be confused for a DAD or anything else.

Are you assuming that the MN knows whether it is on the home link
before sending the DAD or BED? Seems like it must since it would
only do BED on the home link.

This seems to require that the MN always does a RS and wait for enough RAs
to tell whether or not it is on the home link, before it can do DAD or BED.
Do we want that additional delay, or do folks want to do the RS and DAD
in parallel?

  Erik

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 24 Jan 2003 03:04:24 +0100

> only do BED on the home link.

I am assuming this question has been answered already. All
I'm suggesting is that whenever draft 20 says that the
MN does this funky DAD operation, that it be replaced by
this funky BED operation.

As to when either the funky DAD happens,
this is already specified in section 11.5.4
(upon returning home if it ignores the LL address of its
HA). And the way it detects if it is at home
is already specified as well (section 11.5.1, movement
detection).

> to tell whether or not it is on the home link, before it can do DAD or BED.

This is what the draft says, yes, a serial operation.

> Do we want that additional delay, or do folks want to do the RS and DAD

We know what the draft already says. Are you proposing to open a new
last call issue on whether movement detection to detect if the
MN has reached home should be deserialized and run in
parallel with the DAD/BED? This would optimize moving back
home. But since this is probably not the most common movement,
why bother?

Not sure we need to go there. Nevertheless, it does not seem
like sending out extraneous funky DAD's or BED's will do any harm
at the non-home link (besides a little extra traffic).
They'll just fail to elicit a response.

-gabriel

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 25 Jan 2003 06:26:30 +0100 (CET)

> home. But since this is probably not the most common movement,

My point is that since you don't know that you've moved home until
you've run movement detection and received at least one RA,
then for *all movements* you need to defer the DAD until after receiving
at least one RA. 
Thus the serialization will happen for all movements
in order to handle the rare event of moving home.

	Send RS
	Wait for RA
	Are we on home link?
		Send funky DAD or BED
	else
		Send regular DAD

Or am I missing something?

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Sat, 25 Jan 2003 08:57:32 +0200 (EET)

> Or am I missing something?

There seems to be a problem in above.  Sending RS requires the use of the
link-local address, which could create DAD clash.  So it seems one must
wait for a unsolicited RA, right?

Doesn't seem like the best way forward to me..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Francis Dupont <[email-masked]>
Date: Sat, 25 Jan 2003 16:07:10 +0100

There seems to be a problem in above.  Sending RS requires the use of the
   link-local address, which could create DAD clash.

=> no, a RS can be sent from the unspecified address (useful for RS and
DAD (and MLD registration) in parallel in regular IPv6).

   So it seems one must wait for a unsolicited RA, right?
   
=> no!

---

From: Pekka Savola <[email-masked]>
Date: Sat, 25 Jan 2003 17:11:58 +0200 (EET)

> DAD (and MLD registration) in parallel in regular IPv6).

Ah, yes, sorry.. it just must not have the SLLA option.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Jan 2003 10:21:01 -0800

> in order to handle the rare event of moving home.

isnt this true already? a mobile node cant configure a 
CoA till it gets an RA for that link. so DAD for CoA 
can be started only after receiving the RA.

Vijay