Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)

From: "Tom K. Weckström" <[email-masked]>
Date: Sat, 28 Oct 2000 22:42:40 +0300

Hi Annik and WG.

My comments to Annikas first reply, which I somehow managed not to
receive.
Thanks Annika for resending it to me.

Annika Jonsson wrote:
> >>Ch 3.1
> >>? Is there a possibility to make a HA hierarchy as well?
> >>  If not, why then?
> >>--> Possibly another draft. Could be derived from J.K.Malinen's
> >>thesis.
> >>
> >
> >Sure it is, it was included in one of the predecessors to this draft. We
> felt it would be easier to handle it in separate drafts, and we think the
> hierarchical FA:s are more important.

Agreed. This could be handled in another draft. There could also be a
draft about using private addresses in FAs and HAs in the hierarchies
and a solution for allowing duplicate private home addresses for MNs
from different home organizations. These are all solved in Jouni
Malinen's thesis from March/2000. Check it from Dynamics web site (in
signature).

> >>3.1.1.
> >>? Why only assume two levels of FAs in the visited domain?
> >>
> >
> It's mainly for pedagogic reasons. It makes the description of the
> protocol easier and clearer, and also we think that is an important
> scenario. In this way we first describe the basics of the protocol, and
> then add the multiple level hierarchies.

Annika, I have to disagree. Simplifying issues in design may result in
a solution that can not be easily extended - at least not without
breaking backwards compatibility.

Additionally, a 2-level case is just an exception in a hierarchical
environment. I claim one needs to have at least a 3-level example to
demonstrate the different kind of scenarios of regional registrations.
        1. GFA handling the registration (also in 2-level case)
        2. Lowest FA handling the registration (also in 2-level case)
        3. Some intermediate FA handling the registration
           (NOT in the 2-level case)
           Here "intermediate" means any FA between lowest FA and GFA.

So, please improve the draft to handle N-level hierarchies as simply
as 2-level hierarhies, and demonstrate at least the three above
mentioned examples in the draft.

My suggestion is to leave Appendix B to more advanced hierarhcy
discussions if necessary and to include N-level aspect to the actrual
chapters.

> >>3.4.1.
> >>? This makes the possible topologies more cumbersome.
> >>---> Eg. GFA1, ..., GFA4 are all connected to RFA1 and RFA2 and RFA3
> >>and RFA4.
> >>? Why is this needed? For load balancing type of activities?
> >>
> >
> >Yes, we wanted to allow this kind of topology. It can be used for e.g.
> load balancing, or, it could be that an MN should use a specific GFA for
> different reasons.

Ok. Good. No objections on that. :-)

> >>? Does the possibility to set GFA address to zero in the request open
> >>new holes in the security?  E.g. Mallory acts as an additional GFA in
> >>the hierarchy and captures MN's reg.reg. coming from RFA1. This gives
> >>a possibility to intrude as a GFA into MIP signaling. However,
> >>additional bonuses are few. And eventually Mallory could set up his
> >>own ISP.
> >>
> >
> >No, when the reply comes back to the RFA, the FA-FA auth. will fail in
> that case.

You are right.

> >>3.4.2.
> >>
> >>" If the care-of address field is set to zero, the foreign agent
> >>   assigns a GFA to the mobile node, by some means not described in
> >>   this specification, and adds a GFA IP Address extension to the
> >>   Registration Request message."
> >>
> >>? RFA selects the GFA? RFA has no knowledge of GFA conditions (load,
> >>etc.). How could an RFA make the decision? This could be solved with
> >>the topology or by other means, but involves more protocol
> >>intelligence anyway and whence adds to complexity.
> >>
> >
> >We specificaly said: "by some means not described in this specification".
> It's  not necessarily the RFA that decides, but it must have some way of
> finding out which GFA to use, of course.

Please be careful. If some sort of support for this is build to MN
according to the draft/becoming RFC but the mechanism is not in place
for selecting GFA, what will happen then? Have you already planned an
registration erro message for that? ;) Something like: "Feature not
supported".

> >>B.2.
(quotation deleted, see draft, Chapt B.2.)

> >>? So, if the FA hierarchy is not revealed in the advertisements, then
> >>the regional registrations always go to the GFA?

> No. See your quotation above, the first RFA that recognises the MN replies
> (unless the lifetime has expired). This is regardless of whether
> hierarchies are advertised or not.

How do you assure that the bindings in the FA hierarchy remain
consistent when regional registrations are performed in the
"intermediate FAs"?

I read about the reg.reply with zero lifetime down to the "old" FA of
the MN (and the FAs residing on the path between the "old FA" and the
"intermediate FA"). As I told, we called this a "tear down" message
back in Dynamics 0.5 a year ago, but the solution has a race condition
that makes the state of the FA hierarchy inconsistent when packets are
lost and results in severe problems. This is why I recommended the
"previous FA NAI" extension approach that tackles the problem. More
info from Jouni's thesis, or I can explain the solution if desired.

