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

From: Ron Young <[email-masked]>
Date: Thu, 26 Oct 2000 07:24:03 -0500

-----Original Message-----
From: Annika Jonsson [mailto:[email-masked]]
Sent: Thursday, October 26, 2000 3:58 AM
To: "Tom K. Weckström"; Charlie Perkins
Cc: [email-masked]
Subject: Re: [MOBILE-IP]
WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)

------------------
Hi Tom,

I'll try to answer your comments and questions. This mail only deals with
the simple ones, more will follow in separate messages...

At 02:02 2000-10-25 +0300, Tom K. Weckström wrote:
>
>
>Hello Charlie,
>
>Here comes my lengthy comments about reg-tunnel-03. Sorry for a long
>email, but there were lots of things to comment.
>I hope the ASCII graphics is not distorted.
>I found quite many issues.
>Some of them might be possible to solve with more explanations (maybe
>I just did not get the ideas). Some of the issues should be solved in
>other ways. More ideas below. Read on.
>
>Regards,
>       Tom
>
>
>COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt
>
>Tom Weckström
>
>Legend:
>+ = A positive note
>- = A negative note, criticism
>? = A question
>! = Exclamation, either a critical issue or an important suggestion
>idea
>--> = conclusion mark
>

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

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

>? Is the protocol fully flexible in its current form to support
>N-level hierarchies? It should be. More comments after Appendix B.
>

It's supposed to be. If not, we would certainly want to know ;-) I'll look
at your comments after teh Appendix.

>3.3.
>
>" If the `I' bit is set, there MUST be at least one care-of address in
>the Agent Advertisement message."
>"If the `I' bit is set, and there is only one care-of address, it is
>   the address of the GFA."
>---> If so, there cannot be a situation where GFA is not known at the
>     moment of registration. (Provided the address is real, not zero.)
>

The GFA address in the advertisments can be zero. Will clarify this.

>---> The text could be clarified to mention about the relationships of
>     the FAs in the hierarchy. Do they all know each other? Do they
>     only know who's above and who's below them?.
>

Yes, this should be clarified.

>
>3.4.1.
>
>+ Setting GFA IP to zero improves flexibility.
>
>"If the `I' bit is set, but the GFA
>   address is zero (0), the mobile node MUST check to make sure that
>it
>   receives a GFA IP address extension as part of any home
>registration,
>   or else send its home registration using the care-of address of
>some
>   previously known GFA in the same visited domain."
>
>? 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.

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

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

>
>"and it SHOULD be protected by an FA-FA Authentication extension."
>? Where is FA-FA auth ext described? In another draft, I suppose.
>

Oohps, will add that.

>3.5.2.
>
>" The only difference is that there is the GFA IP address instead of
>   the address of the home agent."
>
>? Does this mean that the Home Agent field in the RFC2002 compliant
>registration request field has the IP addr of GFA? Section
>6.1. verified this assumption. This could be more clearly stated
>already in section 3.5.2.
>
>

Will clarify.

>
>B.2.
>"
> This process is repeated in each RFA in the hierarchy, until an RFA
>   recognizes the mobile node as already registered.  This RFA may be
>   the GFA, or any RFA beneath it in the hierarchy.  If the mobile
>node
>   is already registered with this RFA, the RFA generates a Regional
>   Registration Reply and sends it to the next lower-level RFA in the
>   hierarchy.  The lifetime field in the Regional Registration Reply
>is
>   set to the remaining lifetime that was earlier agreed upon between
>   the mobile node and the GFA. If the lifetime of the GFA
>registration
>   has expired, the Regional Registration Request is relayed all the
>way
>   to the GFA.
>
>   If the hierarchy between the advertising foreign agent and the GFA
>is
>   announced in the Agent Advertisement, the mobile node may generate
>   a Regional Registration Request not destined to the GFA, but to the
>   closest RFA with which it can register.
>"
>
>? 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.

I'll come back to your other comments later.

Thanks for your feedback!
/Annika