Subject: RE: [AAA-WG]: Comments on draft-mobileip-03

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 10 May 2001 15:06:27 +0200

My comments enclosed.

> > 4-Last paragraph of section 1.0, the attendant can also be 
> an HA, when
> > the MN is in the Home Domain and the HA is co-located. That 
> should apply
> > to all the document where you refer to the attendant, while 
> having in 
> > parenthesis the FA.
> 
> ok. I fixed the main document, but section 1.0 is giving me 
> some problems.
> I currently have:
> 
> "In this document, the role of the "attendant" [3] is 
> performed by either
> the home or foreign agent for the Mobile-IP Extension, and these terms
> will be used interchangeably."

You could specifying that it is valid only for the HA which is acting
as co-located.
 
> > 6- Second paragraph of page 6, I'm still wondering why a 
> DIAMETER_ERROR_BAD_HAR
> > is required? What is it supposed to mean? We do not have 
> this type of generic
> > error for any other extension, and I don't see why we 
> should have this for MIP.
> 
> If a Home Agent was requested, and the home agent is not 
> available, then
> the error is returned. This could occur if the mobile 
> requested a home agent
> that it is not allowed to, or if the home agent is no longer 
> available.

I thought that DIAMETER_ERROR_HA_NOT_AVAILABLE was meant for that?
The thing is that with the DIAMETER_ERROR_BAD_HAR, it does not
seem to be clear for the client to know what to do, for example,
simply request a new HA.

> > 7- Page 8, second par., the thing is that I think that AAAH 
> can determine that
> > the MN has moved to a new domain by using the Origin-FQDN and the 
> > MIP-Previous-FA-FQDN. However, I'm wondering if the 
> MIP-Previous-FA-FQDN is
> > enough, since the FQDN is highly dependent on the realm of 
> the MIP-Previous-FA-XXXX,
> > right? You can only tell that the MN is moving between 
> domain based on the Realms.
> 
> Correct, so you will have to remove all the data, and the 
> first dot, in the
> fqdn, and that will produce the realm.
> 
> Did I miss the question?
> > 
> > And now, let's say that the HA is located in the former 
> domain, then how can the 
> > AAAF knows that the MN has registered in an other domain? 
> The MIP-Previous-FA-FQDN
> > can not really help, since it will be in that domain from 
> where it moved. The
> > AAAF does not have any mean of knowing the originator of 
> the AMR, AFAIK. I guess
> > that a MIP-Registering-FA-FQDN AVP should be added for that purpose.
> 
> I really don't understand the problem (sorry, a little dense 
> today), but
> I see that you believe that a new AVP would be required that 
> contains the
> identity of the foreign agent, right? And why is that?
 
Rereading my question, I guess it was not really clear. Let's
try it again.

In fact, you should refer to page 9, the last paragraph. It is
mentionned that the AAAH can used the MIP-Home-Agent-Address and
the MIP-Previous-FA-FQDN to detect if the MN has moved to a new
domain. Here are the problems:

1) In section 5.5, it is said that the MIP-Previous-FA-FQDN is
sent by the MN while roaming within the same domain. If it remains
like this, I guess it would not be possible to detect that the MN
has moved to another domain based on that AVP, since it might not
have beed included.

2) I think that MIP-Home-Agent-Address and the MIP-Previous-FA-FQDN
AVPs are not enough to detect that the MN has moved to a new domain. 
I think that the only way that an AAAH can detect it, is by using 
the Origin-Realm and the MIP-Previous-FA-FQDN. Then, it could compare
the Origin-Realm of the FA (the new) with the FQDN of the previous FA,
i.e. MIP-Previous-FA-FQDN.

