Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-01.txt

From: "Martin Julien (ECE)" <[email-masked]>
Date: Wed, 4 Apr 2001 14:06:56 +0200

Thanks for your answer.
See enclosed comments.

> > 1) I think that page 8 should be a new section about a 
> Mobile Node moving to
> > a Foreign Network.
> 
> I *could* but this is just another case of a Home Agent in a 
> visited network,
> so I find it difficult to find a clean separation point.

I simply thought it would help understanding the concepts, since
the section is quite long and contains a lot of stuff not so 
easy to read for new comers.

> > 
> > 4) Page 8, par.2, last sentence. I don't really understand 
> what you mean
> > there. I guess you meant that Home Agent and the requesting 
> Foreign Agent
> > are in different domain. The thing is that it is likely 
> that the Home Agent
> > and the MIP-Previous-FA-FQDN were in the same domain at the last
> > registration, right?
> 
> Of course, but this paragraph has to do with a third network. 
> Is the scenario
> what's confusing you, or the text?

It is the text, which suggests that the AAAH MUST verify whether or
not it will allow a HA to be kept in a Foreign Network different
than the actual FA, only if the MIP-Previous-FA-FQDN AVP and 
MIP-Home-Agent-Address AVP are in different domains. Since both
entities will most probably be from the same domain (in the case where
the FA and HA are in the foreign domain, which is recommended for route
optimization), then no check should be performed, according to your text, right? 
I guess that it is not what you really wanted to express, but rather when an AAAH
receives a MIP-Previous-FA-FQDN AVP, the AAAH deduces that the MN
has moved to a new domain, and then must check if a 
MIP-Home-Agent-Address AVP was present in that same network, in which case
it must take a decision whether or not to allow the HA to be used.

And also, I'm not sure whether the MUST is really necessary, or should simply
be left as a possible local policy?

> > 6) Section 1.4, the second paragraph suggests to release 
> the all resources
> > in the Home Diameter server upon the receipt of the STR 
> from the Home Agent.
> > I guess it should be clear that the referred Home Agent is 
> the "active" Home
> > Agent, since there might be 2 Home Agents at the same time 
> while roaming.
> > During handoffs between different FAs in different domains, 
> and let's say
> > that the Home Agent in the old Foreign domain can not be 
> maintained there,
> > then a new Home Agent has to be started in the Home Domain 
> or the new
> > Foreign domain and the AAAH needs to send a STI to the old 
> Home Agent, which
> > replies with a STR. In that case, the Home Diameter should 
> not release
> > resources, right?
> 
> I think that I view multiple bindings (to home agents) are 
> different Diameter
> sessions. Each would get their own Session-Id, and have their 
> own separate
> session state.
> 

I would really appreciate if you could give me a bit more details 
on what you mean here, because lately, I've been wondering about
how the Session-Id should be handled while moving between FAs within
the same domain, and different domains. 

> 
> You have plenty of comments on section 5.1, which was a mess. 
> My proposed
> cleaned up text is as following 
> 
> <proposed text>
> If the mobile node does not have a Mobile-Home registration key, then
> the AAAH is likely to be the only entity trusted that is available to
> the mobile node.  Thus, the AAAH has to generate the Mobile-Home
> registration key, and encode it for eventual consumption by the mobile
> node and home agent.
> 
> If the home agent is in the home domain, then AAAH can directly encode
> the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP and
> include that AVP in the HAR message for delivery to the home agent.
> 

Why do you say "encode", since it is not encoded, right?

> If, on the other hand, the home agent is to be allocated in the
> visited domain, the AAAH does not transmit the HAR to the home agent,
> but instead transmits the HAR to the AAAF. When the AAAF 
> receives the HAR,
> it first allocates a home agent, and then issues the HAR for 
> that home agent.
> 
> The AAAH also has to arrange for the key to be delivered to 
> the mobile node.
> Unfortunately, the AAA server only knows about Diameter 
> messages and AVPs,
> and the mobile node only knows about Mobile IP messages and 
> extensions[4].
> For this purpose, AAAH encodes the Mobile-Home registration key into
> a MIP-MN-to-HA-Key AVP, using its security association with 
> the mobile node,
> which is added to the HAR message, and delivered either to a 
> local home
> agent, or to the AAAF in the case where the home agent is in 
> the visited
> network. The AAAH has to rely on the home agent (that also understands
> Diameter) to transfer the key into a Mobile IP Generalized 
> MN-HA Key Reply
> extension in the Registration Reply message. The home agent 
> can format the
> Reply message and extensions correctly for eventual delivery 
> to the mobile
> node. The resulting Registration Reply is added to the 
> MIP-Reg-Reply AVP
> and added to the AHA.
> 

