Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 13 Nov 2002 22:31:03 +0100

> The point I was trying to make is that I hear you assuming 
  > the "home network"
  > must have access routers too and that these must be ARs. 

=> No, I wasn't saying that. Sure the home network
can just be a "virtual" link that the MN never connects
to.

  > This assumption seems
  > to be deeply embedded into the MIP document, i.e. all the 
  > discussions about what
  > happens when an MN "returns home," so it is not suprising. 

=> Well, the MIPv6 spec is just covering all cases. It
does not assume a particular configuration.

  > In fact, it could
  > ultimately turn out to be the case that 90% of the home 
  > agents don't host any
  > wireless interfaces and are just a routing box with a huge 
  > cache and lots of
  > reliability features sitting in somebody's network doing 
  > BUs and RR. 

=> Yes, in fact this configurations has advantages like
eliminating any DoS on the MN's HoA based on DAD.

  > That's why I think an AR is different from an HA, and why I 
  > want to preserve and
  > strengthen that distinction.

=> Hmm. It seems that this is not a functional distinction
but one that is based on "likely" use cases. I was
concerned with the functional difference and to me 
there is none.

  > > => BUs are not designed to redirect traffic from
  > > one address to another ??? If you really think so
  > > then this is a comment on MIPv6 in general.
  > >
  > 
  > They are not designed to change routing unless the address 
  > actually does change.
  > What is happening is that the link suddenly goes away and 
  > the host appears on
  > another one. 

=> Well, the address should change in this case.

The address _does not change_ if the PCoA is 
  > being used.

=> It shouldn't be used, why? Because of all
the complexity involved in the current FMIPv6
draft. All this complexity is done to avoid address
duplication. To me, this is an overkill, but I'm not
going to try to remove it from the draft, I just
think HI/HACK should be optional (for the case
where the tunnel is generated based on L2 triggers
only). 

  > >   > Same way as any security is done for any ND message.
  > >
  > > => Which points to the null set today (not considering
  > > manual config).
  > >
  > 
  > RFC 2461 specifies AH, the key distribution needs to be 
  > worked out. SEND is
  > working on it, so at least there is an approach. Is BU any 
  > better? Which way
  > should BU be secured, by manual configuration of an IPsec 
  > SA, as with the HA
  > security association, or by RR as with the CN?

=> This is what should be discussed on this list. 
There are different options:

- IKE
- CGAs
- RR 
-...more

What we should do is see how we can use these or others
and the implications of each case. 

My comment was that both ND and BUs require proof of address
ownership and something like CGAs can solve both problems.
(I'm excluding RAs and redirects from this category because
they need more work)

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Nov 2002 13:59:11 -0800

> concerned with the functional difference and to me

I guess you've lost me there. The function of an AR is to provide last hop
routing service for a wireless link and associated mobile nodes that are using
the link. If an HA can optionally not have any wireless access points and thus
not perform last hop routing service for a wireless link, then how can there not
be a functional distinction?

> => Well, the address should change in this case.

It can't change until RO is complete. And the time required for that depends on
many factors. The FMIP protocol can't assume it will.

> where the tunnel is generated based on L2 triggers

The tunnel is there because it takes a finite amount of time for the RO to
complete and until that happens, the new CoA won't work. The packets routed by
the CN to the old AR will get dropped.

> and the implications of each case.

But why add extra complexity when the design can leverage off an existing
security mechanism (with key distribution planned)? Reuse seems like a big win,
especially when it comes to security protocols.

> (I'm excluding RAs and redirects from this category because

Sure, CGAs came up in the SEND discussion.

            jak

---

From: John Williams Floroiu <[email-masked]>
Date: Thu, 14 Nov 2002 11:38:42 +0100

the discussions on this thread seem to me to point in the direction that a fast handover solution that best fits into 
the current Mobile IP and security architectures must necessarily be built around HMIPv6.

in doing so:
- we mandate the HA functionality exclusively to MAPs, while ARs limit themselves to access control issues --- otherwise 
ARs must provide HA functionality, as already pointed out on this thread;
- we eliminate the need for the (quite disputed in terms of ends, initiation and content) PAR-NAR tunnel --- a "low 
level" MAP has the ability to "switch" the traffic towards the NCoA, as already pointed out (without any problem in 
supporting "anticipation");
- we do not "abuse" the semantics of existing signaling and do not rely on planned but currently inexistent mechanisms;

still MAPs could be deployed hierarchically, so that a better level of privacy would be offered (by "higher level" MAPs) 
to MNs.

it persists the problem related to how fast a NCoA could be allocated.

just my opinion...

John.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Nov 2002 12:55:33 -0800

I want to use HMIPv6 for location privacy, so might others, and the two uses
conflict.

I don't think we want any links in the respective specifications between the
two. In the course of implementing and deploying, there may arise practice that
suggests good ways to combine the technologies. That can be documented at the
time.

            jak

----- Original Message -----
From: "John Williams Floroiu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Hesham Soliman (EAB)" <[email-masked]>;
<[email-masked]>; "Pete McCann" <[email-masked]>; "Karim
El-Malki (EAB)" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 14, 2002 2:38 AM
Subject: Re: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

>
> the discussions on this thread seem to me to point in the direction that a
fast handover solution that best fits into
> - we mandate the HA functionality exclusively to MAPs, while ARs limit
themselves to access control issues --- otherwise
> level" MAP has the ability to "switch" the traffic towards the NCoA, as
already pointed out (without any problem in
> - we do not "abuse" the semantics of existing signaling and do not rely on
planned but currently inexistent mechanisms;
>
> still MAPs could be deployed hierarchically, so that a better level of privacy
would be offered (by "higher level" MAPs)