Subject: [seamoby] The right protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr oblem-00-a1.txt

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 29 Jan 2001 00:36:40 -0500

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 10:01 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [seamoby-mm] ietf-seamoby-mm-problem-00-a1.txt
> 
> 
> > Hi Pat,
> > 
> > > Figuring out that Mobile IP DOES solve all of the problems 
> > > *is* success, btw. Success is not measured by the fact that 
> > > we create a protocol only, since reducing the work load in 
> > > IETF working groups is still an IESG concern (and
> > > protocols with duplicate functionality is one of mine).
> > 
> > Just a procedural question.  Would it be in scope of
> > SeaMoby (maybe after rechartering) to specify how MIP
> > can be used to support Seamless Mobility?  There
> > are a lot of options (headers, etc) for MIP and
> > if MIP was suitable for SeaMoby needs, I think some
> > work might still be needed.  
> > 
> Let me preface this e-mail with a statement that I am NOT 
> against work going
> on here. Some people seem to imply that is the fact. I am 
> just waiting to see
> the problem statement to be convinced.
> 
> I believe that if we can identify changes to the Mobile IP 
> protocol that would
> provide requirements that we've identified, then I think it 
> is within our
> scope. What we may need to do, is create a draft, and once we have WG
> concensus, punt it over to the MIP WG for review.
> 
> PatC
>

Pat,

I have some IP network problems.  I want to know what is needed to provide a
solution.

Problem 1:

I have one Bluetooth access point at home and one work.  Is my domain the
entire city?

Do I gain anything meaningful by treating each access point as part of a
single domain, or is it just extra overhead that can be reduced with the
right protocol?

Problem 2:

I have one Bluetooth access point in my office and one one 802.11 access
point in my office.
And no other access points in the building.  Is each access point also a
seperate domain?

Do I gain anything meaningful by giving each access point a seperate domain,
or is it just extra overhead that can be reduced with the right protocol?

Problem 3:

I have one access point in my office and with one Bluetooth interface and
one one 802.11 interface in my office.
And no other access points in the building.  Is each interface also a
seperate domain?

Do I gain anything meaningful by giving each interface a seperate domain, or
is it just extra overhead that can be reduced with the right protocol?

Problem 4:

I have an office cubicle in large room filled with office cubicles.  It just
so happens that each co-worker has decided on a different access technology
such that when I traverse the room with my PDA the following switching
happens every four feet:

Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11

Since each is considered an "inter-domain" handoff I suppose I can use
SeaMoby.

But suppose, as I enter a hallway it is completely 802.11 and intra-domain.

So, should I go the IESG and request second handoff protocol?

But, as I enter another hallway it is completely bluetooth and intra-domain.

So, should I go the IESG and request third handoff protocol?

When I step outside and switch to GPRS will I be using a fourth protocol
while I drive home?

What would the IESG think if we could have a single protocol that could
handle all edge handovers and let MIP handle core handovers?
Looking at the SeaMoby roadmap I see that by Mar 01 we must submit a revised
charter.

Can we accommodate the above four problems without a revised charter? 

- Kulwinder.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 29 Jan 2001 05:30:38 -0800 (PST)