HAA instead of AHA.

> After the HAA message is parsed by the AAAH, and transformed 
> into an AMA,
> the AMA message containing the MIP-Reg-Reply AVP will 
> eventually be received
> by the attendant (i.e., the foreign agent). The foreign agent 
> can then use
> that AVP to recreate a Registration Reply message, containing 
> the Generalized
> MN-HA Key Reply extension, for delivery to the mobile node.
> 
> In summary, the AAAH generates the Mobile-Home registration key and
> encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key 
> AVP. These
> AVPs are delivered to a home agent by including them in a HAR message
> sent from either AAAH or AAAF. The home agent decodes the key 
> for its own use.
> The home agent also copies the encoded registration key from the
> MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply 
> extension appended
> to the Mobile IP Registration Reply message. This 
> Registration Reply message
> MUST also include the Mobile-Home authentication extension, 
> created using
> the newly allocated Mobile-Home registration key. The home agent then
> encodes the Registration Reply message and extensions into a 
> MIP-Reg-Reply
> AVP included as part of the HAA message to be sent back to 
> the AAA server.
> </proposed text>

Yes, it seems to be OK. Thanks!

> 
> You also had many comments on section 5.2, which has now been greatly
> simplified to:
> 
> <proposed text>
> The Mobile-Foreign registration key is also generated by AAAH 
> (upon request),
> so that it can be encoded into a MIP-MN-to-FA-Key AVP, which 
> is added to the
> HAR, and copied by the home agent into a Generalized MN-FA Key Reply
> Extension [15] to the Mobile IP Registration Reply message. Most of
> the considerations for distributing the Mobile-Foreign 
> registration key
> are similar to the distribution of the Mobile-Home Registration Key.
> 
> If the MIP-FA-to-MN-Key AVP is present in the HAR, the home 
> agent MUST ensure
> that the same AVP is present in the AHA. The AAAH MUST ensure 

HAA instead of AHA.

> that this AVP
> is present in the AMA, which is sent to the foreign agent.
> </proposed text>
> 

I think this section should also mention that the FA needs to add 
the Mobile-Foreign Authentication extension to the MIP-Reg-Reply
message.

> 
> Similarly, section 5.3 was greatly simplified to:
> 
> <proposed text>
> If the home agent is in the home domain, then AAAH has to generate the
> Foreign-Home registration key.  Otherwise, it is generated by AAAF.
> 
> In either case, the AAA server encodes the registration key into a

Why do you say "encode", since it is not encoded, right?

> MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message
> sent to the home agent, and waits for the HAA message to be returned.

Shouldn't the HA include a Foreign-Home Authentication Extension to
the MIP Registration Reply AVP?

> 
> If the MIP-FA-to-HA-Key AVP was present in the HAR, the same AVP MUST
> be present in the corresponding AHA, which is eventually 

HAA instead of AHA.

> transformed by
> the AAAH into an AMA message that is transmitted back to the 
> foreign agent.
> 
> Upon receipt of the AMA, the foreign agent recovers the Foreign-Home
> registration key, and uses this key to create a Mobile-Foreign
> authentication extension to the Registration Reply message.

I don't think the last paragraph is correct. I don't see the link
between the Foreign-Home key and the Mobile-Foreign Authentication
extension.

> </proposed text>
> 
> > 27)  Section 2.1, why is the Session-ID is required with 
> {}, but not with
> > [], like in other messages?
> 
> As per the base protocol, the Session-ID is ALWAYS mandatory 
> to be present.

I meant that it should be consistent in all the document, which means
using {} everywhere for the Session-ID AVP.

> > 29) I am wondering why the Destination-Realm AVP is 
> required in Answer
> > messages?
> 
> hmmmm.... noit quite sure, but it doesn't seem to hurt :)

Well, I wanted to ask why the Destination-FQDN AVP is not required
in the AMA? I think it should be in all answer/reply messages, since
the origin-FQDN seems to be required in Request/Query messages, right?

Thanks a lot!
Martin