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

From: Annika Jonsson <[email-masked]>
Date: Fri, 20 Oct 2000 17:54:04 +0200

Hi Gopal,

as Charlie say's, we have discussed this a lot. Here are some of our
reasoning. The home and the regional registrations will always differ
because of different replay protection and security associations for the
authentication extensions. Furthermore, the FA has to be able to handle
many different cases: a) normal RFC2002 registration b) home registration
through GFA (to prepare for regional registrations) c) home registration
with GFA set to zero (to ask that a GFA be assigned) d)regional
registration e) regional registration with FA set to zero (in case FA does
not advertise itself).

Therefore we think that using different message types to separate the
handling of the home and the regional registration messages would make it
simpler for the FA:s. I can give you one example: The MN is allowed to try
to do a regional registration to the GFA it has been using, even though
that GFA is not advertised by the new FA. In this case, if the FA does not
know this GFA it must send back an error to the MN. If the FA didn't know
that this was a regional registration, it would assume that the old GFA is
the MN:s HA, and that this was a normal RFC2002 registration, and the
registration would fail.

/Annika

At 22:35 2000-10-11 -0700, Gopal Dommety wrote:
>Charlie,
>
>
>1.  If you can perform a global registration via the hierarchy with out
requiring new messages, it is
>possible to do regional reg without introducing the new messages.
>
>2. The difference between the reg and global registration should be where
the registration finally gets processed and reg reply is generated (i.e, in
one case the it goes through the GFA to the HA and gets processed there, in
the regional case
>it is processed by the common GFA between the old and the new paths - if
more than two levels of hierarchy is employed)..
>
>3. The reasons you have given in the Appendix for introducing new messages
are given below:
>
>                -  a mobile node must be able to distinguish
>                            between regional registrations and home
>                            registrations, because when it uses
>                            regional registration, the nounces are not
>                            synchronized with its home agent;
>
>                         -  a mobile node can use a zero care-of
>                            address either to request a GFA (in a home
>                            registration) or to signify the use of an
>                            unspecified regional foreign agent (in a
>                            regional registration).
>
>Both these can be equally easily handled with the extensions approach.
>
>more comments below:
>
>
>>> 1. What is the fundamental reason for introducing  new  regional
registration request/reply messages. I think
>>> this is unnecessary introduction of new message types.
>>
>>We puzzled over this for quite a while, more than one time.
>>There is discussion about the reasons for the change in
>>Appendix A. We think that processing is very much more
>>natural for the case when there are separate message types,
>>instead of extensions to the existing messages.  Clearly,
>>making extensions to the existing messages would have
>>the effect of introducing a lot of additional case analysis
>>into existing code for handling RFC 2002 registration
>
>Could you give concrete examples of the cases that cannot be handled by
>an extension.
>
>
>>messages.  There are other reasons, as mentioned in the
>>draft appendix, related to allowing for non-disclosure of
>>foreign agent hierarchies.  This is especially true for multiple
>>levels of hierarchy.
>
>don't see why multiple hierarchies is a problem.
>
>moreover, if we are employing multiple hierarchies, if will apply to the
home registration also.
>
>
>>>  a) You are using extensions for the initial registration through the
GFA. You could as well use the extensions for achieving regional
>>> registrations.
>>
>>That is different, because the initial registration _is_ a home
registration.
>
>It should not be, other than the fact who is supposed to processes the
message and the extensions.
>
>
>>> b) In fact your version 02 of the draft
(draft-ietf-mobileip-reg-tunnel-02.txt) does not have these new messages.
>>
>>We couldn't make it work very well that way in all cases, as I've alluded
to already.
>>
>>> Unless there is a good reason, I think you should use extensions. Using
existing messages with extensions makes
>>> implementation easier and cleaner (we have seen that in implementing
anchor handoff draft draft-dommety-mobileip-anchor-handoff-02.txt).
>>
>>On the contrary, I really think that using new messages makes the
implementation
>>easier and cleaner, exactly because then the implementation does not have
to build
>>up as much global state and case analysis.  Furthermore, as I have
mentioned already,
>>there are cases that cannot be handled as easily with extensions.  I
think that the
>
>could you provide concrete examples of what cases cannot be handeled?
>
>
>Regards,
>Gopal
>

