Subject: [mobile-ip] Issues from Regional Registrations last call - again

From: "Annika Jonsson (EAB)" <[email-masked]>
Date: Thu, 24 Oct 2002 11:01:38 +0200

Hi!

After taking up the work on the WG last call of the Regional Registration draft again, I discovered that there were a few issues that was never resolved during the previous discussions on the list. Here I have summarized them, and our proposed solutions. Comments welcome, of course. A new version of the draft, where all issues rasied during last call are addressed, will be avilable soon... 

issue 1: The option of advertising a GFA Care-of Address of ZERO, 0.0.0.0 will cause MN which does not support regional registration to go into a loop trying to register using this 0.0.0.0 Care-of Address. 

proposed solution:
The FA:s instead advertises a COA of all ones, but the MN still sets the COA field in the Registration Request to all zeroes. In this way, it is clear that the MN understands the all-ones COA field, and not just copied it as a RFC3220 MN would do. If a RFC3220 MN did copy the all ones into the COA field, the FA denies that registration with the error code "poorly formed request".

Issue 2: The proposed Replay protection scheme using timestamp is a problem, because the MN can't synchronize with the GFA.

Proposed solution:
If timestamps are used, the GFA can add a Replay extension to the home registration replay, which includes the GFA time so that tha MN is in synch. with the GFA for subsequent regional registrations.

Issue 3: There is a security issue of including extensions to the GFA in home registrations after the MN-HA Authentication extension without a clear mechanism for protecting these extensions. 

Proposed solution:
Clarify how the authentication extensions should be placed in home registrations. If the MN and GFA has an established security association, the Replay extension and the hierarchical FA extension (used in the co-located case) is placed after the MN-HA, but before the MN-FA authentiocation extension. Otherwise, they are placed before the MN-HA authentication extension. 

Regards,
Annika