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

From: "Alan O'Neill" <[email-masked]>
Date: Mon, 15 Apr 2002 22:23:21 -0400

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-mods-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: Annika Jonsson <[email-masked]>
Date: Mon, 22 Apr 2002 16:32:37 +0200

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

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Thu, 25 Apr 2002 10:16:57 -0400

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