Subject: [mobile-ip] Re: ID on MIPv4 DHA

From: Milind Kulkarni <[email-masked]>
Date: Fri, 07 Feb 2003 11:09:41 -0800

Kuntal,

Thanks for your mail. We have exchanged many mails in private 
and we realized that the WG community may have similar questions. 
So it's probably beneficial to keep the everybody in the loop, 
hence moving this thread to the WG.

Just to reiterate, the framework is flexible and less stringent.  
It allows all existing dynamic HA assignment mechanisms to work,
and keeps room for future implementations. In essence, all the
framework is doing is to allow the RRQ to be responded to by
a different HA. See inline for more....

Kuntal Chowdhury wrote:
> 
> Hi Milind,
> Please see inline...
> 
> Milind Kulkarni wrote:
> > Kuntal,
> >
> > Thanks for detailed explanation. Now I understand what you are
> > saying. To put it simply, I disagree with new requirement you
> > are proposing in the framework. We can look at this in multiple
> > ways.
> >
> 
> Glad that you understood the scenario.
> 
> > First, as you noted, the MN can be dumb and will use the
> > Directed HA address from the earlier session. There are many
> > things to consider here. In reality, MNs are very smart devices.
> > If the MN gets "HA unreachable" it will switch to dynamic HA
> > assignment right away.
> >
> 
> We don't make MNs, I believe neither does Cisco. So, I cannot claim that all MNs
> are smart. If you think about today's MNs, they are not designed for dynamic HA
> request (all-zero-one-Address). Hence, all of them are dumb with respect to
> dynamic HA assignment framework. My proposal actually takes care of these legacy
> MNs, so that they would still get service when their statically provisioned HAs
> fail.

Even without the framework, the MNs will lose their connectivity if
their statically provisioned HAs fail. The scenario you are describing
exists even today.

> 
> > Second, even if the MN does incur 2 RRQ transactions, what is
> > the practical impact on the session? I understand the theoretical
> > impact of an extra round trip, but how is it different than, say,
> > the MN-HA clocks not being in sync? It will have to retry the
> > RRQ, so it's not bad.
> >
> 
> The primary purpose of the dynamic HA framework that you an I are discussing
> here is to avoid multiple MIP registration transactions. Note that the second
> transaction is only successful with intelligent future MNs that can switch to
> all-zero-one config, the legacy MNs cannot. IMO, we are not trying to solve all
> multiple transaction issues in MIP (e.g. the clock out sync error that you point
> out).

IMHO you seem to be mixing the issues. Your original concern was that
the MN has cached it's Assigned HA address, and uses for next session.
If the Assigned HA failed, MN has to retry, that was the issue. Now
if MN cached Assigned HA address, it means the MN is new implementation
using the framework. But your para above is contradicting it by stating
that it is legacy MN.

> 
> > Third, since we are talking about potential failures, the
> > Assigned HA can fail midway in the Mobile IP session too. Now
> > what can the MN, FA or the Directed HA do? Probably nothing.
> > The session will terminate, unless the Assigned HA has redundancy.
> > FA querying the Assigned HA reachability doesn't help in this
> > case either.
> >
> 
> If the assigned HA fails in the middle of the MIP session, the MN is out of
> luck. It will have to register with a new HA to continue. Albeit, if the
> assigned HA has a hot-stand-by then, it will be OK. The reachability check at
> the FA can be done only when there is no existing mobility binding for the MN
> (registration pending), not during re-registrations.
> 
> > Suppose, we were to adopt the new behavior you are proposing in
> > the framework, how do we address the security considerations?
> > How do we authenticate the DNS/AAA/DHCP responses at FA? Any
> > router can respond to the FA query, diverting the traffic to
> > wrong destination. To secure those, we need some extra mechanism.
> >
> 
> I thought the entire dynamic HA framework in your draft is based on an evenly
> distributed MN-HA, FA-HA SA. If not, then key distribution is another challenge.
> Therefore we have to make sure the RRQ with a particular MN-HA authenticator and
> FA-HA authenticator has to work with any HA in the home domain. If this is not
> the case, then perhaps I am missing something. We may need to talk on this issue.
> 
> > Moreover, what we are trying to fix with your suggestion is
> > something that exists in the Mobile IP even today. Assuming HA
> > and FAs are in same administrative domain (that's one more
> > case to consider, which I didn't elaborate), the HA does not
> > notify all the FAs about other alternative HA.
> >
> 
> I don't understand this scenario, especially the last sentence.

What you are describing exists even today in Mobile IP, regardless
of dynamic HA assignment. If HA is going down/or fails, there is
no mechanism to notify the FAs in the network that it is unreachable. 
That mechanism is not built in the base protocol.
 
> 
> > Don't get me wrong, I completely agree that your suggestion
> > is trying to add more robustness to the solution. However, at
> > what cost? Robustness is a whole new ocean to go into. So should
> > we mandate all of that? I would much rather have one more RRQ
> > fix that.
> >
> 
> Yes, this is adding more robustness to the scheme, and I don't believe 
> the cost we pay for this is too high.

As earlier comment, this is something that even the base protocol does
not have. Your suggestion is not very different from the BUs in 
Mobile IPv6, except here the FA need to notified about HA failure.
Hence it is not something that needs to exist in the dynamic HA
assignment.
Your robustness concerns are definitely valid, but constitute to 
infrastructure changes that the base protocol needs to consider, and 
not by the dynamic HA assignment scheme. 

Practically, the draft leaves the MN implementation open by saying
that the MN *MAY* cache the Assigned HA address across Mobile IP 
sessions. It may or may not do that. So your original issue (of MN
should
not cache Assigned HA address) is allowed anyway.

Thanks,
Milind

> 
> > What do you think?
> >
> > Thanks for a great dialogue,
> 
> Thanks for having this dialogue with me.
> 
> -Kuntal