[lots'a stuff on inter technology handoff and ping pong situations]

> handle all edge handovers and let MIP handle core handovers?

Again, how is an edge handoff different from a core handoff? 

Folks, the reason why I am playing the devil's advocate is because I need the
same answers to the questions that will be asked of me when I move our problem
statement to the IESG. If I have no answers to obvious questions, then it
doesn't look good.

The problems you described above are already handled today, and even more so
with the fast handoff work. HOWEVER, some discussions we've had on handoff in
the network (edge) being related to AR/AP capabilities is not a Mobile IP
thing, so there are certainly some differences there.

> Can we accommodate the above four problems without a revised charter? 

no. We need to hand in our problem statements, and the re-charter will provide
the IESG with a go/no-go on each problem. The end result could be that we only
work on a subset of our existing charter, if some problem statements don't
provide the convincing arguments.

Hope this helps,

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 29 Jan 2001 15:28:01 -0800 (PST)

> We know that Mobile IP requires tunneling and authentication (IPSEC).  Could
> we somehow insert into the problem statement that we need a mobility solution
> where Mobile Device and Server are within the same trusted domain and address
> space, therefore tunneling and IPSEC are not needed.    I don't think Mobile
> IP is addressing mobility solutions that don't require tunnels and
> authentication. The best example I can think of is enterprise mobility.

But we know that IETF doesn't typically work on protocols that don't scale
across the Internet (well, sometimes they do, but shouldn't). I would be
sceptical to create a protocol that does assumes trust in a local subnet (even
more so in the nets that I know need this kind of technology).

> 
> Problem statement text:
> Current mobility standards require tunneling and authentication.  In a
> trusted  domain where both IP endpoints already trust each other and share
> the same address space, tunneling and authentication are not needed.  A good
> example is site local addressing in IPv6.

The problem statement that was made some time back, by yourself, was mobility
within a subnet. I don't know what happened to that one, because that's where
Mobile IP doesn't work. Some comments were made at the last IETF about the
fact that the AP and the AR may be in different boxes, and the fast handoff
work doesn't work well in those scenarios. This same protocol could be used
between the 3G* RAN and core networks. I am sure there are plenty of other
examples where such a protocol would be required.

BTW, some additional information that I've found out today is that the v6 fast
handoff requires a secured binding update between the mobile and the new
access router. I can tell you right now that a full IKE negotiation is far
from what I call fast :(

PatC

---

From: "Dana L. Blair" <[email-masked]>
Date: Mon, 29 Jan 2001 17:57:19 -0500

We know that Mobile IP requires tunneling and authentication (IPSEC).  Could
we somehow insert into the problem statement that we need a mobility solution
where Mobile Device and Server are within the same trusted domain and address
space, therefore tunneling and IPSEC are not needed.    I don't think Mobile
IP is addressing mobility solutions that don't require tunnels and authentication.
The best example I can think of is enterprise mobility.

Problem statement text:
Current mobility standards require tunneling and authentication.  In a trusted 
domain where both IP endpoints already trust each other and share the
same address space, tunneling and authentication are not needed.  A good
example is site local addressing in IPv6.

thanks,
Dana

>provide the convincing arguments.

BTW,  I will be somewhat satisfied if this effort simply devolves into a requirements
discussionfor the Mobile IP Working Group (not necessarily the Mobile IP protocol) since
there really is no requirements document for the Mobile IP Working Group.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 29 Jan 2001 15:43:29 -0800 (PST)

> The IPSEC requirement is a big issue in my opinion. 
yup. Somewhere between huge and gigantic.

> I think it would be
> valuable to define a mobility protocol (maybe just changes to Mobile IP)
> which did not require IPSEC.
check. of course, given the way MIPv6 is designed, that will be quite
difficult :(

PatC

---

From: "Dana L. Blair" <[email-masked]>
Date: Mon, 29 Jan 2001 18:13:26 -0500

>Mobile IP doesn't work. Some comments were made at the last IETF about the

I think that my previous definition still applies.  At least it is in draft document I believe.
I was just trying to make a stronger case.

>access router. I can tell you right now that a full IKE negotiation is far

The IPSEC requirement is a big issue in my opinion.  I think it would be valuable
to define a mobility protocol (maybe just changes to Mobile IP) which did not
require IPSEC.

thanks,
Dana

---

From: Michael Thomas <[email-masked]>
Date: Mon, 29 Jan 2001 16:32:17 -0800 (PST)

> more so in the nets that I know need this kind of technology).

   Binding Updates have such a fundamental
   security hole -- every would-be traffic snooper
   would be given the world's best tool ever -- I
   cannot imagine who in their right mind would
   deploy such a thing, big happy family or not.

 > work doesn't work well in those scenarios.

   I don't understand why it wouldn't? Can
   somebody restate the reason?

 > access router. I can tell you right now that a full IKE negotiation is far

   Before we become despondent and looking for windows in
   tall buildings, it should be noted that this is a 
   consideration only if key negotiation is in the 
   critical path of a handoff. As far as I can tell, it
   doesn't seem to be in MIP fast handoffs, and I don't
   think that anything we're doing would change that.
   If we end up going down a path leads us that
   direction, we can be pretty sure that it is the
   wrong one.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 29 Jan 2001 17:06:03 -0800 (PST)

> check. of course, given the way MIPv6 is designed, that will be quite

   Actually, that's a feature not a bug. I cannot fathom why
   people think that three dozen application layer crypto 
   schemes is better than one IP layer scheme. Unless they
   think that that means that they can not build crypto 
   into their boxes at all.

   IPsec is a v6 MUST and is being widely back implemented
   into v4. Can we move on?

	    Mike

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 29 Jan 2001 18:02:43 -0800 (PST)

>    think that that means that they can not build crypto 

To finish up on our conversation on how IPSec identify a security association
(where I stated it was the combination of both the SPI AND the source IP
address), here is a quote from RFC 2402:

"2.4  Security Parameters Index (SPI)

   The SPI is an arbitrary 32-bit value that, in combination with the
   destination IP address and security protocol (AH), uniquely
   identifies the Security Association for this datagram.  The set of
   SPI values in the range 1 through 255 are reserved by the Internet
   Assigned Numbers Authority (IANA) for future use; a reserved SPI
   value will not normally be assigned by IANA unless the use of the
   assigned SPI value is specified in an RFC.  It is ordinarily selected
   by the destination system upon establishment of an SA (see the
   Security Architecture document for more details)."

So, a move WILL require a full IKE phase 1 AND 2 exchange. Again, far from
fast (especially given that it is over the air).

Now that's said, it certainly makes MM MUCH more attractive in v6 networks,
where a change of care of address could be reduced significantly.

>    IPsec is a v6 MUST and is being widely back implemented

Sure, but where?

:)

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 29 Jan 2001 18:06:18 -0800 (PST)

>    deploy such a thing, big happy family or not.

Hence it's reliance on IPSec.

>    somebody restate the reason?

An AP, say running IAPP, does not have a way to signal a foreign agent on the
local subnet about a handoff. One method that was discussed at the IETF was
for the FA to snoop IAPP traffic, but this is ugly. I am sure that a better
mechanism could be created.

>    direction, we can be pretty sure that it is the

See my previous e-mail. Key neg is in the critical path.

Hey, there's a window up in them there buildings....

PatC

---

From: James Kempf <[email-masked]>
Date: Tue, 30 Jan 2001 00:41:49 -0800

Dana,

>authentication.
>trusted

I think a more basic assumption made by mobile IP is that the mobile node
has a "home" agent somewhere. This assumption comes out of the historical
IP situation where a wired host is tied down to a plug in the wall. The natural
extension from that is that the mobile has some natural "home" subnet.
Getting rid of this assumption would remove the need for tunnelling and 
authentication, but there are consequences.

There are lots of innovations one could make in this area, but I'm afraid that
mobile IP has a certain amount of deployment momentum at the moment. It
would be really a shame, when mobile IP is right at the cusp of becoming real
after 10 years of hard work, to have energy diverted by a new protocol. 
Maybe the right solution for exploring these new protocol possibilities is 
to start up an IRTF
activity for exploring new mobility protocols. This would give Phil, 
AndrewC, and
others that want to look into these research areas a venue to discuss them, 
with
a recommendation to come to IETF when the implications are clear. I would 
certainly like to be involved in such an effort, but at the same time, I 
want to make sure
that IETF speaks with one voice (as much as that is possible) when we 
confront 3GPP and others that have some reservations about deploying mobile 
IP. I would
rather see energy devoted to fixing the holes in mobile IP that are currently
hindering deployability.

                         jak

---

From: James Kempf <[email-masked]>
Date: Tue, 30 Jan 2001 00:49:28 -0800

>to define a mobility protocol (maybe just changes to Mobile IP) which did not

There are other consequences. HMIPv6 exposes the Local Care-of Address for
the same reason. Thus, MIPv6 derives no hierarchy hiding benefits from HMIP.
Also, I suspect that the need for authentication will make network assisted 
handoff
during dormant mode difficult, because the access routers need to do the 
binding
update to the home agent while the mobile is in dormant mode.

                 jak

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 30 Jan 2001 11:45:17 +0100

> the same reason. Thus, MIPv6 derives no hierarchy hiding benefits from HMIP.

this is not true.. in HMIPv6, a MN can hide its Local CoA  from its CNs if
necessary...

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: James Kempf <[email-masked]>
Date: Tue, 30 Jan 2001 05:21:40 -0800

Claude,

>this is not true.. in HMIPv6, a MN can hide its Local CoA  from its CNs if 

Yes, but isn't that only in extended mode? Btw., the extended mode portion of
the draft is very difficult to understand. It took me several reads to figure
out what it was about. I think it could benefit from an extensive rewrite.

                 jak

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 30 Jan 2001 14:51:00 +0100

James Kempf wrote:

> Yes, but isn't that only in extended mode?

no this is possible in both modes...actually this can be used to
provide some kind of mobility privacy...a CN only knows the RCoA
not the actual CoA....

> Btw., the extended mode portion of

ok, thanks. We will work on that....

Claude.

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 30 Jan 2001 08:09:45 -0800 (PST)

> fast (especially given that it is over the air).

Assuming you use IKE, of course. Initially, you
set up an SA with the current AR. With fast
mobility, I believe that you do a BU to the old AR
to set up the forward tunnel, so no IKE here. The
context transfer is likely to be an SA between the
old AR and the new AR. I don't think it's too
unreasonable to expect that they'll end up with
their SA's already up most of the time.

The big question is what happens when MN arrives
on the new AR. Unless it's completely open or
relegated to PPP (ick), I don't know how the
network admission control is performed. This seems
to have been relegated to a BOF, so it's anybody's
guess what the security scheme will be. Going out
on a limb that it's vaguely similar to RFC2752 (a
scheme I hope that DIAMETER adopts as well...),
you wouldn't need a full 6 message IKE exchange on
the air to get admitted. You'd need to do that
eventually (namely, some time before you wanted to
move), but it doesn't seem to be in the critical
path.

Now, you'll get no argument from me that this 
looks pretty crufty from a global view, but
it doesn't seem to be _fatal_ cruftiness.
   
 > where a change of care of address could be reduced significantly.

This seems debatable: with MM can the mobile
node initiate a move? Is it notified of the
move? Given the RSVP analysis I've been working
on, I hope the answer to both of those is yes
and if so, you still need a SA between you and
the old AR.

 > >    IPsec is a v6 MUST and is being widely back implemented

Somewhere warm with drinks with little
umbrellas would be fab.

		   Mike