---

From: Satwant Kaur <[email-masked]>
Date: Fri, 20 Oct 2000 22:46:34 -0500

Hello,

I am implementing the Regional Registration
(draft-ietf-mobileip-reg-tunnel-03.txt), and I agree with Annika that it is
important for FA and GFA to be able to make the distinction between the Home
Registration Request (type 1) and Regional Registration Request (type 2)
messages. Furthermore, the mobility Agents should also be able to make a
distinction between Registration Reply (type 3) and Regional registration
reply (type 4).

Another case where a similar problem would arise:

Suppose MN wants to do Home Registration with a FA who does not advertise
itself. MN wants to be assigned a GFA and so it sends a Home Registration
Request (type 1) with careof field as 0, and HA address in the Home Agent
field.

Now, if we do not have additional message types to be able to make a
distinction between type 1 and type 2 Registration requests, the FA will
have no way of knowing if (1) It is a home Registration with MN asking to be
assigned a GFA for home Registration, or (2) It is a Regional Registration
(with FA set to 0, since FA did not advertise itself).

FA can (mis)interpret it as type 2 message. It will incorrectly assume that
the HA address is really the GFA that the MN wants to register with. It will
then forward the request to its HA address under the assumption it is really
the GFA, instead of assigning a GFA address, and forwarding the registration
to the assigned GFA.

The above problem arose since FA reads the registration requests sent by MN,
and forwards them to GFA. In the absence of the message type that would
enable FA to make a distinction between home registration request (type 1)
and regional registration request (type 2), the FA does not know where to
send the request to. The GFA address lies in the Home Agent field in case of
type 2 and in the careof field in case of type 1 message. If the additional
type 2 message is not there, FA cannot make the distinction between Home Vs
Regional Registration Request.

Similar problems will arise at GFA level, since when the GFA reads the
Registration Requests sent out by FA, and either forwards them to HA (in
case of Home Registration) or sends the reply back to FA (in case of
Regional Registration). If the type 2 message type is not there, GFA cannot
make the distinction between Home and Regional Registration. And it would
not know whether to send it forward to HA, or to send reply back to FA.

Similar problems will also arise on the way back for Registration Reply
messages at FA and GFA, if type 4 is not present.

Apart from the problems in the above special cases, I also do not favor
using anything other than message types to understand what type of
registration /registration reply it is. The reason is if one uses some other
characteristics of the packets (in this case, the extensions) other than its
"type" to identify the type of packets, it is against the spirit of
assigning the right job to the right field. It may also give us grief down
the road as it would restrict our freedom to use extensions in different and
more creative ways in future.

----- Original Message -----
From: "Annika Jonsson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 20, 2000 10:54 AM
Subject: Re: [MOBILE-IP] WG Last
Call -(draft-ietf-mobileip-reg-tunnel-03.txt)

---

From: "Tom K. Weckström" <[email-masked]>
Date: Sat, 21 Oct 2000 23:55:08 +0300

Hi,

In my opinion, additional messages makes the protocol partly clearer,
but partly more complex.

Here are my questions (please point me to the appropriate messages, if
these questions have already been discussed :)

- Is it possible/needed that a FA does not know the GFA or GFAs above
it?
I think FAs and GFAs should have trust relationships = knowledge of
each other.

- Why do we need to add intelligence to the mobile node?
Having a totally transparent hierarchy is possible. The MN would speak
standard RFC2002 MIP and would still get the best efficiency in
registrations through the regionalized handoffs. By defining new
messages we do add intelligence to MN. It must know what kind of
registrations to send.

And my totally subjective opinion:
  ;-)
Despite the lively discussion about regionalized handoffs etc., I
still have not seen many transparent, fast and *implemented*
approaches. If the ideas in the drafts have been implemented, please
provide the community some links to the material. Dynamics  - HUT
Mobile IP has been rocking for 1.5 years now. Dynamics is transparent
to the Mobile Node and still provides fast handoffs.

Should we write a competing draft? ;-) We didn't do it in the first
place because we felt it would just slow down the fast handoff design
process. Unfortunately the process has been unbelievably slow. I am
really looking forward to a solution in this issue.

Regards,
        Tom

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

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