Subject: RE: [mobile-ip] Last Call: Regional Tunneling input

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 24 Apr 2002 11:54:43 -0400

Hi Dana,

Completely sympathise with your position on this. Some clarifications
in-line..

Alan

>
> Now this means that an upgraded HA can always tell if an initial home reg
> came via a GFA...a good thing in my book.
> Unfortunately, a legacy HA will fail this reg - again a good thing in my
> book..more pressure on IT department/operator to upgrade the HA.

I don't think it's good when protocols deployed to potentially millions
of devices are not backward compatible.  You are making an implicit
assumption about common administration of the MN, FA, GFA, and the HA
by the same entity (IT department, ...).  This is not a valid
assumption for internet connectivity.

AWO> No - I am only mentioning not requiring a special relationship between
MN and HA in the administration plane.

Remember,
> the HA and MN share a unique relationship and having them on widely
> different MIP versions for any length of time is somewhat perverse to me.

Disagree for the same reasons again.  If the base mobile IP protocol
is broken (and I don't belive it is), then we should fix it before
it gets too widely deployed.  Otherwise, changes to the MN, FA, and
HA functionality MUST be backward compatible.  I don't believe
introducing a new and unecessary layer of fixed heirarchy
is important enough to break backward compatiblity.

The necessary test for this draft should be backward compatibility.
But that may not be sufficient to warrant a new RFC.

AWO> Sure..see my other e-mail on the higher layer issues...

thanks,
Dana

> What is therefore missing is to enable the GFA to insert the assigned GFA
> CoA into the RREP for the MN if the HA failed to do so. The second attempt
> can therefore still succeed to the legacy HA. Each refresh under the same
> GFA also works and we only have a problem again on each GFA change-over
> whilst the MN and HA are on such different versions...
>
> Alan.
>
> /Annika
>
> At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
> >Below is the abstract for the draft that makes last call suggestions on
> >Regional tunneling.
> >
> >see
> >http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mo
> ds-00.txt
> >
> >Abstract
> >
> >    Regional Registration modifies the normal MIP Registration signalling
> >    back to the HA so that the signalling can traverse an intermediate
> >    Gateway Foreign Agent (GFA). The registered binding is
> between the Home
> >    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
> >    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the
> GFA.
> >    Two extensions are defined to support this new Registration
> processing
> >    these being the Hierarchical Foreign Agent extension (HFAext) and the
> GFA
> >
> >    IP address extension (GFAIPext). The former is used to carry
> the FA CoA
> >    to the GFA and the latter is used by the FA to allocate a GFA to the
> MN,
> >    and by the FA, GFA, HA to securely return the GFA IP address
> to the MN.
> >
> >    The present processing rules for the HA registration enable the FA to
> >    advertise the GFA to the MN in a Foreign Agent Advertisement
> (FAA) and
> >    for the MN to include that GFA address into the CoA field of the MIP
> home
> >
> >    Registration. This however assumes a number of things about the GFA
> >    address in the FAA and the addressing realms between the FA-GFA and
> GFA-
> >    HA.. Specifically, the GFA CoA and the GFA IP address must
> potentially
> be
> >
> >    from two different addressing plans and hence cannot be in the same
> FAA.
> >    This draft describes the issues and suggests a solution that requires
> >    slight modifications to the required extensions, that generalises the
> >    Home Registration signalling for arbitrary intermediate MIP
> nodes, and
> >    only slightly modifies the processing rules for the MIP Home
> >    Registration. This draft also describes a way to support dynamic HA
> >    allocation along-side Regional Registrations.

---

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 25 Apr 2002 22:34:57 -0400

Hi Madhavi,

Good point.

In the context of [RegTunMods] I would restate this as follows;

The FA adds the GFAIPext to inform the HA of the CoA, and to enable the HA
to return the GFA address to the MN. The latter is so that next time the MN
can insert the CoA itself in the next RREQ and also enables the MN to
register directly to the GFA with a CCoA.

Now RegTunMods suggests splitting the GFA address into two bits. 

1) The GFAIPext is the address of the GFA from the MN and FAs perspective
and can therefore always appear in a FAA for movement detection unless a
dynamic allocation is to be made by the FA. In this case though, the FA
simply sends to the GFA. The FA then inserts GFAIPext in the RREP to the MN
protected by the FA_MN authext. The problem you raise goes away here.

2) The GFA CoA is the address of the GFA from the perspective of the HA and
therefore should go into a HFAext (not GFAIPext) inserted by the GFA (and
not by the FA) and sent to the HA protected by the GFA-HA auth ext.  This
repeats the general hierarchical HFAext mechanism that can used by the FA to
inform the GFA of a dynamically assigned FA CoA. Once again the problem goes
away. Note that the HFAext does not need to be returned to the MN but must
be returned just to the GFA so it knows that the HA processed the HFAext.

Therefore, in this more general model we can deal with disparate addressing
plans yet still protect all exchanges..

Alan.

-----Original Message-----
From: Madhavi W. Chandra [mailto:[email-masked]]
Sent: 25 April 2002 23:47
To: Annika Jonsson; [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] Last Call: Regional Tunneling input

Hi Annika and Charlie,

Putting RFC issues aside for a moment, please clarify a 
technical doubt...

