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

From: Gopal Dommety <[email-masked]>
Date: Fri, 10 Nov 2000 12:37:16 -0800

At 10:46 PM 20/10/00 -0500, Satwant Kaur wrote:
>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).

You will be able to distinguish between a the two type of registrations (I would like to
call regional registration a special case of registration) based on the persence or absence
of the new extension (call it regional extension). The same will apply to the registration reply.
To clarify the case when you are performing a regional registration the registration will have this
extension (this extension can be of critical type).

The reason one should use an extension  and not a new type is because:

1. Regional registration is a special case of registration and the solution is not to create a new type for
every special case.

2. One does not have to reinvent everything  (such as extensions ) for this new registration ( even if we
ignore the simplicity of developing this feature on the mobiles and agent using the existing code base).

-Gopal

Thanks
Gopal

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