3) The problem with the previous comment, is that the MIP-Previous-FA-FQDN
does not represent the realm of the previous domain, only the FQDN of the
FA, which might be only routable by the AAAF, right? I am not sure that
the discussion we had on the mailing list a while ago suggested that the
FQDN (let's say ABC.com) was the realm plus another name 
(let's MACHINE1.ABC.com). That does not make sense to me at least. If it
would have been like that, I would argue that we do not need two 
destination FQDN and Realm.

4) The decision to reject the access to the HA seems to be possible by
the former AAAF. The thing is that I don't know how it can know that 
the MN has moved for sure to another domain. Based on the 
MIP-Previous-FA-FQDN does not help, since it will most probably be
in that domain as well, since the MN has just moved out of it to
another domain, right? Also, the Origin-Realm of the AMR, which 
identifies the originating FA, is not available in the HAR, only
in the AMR. So, unless we had in the HAR an AVP for the Origin-FA,
I do not see how the former AAAF could perform policies to reject
such a service.

I hope it is a bit clearer.

> > 13-Section 5.7, I guess that when the 
> MIP-Mobile-Node-Address and the MIP-Home-Agent-
> > Address AVPs are not in the message, the AAAF and the AAAH 
> knows that Home-Agent is
> > requested and that a Mobile-Node-Home-Address is requested. 
> I don't see the need for
> > those 2 flags.
> 
> ok, I see your point. The information is redundant. However, 
> I don't really
> like that a zero HA or home address doesn't require that the 
> AVP be present,
> since a -1 value DOES require that it be present.
> 
> Do others agree that these two bits should be removed?

The thing is that the spec especially mentions in section
2.1, that if those flags are set, those AVPs MUST NOT be
present in the message. 

I would tend to agree that I would
prefer that decision to be left to the AAAH, or the AAAF, 
to decide the meaning of the content of those AVPs, instead of 
not sending the AVPs of setting a flag.

> > 14-Page 20, par.3, I don't think it is the correct meaning. 
> My understanding, after
> > talking with Tony Johansson, is that the 
> Home-Agent-In-Foreign-Network is used when
> > the MN requests a Home-Agent, and that the AAAF detects 
> that it is located in its
> > foreign domain, before it forwards the AMR to the AAAH.
> 
> It now reads:
> 
> "If the mobile node requests a home agent in the foreign 
> network either
> by setting the home address field to all ones, or by specifying
> a home agent in the foreign network, and the AAAF authorizes
> the request, the AAAF MUST set the Home-Agent-In-Foreign-Network
> bit to one."

Then, should an AAAF return a DIAMETER_ERROR_HA_NOT_AVAILABLE 
when it can not allocate it?

> > 22- Section 8.2 and 8.5, should be "by the user" instead of 
> "to the user".
> 
> Output packets and octets are those sent to the user, not by the user.
> You are confusing these with the input counters.

The confusion is from what you say for Input and what you say for
Output. In 8.1, you say "received by the user", and in 8.2, you say
"sent to the user". Maybe you meant, in 8.1, "received from the user"?
Also apply to 8.4 and 8.5.

If there is something more I should know about the difference between
them, maybe it would be good to add some more text in the descriptionç
of those AVPs.

> > 
> > 23-Some updates to the table 10.1 as follows:
> > 
> >                                  +-----------------------+
> >                                  |      Command-Code     |
> >                                  |-----+-----+-----+-----+
> >    Attribute Name                | AMR | AMA | HAR | HAA |
> >    ------------------------------|-----+-----+-----+-----+
> >    Authorization-Lifetime        | 0-1 | 1   | 1   | 1   |
> >    Destination-FQDN              | 0-1 | 1   | 0-1 | 1   |
> >    Destination-Realm             | 1   | 0   | 1   | 0   |
> >    Error-Reporting-FQDN          | 0   | 0-1 | 0   | 0-1 |
> >    Auth-Extension-Id             | 1   | 1   | 1   | 1   |
> >    Filter-Rule                   | 0   | 0-1 | 0-1 | 0-1 |
> 
> No, you can have more than on Filter-Rule AVP.

Then, please change the message's ABNF to reflect the *.

Thanks a lot for your answers.
I'm impressed, as usual.
Martin

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 12:07:25 -0700

> seem to be clear for the client to know what to do, for example,

oops, I was a little too quick in responding to the question, and you
are correct, the error message *BAD_HAR is really not required, as 
there are more useful error messages in the base protocol.

> has moved to another domain based on that AVP, since it might not

sure.

> i.e. MIP-Previous-FA-FQDN.

yes, this does make sense, and I have made the change.

> destination FQDN and Realm.

It is, and the reason why we have two separate AVPs is to reduce the amount
of work done on proxies. This has been done in RADIUS via some vendor-specific
AVPs, because otherwise each proxy must extract the FQDN, and retrieve the
Realm. Not alot of work, but very repetitive, so let's save some CPU
cycles while we can.

And, btw, if we only had the Destination-FQDN,  it wouldimplies that a
message would have to be sent to a specific Diameter entity, not
any one in a given domain.

> I do not see how the former AAAF could perform policies to reject

yes, I agree that this is required to make the necessary policy decisions.

> 2.1, that if those flags are set, those AVPs MUST NOT be

not sure this really needs to be a MUST NOT.

> not sending the AVPs of setting a flag.

Well, the flags *are* necessary for accounting purposes. No way
around that. The Feature-Vector in the accounting message will
provide some details on the type of session being provided. At
the same time, you want the home address and agent to be in the
accounting record, so including the zero or all ones in the
accounting message would be bad.

So, bits are necessary. The real question is whether it really makes
sense to state that the AVPs MUST NOT be included if the bits are
set.

Anyone?

> when it can not allocate it?

yes.

> Also apply to 8.4 and 8.5.

so "received by the user" -> "received from the user"
"sent to the user" stays the way it is.

right?

> them, maybe it would be good to add some more text in the descriptionç

no, just poor choice of english words on my part :(

Thanks again,

PatC