> >Thanks for your feedback!
Thanks, it is great to be able to give the feedback and possibly
improve the becoming RFC. :-)

Best regards,
                Tom

--
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                [email-masked]

http://www.cs.hut.fi/Research/Dynamics/

---

From: Satwant Kaur <[email-masked]>
Date: Sat, 28 Oct 2000 23:34:18 -0500

Hi Annika, Tom and WG,

In this email I would like to comment on Tom's suggestion regarding number
of levels of FA in the hierarchy.

I understand what Tom has said about having a minimal number of 3 levels for
a base case of Hierarchical FA, namely GFA, intermediate FA, lowest FA. I
can see that GFA is unique in the sense it is the only agent in Foreign
Domain that talks to HA directly, and lowest FA is unique in the sense that
it the only Agent that talks to MN directly. Thus intermediate FA is a
different entity from both of these since its role is to pass on
registration reply/requests to other and open up and build tunnels. And so
you want to start with a 3 level scenario of one intermediate FA that can be
scaled up by just adding more of intermediate FA's.

I had initially thought that way too. But, I want to share what I have
started seeing as I am in the process of implementing the roles for these
agents. Please feel free to point whatever mistakes I may have made in my
understanding:

In RFC 2002, we had just two Agents, one in Home network and one in Foreign
Network, namely HA and FA, one the transmitter and other the receiver
(depending on the direction the packets are going). We needed at least two
because we want one of our Agents at both link layer endpoints, HA to grab
the packets meant for the MN at link layer, and FA to be able to deliver the
packets to MN via link layer.

From that stance of having two endpoints of a tunnel, the authors of this
draft have discussed a paradigm shift in allowing intermediate nodes whose
link layer positions don't matter (as we don't care if they are on Home
Subnet or Foreign Subnet). They are just some 'positions' on the route
between HA and FA so as to optimize the travel distance/number of signals
that are sent to enable transparent communications of world with MN.

I think GFA is distinct from both FA and HA, since-

(1) As I said there is no restriction on which link layer it is. HA has to
be on the same link layer as MN's Home Address, and FA has to be on same
link layer that MN is now at.

(2) It is the entity that does BOTH encapsulation and decapsulation of the
same packets. HA encapsulates incoming packets to MN but decapsulates
outgoing packets. Similarly, FA encapsulates outgoing  packets from MN but
decapsulates incoming packets.

Thus GFA is first level of intermediateness between HA and FA by itself.
Therefore, I am saying that in a minimal setup of Regional Registration we
have to have GFA in addition to nodes in RFC 2002 since it is so different
than HA or FA.

On the other hand, an intermediate FA, although is an additional level, is
not really as distinct from GFA in the above two respects. And I consider it
the second level of intermediation.

Also regarding intermediate FA,
1. It is not needed even. One can have a decent Regional Registration
without it.
2. It is similar to GFA in terms of being an intermediate node between HA
and FA, having no link layer restriction, and having to do both
encapsulation and decapsulation of same packets.

In my mind, the first intermediate level of mediation between FA and HA has
already been provided by the GFA.

All further levels will be providing yet another level, and may be
considered as an appendix.

Therefore, I am advocating what exists in the draft, and what Tom has called
a 2 level hierarchy as a base case for hierarchical FA. I think the base
case is having the first intermediate FA, called GFA. Any other FA's
addition can be handled in appendix, and can be built on the model proposed
in this draft.

Regards,
Satwant

---

From: "Tom K. Weckström" <[email-masked]>
Date: Sun, 29 Oct 2000 13:06:43 +0200

Hello Satwant and others.

You have valid points. I agree on all you say about the roles of
different agents. And GFA really is the first level of
"intermediateness" when thinking from you point of view.

BUT:

Thinking from the regionality point of view, GFA is the zero level,
because it is not intermediate from the regionality point of view.
If the registrations go to the HA, they are not regionalized, and thus
HA can not be considered as level zero from the regionality point of
view. As Annika said, GFA is sort of a replacement for a HA. This is
also said in our paper presented in MoMuC99. We called this idea
"distribution of mobility agent functionality", because a part of HA's
functionality is distributed to FA's (namely the functionality to
reply to registration requests).

The important example I would like to see in the draft is the example
of FAs handling a consistent state information throughout the FA
topology. To clarify this operation, I would vote for a 3-level FA
hierarchy example. I admit, that even this state example could be
simplified to a 2-level example, but I see it would be misleading in
two ways: it is more trivial and it urges thinking of only 2-level
hierarchies. 2-level hierarchies are likely to be the most used
topologies, but as networks grow and needs arise for even more
regionalized registrations, deeper FA topologies may gain importance.

