Subject: RE: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 10 Oct 2001 13:44:11 -0500

Worries below:

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 12:29 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: [email-masked]
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security
discussion

Hello Glenn,

> Besides route optimized MIPv6 will never be ubiquitous anyway as long as
the
> binding update processing by CN's is only a SHOULD. The MN and HA will
always
> have to be complicated by back-off procedures to forward stream tunnel
> mechanisms.

I think it's too late by more than a year to change this from
a SHOULD to a MUST.  And, anyway, we can hope that by the time
we're pushing multiple billions of IPv6 nodes, the benefits of
routing directly to the care-of address are obvious enough, and
the code well enough understood.  Then naturally, most nodes
will process Binding Updates.

GM] I would like to believe this but then I see these documents from the
3GPP mobile vendors that say they won't even support the binding update as a
requirement. It seems to me that if the mobile vendors won't support it as a
requirement, why should the standard OS manufacturers support it? MSFT has
prototyped it, but it ain't in there. I don't see a critical mass going to
Linux and Star office yet, either. I do hope you are right, though, and I
have pretty much resigned myself to it standing as is. I don't see why its a
problem if every now and then I keep bringing the suggestion up on the
mailing list, though.

> In my opinion removing this complication is more important than removing
the
> piggyback complication for specific access technologies and compression
> mechanisms.
> 
> I would rather see the group focus on making the route optimized mobility
> ubiquitous and removing the complications of it not being.

The complications of using Destination Options with payload are all
on the sending side.  The receivers implementation is very natural.
That's why it makes very much sense to me, to leave it as a possible
option for _senders_ that want to maximize the performance of their
communications.

GM] I am definitely O.K. with it being a destination option.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 10 Oct 2001 12:10:23 -0700

Hello Glenn,

> GM] I would like to believe this but then I see these documents from the 3GPP
> mobile vendors that say they won't even support the binding update as a
> requirement, why should the standard OS manufacturers support it?

3GPP documents are driven by a very strong requirement to utilize
only existing IETF standards, and I believe that is the problem in this
case.  When we have Mobile IPv6 as a Proposed Standard, then I believe
we'll have a case for inclusion of IP-mobility features into subsequent
3GPP standards.

On the other hand, if people say that they wish to change the specification
for supporting Binding Update from a SHOULD to a MUST, then I'll be quite
happy do edit the document accordingly :-)

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Oct 2001 14:15:36 -0400

Charlie, Glenn,

Glenn Morrow wrote:

>
>
> Worries below:
>
> > Besides route optimized MIPv6 will never be ubiquitous anyway as
> long as the
> > binding update processing by CN's is only a SHOULD. The MN and HA
> will always

This must a political way of moving drafts fast. I thought that IPv6 had
a requirement on all IPv6 nodes to support CN functionality of MIPv6,
and I could not locate the document that stated this!
Remember that MIPv4 allows having configurations with no FA.
All to satisfy in short term the 3GPP guys
which is trying to handle mobility in VoIP using SIP mobility!
  What we need is that people like Charlie from Nokia and Hesham from
Ericsson going to 3GPP meetings, I think.

Regards,

--
Behcet

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Oct 2001 15:26:37 +0200

=> requirements (for all nodes) are:
 - MUST support the home address option
 - SHOULD support CN functionality
They should be in an old proceeding (the presentation was done by
David Johnson many years ago at the IPng WG).

Regards

[email-masked]

PS: with (*not-optional*) security it seems the best way to refuse
BUs is to refuse Mobile SA establishment attempts, doesn't it?