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

[Pete McCann <mccap@lucent.com>]

Hi, Milind,

Milind Kulkarni writes:
 > Hi Pete,
 > 
 > Sorry for the delay.

No problem - sorry this note is delayed a couple of days as well.

 > Kuntal has already answered most of the
 > concerns.

Hmm... I think we have a slightly different reading of his note.

 > 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.

I agree with the above goals; however, I think you may have combined
two separable mechanisms unnecessarily, and I have a couple of issues
with each.

 > 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.

I agree with this statement, and I am not proposing that we add
selection mechanisms or criteria to the draft.

 > > 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.

I don't think it needs to be removed everywhere (it is appropriate in
some places).  See below...

 > >         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.

Let me try to rephrase my issue: there are many lines of text in the
draft devoted to the forwarding registration requests from Directed HA
to Assigned HA.  In fact, I would have to say this mechanism is the
main new *protocol* that is specified by this draft.  However, this
mechanism seems targeted at the second motivation, rather than the
first.

Personally, I would have written this draft with more of a focus on
the way an MN sends the RRQ to an FA, and the FA picks an HA.  Sure,
the actual choice is outside the scope, but you could mention, e.g.,
consultation of a AAA infrastructure, and/or looking at the HA address
in the RRQ to determine local vs. home network.  Also, I think this
should only be allowed when the MN uses an authorization enabling
extension that can be verified from multiple different points in the
network, such as MN-AAA (i.e., MN-HA MUST NOT be used with this
mechanism).  It can only be used when registering via an FA.  Also, a
new security association MUST be created along with the registration.
Taken together, these sorts of changes would go a long way to
satisfying the first stated goal, which is allocation of a
local/remote HA for assisting with more optimal routing.

 > > 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.

I like the term "front end mechanism" better than "framework."  This
draft really describes only the Mobile IP processing, while leaving a
lot to back-end infrastructure.  The term "framework" implies
something more complete.

 > > 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.

Ok, I look forward to it.

 > > 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.

I do see value in load balancing, but I wonder if it could be
addressed separately.  For example, we could have a rejection code
that specified a new HA.

Upon further consideration, I have a number of new technical questions
about the mechanism of forwarding a registration request from one HA
to another:

1) It doesn't appear to work when using co-located COA when
   registering via an FA.  In this case, the COA in the RRQ does NOT
   indicate where to send a response.  Your mechanism seems to depend
   on this, because it over-writes the original source IP address of 
   the packet.

2) It seems to open a security vulnerability, because an FA must now
   process any response that comes from anywhere with a matching
   Identifier.  If it is a rejection, the FA will delete the pending
   visitor list entry.  This could allow attackers to deny service when the MN
   tries to register.  Previously, we could argue that deployment of
   ingress filtering alleviated this concern.  Note that an FA often does
   not have a security association to every HA with which it will interact.
 
3) Can we guarantee that the routing of RRQs among HAs will be
   loop-free?

In contrast, a rejection code would not introduce the new security
concerns, because we keep the existing Mobile IP message flow.  The MN
would need to create/obtain security associations with each HA
independently (i.e., security would be orthogonal to the dynamic
assignment).  Finally, the MN would have the ability to detect
misconfigured HAs that were pointing at each other because it would
see each redirection on an end-to-end basis.

-Pete
 

 > 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