If the MN sets the CoA field to 0.0.0.0, then the
FA assigns a GFA and appends the GFA IPext to the RRQ.  The
HA extracts the GFA CoA from the GFA IPext, and sets up the
tunnel end point to this GFA CoA.  However, it is not mandatory
to protect the GFA IPext with the FHAE.  I'm wondering what
the security implications of this are...since the tunnel
endpoint may be determined by an unprotected extension.  It
seems more susceptible to MN traffic hijacking by a 
man-in-the-middle.  What are your thoughts?

Thanks,
Madhavi

On Mon, Apr 22, 2002 at 04:32:37PM +0200, Annika Jonsson wrote:
> Hi Alan,
> 
> I have read your suggestions, and I have a few comments.
> 
> First, regarding the dynamic allocation of HA: we do support that in the 
> current draft. We assume that it is the GFA that participates in the 
> authentication procedure as AAA client and not the FA (see section 3.1.2).

> The reason for this is that it is the GFA that acts as FA towards the HA, 
> and therfore needs the keys for securing registration messages. So, in
this 
> way, a AAA server can dynamically allocate an HA, and the GFA will be 
> informed about this.
> 
> Second, the problem with how to handle different addressing plans between 
> FA - GFA and GFA - HA. I agree that this should be supported. Let's see if

> I understand your suggestion correctly:
> * The GFA address advertised in the Agent Advertisement should be the 
> "local" address of the GFA, where it can be reached from the FA.
> * A Home registration from a MN should never include any CoA address
> * The FA sends the registration req. on to the GFA "local" address
> * The GFA allocates CoA to the MN
> * The GFA IP extension (forget the name change for now...) should be used 
> to transport the selected CoA to the HA and to carry the selected CoA back

> to the MN, as is already the case in the draft.
> 
> I agree that dynamically allocating the CoA is the best way, and it seems 
> resonable that this is the responsibility of the GFA and not the FA. But, 
> the reason why we didn't specify that all MN:s must use that method is
that 
> we wanted to be backwards compatible wiht HA:s that does'nt specifically 
> support Regional registrations (or rather, the GFA IP extension). If MN:s 
> are allowed to put the CoA in the Registration request, the HA will never 
> need to know that the visited network uses regional registrations, and the

> GFA will look lika a normal FA. I still think this is a good feature.
> 
> To allow this, the FA must advertise a publicly routable GFA (CoA)
address. 
> If the FA and GFA belongs to a private address domain, the FA needs to
have 
> a mapping from the public CoA address to the private GFA address that it 
> should use to send the Registration request to. I think this solves the 
> problem.
> 
> To summarise, I suggest that we:
> * clarify that dynamic allocation of CoA is preferable
> * add that the FA might use another address to communicate with a GFA than

> the CoA advertised, and that it in that case needs a mapping between these

> two addresses
> * change the allocation of CoA and use of the GFA IP address extension, by

> saying that it is the responsibility of the FA to select GFA, but not to 
> include any GFA IP extension, because it is the responsibility of the GFA 
> to allocate CoA, and it will add the GFA IP extension.
> 
> Do you agree that this solves the problems you raised?
> 
> /Annika
> 
>http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt
> >
> >Abstract
> >
> >    Gateway Foreign Agent (GFA). The registered binding is between the
Home
GFA.
processing
GFA
> >
> >    IP address extension (GFAIPext). The former is used to carry the FA
CoA
MN,
> >    and by the FA, GFA, HA to securely return the GFA IP address to the
MN.
> >    advertise the GFA to the MN in a Foreign Agent Advertisement (FAA)
and
home
GFA-
> >    HA.. Specifically, the GFA CoA and the GFA IP address must
potentially be
FAA.
> >    Home Registration signalling for arbitrary intermediate MIP nodes,
and

---

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 25 Apr 2002 22:35:00 -0400

Hi Annika,

You said..
I think that you misunderstood me (or I you). What you say here is more or 
less what I meant. The only difference is that I still think that an FA 
could in most cases advertise a GFA CoA. This should be a public address, 
sort of a "default CoA", that an MN MAY use, e.g. if it's HA doesn't 
support the GFA IP extension. By specifying that an MN SHOULD set the CoA 
field in the Registration request to zero, that method will be used in most 
cases. I agreed that we could change so that the FA only forwards the 
registration to the GFA, and the GFA selects CoA, and adds the GFA IP 
extension. I don't think that this requires the FA to have an extensive
mapping 
knowledge. It needs to know the address to use to send the registration 
request to the GFA, but you can never get away from that.

AWO> I think we will call it a mutual misunderstanding ok :-)

So It is still not quite clear to me what you are suggesting...My logic
which I think is similar would be...

1) That the FA advertises the default GFA in the FAA for movement detection
reasons (but may not)..

2) f present, the MN SHOULD NOT use this as the GFA CoA in the first RREG to
a new HA

3) If the MN detects that the HA does not support GFAIPext then the MN can
try to use the GFA address in the FAA as the CoA.

Is that what you mean and do we differ by the fact that you wish the GFA in
the FAA to be public whilst I am happy for it to be public or private and
then rely on NAT higher in the topology....

Now when applied to RegTunMods, the last line becomes

3) If the GFA detects that the HA does not support HFAext, then it informs
the MN who can try to use.....

Now Ahmads suggestion on how to deal with legacy HAs, by the GFA detecting
if a GFAIPext is not returned, must now be revised as follows..

We are now interested in finding out if the HA pocessed the HFAext which
contained the GFA CoA. Therefore, the HA should return the HFAext to the
GFA, protected by the HA-GFAauthext to indicate this. The GFA then knows
whether or not to return an  error to the MN.

Progress or are the waters muddying ?

Alan