Subject: RE: [mobile-ip] Regional Registration Last Call issue #3

From: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 15 May 2002 13:41:39 -0500

Annika;
Please see my comments inline.

Regards;
Ahmad Muhanna

> 
> 
> Hi
> 
> Here are my conclusions and proposals for additions/changes 
> to solve most 
> of  the technical  issues raised during last call of Regional 
> Registrations. I have excluded the issues around multiple levels of 
> hierarchies, which will be dealt with separatley.
> 
> Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the 
> recommendation. And on the response put in the subject line, 
> CLARIFICATION 
> if you have a clarification to recommend, or ISSUE if you 
> have an issue to 
> raise.
> 
> A. Differnet addressing realms.
> 
> The issues raised about supporting different addressing 
> realms between 
> FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those 
> addressing realms). The basic problem is how to allow for 
> flexibility in 
> addressing between FA-GFA and GFA-HA, which does not work 
> with the way the 
> draft specifies the use of GFA CoA today. To allow this, it 
> should be the 
> GFA that decides wich CoA to use, possibly individually for 
> each MN. To 
> support this, the following changes are proposed:
> 
> - clarify that a MN that supports regional registrations 
> SHOULD send home 
> registrations with a zero CoA, to allow the GFA to allocate 
> CoA. (it is 
> SHOULD and not MUST, because if the MN's HA doesn't support regional 
> registrations, it should be allowed to use an advertised CoA, 
> see mail on 
> issue #2). An FA can force the use of zero CoA by not 
> advertising any CoA 
> address, but it will then not be backwards compatible (see 
> mail on issues 
> #2). This will be clarified in section 4.1.

I DISAGREE.

Mail on issue #2 does not talk about the FA advertising NO Care-of
Address(es).
It talks about advertising one care-of Address and that one is set to ZERO.

There is no Foreign Agent allowed to claim that it is a Foreign Agent and at
the same time
advertise NO care-of address(es). (this is a violation of RFC3220 section
2.1.1.)

> 
> - change the allocation of CoA if the MN uses zero COA in the 
> registration: 
> in the draft right now, it is the FA that decides what CoA 
> the MN gets. 
> This should be changed so that the FA only forwards the 
> registration to a 
> GFA node (using an address in the address realm between the 
> FA-GFA). Then 
> the GFA selects the CoA (possibly based on the MN:s HA 
> address, or  MN-NAI 
> if present, or information from AAA server etc...), adds GFA 
> IP extension, 
> protects it with FA-HA auth- extension and sends it to the 
> HA. This will be 
> changed in section 4.2, 4.3 and 8.1.
> 
> - clarifiy that if the FA advertises a GFA CoA, this is regarded as a 
> "default" CoA that could be used, especially by MN:s that 
> supports regional 
> registrations, but have HA:s that don't. If this CoA is not 
> within the same 
> addressing realm as the FA-GFA, the FA needs to have a mapping to the 
> address that it should use to communicate with the GFA. This 
> will be added 
> to section 4.2
> 
> B. too many options.
> 
> Some people commented that it is a problem with too may 
> optional ways to do 
> things, since it would be difficlut to imlement and can 
> create problems for 
> interoperability.
> 
> - Most of the options are around the advertised addresses and 
> what address 
> the mobile node uses in registration messages. Hopefully this is much 
> better now that we clarifies the use of those addresses both 
> for backwards 
> compatibility and for different addressing realms, so I 
> consider this issue 
> solved
> 
> C. protection of the GFA IP address extension
> 
> It was pointed out that the GFA IP address extension needs to 
> be protected 
> by an authentication extension.
> 
> - this should be clarified in section 4.3.
> 
> D. reverse tunnelling clarification
> 
> It was pointed out that if reverse tunnelling is used, the FA 
> must use the 
> address in the registration request (from the HFA extension) 
> as source for 
> the tunnel.
> 
> - this should be clarified in section 4.2 and 4.3.
> 
> E. Generalized NAI extension
> 
> There was a question about why the Generalized NAI extension 
> is needed, why 
> not use an FA-NAI extension directly?
> 
> - RFC3220 recommends that new extensions should be in this format if 
> possible. Therefore I propose that we keep this.
> 
> F. added delay with extra round-trip
> 
> It was pointed out that if the FA is allowed to deny a regional 
> registration because it doesn't support that GFA, this means 
> one extra 
> round-trip before the registration is completed, which could 
> lead to extra 
> delay for traffic.
> 
> - That is true, but I still think we should allow this 
> feature because:
> *  the first "round-trip" is very short, only to the FA and back.
> * FAs in the same domain should in most cases support the 
> same GFAs so this 
> would not happen very often.
> * allowing an FA to deny the use of a specific GFA would be 
> useful, for 
> example if a GFA breaks down, since it would force the MN to 
> register a new 
> GFA with it's HA.
> * the FA needs a way to deny unvalid registrations, in this case if a 
> mobile node uses a non-existent CoA in the registration request.
> 
> Therefore I propose that we don't change this.
>

I DISAGREE.

There is a big difference between the standard proposing a behavior for the
Foreign
Agent to be used in case the Mobile Node did not follow the standard, like
in the case
when the FA receives a Registration Request with an invalid care-of address,
as 
indicated in RFC3220, and of a protocol allowing the Mobile Node to act
NORMALLY
and STANDARD COMPLIANT and the same time considers it as an error scenario.
 
> Regards,
> Annika

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 15 May 2002 15:38:40 -0500

Hello Annika,

Clarification: Missing technical issue 1:

In section 4.1 the third paragraph it talks about Mobile Nodes
with co-located care-of address and the way it uses
Regional Registration. This section is under Home Registration.
This means that it does not talk about the Regional Registration mechanism
YET. Because that has a separate section No. 5.

Now in the third paragraph section 4.1 as shown below, it talks about the 
Mobile Node adding a Hierarchical Foreign Agent extension and to be placed
after the MN-HA authentication extension in Registration Request message. 
Also, to be protected by the MN-GFA authentication extension. It also
continues 
to say using the mobility security association which has been established
with 
GFA according to section 3.1.2.

" ........... 
   In this case, the mobile node MUST add a
   Hierarchical Foreign Agent extension 8.2, including its co-located
   care-of address, to the Registration Request before sending it.  The
   Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA
   authentication extension.  It SHOULD be authenticated by using the
   MN-GFA authentication extension (see Section 10).  The authentication
   data SHOULD be calculated using a mobility security association
   that has been established with the GFA (Section 3.1.2). ...........
"

I am really confused here for the following points: 
1. We are talking about Home registration. Which I understand is the initial
registration with the Mobile Node Home Agent or when it changes GFA.
However,
the text talk about the initial registration request here.
2. Now at this point of time, there is no established mobility security
association
between the mobile Node and GFA.
3. section 3.1.2, talks about using the mobility security association, which
has been 
established during the initial (Home Registration), in Regional Registration
NOT Home
Registration.
4. In other words, Mobile Node does not have a mobility security association
with the
GFA at the time of initial or Home registration that paragraph 3 talks
about.

Am I correct ? or I am missing something. 

Clarification: Technical issue 2:
In section 8.3 paragraph 3:
"
   The mobile node SHOULD append the Replay Protection Style Extension
   to the home registration following the MN-HA authentication
   extension, but before any MN-GFA authentication extension.  Then,
   the GFA can remove the extension without damaging the MN-HA
   authentication data needed by the home agent.
"

Do we assume here that there is a statically preconfigured security
association 
between the MN and GFA which include a secret key?

This issue is very much related with Technical issue No. 1.

Clarification: Technical issue 3:
In section 5.3. First Paragraph:

" If the GFA accepts a request for regional registration, it MUST set
   the lifetime to be no greater than the remaining lifetime of the
   mobile node's registration with its home agent, and put this lifetime
   into the corresponding Regional Registration Reply.  The GFA MUST NOT
   accept a request for a regional registration if the lifetime of the
   mobile node's registration with its home agent has expired.  In that
   case the GFA sends a Regional Registration Reply with the value in
   the Code field set to HOME_REG_EXPIRED.
"

Are you suggesting that the GFA keeps the binding of the Mobile Node EVEN
after the Home registration lifetime has already expired?

Clarification: Technical issue 4:
This is not a technical issue per say BUT it is important in my view:

Why you are suggesting two different extensions with two different types 
for the following extensions:

1.	GFA IP Address Extension
2.	Hierarchical Foreign Agent Extension.

CAN'T we use one extension as per MEIR originally and RFC3220 recently
with one TYPE and two different subtypes. 
You never know, those type numbers are going to be very precious 
in the very near future!!!

Regards;
Ahmad Muhanna

---

From: Annika Jonsson <[email-masked]>
Date: Fri, 17 May 2002 10:59:20 +0200

Hi Ahmad,

>It talks about advertising one care-of Address and that one is set to ZERO.

I was just careless, with NO CoA, I meant ZERO CoA. As you pointed out, 
there are problems with this approach also, and I am thinking about how to 
solve that.

>There is no Foreign Agent allowed to claim that it is a Foreign Agent and 
>at the same time
>There is a big difference between the standard proposing a behavior for 
>the Foreign
>when the FA receives a Registration Request with an invalid care-of 
>address, as

I disagree, I think that this message, which is the way to tell the MN why 
a registration was denied and not necessarily an error, can and should be 
used even if the MN did everything correct if something in the network 
makes it impossible. The MN did not cause an error, but it needs to know if 
something else went wrong. RFC3220 has several such codes for the 
registration reply, such as: "administratively prohibited", "insufficient 
resources", "home network unreachable" etc.

Regards,
Annika

---

From: Annika Jonsson <[email-masked]>
Date: Fri, 17 May 2002 13:50:47 +0200

Hi Ahmad

At 03:38 PM 5/15/2002 -0500, Ahmad Muhanna wrote:

>registration with the Mobile Node Home Agent or when it changes GFA. However,
>3. section 3.1.2, talks about using the mobility security association, 
>which has been
>established during the initial (Home Registration), in Regional 
>Registration NOT Home
>Registration.
>4. In other words, Mobile Node does not have a mobility security 
>association with the
>GFA at the time of initial or Home registration that paragraph 3 talks about.
>

You are right. We have obviously not put enough effort on the co-located 
case ;-) This should be clarified, so that in the home registrion, it's the 
MN-HA auth. extension, and in the regional registration, it's the MN-GFA.

>This issue is very much related with Technical issue No. 1.

see above.

>after the Home registration lifetime has already expired?

No. This should be changed so that when the GFA gets a regional reg.and it 
doesn't have any home reg. for this MN, it should use a code like 
"NO_HOME_REG".

>in the very near future!!!

Yes, we should.

Thanks,
Annika