Let me explain.
Again, I use the example hierarchy:

                                 ------
                                 | HA |
                                 ------
                                   |
                               (Internet)
                                   |
                                -------
                                | GFA |
                                -------
                              /         \
                      -------             -------
                      | FA1 |             | FA2 |
                      -------             -------
                       /   \               /   \
                 -------   -------   -------   -------
                 | FA3 |   | FA4 |   | FA5 |   | FA6 |
                 -------   -------   -------   -------
                                  \
                                   \
                                 ------
                                 | MN |
                                 ------

In the initial situation in the figure, IFA (FA1) is the intermediate
FA on a path from HA to MN, GFA has its own special name and role, and
LFA (FA4) is the lowest FA on a path from HA to MN. MN has registered
with a home registration and has received a reply through FA4 (LFA).

Now, consider a situation, in which MN changes its lowest FA (the FA
to which it sends its registrations) in the following order:
-- FA4, FA3, FA6, FA5, FA4,...

Now, what entities send the regional registration reply to MN?
In the corresponding order:
-- FA1, FA1, GFA, FA2, GFA,...

Now, also FA1 and FA2, and even GFA may send agent advertisements.
MN could also roam vertically and register like this:
-- FA4, FA1, FA2, FA3, FA2, FA6, FA1

And the FA sending the registration reply would be:
-- FA1, FA1, GFA, GFA, GFA, FA2, GFA

These (or similar) are important examples that should be handled in
the draft for example to justify the use of "previous FA NAI"
extension. For example, in the latter example, changing from FA1 to
FA2 and to FA3 would result in error, if a "tear down" message from
GFA to FA1 was lost after the FA1-->FA2 transition. In that case, the
registration reply associated with the FA2-->FA3 transition would be
handled by FA1 leaving GFA unaware of the change, i.e., GFA would
still route the packets for MN to FA2.

When using "previous FA NAI" extension, FA3 would know that the
previous FA, FA2, is not under it and would delegate the
responsibility to FA1. FA1 would also notice that FA2 is not beneath
it in the hierarchy, and would delegate the registration to GFA, which
would be able to handle the registration correctly. This solution
requires the FAs to be aware of other FAs below them in the hierarchy.
This is solved with a specific automatic "FA registration protocol"
also designed by Jouni Malinen in his thesis and implemented in
Dynamics - HUT Mobile IP v0.7. Of course, also manual configuration
could be used.

Tear down could be used *in addition* to the "previous FA NAI"
extension. The role of the previous FA NAI extension is to make the
state of the hierarchy consistent and the role of the tear down
message would be just to release the resources from FA2. E.g., FA2
could have had the maximum number of mobility bindings and it would
have been unable to serve new MNs before the timeout of the already
useless binding. Tear down would then release the resources for other
MNs.

It is not possible to show examples like this with a 2-level FA
hierarchy. A significantly simpler scenario could be shown, though.
What do you think, would the simpler scenario be enough to demonstrate
the issues involved in FA hierarchies deeply enough to help the
implementors avoid failures in coding their implementations? I think
guidance to implementors is one of the most important missions of RFCs
(and drafts). Would the simpler scenario also demonstrate the
solution's capability to extend to any level FA hierarchies?
Furthermore, if someone has thought these - to me quite nontrivial -
issues through, I think the conclusions should be included to a draft
that describes the solution and not to hide them so that everyone
would need to re-think the issues and re-invent the solution for
3-level hierarchies.

I agree, that a simplistic case could be handled in the main text and
3-level considerations could be left to Appendix, if length of the
document becomes an issue, for example. However, these scenarios and
the operation of the system elements are so important for the whole
concept of regional registrations that I would rather write them to
the actual part of the draft, not Appendix.

Regards,
        Tom

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 31 Oct 2000 05:51:21 -0800

Hello Tom,

I have studied your examples, and I have two overall
comments.

It seems to me that using the Previous Foreign Agent
Notification (PFAN) extension (from the Route Optimization
draft) solves the problems that you posed.  This message
forces an acknowledgement from the previous foreign agent
after it receives the Binding Update.  Thus, the mobile
node has a way to know its registration status at previous
foreign agents.  All along, we tried to make the regional
registration draft coexist well with the Binding Update
mechanism specified in the Route Optimization draft, while
still remaining sufficiently independent so that the
regional registration draft could be considered separately.

Do you agree that this is a good solution?

I am very tempted to agree with you about the need to
insure that regional registration messages work with multilevel
hierarchies.  And, in fact, I think that the messages in the
current draft do work in multilevel hierarchies.  We all
thought about this problem of multi-level hierarchies many
times, and that was a partial motivation for using different
message types.  However, if you see any particular place where
there is any existing problem in the protocol, where the
regional messages would not work for the multi-level hierarchy,
please let us know.

For convenience, I have reproduced your example hierarchy
and mobility patterns below.  I think that, given PFAN,
the existing draft solves your concerns, but again if I am
wrong I hope you will help us find out what is still wrong.

Regards,
Charlie P.