Re: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as WorkgroupItem?

[Milind Kulkarni <mkulkarn@cisco.com>]

Hi Pete,

Sorry for the delay. Kuntal has already answered most of the
concerns. Before we go into the details of  the draft, the
motivation for the draft is:

- To get assigned with an "optimized" home agent for a given MN.

- The definition of "optmized" home agent is left to suit the
  various deployments. That is because we want to keep the
  mechanism generic, so that it can accommodate different
  requirements.
  For example, one deployment may want to select nearest
  geographical HA, while another may choose to select the
  HA that is cheaper (in terms of money) to go to. Some
  other deployment may want to choose an HA based on certain
  time of the day, and so on. There can be many variations.

- To propose a mechanism that is generic, open for accommodating
  various requirements and should work with any existing
  infrastructure such as AAA etc.

- The MIP v6 group also considers this as a problem, and was
  presented in Vienna IETF as part of Thoughts on
  Bootstrapping Mobility.

More inline.....


Pete McCann wrote:
> Hi,
>
> Henrik Levkowetz writes:
>  > 
>  > One of the charter items of the mip4 working group is dynamic HA 
>  > assignment. The document draft-kulkarni-mobileip-dynamic-assignment-01.txt 
>  > proposes a mechanism for doing this at registration time. We would now 
>  > like to confirm with the working group that this document should be
>  > made the basis of registration time HA assignment, and moved forward
>  > as a workgroup item. Any objections?
>  > 
>  > 	The chairs
>
> [chair hat off for a moment]
>
> I wanted to offer some of my own comments on this draft - I hope
> others will read it closely and comment as well.
>
>
> At a high level, what this draft does is allow one HA to redirect a
> registration request to a different HA, when the HA field (not the
> destination IP address) is set to 0.0.0.0 or 255.255.255.255.
One of the key points of the draft is that it allows the RRQ to be
responded to by a dynamically assigned home agent.

Various metrics and mechanisms can be used to assign the HA
intelligently. We are not suggesting or enforcing any specific
mechanism. Using the same logic, there may not be any further
redirection and the first HA to receive the RRQ can accept and
create binding.

> My main concern with this draft is that there is a lot left
> unspecified (just look for all the occurrences of "outside the scope")
> and some of these unspecified procedures are actually quite
> important.  For example, the abstract says:
Since the draft specifies a framework (or a structure or a front
end mechanism, whatever we call it), in our opinion it should
be open and satfisy as many requirements. As mentioned earlier,
we want various implementors to define their own "optimal"
behavior rather than forcing what we think is optimal.
Hence the details on how to get to ones optimal HA is left
out of scope. The draft says this in sections 1, 5.5. However
the mulitple occurrences of the text "out of scope" are due to
repeatition of same text so that each section is self sufficient.
It can be removed in next rev.


>         The distance between a
>         MN and HA affects the latency for control and data traffic.
>         When the distance between the MN and HA is large, the resulting
>         latency may be unacceptable. Therefore, it is advantageous to
>         select a nearest HA to the MN during initial registration.  
>         
> The mechanism outlined in the draft doesn't seem to satisfy this
> requirement.  This is because "Directed" HA must be a-priori
> configured with the "Assigned" HA IP address, which implies they would
> be in the same domain.  So, the real meat of the above requirement is
> that:
>
> (1) the MN (or the FA) must somehow discover a local HA to which the
>     message can be sent; and, 
> (2) the MN must develop a security association with that HA.
>
> Both of these procedures are ruled explicitly outside the scope of the
> draft.  Note that I think (1) or (2) can be met with procedures that
> don't require any notion of "Directed" or "Assigned" HA.  Rather, the
> main thrust of the draft seems to be at the next requirement listed in
> the abstract:
>
>         There are other reasons for assigning an optimal HA beyond just
>         locality, such as administrative policies, load balancing etc.
Right, the framework tries to provide a sort of tool that can satisfy
more that one requirement. I am not sure why that's not ok.


> The abstract goes on to state:
>
>         This draft proposes a generic lightweight dynamic home agent
>         assignment framework. The goal of the framework is to provide a
>         mechanism to assign an optimal HA for a Mobile IP session while
>         allowing any suitable method for HA assignment. 
> At best, this draft is really defining some front-end behavior
> (message formats and Mobile IP processing) that would enable dynamic
> home agent assignment, but I wouldn't go so far as to call it a
> framework (due to the large amount of unspecified work left to do).
If the term "framework" isn't appealing, can you suggest appropriate
alternative? The reason for terming as such is because it incorporates
(i) the ability to allow the RRQ to be responded to by dyn HA and
(ii) logical separation of 2 addresses viz. Directed HA address and
Assigned HA address. The Directed HA and Assigned HA are merely
logical entities and dealt extensively in section 5.3, 5.4 and 5.5.

We do not want to suggest a specific mechanism e.g. AAA, DNS etc.
and tie it specifically tp form a solution as we envision that it
is deployment specific.  Thus we are providing a generic framework/
front end mechanism within MoObile IP to allow that.

> The draft also assumes that the assigned HA will be able to verify the
> authentication extensions in the redirected RRQ.  In section 5.1 the
> draft states:
>
>         Example of one such implementation is where MN
>         shares identical security associations with all the Directed
>         HA(s) and Assigned HA(s) in the network. 
> I consider this to be completely unacceptable security practice and I
> think this statement should be removed from the draft.  Rather, it
> seems like this method will only work with something like the MN-AAA
> extension that can be verified from one of many HAs in the network,
> and that a security association MUST be developed dynamically along
> the lines of the AAA-keys draft.  I think limitations like this should
> be described in the security considerations.  I understand a new
> version with expanded security considerations is in preparation; I
> will defer additional security comments until it comes out.
Since this section is updated in latest version of the draft, let's
defer the discussion on SAs. I will send the new version to the
WG soon.


> So, I think the draft may be valuable in that it specifies the
> front-end behavior necessary to enable AAA-keys and the MIPv4 Diameter
> application.  This is similar to the way the NAI and MN-AAA draft
> specify front-end behavior, while leaving the actual authentication to
> AAA mechanisms specified elsewhere.  However, this draft seems to
> sneak in some additional HA redirection functionality (purely for load
> balancing) that I am not convinced is required at this time.  
I respectfully disagree, load balancing may not be needed
immediately, but is a valid requirement and the logical separation
of assigned HA and directed HA address solves it too.

Load balancing is one example where dynamic HA framework is useful. 
There is no intention to 'sneak' in a solution. THis is a real
problem for large deployment with 'millions' of subscribers as is
starting to happen with 3G deployment.

On the contrary, the way we see it is, this draft adds a lot of
practical value to the MN-AAA key distribution draft. With that
draft, the SA are dynamically derived with an HA, but how is the
HA found. If an 'optimal' HA is dynamically found, then that
draft can be used to set up SAs.

Thanks,
Milind


> I would
> like to hear the opinions of others in the WG on whether this is
> important enough to include in the current draft - perhaps it could
> best be addressed with a separate draft, using a Rejection code
> instead of a forwarding mechanism?
>
>
> -Pete
>
>
> _______________________________________________
> Mip4 mailing list
> Mip4@ietf.org
> https://www.ietf.org/mailman/listinfo/mip4


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4