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

From: Annika Jonsson <[email-masked]>
Date: Thu, 26 Oct 2000 17:55:47 +0200

Hello Tom,

here is part two of my answer to your comments. (if you didn't see the
first one, it's probably because I sent it from the wrong address, and it
went via the moderator)

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

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

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

<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:
>
>                                 ------
>                                 | 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!
>
>

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.

<snip...>

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

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.

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

It would be interesting to see your solution.

<snip...>

---

From: Gopal Dommety <[email-masked]>
Date: Thu, 26 Oct 2000 10:23:00 -0700

>the home and the visited authentication and both the home and the visited

You need not do this (adding two authentications) . Because, if you knew to
 send a reg registration, then the
mobile knows which security association and reply to use, and the network can 
validate that. May be I am missing something.

Since you are saying it (the decision to use new messages) has nothing to do with benifits, if 
what you said above is not true, then we should use the extension method.

Thanks
-Gopal

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Oct 2000 11:51:31 -0700

Hello Gopal,

Gopal Dommety wrote:

> You need not do this (adding two authentications).  Because, if you knew to
> send a reg registration, then the  mobile knows which security association
> and reply to use, and the network can validate that.  May be I am missing
> something.

If the mobile node sends a home registration, then it needs to use
the security association with the home agent.

If the mobile node sends a regional registration, then it needs to
use the security association with the regional mobility agent
(e.g., GFA).

The mobile node does know which security association to use,
depending on which kind of registration it is performing.

What does it mean, "the network can validate that"?

> Since you are saying it (the decision to use new messages) has nothing
> to do with benifits, if what you said above is not true, then we should
> use the extension method.

The decision has to do with protocol correctness, feature availability,
and enabling natural processing techniques for the mobile entities.
I think this is the bottom line on what others have said.

Regards,
Charlie P.

---

From: "Tom K. Weckström" <[email-masked]>
Date: Fri, 27 Oct 2000 00:07:57 +0300

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

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

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

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.

> >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
                                [email-masked]

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