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

[Henrik Levkowetz <henrik@levkowetz.com>]

Hi,

	I pretty much agree to what Pete's said below. With respect
to making this a workgroup item (co-chair hat off), I've got two 
possibly conflicting comments. (I'll expand on these in follow-up
mails):

	1) We've had some very recent discussions in the office about
	this, and will be implementing the current proposal (due to
	customer demand), but with the expectation that the mechanism
	will change, and also with the addition of a vendor-specific
	extension we see is needed. This is to some extent in favour
	of making this a workgroup item, to get standardisation.


	2) I have concerns with the routing in this proposal - RRQ's
	being answered by a different HA than the one they were directed
	to seems to break more than one current mechanism, and open
	up security issues (as mentioned by Pete below). One mechanism
	which Pete doesn't mention, which may also be broken by this
	changed routing is NAT traversal, which is crucial in practical
	deployment today. This indicates quite strongly that we need to
	develop and possibly change this proposal quite materially
	before making it a workgroup item.

Having these two quite contrary viewpoints, I'd like to propose a way
forward, too:

Having participated on the EAP list to some extent the last half year
or so, as editor of the revised EAP specification (rfc2284bis) I have
seen one possible way to work which has been used quite profitably
there: Worthwhile drafts which are within the charter are discussed and 
developed on the list, with formalized issue tracking and everything, 
but only made formal workgroup items when they appear reasonably mature.

The eap drafts in this category today are respectively in version -03,
-04 and -07. This is a way forward where drafts get some further time to
show whether they have support from the list in general, get more
stability, have possibly major changes worked out etc, before the WG
commits to bringing them forward as standards. Maybe this is a model to
consider here too?

	Henrik


Friday 29 August 2003, Pete wrote:
> 
> 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

Attachment: pgp00007.pgp
Description: PGP signature