Re: [MOBILE-IP] WG Last Call-(draft-ietf-mobileip-reg-tunnel-03.txt)
Sat, 21 October 2000 20:55 UTC
Date: Sat, 21 Oct 2000 23:55:08 +0300
To: Satwant Kaur <wizkid11@XNET.COM>
CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] WG Last Call-(draft-ietf-mobileip-reg-tunnel-03.txt)
X-Message-ID:
Message-ID: <20140418065128.2560.46415.ARCHIVE@ietfa.amsl.com>
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 dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ 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). > > 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. --VxBmi9VgMIlnmxn8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="2000-10-25.txt" Content-Transfer-Encoding: 8bit Date: Wed, 25 Oct 2000 02:02:19 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" <tweckstr@cc.hut.fi> To: Charlie Perkins <charliep@iprg.nokia.com> CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, Annika Jonsson <annika.jonsson@ericsson.com> Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) 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 1. + Decision power at MN: regional or home registration possible ? Is it always good to let the MN deicde what kind of registration to use? ? What are the benefits in giving the MN the right to decide? - Different registration types makes the protocol more complex - Changes to std RFC2002 MN - Changes to FAs 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. 3.1.1. ? Why only assume two levels of FAs in the visited domain? ? Is the protocol fully flexible in its current form to support N-level hierarchies? It should be. More comments after Appendix B. "We assume that there exist established security associations between a GFA and the regional foreign agents beneath it." ---> This implies the RFAs HAVE to know their GFA. ---> Satwant Kaur's scenario with RFA not knowing the GFA is impossible. ---> No need for different message types for regional and home registration. ---> More transparency and simpleness achieved. 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 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?. 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? ? 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. 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. "and it SHOULD be protected by an FA-FA Authentication extension." ? Where is FA-FA auth ext described? In another draft, I suppose. 3.5.1. " it is necessary to distinguish regional registrations from home registration. Thus, we introduce new message types for the Regional Registration messages." ? Could we make the distinction by defining that every registration with a valid MN-FA auth ext is a regional registration? Furthermore, if there is no MN-FA auth ext or if that extension is invalid, the FAs forward the message upwards in the hierarchy. Example: Consider an N-level hierarchy. See image below: ------ | HA | ------ | (Internet) | ------- | GFA | ------- / \ ------- ------- | FA1 | | FA2 | ------- ------- / \ / \ ------- ------- ------- ------- | FA3 | | FA4 | | FA5 | | FA6 | ------- ------- ------- ------- \ \ ------ | MN | ------ Figure 1: Mobility Agent Hierarchy ! Now, if MN is registered to FA4 and changes to FA6, then it sends the registration request to FA6 and FA6 does not know the MN-FA auth ext in the registration neither has it heard of MN before (no mobility bindings existing for MN). Then FA6 jsut forwards the request upwards to FA2. FA2 also does not have a clue about MN, so it too forwards the request upwards. Finally, GFA knows the MN from its bindings and also can validate the MN-FA auth ext. Eventually, this registration became regional. Now, if there were no MN-FA auth ext, or if it was invalid, also the GFA would have forwarded the message - now to the HA. Maybe an invalid auth extensions should result in request denial if the MN is known to the FA (i.e. there is a binding for the MN in the FA). After all the MN is known, and the authentication does not match. ! Anyway, there seems to be no need for separate regional and home registration messages. The MN still has the choice to either include the FA-MN auth ext or leave it away. ! NOTE, that this is directly applicable to N-level hierarchies! 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. 4.2. "By comparing the domain part of the foreign agent NAI with the domain part of its own NAI, the mobile node can determine whether it is in its home domain or in a visited domain, and whether it has changed domain since it last registered." + Exactly! Good. :) 6.1. " GFA IP Address The IP address of the Gateway Foreign Agent. (Replaces Home Agent field in Registration Request message in [9].) Care-of Address Care-of address of local foreign agent; MAY be set to zero. " ? Why should the HA field be replaced? There is the COA field to be used for the GFA IP addr. The FAs in the hierarchy can use extensions or directly the source IP of the outer header to get the address of the "lower" agent in the hierarchy as the registration traverses upwards. ? Why is the COA field filled with the local COA? The lowest FA always knows behind which interface the MN is. The FA aboe the lowest FA knows the interface from which the first reg.request came and also the IP of the lowest FA. This continues from the bottom of the FA tree to the top, i.e., the GFA. ALL that is needed in MIP sense is the GFA IP in the COA field and this is for the HA. The hierarchy of FAs handles the tunneling in the hierarhcy by other means. A. " - 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;" ! Dynamics works with nonces also, and it supports regional registrations. I have to find out how the nonce synchronization is done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough for the MN to control between home and regional registrations. 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? ! There are drawbacks with this approach: - The hierarchy is not transparent anymore --> A security issue --> Needs more functionality in MN - The advertisements become some bytes larger because of the hierarchy information in them. - IF the hierarchy is not revealed, then the GFA is loaded because of ALL the regional registrations coming to it. --> SUGGESTION: ! Make the MN add a "previous FA NAI" extension to its registrations intended for regional handling. See more info from Jouni Malinen's thesis (p. 29-30) available on Dynamics HUT MIP web site. This removes the rece condition inherent in for example Dynamics v. 0.5 which used specific tear down messages. This also keeps the hierarhcy completely transparent and does NOT require any complex intelligence from the MN, e.g. to claculate the closest "common" RFA that could be the target for a regional registration. Adding the previous FA NAI extension is very straightforward and does not require any additional intelligence from the MN. B.2.1. " recognizes the mobile node as already registered, may generate a Regional Registration Reply, not all Regional Registration Requests will reach the GFA. Therefore, if old locations are not deregistered, it is possible that tunnels are not correctly redirected when a mobile node moves back to a previous foreign agent." ! I think Jouni Malinen solved this issue in his thesis, too. The solution is tied to the "previous FA NAI extension". Jouni's thesis, pages 29-30 at least, clarify this solution. " In case (3), the mobile node sends a Regional Registration Request to its new foreign agent. If the mobile node does not request smooth handoff, the previous foreign agent is not notified. The Regional Registration Request is relayed upwards in the hierarchy until it reaches a foreign agent that recognizes the mobile node as already registered. This foreign agent generates a Regional Registration Reply and sends it downwards in the hierarchy toward the new location of the mobile node, updating its own visitor list. At the same time, it also sends a Binding Update with a zero lifetime to the previous care-of address it had registered for the mobile node. The Binding Update is authenticated by the FA-FA Authentication extension. Each foreign agent receiving the Binding Update removes the mobile node from its visitor lists. The Binding Update is relayed down to the care-of address of the mobile node known to that foreign agent, and each foreign agent in the hierarchy receiving this notification removes the mobile node from its visitor list. " ! This results in the race condition I mentioned before. Dynamics v 0.5 had similar kind of message with zero binding lifetime. We called this a "tear down" message, because it tore down the old bindings and tunnels. There is a race condition in this, when for example tear down messages are lost. The state of the FA hierarchy is not up to date a fter one missed tear down message. Use "previous FA NAI" extension instead. This, too, has a possible problem, also mentioned in Jouni's thesis, if the reg.reply is lost and MN moves forward to another FA that may think it can actually answer the request. This can be soved as in Jouni's thesis or by only using the NAI of that FA from which we previously have received a positive reg.reply.... " If the mobile node uses a co-located care-of address for its regional registration, there is no need to deregister its previous location when it moves, since regional registrations with a co-located care-of address are performed directly with the GFA." ! I would say this is a limitation of your architecture. The GFA MUST NOT be automatically burdened by this kind of registrations. If this is not fixed, then we lose a part of the whole idea of using hierarchies - to distribute and localize the registration handling as much as possible. Charlie Perkins wrote: > > Hello Tom, > > > I discovered the 'hidden' assumption of RFAs and their GFA knowing > > abouit each other from the draft. :-) > > It wasn't intended to be hidden. How can we make it more explicit? > > > I will check the security association issue more closely. > > I am not completely convinced that there needs to be a separate > > message type for different uses of security associations. > > Why couldn't the FAs automatically consider the registration as a home > > reg if there is not acceptable sec association used for FA-MN > > authentication? > > Because the mobile node is very likely to want to send a home > registration whenever it feels like renewing its current care-of > address, thereby increasing the lifetime. We do not want to make > any implicit judgements about type of registration based on the > remaining registratoin lifetime. That sounds like a really bad idea. > > At any time, the mobile node should be allowed to send either a > home registration or a regional registration, subject only to the > constraint that the lifetime of the regional registration should not > exceed the lifetime of the regional registration. > > > I will send my comment later. > > Hopefully not too late. :-/ > > When does the last call end? > > I think formally it might have ended a month ago, but the purpose > after all is to find out if the draft is ready for advancement. So, > I think it's just fine to ask questions. So far, the main comments > we have gotten about necessary changes is to put in more details > about running in the mode where the "first" foreign agent becomes > the GFA (what others have called "anchoring"). > > Other than that, I think we're ready to go depending on your > comments. > > Regards, > Charlie P. -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ --VxBmi9VgMIlnmxn8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="2000-10-27.txt" Content-Transfer-Encoding: 8bit Date: Fri, 27 Oct 2000 00:07:57 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" <tweckstr@cc.hut.fi> Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) Hi, I am slowly starting to "buy" the idea of separate message types for regional and home registrations... More comments below. I am waiting your reply about the other issues I mentioned. Here is a brief checklist of issues not handled in this email (or in your reply). - Revealing the hierarchy in advertisements vs - Using previous FA NAI extensions * Limiting the solution to 2 levels vs * Making generic solution that is ready for N-levels. o Forcing registrations from co-located COA to GFA vs o Always using the optimal RFA for handling the registrations x Possibility to use HA hirarchies (possibly another draft). Annika Jonsson wrote: > > These comments are all about the issue of different message types for > regional registrations. Summary: I still think it's the best way. See my > arguments below. > > /Annika > > > >COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt > > > > It has nothing to do with benefits. As I see it it is a _necessity_ for the > MN to know who will process the registration, the HA or an FA, because it > needs to know what security association to use (I feel I am repeating > myself;-). It is possible that it could be solved by having the MN add both > the home and the visited authentication and both the home and the visited > replay protection (in case of nounces), and then let the network take the > actual decision, but that introduces even more complexity in the MN. > > <snip...> > > >"We assume that there exist established > > security associations between a GFA and the regional foreign > > agents beneath it." > >---> This implies the RFAs HAVE to know their GFA. > >---> Satwant Kaur's scenario with RFA not knowing the GFA is > >impossible. > >---> No need for different message types for regional and home > >registration. > >---> More transparency and simpleness achieved. > > > > You are right, but my example still holds! I will repeat it here: > > "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." Yes, MN needs to be able to control what kind of registration it requests. Your problem in the example above comes from a case where you would use GFA's IP in the HA field and only one type of registration message. That is the wrong way, we both know that. We end up to two alternatives already presented, but I write them here to make WG "voting" easier: A) Use separate message types for regional and home registrations. Use FA IP in the "HA field" of the regional registration. Actually, if this is a separate message type, then the RFC's sepcification is not misused, because we are talking about an entiryl new message here. :) B) Use only one registration request message type. Add FA-MN auth.ext. to registration, if regional registration is requested. Always use HA IP in its field. The registration can still be forwarded up to HA, if FAs decide so. MN will know the "destiny" of the registration only when regreply arrives. (with Home auth ext. or with foreign auth ext.) > <snip...> > > >3.5.1. > > > >" it is necessary to distinguish regional registrations from home > > registration. Thus, we introduce new message types for the > > Regional Registration messages." > > > >? Could we make the distinction by defining that every registration > >with a valid MN-FA auth ext is a regional registration? Furthermore, > >if there is no MN-FA auth ext or if that extension is invalid, the FAs > >forward the message upwards in the hierarchy. > >Example: Consider an N-level hierarchy. See image below: <snip> > > I agree, it could be done in this way, but you still need a change to an > RFC2002 MN, since it will always include the MN-FA auth. ext if it has an > SA with the FA (that is mandatory). Secondly, one argument that persuaded > us that different message types is a "cleaner" solution is that we didn't > like the idea to use e.g. the auth. ext. to let an FA decide what it > "thinks" that the MN wants. This is why: normally if the authentication > fails, this error should be reported back to the MN and no registration be > made. The authentication could fail for several reasons! It feels wrong, > both "decisionwise" and "securitywise", to use this failure to authenticate > the message as an indication of something that the MN wants the FA to do. Couple of additional comments: - Changes to RFC2002 MN would still be needed - True. We need an MN taht can leave the foreign euth ext away on purpose to force registration to HA (when we are using approach B above). - It would be good that a RFC2002 MN would be using regional registrations by default when adding the MN-FA auth.ext. by default. As an Internet user I would be concerned, if a proposed standard would not act optimally, but rather consumed bandwidth from the Internet with its non-optimal registration sequences. - "Failure to authenticate" would for me be: there was a foreign auth ext. but we could not verify its authenticity. --> Direct regreply with correct reason code to MN. - Lack of the auth ext. would not mean "failure", but the FA would forward the request onwards. > >? Why should the HA field be replaced? > > Why use extensions when we don't have to? In a regional registration the HA > address is not needed, so we reuse that field. Actually, the GFA kind of > acts as a "local HA", so doing it in this way makes it very consistent with > RFC2002. We come back to options A and B. As I said, using GFA IP in the new message in option A is OK, since it is not anymore a RFC2002 registration request but a new type of request. > >A. > > > >" - 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;" > > > >! Dynamics works with nonces also, and it supports regional > >registrations. I have to find out how the nonce synchronization is > >done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough > >for the MN to control between home and regional registrations. I discussed with Jouni. Dynamics can uses nonces for home registrations, i.e., registration requests without MN-FA auth ext. but only timestamps are used in registrations with FA-MN auth. ext. This eliminates the possibility of uncontrolled nonce asynchronization. > It would be interesting to see your solution. :-) Download Dynamics from the URL in my signature. You are also welcome to visit Finland to see it work. Unfortunately we do not have any conference papers in pipeline or budget to travel to WG meetings. Best regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ --VxBmi9VgMIlnmxn8--