Subject: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as Workgroup Item?

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 10 Aug 2003 07:02:59 +0200

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

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Pete McCann <[email-masked]>
Date: Thu, 14 Aug 2003 16:44:24 -0500

Hi,

 > as a workgroup item. Any objections?

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

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:

        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.

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

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.

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

---

From: Kuntal Chowdhury <[email-masked]>
Date: Thu, 14 Aug 2003 18:26:20 -0500

> destination IP address) is set to 0.0.0.0 or 255.255.255.255.

The MN does not know the HA's address to begin with. Therefore the FA needs to 
figure out (R=1 case) which directed HA to relay the RRQ. The draft talks about 
how the FA discovers the "unicast" address to put in the destination of the IP 
packet. This is also an important aspect of the draft.

>     message can be sent; and, 

I think the draft talks about this part in 5.4.

> (2) the MN must develop a security association with that HA.

The MN has an SA with the home network: is a valid assumption. I don't think we 
need to pick a particular mechanism to establish SA between the MN and the HA in 
a framework document.

> main thrust of the draft seems to be at the next requirement listed in

My reading of the draft is somewhat different. I think the above paragraph in 
the abstract clearly states that assignment of an HA in the close proximity of 
the MN is the main motivation for dynamic HA assignment. If dynamic HA 
assignment addresses RO for MIPv4, then we should go for it. However, I think 
the draft lacks details on how this location aware HA assignment scheme works 
without any location info exchange.

>         locality, such as administrative policies, load balancing etc.

I think load balancing is an important motivation for dynamic HA assignment. I 
would say that the draft lacks details on this significant motivation.

> framework (due to the large amount of unspecified work left to do).

I agree that this draft leaves too many things unspecified. We should identify 
those areas for improvement and add necessary details.

> will defer additional security comments until it comes out.

The above sentence is an example. It does not mandate anything. No harm keeping it.

> instead of a forwarding mechanism?

I don't think we should attempt to link this draft with AAA-keys and MIPv4 
Diameter at all, it is irrelevant.
Regarding load balancing, the draft does not emphasize much about it. I believe 
the draft should have a section on load balancing aspect as well.

-Kuntal

---

From: Milind Kulkarni <[email-masked]>
Date: Wed, 27 Aug 2003 12:11:59 -0700

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

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

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

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

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

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

> 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

---

From: Pete McCann <[email-masked]>
Date: Fri, 29 Aug 2003 13:54:48 -0500

Hi, Milind,

Milind Kulkarni writes:
 > 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

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.

 > redirection and the first HA to receive the RRQ can accept and

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

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

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

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

 > defer the discussion on SAs. I will send the new version to the

Ok, I look forward to it.

 > 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

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 30 Aug 2003 12:14:27 +0200

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