Subject: [AAA-WG]: Mobile IP Extension

From: Patrice Calhoun <[email-masked]>
Date: Thu, 8 Mar 2001 11:12:59 -0800

All,

This is just a heads up on changes that are required in the Mobile IP Extension,
as a result of the testing this week in San Jose.

The Mobile IP extension currently defines the following signalling 

FA       AAAF      AAAH      HA
   -AMR->    -AMR->    -HAR->
   <-AMA-    <-AMA-    <-HAA-

However, if the Home Agent is assigned in the visited network, the
following signalling is mandated:

FA       AAAF      AAAH      AAAF      HA
   -AMR->    -AMR->    -AMA->    -HAR->
   <------------AMA----------    <-HAA-
                        <-HAI-

We had originally decided to do this to reduce the number of round trips to
the AAAH. In the above scenario, the AAAH authenticates the mobile, generates
keys, and replies back to the AAAF. The AAAH is not contacted again until the
HAI is sent to inform the AAAH of the status of the request.

However, this scheme, while reducing round trips, does require that HAR-ish
AVPs are present in the AMA. This really makes the protocol quite complicated,
and further requires that the HAI include some success result code. This
means that in order to save round trips, we end up abusing protocol messages.

Therefore, after discussin this over with people that have implemented it, we
decided that protocol complexity did not justify this, and we reverted back
to what was in the spec some time back, which is:
FA       AAAF      AAAH      AAAF      HA
   -AMR->    -AMR->    -HAR->    -HAR->
   <-AMA-    <-AMA-    <-HAA-    <-HAA-

This means that the signalling is exactly the same, whether the Home Agent is
in the home or visited network. Furthermore, it makes it VERY simple to also
handle the case where the Home Agent is in a third network, as below:

                              (3rd domain)
FA       AAAF      AAAH      AAAF      HA
   -AMR->    -AMR->    -HAR->    -HAR->
   <-AMA-    <-AMA-    <-HAA-    <-HAA-

Anyone object to the above changes in the -02 of the Mobile IP extension? Again,
implementors found this to be the simplest.

Thanks,

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 8 Mar 2001 14:55:43 -0800

hmmmm.... I recall having this discussion, and I am quite sure that my response
will be the same.

I really do not care much for messages that have to be treated completely
differently, based on whether the receiver is a home server or a home agent.

Your proposal makes it REALLY hard to have a single code base, that supports
both client and server side (NAS/FA and AAAH).

Anyone else?

PatC
>Pat,
>
>I would like to propose we generalize AMR and AMA 
>so that both of these messages can be used between
>all four entities involved (FA, AAAF, AAAH and HA) during
>registration. That way, we can truly ignore the 
>geographical proximity between them and focus on their
>functional behavior.
>
>So, this is what the flow would look like.
>
>FA 		AAAF 		AAAH  	HA@visited_network
>  -AMR->  		-AMR->
>  	  		<-AMA-
>			--------AMR-------->
>			<--------AMA--------
>  <-AMA-  		
>
>Granted, there are differences between the functions that
>needs to be performed after receiving AMR vs. HAR, however,
>the Session ID can keep the servers stateful.
>
>Also, you are having to open up the AAAF for both AMR/AMA 
>and HAR/HAA interfaces in the option cited below. Combining
>them into one interface will, in my opinion, make a better
>protocol. 
>
>Regards,
>
>Haseeb
>
>
>
>-----Original Message-----
>From: Patrice Calhoun [mailto:[email-masked]]
>Sent: Thursday, March 08, 2001 1:13 PM
>To: aaa-wg; diameter
>Subject: [AAA-WG]: Mobile IP Extension
>
>
>All,
>

---

From: "Haseeb Akhtar" <[email-masked]>
Date: Fri, 16 Mar 2001 15:37:29 -0600

Hello all,

I also agree that there should be a separate extension 
that would only describe the Radius only attributes for 
Diameter. That could also be part of the base protocol.

Since the early implementation of Diameter (Mobile IP) 
does not require the Nasreq extension, it ought be optional.

Regards,

Haseeb

-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: Friday, March 16, 2001 1:52 PM
To: Bernard Aboba
Cc: Patrice Calhoun; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Mobile IP Extension

> >Historically, an extension consists of at least one command code. I
realize
> my
> >e-mail was off the wall, but I listed it as an option. Taking that
option,
> of
> >course, would lead us in unchartered Diameter territory...
> 
> OK, this makes sense. Extensions are created only to support new message
> types,
> not just new AVPs. I'd recommend that these paragraphs be put in the spec
> somewhere to make sure this is clear.

ok, will do.

> 
> >A mix of both.
> 
> >During the DRI, you discovery your peer's capabilities, and don't send
any
> >messages whose extension wasn't advertised. Each message has a list of
AVPs
> >that MUST, and SHOULD, be present. Of course, one can always add some
other
> >arbitrary AVP in the message, and hope that the other end supports it, as
> in
> >RADIUS, and there isn't much we can do to protect against that, IMHO.
> 
> OK. As a result of this, I would say that any AVP that is listed as a
MUST,
> SHOULD
> or MAY within multiple extensions should go into the Base Protocol. Also,
> for
> RADIUS interoperability, I would suggest that any AVP or message that is
> defined in
> RFC 2865-2869 should also go into the base protocol. That way any DIAMETER
> implementation can be guaranteed to be able to gateway RADIUS messages, as
> noted in the requirements. This means that Accounting and NASREQ
extensions
> need to be mandatory to implement.

hmm... well NASREQ has much more than just RADIUS, it has a whole bunch of
Diamter-only AVPs, and mandating those would be a mistake, IMHO.

Perhaps it is necessary to split up the NASREQ extension into two. One
containing all of the RADIUS attributes, and the other containing the
Diameter-only attributes.

Or perhaps just a paragraph in the base that states that a Diameter
implementation MUST support all attributes in RFC 2865-2869. However, both
of
the above is a red herring, since the initial Diameter deployment will be
for
Mobile IP, and they don't even need any RADIUS compatibility.

PatC