Subject: Re: [mobile-ip] RFC3012 interpretation yet again

From: [email-masked]
Date: Mon, 12 Nov 2001 17:52:50 -0600

Looks great.  A couple of nits:

- Wouldn't the message to/from the verification infrastructure
be something other than RRQ and RRP?

- The RRQ and RRP would be going to the HA instead, and this
step should be there as well IMO.

Thanks,
Mike

"Charles E. Perkins" <[email-masked]>@iprg.nokia.com on 11/11/2001
05:32:31 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: [mobile-ip] RFC3012 interpretation yet again

Hello Mike,

[email-masked] wrote:

> Well, since you asked...  This is not a purely technical issue, but
> I think it would help a lot if RFC3012bis included a ladder diagram
> of a canonical call flow.  Right now each element's processing
> is discussed in isolation and I believe that an appendix showing the
> order in which events typically occur would help.

How's this:

        MN                  FA              Verification Infrastructure
         |                   |                        |
         |<-- Adv+Challenge--|                        |
         |    (if needed)    |                        |
         |                   |                        |
         |-- RReq+Challenge->|                        |
         |    + Auth.Ext.    |                        |
         |                   |--- RReq + Challenge -->|
         |                   |      + Auth.Ext        |
         |                   |                        |
         |                   |<-- RRep + Auth.Ext.----|
         |                   |                        |
         |<-- RRep+Auth.Ext--|                        |
         |     + Challenge   |                        |
         |                   |                        |

... along with an explanatory paragraph...

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Nov 2001 16:46:44 -0800

> be something other than RRQ and RRP?

It could be anything. This draft tries to introduce the verification
infrastructure to satisfy review comments, but we also don't want to 
copy text from another spec that defines the actual protocol.

PatC

---

From: "Juan Caballero" <[email-masked]>
Date: Tue, 13 Nov 2001 11:49:56 +0100

Sorry to bring up again the subject but I am doing a thesis work with Mobile
IP and I am trying to integrate AAA (Radius) with Mobile IP and found some
questions regarding the Challenge-Response RFC. I apologize if I just
misunderstood the standards.

1-How is this suppose to work with Hierarchical Mobile IP?

I believe that if a hierarchical structure of FA is used, the lowest FA is
the one sending the Challenge and waiting for the response but it is most
probable the Highest FA the one which communicates with the AAA structure.
Then if the Lowest FA removes the MN-AAA Authentication Extension there is
no info for the highest FA to perform the authentication. Should the lowest
FA just forward the Challenge extension to the Highest FA and this one takes
care of the rest? How are the extensions handled?

2-RFC 2977 (Mobile IP AAA Requirements) states:
"All needed AAA and Mobile IP functions SHOULD be processed during a single
Internet traversal.  This MUST be done without requiring AAA servers to
process protocol messages sent to Mobile IP agents.  The AAA servers MUST
identify the Mobile IP agents and security associations necessary to process
the Mobile IP registration, pass the necessary registration data to those
Mobile IP agents, and remain uninvolved in the routing and authentication
processing steps particular to Mobile IP registration."

In the specific case of Radius, I do not see how to meet both ideas. Either
I try to make a single Internet traversal and then the AAA server needs to
take care of delivering the Mobile IP Registration to the HA or the FA
blocks the Registration Request until the Authentication process is
completed but then two Internet traversals are done.

Should the FA send the registration request to the HA without delay and just
block the reply until it gets a message from the AAA authentication? This
will shorten the delay in the registration even if two Internet traversals
are still needed. But on the other hand the Home Agent will receive a MN-AAA
authentication extension which does not know how to handle since RFC 3012
states:
"The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension from
the Registration Request prior to the completion of the authentication
performed by the AAA infrastructure.  "

It would be nice if some of the people implementing this would show their
opinion.
Thanks,

Juan Caballero

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 13 Nov 2001 09:20:03 -0800

I think the problem is that you are trying to satisfy Mobile IP 
requirements with a protocol that cannot. It is for this reason
that the IETF (and the MIP WG) decided instead to go with the protocol
being designed by the AAA WG.

PatC