Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA)

From: [email-masked]
Date: Mon, 16 Sep 2002 11:24:53 -0700

Fully agreed.

However, and this is the reason of the discussion and concern I have. There are scenarios where forwarding from previous COA is useful. Namely when the Home Agents (the home, and all the visited link home agents) have a common group SA. We don't need to describe how this SA is set, but just note that this is a possibility as the spec has it already (in terms of MN home agent list functionality). 

Regards Hannu

-----Original Message-----
From: ext Hesham Soliman (EAB) [mailto:[email-masked]]
Sent: 16 September, 2002 11:16 AM
To: Flinck Hannu (NRC/MTView); [email-masked]; Patil Basavaraj
(NET/Dallas); [email-masked]
Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from
previous CoA)

  > in section 8.3 of MIPv6 spec we have a list of shoulds 
  > against  "all IPv6 routers". Further we say in section 10.2
  > 
  >       " If the node is not a router that implements home agent
  >        functionality, then the node MUST reject the Binding Update
  >        and MUST return a Binding Acknowledgement to the mobile node,
  >        in which the Status field is set to 132 (home 
  > registration not
  >        supported). "
  > 
  > So there are already recommendations for all routers. 
  > 
  > There seems to be a number of ways to interpret the text. 
  > Mine is that that BUs are sent to CNs and Home Agents, not 
  > to (access)routers. I agree that this mentioned in the 
  > context of handovers but so are all the other BUs, even the 
  > BU to set up the primary care-of address registration to 
  > the Home Agent. At least I fail to see the difference.

=> The main problem here is how to setup security
with random ARs. This is _not_ the same as a HA
where there is a strong assumption that most of 
the time manual config will be used. This is 
why the issue needs to be investigated in a lot
more detail than the MIPv6 spec can do now given 
the time limitations and difficulty of the problem.
Using manual config with random ARs is not
going to be useful in most deployment cases. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Sep 2002 23:04:14 +0300

[email-masked] wrote:

> However, and this is the reason of the discussion and concern
> I have. There are scenarios where forwarding from previous COA is
> useful. Namely when the Home Agents (the home, and all the visited

I don't think anyone is arguing that prev-CoA-forwarding would not be
useful. It is potentially very useful. There's been two kinds of
arguments against placing it in the base RFC. One, that there would be
a better place for it in the fast handoffs work. Two, while the security
story is technically correct, it isn't necessarily practically deployable.

 > link home agents) have a common group SA. We don't need to describe
 > how this SA is set, but just note that this is a possibility as the
 > spec has it already (in terms of MN home agent list functionality).

Unfortunately, we don't have any publicly available, specified magic that
can take care of this. We *do* allow home agent discovery but at the same
time we require the security set-up for these HAs to be in place beforehand.

When a set of HAs take care of a common set of MNs, we can either set all
combinations of SAs manually, or use dynamic keying where the HA side of
the security policy data base ties the specific user identities with
their rightfully owned home addresses. The security policy data base
could be automatically shared between the HAs.

However, if we try to extend this to all routers within a specific area
we run into some additional trouble. One problem is that the number of
SAs in the manual case grows unreasonably large when each MN needs an
SA to every place where it might possibly go to. This also applies to
the address-specific policy data base that we need even if dynamic keying
is used. In the multiple-HA case the size of the necessary data bases
is proportional to the number of home addresses. In the prev-coa-forwarding
case its proportional to the number of interface IDs times the number of
prefixes.

Since all of this is pretty much based on addresses, we need
to ensure address uniqueness even for care-of addresses on the whole
network and not just at one link. There may be other issues that we
haven't thought of -- has someone done this on a large scale somewhere?
Anyway, none of the issues are unsolvable but I'm not convinced that
we have all the answers yet that we can confidently claim that the
thing works and can be deployed. (I'd like to be convinced otherwise,
perhaps some of you have all the answers.)

Jari