Subject: [Mipshop] MIPSHOP discussion on new items and milestones

From: gabriel montenegro <[email-masked]>
Date: Wed, 16 Mar 2005 10:18:22 -0800

Folks,

As you may be aware, the working group's current milestones are
all done.

I spoke with Margaret Wasserman (taking over from Thomas Narten
as our advising AD) during IETF week, about possible next steps
for MIPSHOP.

It seems like there is sufficient interest and plenty of potential
work items to keep the working group going. Possible items
Margaret and I talked about include the following areas:

Further work on FMIPv6
----------------------

- work on MN-AR security. For example:

   - AAA-based keys for handovers - the need/desirability for such
	an item was brought out in Jari's presentation in MOBOPTS.
	even though this item does not yet exist in the form of
	an I-D, it seems we should not have major difficulties
	identifying interested parties to work on it.
	This item is limited in terms of the deployment scenarios
	it supports, but the carrier/service provider scenario it
	caters to seems important enough to warrant work on it.
	perhaps for PS?

   - derive key from SeND for fmip (Rajeev/Kempf draft)
	despite the IPR implications because of the use
	of CGA (from SeND), this could target PS

- work on FMIPv6 itself:

   - The above items will go a long way towards solving the security
	issues in FMIPv6. The current lack of such solutions is
	perhaps the major issue why FMIP is currently experimental
	and not PS. Given the above items, the WG could also take
	on the effort to revise the base FMIP to PS. This effort
	will clearly benefit from the fact that there are several
	implementations of FMIPv6 (including publicly available
	ones), so feedback from these effort will surely help in
	cleaning it up towards PS.

   - Apparently, the CDMA folks (in particular, those working
	on "1x-EV evolution" have some interest in using FMIPv6.
	Another potential WG item could be a document to describe
	how FMIPv6 would work over such a link. This document
	would be analogous to our current FMIPv6 over 802.11
	document, and would similarly target informational.

RR optimizations
----------------
I must confess to me these seem less coherent and ready as a group than
the above group. E.g., it's not clear to me whether a standards-track
document would end up mixing different proposals, and how.

- CGA type idea from OMIP
- CBA (credit-based) maybe no 'spot checks', just the basic stuff
	as is being applied to HIP, for example. this could complement
	other proposals like CGA or preconfigured MN-HA SA, for example.
- EBU - but have heard concern that this *increases* signaling cuz it adds
	messages, what we want is less (not more) signaling.

----

These are the two areas I see most probable for continued work.
Nevertheless, there are other items people have mentioned. Feel
free to propose additional items if you consider they are ready for
standardization. This is diffucult to judge, but the following
are things to keep in mind (of course, they are *not absolute
requirements*):

- are the proposals mature (e.g., plenty of discussion, several
	revisions taking into account WG feedback, published
	results, existing implementations, etc)
- is there interest in the proposals (e.g., are folks interested
	in deploying, perhaps because the proposal enables certain
	scenarios, is there interest from *more than one party*, etc)
- is IPR resolved (at least RAND as per IETF rules, hopefully
	royalty free of course)

Items not ready *now* may of course be ready later on. In the meantime,
those items may continue being discussed in other working/research groups,
as individual submissions, etc.

I have spoken with some of you about the above (thanks for the feedback).
Even if you have privately expressed your opinions, please send your
comments on the above items to the list. Besides expressions of
support, negative opinions are equally important. I have purposely
listed perhaps more items than we'll be able to take on, so we
will probably have to cut the list a bit shorter. Hence, any
comments to help in that respect are also very useful.

So please consider the rechartering discussion for MIPSHOP open
(hopefully the directions mentioned above are close enough).

Comments?

-gabriel

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 11:20:14 -0800

Hi Gabe,

> caters to seems important enough to warrant work on it.

I believe there is a draft currently underway on this.

> of CGA (from SeND), this could target PS

AFICT, there are no IPR implications other than those associated with SEND
itself. The draft uses the SEND CGA key to derive another key, but does not
use CGAs in any way other than SEND, which the CGA IPR holders have released
no-fee. There is no IPR on the handover key draft itself. Of course, I am
not a patent lawyer, and I suppose if the IPR holders wanted to try to
assert IPR on the handover key draft, they could, since anybody can assert
IPR in IETF simply by posting a statement.

> cleaning it up towards PS.

I would support this, however, I think there needs to be some work on FMIP
first in MOBOPTS.

Specifically, I would like to see the PrxyRtXXX messages removed from the
draft, and have the draft focus on the basic FBU/FBack used for changing the
MN's local routing. The original intent of the PrxyRtXXX messages was as a
Layer 3 handover trigger or probe, and that is what the DNA WG was chartered
to solve. The actual task of determining whether a host has moved subnets
requires a reachability round trip with the access router, on those link
technologies where the Layer 2 information on link movement is unreliable
(such as Ethernet/802.11). That probe will be provided by DNA in a PS way.
Where Layer 2 information is definitive including predictively (such as
CDMA2K), DNA is not required, but neither is PrxyRtXXX, and the host can use
the Layer 2 information to determine whether it has moved.

As a result, the PrxyRtXXX messages only serve the function of providing
information, best well in advance of a handover, about surrounding subnets.
In this, they overlap considerably with CARD. Therefore, I think there is a
design item here to merge the PrxyRtXXX messages and CARD.

Regarding CARD, there is some activity underway in MOBOPTS to define an
EAP-like mechanism which would use the existing CARD IANA registries and the
CARD underlying information element definitions, but would be free from the
specifics of IP transport defined in the CARD RFC. This would support both
802.21 and IETF. For IETF, it would use a transport similar to the current
CARD draft, for 802.21, presumably something like EAPoL. Rajeev and I are
working on this in co-ordination with 802.21, we call it "Neighborhood
Discovery". This draft, when it is more mature, would be another item that
MIPSHOP could take up.

> document, and would similarly target informational.

Sound like an excellent idea, provided we can achieve the abovementioned.

> RR optimizations

Well, I have some personal, hard to substantiate opinions on these, but I am
open to being proven wrong.

I do believe CGA type route optimization could be a win, but, again there's
the IPR issue. IPR has only been released for SEND, not for MIP. I am not a
big fan of credit-based, it seems a lot of complexity for very little gain,
and it does nothing to remove the basic residual vulnerability in RR. I
think we could use a little simulation work on the various alternatives,
hopefully from a couple of competing groups with the simulation parameters
and measurement metrics set in advance, so that we could have some kind of
objective measurement about which of these techniques provide benefit. That
kind of work sounds more appropriate for MOBOPTS.

IHMO, however, the real issue in RO security is finding a technique that
removes the residual vulnerability in RR, even if it might require somewhat
more heavyweight infrastructure. If it can be infrastructureless or with
very minimal infrastructure, even better.

            jak

---

From: Christian Vogt <[email-masked]>
Date: Wed, 16 Mar 2005 20:36:38 +0100

Hi Gabriel, hi all.

> - EBU - but have heard concern that this *increases* signaling cuz it
> adds messages, what we want is less (not more) signaling.

I heard about these concerns.  Indeed, there are two ways in which EBU
increase signaling:  through the proactive HoA test (if done on a
periodic basis) and through the additional EBU/EBA messages.  Both can
be mitigated, however.

(i) Proactive HoA tests

When the proactive HoA test is done on a periodic basis, it needs to be
done every 3.5 minutes.  (3.5 minutes is the lifetime of the Home Keygen
Token.)  Roughly speaking, this causes additional signaling only when
the mobile node moves less often than every 3.5 minutes.  And for such
"low-mobility" scenarios, one can use [1] to reduce the signaling
overhead of Mobile IPv6 both with and without proactive HoA tests.

[1]
http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt

(ii) Additional messages

The EBU/EBA messages are exchanged in parallel to the CoTI/CoT messages.
 So some folks have suggested to combine the EBU with the CoTI as well
as combining the EBA with the CoT.  This is certainly possible and would
eliminate the additional signaling.

Of course, we had thought about the benefits of combining messages when
we wrote the initial EBU draft.  The rationale for using separate
EBU/EBA messages back then was to modify as little as possible from the
base specification.  But as folks start to become concerned about the
additional signaling, yes, we can integrate the EBU/EBA messages with
the existing CoTI/CoT messages.

Still, one also needs to consider that separate EBU/EBA messages have
advantages, too.  One such advantage is backward compatibility:  If a CN
does not understand an EBU message, and the EBU and CoTI messages are
separate, the CN can just drop the EBU and respond to the CoTI.  Another
advantage comes into play when combining EBU with direct signaling [2].
 There was a discussion on this on the Mobopts mailing list shortly
before IETF 62.

[2]
http://www.ietf.org/internet-drafts/draft-ewu-mobopts-directsig-00.txt

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

> Margaret and I talked about include the following areas:

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Gopal Dommety <[email-masked]>
Date: Wed, 16 Mar 2005 10:58:22 -0800

Hello Gab,

          The list you have looks good. Fast Handovers for CDMA networks is 
very interesting. Definetly interested in working on this.

Regards,
-Gopal

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 16 Mar 2005 12:01:48 -0800

Jim,

>the Layer 2 information to determine whether it has moved.
Some clarifications. First, Proxy Router messages are _not_ handover
triggers. They only supply
neighborhood IP config information. Second, with the neighborhood
discovery _in an
access independnt way, we can determine subnet movement without
necessarily requiring
DNA. However, when no neighborhood information available, DNA is very
useful. Indeed,
at one point DNA considered FMIP as an approach in BCP. Finally, relying
on L2 triggers
to provide subnet information, no matter how appealing, is a bad idea.
If they exist, Proxy
Router messages can be made optional on such links. Otherwise, they
provide an _IP way_
of doing things without expecting L2 to provide L3 information. Why did
not we let L2s
standardize ARP/ND? Proxy messages are serving the purpose of off-link
ARP/ND.

>design item here to merge the PrxyRtXXX messages and CARD.
CARD came up with Proxy Router style messages long after FMIP had long
proposed them.
CARD can provide a good solution for populating the neighborhood map on
the ARs, instead
of focussing on MN - AR signaling.

>Discovery". This draft, when it is more mature, would be another item that
I wonder if we should consider another venue for retooling CARD and
CTP.. How about
awakening seamoby? :-)

-Rajeev

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 16 Mar 2005 15:36:52 -0500

Please note that one of OMIPv6 features is actually the same one  
offered by EBU.
BUT OMIPv6 is *more* secure, *eliminates* the HoTI/HoT and offers you a  
long
lifetime Kbm.

Regards,
Wassim H.

On 16-Mar-05, at 2:36 PM, Christian Vogt wrote:

>> adds
Regards,

Wassim H.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Mar 2005 13:53:55 -0800

hi all,

> Further work on FMIPv6

the FMIPv6 tasks look good. I like the last task very much. :)

> RR optimizations

IMO, these work items should not be taken up by MIPSHOP.
my understanding is that these proposals become mature in
MOBOPTS and MOBOPTS will recommend to MIP6 WG when they are
ready to be standardized as a proposed standard.

I am *not* looking forward to multiple RR Optimization
proposed standards in MIPSHOP.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 14:01:00 -0800

Hi Rajeev,

> triggers.

Like I said, that's how they started. Today, as you say, they are primarily
for information.

> They only supply

In CDMA, they are pretty definitive. Terminals never handover anywhere
unless the network tells them where to. Otherwise, the spreading codes might
not be right and the BS and MS can't talk. So it really depends on the link
technology.

> of focussing on MN - AR signaling.

Do you believe, from a design standpoint, that it makes sense to have two
separate ways of providing neighborhood information, one tied to FMIP
exclusively but only for access router information and one for that and
everything else?

> I wonder if we should consider another venue for retooling CARD and

Um, no. :-) I think we ought to retool CARD to Neighborhood Discovery in
MOBOPTS for 802.21 and IETF then talk to the ADs about what they think is
best. MIPSHOP would be a candidate, but so would a new WG. As for CxTP, I'm
still waiting for the "killer ap" to convince me that it's worth the work to
move it to PS. PANA looked good, but, sad to say, I'm unconvinced after
seeing the presentations at IETF 62.

            jak

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 16 Mar 2005 22:04:48 +0000

Hi Rajiv/all,

> Finally, relying

Correct, in the number of experiments I did here I get really bad 
oscillations..false positives...

the agenda does sound good...

from what I see here..FMIPv6 and HMIPv6 is a really bad idea 
together..leave them separate..the signalling will kill it..

thanks
t.

-- 
theo
Nets & Mobile Systems Group
UCL-CS

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 14:32:26 -0800

Theo,

We had no problem on CDMA2K. See:

http://www.geocities.com/kempf42/fmipv4-wireless-networking-revised-posted.pdf

We used the triggers for the LLHO MIPv4, but they could be used for FMIPv6
as well. What link layer technology were you using?

            jak

----- Original Message ----- 
From: "Theo Pagtzis" <[email-masked]>
To: "Rajeev Koodli" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "gabriel montenegro"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, March 16, 2005 2:04 PM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 16 Mar 2005 14:47:13 -0800

Hi Jim,

perhaps we are digressing here from the topic..We should debate
later as we work on the PS document.

Gabriel: the RR optimizations work is interesting. I think MobOpts
would be a good venue for the proposals. We have already had a
"toolbox" id, and some discussions on EBU and CBA. I would
encourage further discussion, and I would also support making
the mature ones IRTF RFCs. (NOTE: there is an effort on-going to
define a new Research track for IRTF RFCs).

MIPSHOP should focus on a narrowly scoped charter. We get done
faster that way.

Regards,

-Rajeev

James Kempf wrote:

>>>information, best well in advance of a handover, about surrounding
>>>      
>>>
>subnets.
>  
>
>>>In this, they overlap considerably with CARD. Therefore, I think there is
>>>      
>>>
>a
>  
>
>>>EAP-like mechanism which would use the existing CARD IANA registries and
>>>      
>>>
>the
>  
>
>>>CARD underlying information element definitions, but would be free from
>>>      
>>>
>the
>  
>
>>>specifics of IP transport defined in the CARD RFC. This would support
>>>      
>>>
>both
>  
>
>>>802.21 and IETF. For IETF, it would use a transport similar to the
>>>      
>>>
>current
>  
>
>>>Discovery". This draft, when it is more mature, would be another item
>>>      
>>>
>that
>  
>
>>>MIPSHOP could take up.
>>>
>>>
>>>
>>>      
>>>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 14:52:28 -0800

> later as we work on the PS document.

Agree.

> MIPSHOP should focus on a narrowly scoped charter. We get done

Yes!

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 16 Mar 2005 14:55:55 -0800

>not be right and the BS and MS can't talk. So it really depends on the link
I am not talking about how certain the prediction is on a particular
access technology. I am talking about what L3 information we can
expect from a particular L2 technology.

If we remove Proxy Router messages all together, we will _require_ every
L2 to provide the L3 information we need. That's certainly different from
allowing Proxy Router messages to be optional on certain links.

-Rajeev

---

From: Christian Vogt <[email-masked]>
Date: Thu, 17 Mar 2005 00:18:14 +0100

> IHMO, however, the real issue in RO security is finding a technique
> that removes the residual vulnerability in RR, even if it might
> require somewhat more heavyweight infrastructure. If it can be
> infrastructureless or with very minimal infrastructure, even better.

Hi James,

considering the response to Wassim which I have just sent to the list,
the combination of CGA-OMIPv6 and CBA might actually be a good
candidate.  It provides a higher level of security than RR and
decreases handover latency at the same time.  Do you agree?

- Christian

subnets.
both
current
that
adds

---

From: Christian Vogt <[email-masked]>
Date: Thu, 17 Mar 2005 00:16:52 +0100

Wassim Haddad wrote:
> offered by EBU.  BUT OMIPv6 is *more* secure, *eliminates* the
> HoTI/HoT and offers you a long lifetime Kbm.
>
> Regards,
> Wassim H.

Hi Wassim,

are you refering to CGA-OMIPv6?

It is true that CGA-OMIPv6 replaces the HoA test through the more secure
CGA mechanism.  But you still need to do the CoA test, so handover
latency may still be high.

OTOH, you could move the CoA test off the critical path by complementing
CGA-OMIPv6 with CBA (see Gabriel's mail).

- Christian

>> overhead of Mobile IPv6 both with and without proactive HoA tests.
http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-
>> extension-00.txt

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 15:29:04 -0800

> allowing Proxy Router messages to be optional on certain links.

I didn't mean to suggest that the messages be removed entirely. I actually
agree that they are necessary, since, for those L2 technologies that support
safe L2 triggers, IP information may not be available at L2 either. So there
might still be a need for mapping between L2 information and L3 information
on the host during or after handover. My only concern was whether coupling
them together with the local routing change signaling provided by FMIP is
such a wise choice in general.

What I think we need is a clean design in which all the neighborhood
information, including the next router information conveyed by the Proxy
messages, is provided in a way that is orthogonal to the transport used to
convey it, like EAP does for AAA. And, an IP transport, which might be the
Proxy messages, that can be used when the neighborhood information can't be
conveyed over L2. I think such a design would maximize the reusability of
the various components and reduce implementation complexity on the host,
since the interpreter for the neighborhood information could be modularized
and reused for different interfaces on the same host that support
neighborhood discovery at different layers of the stack.

Does this make sense?

        jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 15:32:10 -0800

Christian,

> decreases handover latency at the same time.  Do you agree?

I have not looked at these drafts in a while, and would need to revisit them
to say for sure, though the approach looks promising.

In any event, I think a thorough analysis would be needed, to make sure no
threats were ignored. Other than that, the only other issues I would have
are implementation complexity and the IPR issue with CGA for anything other
than SEND.

            jak

---

From: "Charles E.Perkins" <[email-masked]>
Date: Wed, 16 Mar 2005 15:32:57 -0800

Hello Jim,

> Like I said, that's how they started. Today, as you say, they are primarily

Isn't there any wiggle room here?  The proxy router messages
contain information which is most important to have at
handover time.  Thus, a system which employed these messages
in conjunction with some layer-2 trigger would make sense to
me.  In fact, I can imagine that reception of some such message
by the mobile node "could" be interpreted as a suggestion that
maybe a handover would be a good idea.

> exclusively but only for access router information and one for that and

As I remember, it was always very definitely stated that
FMIP should not have any normative dependencey on CARD,
and I never heard anybody change the rules.  I view CARD
as a "background" activity, without strong deadlines.
I view FMIP as local signaling that very definitely has
to meet stringent deadlines.

>         .....         As for CxTP, I'm
> move it to PS.

Hmmm...  It seems pretty clear that _with_ context transfer, one
can achieve some nice goals w.r.t. VoIP and other interactive
applications.  And, without context transfer, one probably has
to rely much more on make-a-long-time-before-break.  Yecchh.

I don't see why this is not sufficient "motivation".

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 16 Mar 2005 15:32:31 -0800

>neighborhood discovery at different layers of the stack.
Yes. Worth considering.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 15:59:02 -0800

Hi Charlie,

> maybe a handover would be a good idea.

Possible.

> to meet stringent deadlines.

I think we ought to get beyond CARD/FMIP and decide what functionality we're
trying to support. I think there is 1) one set of functionality involving
conveying "neighborhood information" and 2) another involving handover
signaling including changing local routing and possibly telling the host
that there's been a change in routing. The neighborhood information could be
conveyed across a variety of transports to the host, including 1) in an L2
trigger at handover, 2) through some kind of L2.5 protocol prior to
handover, or 3) in an IP message (like CARD or the Proxy messages). The
handover signaling requires 1) changing local routing, which FBU does, and
2) possibly signaling a subnet change at L3, though I can think of other
ways that might be better than the Proxy messages, for example, a new kind
of Redirect, which I believe was in one of the original FMIP drafts. From a
functionality standpoint, therefore, I think it makes sense to have 1) a
transport-independent way of conveying neighborhood information (like EAP
does for AAA), 2) an IP transport to convey that information if not
available from L2 (as the Proxy messages and CARD try to do), and 3)
handover signaling that includes both FBU to actually change the routing and
some kind of message that says "your routing may have changed, please take
some kind of action".

        jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 16:09:34 -0800

Hi Charlie,

(separating this out into a different thread)

> I don't see why this is not sufficient "motivation".

I guess one could go to Watersprings and resurrect some of the early drafts
from Seamoby on various applications of CxTP. The problem is, there was
never a place that these drafts could be developed because Seamoby had too
much on its plate and it wasn't chartered to do any applications of CxTP
anyway. In addition, unlike EAP, there is not a bunch of outside STOs and
vendors clamoring for CxTP and defining new methods at a fast clip. IAPP had
industry mindshare for context transfer, and, as I understand it, that
failed due to lack of a way to define extensions and lack of a desire for
vendors to implement it. The one rather compelling application for IAPP in
the 802.11 space would be transferring AAA keys, since AAA is -the- major
bottleneck in 802.11 handover, but that is a really bad idea for security
reasons, and, as a result, 802.11r has been chartered to determine how to do
it without context transfer. CxTP and context transfer in general inherits
some of the bad odour surrounding IAPPs demise, and the attempt to use it
for the discredited application of transferring AAA keys (which was lately
attempted for PANA). In Seamoby itself, there was technical disagreement
about the need for context transfer for header compression, and this was
never resolved.

So, Charlie, to sum it up, at this point, it doesn't matter a lot what I
think about CxTP. Until somebody comes up with some compelling applications,
proof that it is absolutely necessary, research results indicating that it
makes a big difference, and/or some pull from 3GPP/2 or IEEE, I have some
difficulty seeing where we can go from here with it.

            jak

---

From: "Charles E.Perkins" <[email-masked]>
Date: Wed, 16 Mar 2005 16:34:29 -0800

Hello again Jim,

James Kempf wrote:

>        .....                  The problem is, there was
> anyway.

That is definitely Catch-22.  I notice you aren't saying that
context transfer does not work.

> .............         The one rather compelling application for IAPP in
> reasons,

You'll have to be more specific here...  Transfering security contexts
isn't inherently a bad idea.  Transferring layer-3 contexts at layer-2
might not be so great...

>  ...  and, as a result, 802.11r has been chartered to determine how to do
> some of the bad odour surrounding IAPPs demise,

The winds of time can blow away any bad odor with fresh air.

>                        and the attempt to use it
> attempted for PANA).

I don't see that PANA is the determining factor, especially if
the signaling would be confined to the access routers themselves.

>            In Seamoby itself, there was technical disagreement

Well, it was shown to be useful for compression that depends
on compression state, to my understanding.  I thought this was
a _much_ more political discussion than a technical one.
I offered to try to help resolve technical issues, but there
were no takers.

> think about CxTP. Until somebody comes up with some compelling applications,

Hmmm...  VoIP and other interactive applications...  what was
wrong with those again?  Your point about odors and vendors wanting
to do it at layer 2 is not overwhelmingly technical.

> difficulty seeing where we can go from here with it.

There is no proof that it is absolutely necessary.  In fact,
quite the contrary.  Even the Internet isn't absolutely
necessary.  Even if research results show only a 15% improvement
25% of the time, that _could_ translate into a more consistently
pleasant user experience.  If the performance improvement
reduces average transit times below 175ms "most" of the time
instead of "some" of the time, during handovers, that's important
enough for me.  Please note the "IF" in the previous sentence.
I do NOT suggest that I have exactly these figures.

We could publish an Internet Draft showing how to do things
in ways that are interoperably good, and see what happens.
As I remember, there were many nontechnical factors surrounding
the whole [seamoby] experience that one might endeavor to avoid
repeating.

Regards,
Charlie P.

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 17 Mar 2005 03:18:20 +0200 (EET)

> proposed standards in MIPSHOP.

=> I am looking exactly to the *opposite* especially when you have a
proposal which makes sense!

Wassim H.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Mar 2005 17:39:58 -0800

James,

> The one rather compelling application for IAPP in

"transferring keys is a bad idea"... I hope we can use such blanket
statements a bit more cautiously. If everyone were to follow this
advice, the most of the Internet access would stop now (note that RADIUS
server transfers AAA-Key to NAS for a host to gain Internet access --
this is a typical deployment).

We really need to scratch the surface and get to more details. 

For example, NAS1 sharing its EAP AAA-Key with NAS2 is a bad idea
because compromise of one leads to compromise of the other NAS. Or, the
context applicable to NAS1 may not be applicable to NAS2. ... We should
be talking about these details, not making a wide open statements and
spend next couple years explaining people "but, it is not that bad...."

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Mar 2005 18:45:55 -0800

> proposal which makes sense!

Wassim, I am not disputing whether the proposals make sense
the question is whether we want multiple RR optimization
solutions standardized in the IETF as proposed standards.

Vijay

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 17 Mar 2005 05:06:14 +0200 (EET)

> solutions standardized in the IETF as proposed standards.

=> I think it does not hurt to standardise a new RR when it makes sense.
Note that i am talking about OMIPv6 *only*.

Wassim H.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 16 Mar 2005 21:13:49 -0600

James,

I will make the CBA source code (for Kame-Shisa Mobile IPv6) available 
as soon as I'm back in Germany.  The source code includes CBA without 
CoA Spot Checks, which Gabriel intends to leave to Mobopts anyway.

I am pretty sure that any concerns about implementation complexity are 
unjustifiable.  We are talking about a few lines of code that CBA adds 
to the kernel part of the Mobile IPv6 implementation.  Note that this 
was one of the drivers that led the HIP community to add CBA to the MM 
specification.

- Christian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 08:14:19 +0200

Hi Gabriel, and thanks for considering some new work!
Here are my main comments:

- MN-AR security is a significant issue in current specifications,
and as such addressing it would be really useful. But I wonder
about the need to have two different solutions in this space.
Seems like James' draft would technically work in all scenarios.
What he said about the IPR sounded positive too (but I am not
a lawyer nor have I looked at the relevant patents).

- FMIP PS is a good idea. Need to think about sequencing of
work, however. Presumably this would come after MN-AR security,
right?

- 1X-Ev or 802.11 applicability draft would also be useful, probably
Informational though.

- I believe RR optimizations are of great interest to the industry.
Ericsson is planning to implement OMIP/CGA scheme in products,
but its not going to happen if there are no RFCs or allocated numbers.
So this would be my first priority. (The current IPR note on that
is RAND, I believe, but I'm not a lawyer. Note also that our lawyer
has had some trouble making that note appear on the IETF web,
despite it being sent from us. We are trying to work on that problem.)

As draft-irtf-mobopts-ro-enhancements states, there are some
relatively stable RR enhancements that are basically waiting for
deployment experience. And different optimizations target different
scenarios (e.g. tradeoffs between latency and amount of signaling).
So I wouldn't want us to end up debating which single scheme
we need to choose, or attempt to perform more measurements.

As for the individial schemes, EBU as in doing proactive HOTIs
is probably sufficiently documented in terms of RFC 3775
already. To me only the CBA variant of EBU is interesting, so I'd
consider only doing a combined EBU/CBA document if we are going
to do it.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 08:22:25 +0200

Vijay,

>>solutions standardized in the IETF as proposed standards
>>
We've already got two. Base RR and Charlie's fixed
key scheme. But the latter isn't very easily deployable,
so if people want higher efficiency and something that
can actually be deployed, we need new RFCs...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 08:36:31 +0200

CBA looks complicated because the document explains the
justification for its security at length. But the actual implementation
is not much more than a "++" statement in one place and a "--"
in another... :-)

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 08:58:05 -0800

Alper,

> this is a typical deployment).

Yes, and that is, in fact, the only key transfer application that the
security guys are willing to bless. When you ask them about this seeming
contradiction, they state that they've convinced themselves that it will
work, even though it involves transferring the AAA-Key outside the
"cryptographic boundary" of the RADIUS server. When you dig a little deeper,
there were some practical considerations involving how existing drivers work
that drove the decision in 802.11 to use this method.

> spend next couple years explaining people "but, it is not that bad...."

If you want to convince the security guys of this, I'd suggest you look at
constructing a formal proof of security for whatever key transfer protocol
you are interested in. That way, they will be unable to wriggle out of
approving it, provided, of course, the proof is sound.

Please don't get me wrong, I am not opposed to key transfer on any grounds
other than that some fairly useful and general principles in security design
suggest that it might not be secure.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 09:16:07 -0800

Jari,

> despite it being sent from us. We are trying to work on that problem.)

The difficulty with CGA is that there are two IPR holders. So for CGA for
MIP to be most acceptable to MIPSHOP, both would need to release the IPR. Of
course, it is possible that the WG might approve it with RAND IPR, but I
doubt it.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 09:17:26 -0800

Vijay,

So suppose the CGA IPR is released. Would it make sense to EOL base RR and
make OMIP/CGA the standard?

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Wassim Haddad" <[email-masked]>
Cc: "gabriel montenegro" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 16, 2005 6:45 PM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

adds

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Mar 2005 09:39:38 -0800

Jari Arkko wrote:
> key scheme. 

actually three. Francis Dupont's IPsec between MN and CN.

> But the latter isn't very easily deployable,

right, but having one mechanism that can be run irrespective
of the type of deployment is enough, IMHO.

> can actually be deployed, we need new RFCs...

well, 3GPP2 has adopted MIPv6 into their standards and they
were quite fine with Return Routability as it is currently.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Mar 2005 09:43:35 -0800

Jim,

I wasnt talking about the IPRs at all. it just didnt make sense to
me to have multiple RR enhancements as proposed standards. I would
like to see the work done in MOBOPTS. once MOBOPTS recommends a
particular proposal saying it is ready for standardization, we
quickl standardize it in MIP6 WG. it shouldnt take more than a
couple of revisions in the MIP6 WG before the document can be sent
to the IESG.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Mar 2005 09:44:34 -0800

hi Jari,

> a lawyer nor have I looked at the relevant patents).

in some networks, where there is access network authentication
using AAA access, it might make sense to setup keys for securing
FBU along with access authentication. so, I think we should take
a look at this solution too.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 10:10:05 -0800

Hi Charlie,

The problem with transferring security context is that the security guys get
nervous if keys are transferred outside the "cryptographic boundary", which,
in practice, seems to mean "the box on which the key was derived". They've
loosened the rules in the case of the AAA-Key for practical reasons, but
have convinced themselves that it will not cause a security problem. For any
other case, there would have to be some pretty strict security proof to get
them to change their minds. And, if you can't transfer keys, I have a little
difficulty seeing what use context transfer is for AAA/security, because
everything else can be easily re-derived, or is somehow related to the key,
which must be rederived.

As for technical v.s. political on CxTP, as is true of IETF in general,
Layer 9 asserts its ugly head regardless of whether the technical arguments
are lined up. I've always been convinced there's technical value in context
transfer; otherwise, I wouldn't have spent over a year trying to get it to
RFC as Seamoby chair despite the diminished prospects for its widespread
implementation and deployment.

            jak

----- Original Message ----- 
From: "Charles E.Perkins" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 16, 2005 4:34 PM
Subject: Re: The problem with CxTP (was: Re: [Mipshop] MIPSHOP discussion on
new items and milestones)

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 20:17:47 +0200

>a look at this solution too.
Maybe. But only if the other solution has a drawback
that the AAA based solution could fix, such as better
efficiency, higher security, or ability of service providers
to get additional money. Is there such an advantage?
(If the solutions are similar from the user's point of view,
I don't think we need several solutions.)

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 20:32:53 +0200

Hi Vijay,

>
> it just didnt make sense to

Well, as you pointed out we seem to have several schemes already in
progress in MIP6 around this. I just don't find personally neither one of
those new schemes as something that is likely to be widely deployed and
interesting. But that's OK, as any of these non-base-RR schemes are
optional.

By the way, MIP6 seems pretty overloaded, IMHO. The bootstrapping work
is using quite a lot of energy. Frankly I'm not sure how much new
work the group will accept in the future. Or that's at least the impression
I got when I talked to the chairs some time ago.

Finally, I wonder what you would consider as a MOBOPTS recommendation?
We already have WG documents that do precisely what you say above,
i.e., state that there are some methods that are quite stable. Ok, I admit
that I'm an author of such a document but we have done quite a lot
of analysis in draft-irtf-mobopts-ro-enhancements and I think we can
back our statements up with a good rationale.

This leaves me wondering what to do next, and when we get to
do enhancements that are potentially widely deployable and could
have a big impact on amount of signaling and latency in RO, for
the vendors that care about this. And whether those enhancements
should be on the same or different track than things like the fixed
key RO scheme. What's your suggestion?

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Mar 2005 10:35:22 -0800

> I don't think we need several solutions.)

sure. if the AAA based solution does not give an advantage
over SEND based solution, we wont do it. :)

it is not known yet, if all MNs will implement CGA for address
configuration. but in deployments where AAA based access
authentication is used, the MNs implement whatever is necessary
to gain access to those networks.

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 17 Mar 2005 10:44:40 -0800

>work, however. Presumably this would come after MN-AR security,
I don't think sequencing is necessary. FMIP needs a way to secure FBU.
That's what the AAA, SEND-derived keys should provide. FMIP spec itself
can be revised independently, and refer to the companion drafts for securing
signaling. Just like RFC 3775 and 3776.

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Mar 2005 10:56:28 -0800

Jari Arkko wrote:
> By the way, MIP6 seems pretty overloaded, IMHO. 

:)

IMHO, it is exactly the opposite. when the privacy work was sent
to MOBOPTS, I was like, come on, MIP6 WG does not have much on
its table, we should do it here.

> The bootstrapping work
> is using quite a lot of energy. 

it is being done off the list in a design team. it is *not* taking
up MIP6 WG mailing list bandwidth.

> Frankly I'm not sure how much new

if the work is ready (as in all the details are already worked out)
it shouldnt overload MIP6 WG.

> back our statements up with a good rationale.

thats good. I havent been following this work. if MOBOPTS thinks
they are ready, they be should be brought right away to the MIP6
WG. but, I would like to see one RR enhancement standardized. not
multiple ones. Jari, you tell me which one is ready. I trust you
enough to just go with your recommendation. :)

> key RO scheme. What's your suggestion?

well, basically I think Return Routability is enough for now. we
dont have much deployment experience to say we need enhancements.
3GPP2 was basically fine with return routability. infact, I
remember an Operator saying in 3GPP2, "running return routability
every 420 seconds is fine with us". this was when OMIPv6 was
presented in 3GPP2.

but since so many people in the IETF think we need an RR
enhancement mechanism right away, I wont object to the work being
done. but I am not looking forward to a lengthy discussion and
multiple iterations on the MIPSHOP mailing list. get the work done
in MOBOPTS and quicky standardize it in the MIP6 WG.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 20:59:38 +0200

Hi Vijay (everyone: this thread has too many separate
sub-threads, hence I have used a more descriptive subject
line)

> over SEND based solution, we wont do it. :)

Ok, we are in agreement.

> to gain access to those networks.
This is true. Presumably, MNs will implement anything that the
FMIPng RFC requires, within some reasonable limits. But the
main question is if we are setting some unreasonable requirements,
or place some limitations on other parts of the system. From the
top of my head here's a couple of external limitations that the different
solutions set here:

- existence of network access control mechanism (in the AAA solution,
  but all commercial deployments have this, would preclude some open
  networks though.)
- availability of keys from AAA (in the AAA solution, some commercial
  deployments could provide this, but not all)
- ipv6 only (in cga solution)
- ability to use stateless address autoconfig (in cga solution, though
  cgas could presumably be extended to handle dhcp too)

Anything else?

--Jari

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 17 Mar 2005 21:16:31 +0200 (EET)

> every 420 seconds is fine with us". this was when OMIPv6 was

=> Good to have feedback from *one* PP2 operator. BTW, do you think that
if you tell him he can do it in less than that then he will get upset? :)
What about having one of the biggest operators in Europe rejecting the RR
because of its security?

Wassim H.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 21:26:29 +0200

> enough to just go with your recommendation. :)

Thanks, but I may have to disappoint you! See, the problem is that
people have different objectives. For instance, having a scheme
that is blazingly fast may make voice over IP people happy. But
people who wanted to save their battery life may not be happy
with the resulting signaling. Or someone wants to setup a shared
key between his laptop and home server may like his solution, but
that might not satisfy others who want to use this stuff with a
random web server in the Internet.

Anyway, here's one suggestion that would perhaps make you
happier. The EBU/CBA direction has been studied mainly in an
attempt to make handoffs faster and to reduce latency. The
technical solution boils down to a better way of performing the
care-of address test. The OMIP/CGA direction has been studied
mainly in an attempt to reduce signaling and to make handoffs
faster. The technical solution boils down to a better way of
performing the home address test.

This suggests potential way forward, as we realize that the
two different approaches are complementary. If you use them
together, we get a new "super RR" that keeps the original zero-config
nature of zero-config RR but has less latency and less signaling.

I have high reliance that the basic schemes are solid, even if
there's certainly work left for a number of I-D revision cycles.
CGA has been around longer than base RR, and if you take
all the advanced asymmetric flow stuff away from CBA, you get
a very simple scheme.

--Jari

*) Note that I don't think the two documents should be combined since
the solutions are orthogonal. And in some cases you may want to do just
one of them, e.g., if you care so much about battery power that
you want to sacrifice some latency to avoid sending a couple of
extra packets. But if both improvements were adopted, we would
have a deployable and efficient new scheme.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Mar 2005 11:41:32 -0800

> if you tell him he can do it in less than that then he will get upset? :)

well, its a tradeoff between having something that works and something
that is complex. they are not dumb, you see...

> What about having one of the biggest operators in Europe rejecting the RR

I would love to hear from them. can you ask them to send a mail to
MIP6 WG mailing list? I would also like to see how they are planning
to deploy MIP6 and for what. and what their requirements are with
respect to efficient and secure route optimization mechanism.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 11:43:14 -0800

Rajeev,

> signaling. Just like RFC 3775 and 3776.

I don't think they can be completely independent. There are some specific
requirements in 3775 that are fufilled by 3776.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 17 Mar 2005 11:46:29 -0800

James Kempf wrote:

>>can be revised independently, and refer to the companion drafts for
>>    
>>
>securing
>  
>
There will be dependency on methods to provide keys, yes.
That does not mean that you have to wait for the keys solution
before you begin any revision.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 11:51:07 -0800

Jari,

This sounds like a good design plan.

So do think there might be enough agreement among the various authors to
come up with a draft merging the two?

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 17, 2005 11:26 AM
Subject: RR enhancements (Was: Re: [Mipshop] MIPSHOP discussion on new
itemsand milestones)

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 17 Mar 2005 21:51:17 +0200 (EET)

> that is complex. they are not dumb, you see...

=> something complex you say?? I was not aware that when you eliminate
(useless) messages and compute only *one* key (for 24 hours) then you get
a more complex scheme! But I fully agree that they are not dumb at all.

> MIP6 WG mailing list?

=> Yes sure.

> I would also like to see how they are planning to deploy MIP6 and for
> what. and what their requirements are with respect to efficient and
> secure route optimization mechanism.

=> I hope you will ask them.

Wassim H.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 17 Mar 2005 12:05:35 -0800

> key RO scheme. What's your suggestion?
It is upon MobOpts to convince relevant groups to accept our
recommendation. We seem to have already done that with the handover keys
draft, assuming of course MIPSHOP gets chartered to include it.
The other example is the Location Privacy topic. MIP6 has promised
to take it from us. I will, as a MobOpts chair, work with IETF WG
chairs to funnel mature IDs back.

Specific to RR enhancement procedures: My sense is that we have not
had enough discussion. We got a glimpse of EBU results from Christian
during the last meeting, but perhaps more discussion is needed. I am looking
forward to discussion on the ML. Perhaps we could have a slot
to discuss just the RR enhancements at the next meeting. Once we are
comfortable with an ID as a group, we can take it to the WG chairs.

-Rajeev

---

From: Charlie P <[email-masked]>
Date: Thu, 17 Mar 2005 12:06:32 -0800

Hello Jim,

I cannot subscribe to this restriction.  I believe that with a well
designed specification, and sufficient interaction with the appropriate
IESG members, we can get the results that are needed.  If there
are unstated guidelines, then they need to be published and not
used as hidden traps for the unwary.  For instance, I think that
Russ Housley's guidelines need to be published as an RFC, or
else abandoned as suggestions without force.

We can't go on with failure to meet the security needs of
IETF protocols, based on fuzzy handwaving about what the
IESG "feels" like doing at the moment.

>are lined up.
If we sit around quaking in our boots, afraid to develop anything that
conceivably might rub some IESG member the wrong way depending
on what day it is, then the Internet will suffer immensely.

>I've always been convinced there's technical value in context transfer ...
>
Then don't give up on it.

Regards,
Charlie P.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 Mar 2005 12:18:10 -0800

Hi Jim,

> there were some practical considerations involving how existing
drivers
> work

I cannot imagine how we can achieve the 3rd party introduction (e.g.,
trusted 3rd party AAA introduces host to NAS) without some key exchange.

> suggest that it might not be secure.

I totally agree. This is a good warning. We should go case by case.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2005 23:07:29 +0200

Hi Charlie,

I haven't followed this part of the thread very carefully, so
I may have lost some context. Are you talking about
Russ Housley's criteria for use keys in an AAA/EAP system?
If so, I am in complete agreement with you about the
need to document these guidelines. In fact, we are
doing that in EAP WG in draft-ietf-eap-keying-05.txt.
The document is still being worked on, so contributions
and review would be highly welcome.

This document talks about the security of the system consisting
of clients, NASes, and AAA servers when keys are derived
by EAP and used in various ways. What we do currently
is to describe the implemented & specified usage, such as
delivering a AAA-Key to NAS. We also see a need to potentially
describe other kinds of key usage, but leave this for future
documents. So it is possible to design advanced ways of
using AAA keys! Of course, some basic requirements need
to be fulfilled*, the system-level security analysis needs to be
there & IETF consensus achieved on any new scheme. But
this is achievable.

--Jari

*) One example is that the compromise of a single AP should
not lead to the compromise of other parts of the system.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 13:11:15 -0800

I also believe Bernard Aboba and Russ are working on an IAB draft
documenting the Housley Criteria. I think it is intended to provide
architectural guidance for people who want to design AAA key distribution
algorithms.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Mar 2005 17:57:25 +0200

>come up with a draft merging the two?
I think I can twist the arms of my co-authors, if necessary. But
I don't its a problem. Nertheless, I believe we should still have
two documents, one for care-of and another one for home address
test improvements. But the documents need to work when used
together. Right now they don't -- not because the authors didn't
want that, but because it has been unclear what, if anything, we
can assume about the existence of other newer RO schemes.

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Sun, 20 Mar 2005 22:57:06 +0100

Hi everybody.

Sorry for jumping into this thread late.

> there's certainly work left for a number of I-D revision cycles. CGA
> has been around longer than base RR, and if you take all the advanced
> asymmetric flow stuff away from CBA, you get a very simple scheme.

Let me just clarify this for those folks who are not so familiar with CBA.

The CBA proposal currently under discussion in Mobopts introduces two
"modes".  In the "simple mode" (let's call it so for now), the CN gives
credit to a MN for packets received from the MN.  The CN reduces the
credit for packets that it sends to it at an unverified CoA (for which a
*concurrent* CoA test is still in progress) of the MN.  This is the
easiest way to rule out any amplified flooding attacks that malicious
MN's may otherwise use their unverified CoA's for.

The simple mode is easy to implement; we did this for Kame-Shisa Mobile
IPv6.  Also, the simple mode is transparent to the MN; only the CN needs
to implement it.

In the "advanced mode", the CN gives a MN credit for packets that the MN
has received from it (i.e., for packets going into the opposite
direction than in simple mode).  The advantage here is that the same
communication direction is used for increasing and decreasing the
credit.  Applications with asymmetric traffic streams like TCP downloads
and streaming may work better in the advanced mode.  More symmetric
applications like VoIP and video conferencing are fine with both the
simple and advanced mode.

Yet, for the CN to know how may packets the MN actually receives, the
advanced mode needs some sort of packet-loss feedback.  We thus
introduced an optional in-band-signaling mechanism, CoA spot checks.
CoA spot checks require support from the MN, however.

Due to the additional complexity and the loss of transparency, Jari's
suggestion (and Gabriel's earlier suggestion) is to standardize the
simple CBA mode, and leave the advanced CBA mode to Mobopts.  I do
support this approach, but I should add that I am a co-author of CBA.

Standardizing simple CBA can well be done in a way complementary to, but
independent of, CGA-OMIPv6.  BTW, the HIP community will integrate
simple CBA to HIP mobility, too, as decided at IETF 62.

- Christian

Jari Arkko wrote:
> Vijay Devarapalli wrote:
>
>>> Finally, I wonder what you would consider as a MOBOPTS
>>> recommendation? We already have WG documents that do precisely
>>> what you say above, i.e., state that there are some methods that
>>> are quite stable. Ok, I admit that I'm an author of such a
>>> document but we have done quite a lot of analysis in
>>> draft-irtf-mobopts-ro-enhancements and I think we can back our
>>> statements up with a good rationale.
>>
> people have different objectives. For instance, having a scheme that
> is blazingly fast may make voice over IP people happy. But people who
> wanted to save their battery life may not be happy with the resulting
> signaling. Or someone wants to setup a shared key between his laptop
> and home server may like his solution, but that might not satisfy
> others who want to use this stuff with a random web server in the
> Internet.
>
> Anyway, here's one suggestion that would perhaps make you happier.
> The EBU/CBA direction has been studied mainly in an attempt to make
> handoffs faster and to reduce latency. The technical solution boils
> down to a better way of performing the care-of address test. The
> OMIP/CGA direction has been studied mainly in an attempt to reduce
> signaling and to make handoffs faster. The technical solution boils
> down to a better way of performing the home address test.
>
> This suggests potential way forward, as we realize that the two
> different approaches are complementary. If you use them together, we
> get a new "super RR" that keeps the original zero-config nature of
> zero-config RR but has less latency and less signaling.
>
> there's certainly work left for a number of I-D revision cycles. CGA
> has been around longer than base RR, and if you take all the advanced
> asymmetric flow stuff away from CBA, you get a very simple scheme.
>
> --Jari
>
>  the solutions are orthogonal. And in some cases you may want to do
> just one of them, e.g., if you care so much about battery power that
> you want to sacrifice some latency to avoid sending a couple of extra
> packets. But if both improvements were adopted, we would have a
> deployable and efficient new scheme.

---

From: Christian Vogt <[email-masked]>
Date: Sun, 20 Mar 2005 23:02:39 +0100

> deployable and efficient new scheme.

Note that CGA-OMIPv6 reduces signaling compared to standard Mobile IPv6,
and (simple) CBA reduces latency without adding any messages because
it's transparent to the MN.  So, the combination of CGA-OMIPv6 and
(simple) CBA *always* reduces signaling, and is *always* faster than
standard Mobile IPv6.

Alright,

- Christian

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 21 Mar 2005 00:25:21 +0200 (EET)

> (simple) CBA *always* reduces signaling, and is *always* faster than

=> Note also that the CoTI/CoT messsages are "normally" not needed except
in particular cases well explained in draft-dupont-mip6-3bombing-01 (but I
am quite sure that you know that).

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 21 Mar 2005 01:04:50 +0200 (EET)

> MN's may otherwise use their unverified CoA's for.

=> Can you please explain more on this? For example what happens after I
get enough high credits from the CN? Does this mean that I won't have to
do the CoTI/CoT messages in the future? Or I can simply increase the delay
to do it?

OTOS, is there any relation between the number of credits provided for
each packet and the _number_ of previous handover also?

> support this approach, but I should add that I am a co-author of CBA.

=> Good to have a confirmation but your name is in clear on the draft!

> simple CBA to HIP mobility, too, as decided at IETF 62.

=> Good to know. But I don't see the link!

Wassim H.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Mar 2005 14:33:04 +0200

Hi Christian,

> it's transparent to the MN.  

I could be missing something here, but I thought that CBA needs to operate
together with EBUs, because otherwise the CN will not learn the unconfirmed
care-of address. Or are you thinking of piggybacking this into a home test
init message?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Mar 2005 14:50:47 +0200

>do the CoTI/CoT messages in the future? Or I can simply increase the delay
As long as you have credits, your payload packet latency
is minimal, i.e., you don't have to wait for the completion
of the care-of test exchange. You need to do it, however,
because the credits don't last in practise more than a few
seconds, at least in some scenarios.

(Note that both the cba and cga drafts keep the care-of
tests and do not suggest removing them. The cga draft
does say, however, that an orthogonal optimization of the
care-of address tests could employed together with it.)

>each packet and the _number_ of previous handover also?
There's an aging factor, credits that you earned recently
are more valuable than older ones. Or are you thinking of the
other suggested method where the binding lifetime could be
increased from RFC 3775 limits based on the number of
already accumulated total lifetime? This is possible too,
but perhaps a bit more speculative than the other proposals
on the table.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Mar 2005 15:12:06 +0200

> care-of address. Or are you thinking of piggybacking this into a home 

I'm sorry, I should have said "piggybacking this into a care-of test
init message".

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Mar 2005 10:50:05 -0600

Hi Wassim.

Wassim Haddad wrote:
>> The CBA proposal currently under discussion in Mobopts introduces 
>> two "modes".  In the "simple mode" (let's call it so for now), the 
>> CN gives credit to a MN for packets received from the MN.  The CN 
>> reduces the credit for packets that it sends to it at an unverified
>>  CoA (for which a *concurrent* CoA test is still in progress) of
>> the MN.  This is the easiest way to rule out any amplified flooding
>>  attacks that malicious MN's may otherwise use their unverified 
>> CoA's for.
> 
> => Can you please explain more on this? For example what happens 
> after I get enough high credits from the CN? Does this mean that I 
> won't have to do the CoTI/CoT messages in the future? Or I can simply
>  increase the delay to do it?

A CoA can be in one of two states: verified or unverified.  A new CoA is
unverified from the time the CN gets to know this CoA up to the time the
CN receives evidence that the MN is indeed reachable at this CoA.  This
makes sense only when the CN learns about the new CoA *before* the CoA
test.  This is why we need the additional EBU message in Mobile IPv6 in
order to inform the CN about the new CoA *before* the CoA test starts.

A CoA moves from unverified to verified state once the CN receives
evidence that the MN is indeed reachable at this CoA.  In Mobile IPv6,
this happens through reception of a standard Binding Update message (for
which the BAD Authenticator's correctness depends on a successful CoA test).

Now, the CN sends packets to an unverified CoA only if the MN has
sufficient credit.  The credit is reduced for each packet sent to an
unverified CoA.  These rules do not apply to verified CoA's.

Note that the EBU and CoTI messages may be combined in order to reduce
signaling.  Alternatively, the CN could retrieve the new CoA from the
CoTI message's IPv6 header.  This can also be done with the CoTI message
used in CGA-OMIPv6.

 > OTOS, is there any relation between the number of credits provided
 > for each packet and the _number_ of previous handover also?

The credit does not change (other than the way explained above) with the
number of previous handovers.  However, old credit decreases over time
so that the MN cannot slowly collect credit over an extensive time 
period and later use its credit all at once.

Does this make things clear?

- Christian

---

From: "James Kempf" <[email-masked]>
Date: Mon, 21 Mar 2005 09:04:41 -0800

Chrisian,

Since the point of the COTI/COT is to eliminate the possibility of bombing
attacks in which traffic coming from the CN is used to bomb at an unverified
CoA, why do you think that using the simple mode, in which traffic in the
other direction is given credit, will not open the bombing threat again?

            jak

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Mar 2005 11:03:01 -0600

Hi Jari,

sure, as I mentioned earlier, adding the extra EBU message was primarily 
to ensure backward compatibility.  But there are alternative ways to 
ensure backward compatibility.

To eliminate the extra message, I was thinking of one of the following 
approaches:

- Piggybacking the EBU onto the CoTI
- Having the CN derive the new CoA from the CoTI (eliminating the EBU)
- Interpreting the EBU as a CoTI (eliminating the CoTI)

As an aside:  If one wants to allow a MN to possibly register a new CoA 
from an old link in a proactive way, there should be a way for the MN to 
choose a IPv6 Source Address different than the new CoA.  One would need 
the Alternate CoA option then.  This is something one should keep in mind.

- Christian

---

From: "James Kempf" <[email-masked]>
Date: Mon, 21 Mar 2005 09:22:10 -0800

>(simple) CBA *always* reduces signaling, and is *always* faster than

The packet drop latency can also be reduced by routing back through the home
agent until RR/RO completes. Of course, it will increase the RTT latency,
but only transiently. This won't work so well on a unidirectional flow from
CN to MN, since the CN won't have any indication that it should switch
routing to the home agent, so it wouldn't work for streaming media, but it
would work for bidirectional flows like VoIP.

            jak

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Mar 2005 12:44:38 -0600

Hi James,

the purpose of CBA is to eliminate the threat of *amplified* flooding 
attacks (not packet redirection per se).  Amplification means that the 
CN sends more data to an unverified CoA than the MN (or attacker) sends. 
  This is what would make this kind of attack attractive to an attacker.

So, if we make sure that the CN does *not* send more data to an 
unverified CoA than the MN (or attacker) has recently sent, then 
amplification is by definition not possible.  CBA does just this:  The 
MN's credit represents how much data the MN has sent, and the CN cannot 
send more than this to the MN while the MN's CoA is unverified.

Since, with CBA, amplification is impossible, redirection-based flooding 
attacks no longer make sense.  After all, the attacker could more easily 
send the bombing packets to its victim directly, and it would get the 
same "benefit" this way.

Does this make things clearer?

- Christian

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 21 Mar 2005 22:51:22 +0200 (EET)

> order to inform the CN about the new CoA *before* the CoA test starts.

=> Ok

> which the BAD Authenticator's correctness depends on a successful CoA test).

=> OK. So you always do the CoTI/CoT but you delay it? Is this correct?

> unverified CoA.  These rules do not apply to verified CoA's.

=> How the MN knows his credits? Can he increase them?

> signaling.

=> OK

> Alternatively, the CN could retrieve the new CoA from the CoTI message's
> IPv6 header.  This can also be done with the CoTI message used in
> CGA-OMIPv6.

=> OK

> period and later use its credit all at once.

=> Sorry for asking this question but IMHO, something is missing from the
equation. Don't you think that it may make sense to consider that a MN who has
"well behaved" for the last 10 handovers deserves a "slightly" better
treatement than another MN who has performed only 1 or 2 handovers...?
Is there any impact from the type of application itself on the number or
"value" of the credit?

> Does this make things clear?

=> IMHO, things will become more clear to all of us if you can write
please 1 or 2 pages just on the simple mode. But yes this was helpful... Thanks!

Wassim H.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Mar 2005 23:29:40 +0200

>=> OK. So you always do the CoTI/CoT but you delay it? Is this correct?
Yes. Or to be more precise, traffic starts flowing even while the
CoTI/CoT is still ongoing. You still start the test right after
movement. Just that it takes a while, and you might not want
to wait.

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Mar 2005 23:08:35 +0100

Hi James.

> The packet drop latency can also be reduced by routing back through
> the home agent until RR/RO completes. Of course, it will increase the
> RTT latency, but only transiently.

You are absolutely right.  In fact, the CN has three options for what it
can do with a packet in case the MN's credit is insufficient and the
MN's CoA is unverified:

(i)  The CN can drop the packet.
(ii)  The CN can buffer the packet for later transmission once the CoA
becomes verified.
(iii)  The CN can send the packet to the MN's HoA.

Option (i) is obviously the easiest approach from an implementation's
perspective.

Security folks may feel uncomfortable with option (ii), because
buffering can potentially be misused for DoS.  OTOH, one should keep in
mind that a CN buffers packets only for properly authenticated MN's.
(The EBU message authenticates a MN by providing evidence of a
successful HoA test.)

Option (iii) needs to be well considered.  Its performance depends on
the RTT between the MN and the CN via the HA relative to the direct RTT
between the MN and the CN.  If the HA is far away, it may be more
efficient to go with option (i) or (ii).

Option (iii) has been the default mechanism in the EBU/CBA drafts from
the very beginning.

> This won't work so well on a unidirectional flow from CN to MN, since
> the CN won't have any indication that it should switch routing to the
> home agent, so it wouldn't work for streaming media, but it would
> work for bidirectional flows like VoIP.

Well, it *would* work:  If you use Early Binding Update, then the MN
sends the EBU message when it makes the L2 handover.  The EBU message
tells the CN about the new CoA irrespective of the flow of data packets.
  If you use CGA-OMIPv6, there would have to be some early registration
of a new CoA, too, in order to allow the CoA test to become concurrent
with normal communications.  (Tell me if I am missing something.)

- Christian

James Kempf wrote:
>> Note that CGA-OMIPv6 reduces signaling compared to standard Mobile
>>  IPv6, and (simple) CBA reduces latency without adding any messages
>>  because it's transparent to the MN.  So, the combination of
>> CGA-OMIPv6 and (simple) CBA *always* reduces signaling, and is
>> *always* faster than standard Mobile IPv6.
>
> The packet drop latency can also be reduced by routing back through
> the home agent until RR/RO completes. Of course, it will increase the
>  RTT latency, but only transiently. This won't work so well on a
> unidirectional flow from CN to MN, since the CN won't have any
> indication that it should switch routing to the home agent, so it
> wouldn't work for streaming media, but it would work for
> bidirectional flows like VoIP.
>
> jak

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Mar 2005 23:27:02 +0100

Hi all,

in a previous message, I said this:

>                     [...] adding the extra EBU message was
> primarily to ensure backward compatibility.  But there are
> alternative ways to ensure backward compatibility.
>
> To eliminate the extra message, I was thinking of one of the
> following approaches:
>

Sorry, but the second option was premature (as you have probably already
noticed anyway).  The EBU not only serves the purpose of notifying the
CN about the MN's new (unverified) CoA, but it also authenticates the
MN.  This is *very* important, as we all know, because the EBU would
otherwise introduce the possibility of connection-highjacking attacks.

Basically, what we need is a message that the MN can send immediately
after the handover which

(i) authenticates the MN
(ii) informs the CN about the new CoA
(iii) initiates the CoA test

In the Early Binding Updates proposal, it's the EBU message that serves
these purposes.  In CGA-OMIPv6, it's the (extended) Care-of Test Init
message.

- Christian

Christian Vogt wrote:
> Hi Jari,
>
> sure, as I mentioned earlier, adding the extra EBU message was
> primarily to ensure backward compatibility.  But there are
> alternative ways to ensure backward compatibility.
>
> To eliminate the extra message, I was thinking of one of the
> following approaches:
>
> - Piggybacking the EBU onto the CoTI - Having the CN derive the new
> CoA from the CoTI (eliminating the EBU) - Interpreting the EBU as a
> CoTI (eliminating the CoTI)
>
> As an aside:  If one wants to allow a MN to possibly register a new
> CoA from an old link in a proactive way, there should be a way for
> the MN to choose a IPv6 Source Address different than the new CoA.
> One would need the Alternate CoA option then.  This is something one
> should keep in mind.
>
> - Christian
>
>
> Jari Arkko wrote:
>
>> Hi Christian,
>>
>>> Note that CGA-OMIPv6 reduces signaling compared to standard
>>> Mobile IPv6, and (simple) CBA reduces latency without adding any
>>> messages because it's transparent to the MN.
>>
>>
>> I could be missing something here, but I thought that CBA needs to
>>  operate together with EBUs, because otherwise the CN will not
>> learn the unconfirmed care-of address. Or are you thinking of
>> piggybacking this into a home test init message?
>>
>> --Jari

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Mar 2005 23:58:00 +0100

Hi Wassim.

>> evidence that the MN is indeed reachable at this CoA.  In Mobile
>> IPv6, this happens through reception of a standard Binding Update
>> message (for which the BAD Authenticator's correctness depends on a
>> successful CoA test).
>

Ok, see Jari's response for this.

>> sufficient credit.  The credit is reduced for each packet sent to
>> an unverified CoA.  These rules do not apply to verified CoA's.
>

See, (simple) CBA is transparent to the MN.  The implementation is
entirely inside the CN.  Hence, the MN does not know how much credit it
has.  In fact, the MN may not even be aware at all that CBA is happening
at the CN's side.

The only thing the MN knows is that the CN supports CGA-OMIPv6 or EBU,
so that it can start sending packets to the CN from a new, unverified
CoA.  These packets are not dangerous; they are not redirected.

CBA is a good way for the CN to decide whether it is save to send
packets to the MN (at the unverified CoA).  In this direction, packets
*are* redirected, so the CN wants to be careful.

There is no need for the MN to know how much credit it has.  It will
eventually find out anyway whether or not the CN sends packets to its
unverified CoA.

> => Sorry for asking this question but IMHO, something is missing from
> the equation. Don't you think that it may make sense to consider that
> a MN who has "well behaved" for the last 10 handovers deserves a
> "slightly" better treatement than another MN who has performed only 1
> or 2 handovers...? Is there any impact from the type of application
> itself on the number or "value" of the credit?

Note that it is elimination of amplification for redirection-based
flooding attacks which makes CBA secure.  We have to stick to this
simple rule to remain convincing.  Including into the credit formula the
number of handovers, and some sort of metric for the MN's behavior
during those handovers, would make things more complex while diluting
the primary goal to rule out amplification.

Ok, so far, so good.

- Christian

Wassim Haddad wrote:
>>>> The CBA proposal currently under discussion in Mobopts
>>>> introduces two "modes".  In the "simple mode" (let's call it so
>>>> for now), the CN gives credit to a MN for packets received from
>>>> the MN.  The CN reduces the credit for packets that it sends to
>>>> it at an unverified CoA (for which a *concurrent* CoA test is
>>>> still in progress) of the MN.  This is the easiest way to rule
>>>> out any amplified flooding attacks that malicious MN's may
>>>> otherwise use their unverified CoA's for.
>>>
>>> after I get enough high credits from the CN? Does this mean that
>>> I won't have to do the CoTI/CoT messages in the future? Or I can
>>> simply increase the delay to do it?
>>
>> A CoA can be in one of two states: verified or unverified.  A new
>> CoA is unverified from the time the CN gets to know this CoA up to
>> the time the CN receives evidence that the MN is indeed reachable
>> at this CoA.  This makes sense only when the CN learns about the
>> new CoA *before* the CoA test.  This is why we need the additional
>> EBU message in Mobile IPv6 in order to inform the CN about the new
>> CoA *before* the CoA test starts.
>
>
> => Ok
>
>
>> evidence that the MN is indeed reachable at this CoA.  In Mobile
>> IPv6, this happens through reception of a standard Binding Update
>> message (for which the BAD Authenticator's correctness depends on a
>> successful CoA  test).
>
>
>> sufficient credit.  The credit is reduced for each packet sent to
>> an unverified CoA.  These rules do not apply to verified CoA's.
>
>
>> Note that the EBU and CoTI messages may be combined in order to
>> reduce signaling.
>
>
> => OK
>
>
>> Alternatively, the CN could retrieve the new CoA from the CoTI
>> message's IPv6 header.  This can also be done with the CoTI message
>> used in CGA-OMIPv6.
>
>
> => OK
>
>
>>> OTOS, is there any relation between the number of credits
>>> provided for each packet and the _number_ of previous handover
>>> also?
>>
>> The credit does not change (other than the way explained above)
>> with the number of previous handovers.  However, old credit
>> decreases over time so that the MN cannot slowly collect credit
>> over an extensive time period and later use its credit all at once.
>>
>
>
> => Sorry for asking this question but IMHO, something is missing from
> the equation. Don't you think that it may make sense to consider that
> a MN  who has
>  treatement than another MN who has performed only 1 or 2
> handovers...? Is there any impact from the type of application itself
> on the number or "value" of the credit?
>
>
>>>>> I have high reliance that the basic schemes are solid, even
>>>>> if there's certainly work left for a number of I-D revision
>>>>> cycles. CGA has been around longer than base RR, and if you
>>>>> take all the advanced asymmetric flow stuff away from CBA,
>>>>> you get a very simple scheme.
>>>>
>>>> Let me just clarify this for those folks who are not so
>>>> familiar with
>> CBA.
>>>
>>>
>>>> The CBA proposal currently under discussion in Mobopts
>>>> introduces two "modes".  In the "simple mode" (let's call it so
>>>> for now), the CN gives credit to a MN for packets received from
>>>> the MN.  The CN reduces the credit for packets that it sends to
>>>> it at an unverified CoA (for
which a
>>>> *concurrent* CoA test is still in progress) of the MN.  This is
>>>> the easiest way to rule out any amplified flooding attacks that
>>>> malicious MN's may otherwise use their unverified CoA's for.
>>>
>>>
after I
>>> do the CoTI/CoT messages in the future? Or I can simply increase
>>> the
>> delay
>>> to do it?
>>>
>>> OTOS, is there any relation between the number of credits
>>> provided for each packet and the _number_ of previous handover
>>> also?
>>>
>>>
>>>> The simple mode is easy to implement; we did this for
>>>> Kame-Shisa Mobile IPv6.  Also, the simple mode is transparent
>>>> to the MN; only the CN
needs
>>>> to implement it.
>>>
>>>
>>>> In the "advanced mode", the CN gives a MN credit for packets
>>>> that
the MN
>>>>  direction than in simple mode).  The advantage here is that
>>>> the same communication direction is used for increasing and
>>>> decreasing the credit.  Applications with asymmetric traffic
>>>> streams like TCP
downloads
>>>> and streaming may work better in the advanced mode.  More
>>>> symmetric applications like VoIP and video conferencing are
>>>> fine with both the simple and advanced mode.
>>>>
>>>> Yet, for the CN to know how may packets the MN actually
>>>> receives, the advanced mode needs some sort of packet-loss
>>>> feedback.  We thus introduced an optional in-band-signaling
>>>> mechanism, CoA spot checks. CoA spot checks require support
>>>> from the MN, however.
>>>>
>>>> Due to the additional complexity and the loss of transparency,
>>>> Jari's suggestion (and Gabriel's earlier suggestion) is to
>>>> standardize the simple CBA mode, and leave the advanced CBA
>>>> mode to Mobopts.  I do support this approach, but I should add
>>>> that I am a co-author of CBA.
>>>
>>>
>>>> Standardizing simple CBA can well be done in a way
>>>> complementary
to, but
>>>> independent of, CGA-OMIPv6.  BTW, the HIP community will
>>>> integrate simple CBA to HIP mobility, too, as decided at IETF
>>>> 62.
>>>
>>>

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 22 Mar 2005 03:38:07 +0200 (EET)

> the primary goal to rule out amplification.

=> IMHO, even if it makes things more complex but it gives more sense
since you're talking about "fostering" some kind of trust between the CN
and the MN so the MN's previous behavior should be taken into account.
Based on that, I think your solution is just a first piece of a bigger
and probably more interesting solution.
So does it make sense to standardise it from now or do you intend to
standardize each improvement in the future?

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 22 Mar 2005 04:26:37 +0200 (EET)

Hi all,

After reading all comments, I would like to suggest the following (and
wish you luck for the rest):

IMHO, we should always provide the best possible solution and not a
collection of optional solutions under the assumption/theory that each
is for a problem while the mandatory solution is the real problem. Based on
that, I suggest the following:

- We replace the MIPv6 RO mode with OMIPv6 for better security, less
signaling and lower latency (i.e., reasons that you all know as being
one definition of simplicity).

- We build additional optimizations only on top of OMIPv6, e.g., CBA or
something more sophisticated and we don't make them optional in order to
keep the mandatory solution as the best one.

Regards,

Wassim H.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Mar 2005 08:49:47 -0800

>with normal communications.  (Tell me if I am missing something.)

What I meant by "it won't work" is it won't work with standard RO/RR as
described in RFC 3775. Of course it will work if there's a signal that a
handover has occured, such as the EBU for EBU/CBA. But even with standard
RR, the CN could use the HOTI or COTI to switch back to routing through home
agent.

Here's an example:

- MN detects movement, sends HOTI or COTI
- MN switches to sending packets through home agent
- CN receives HOTI or COTI -or- a packet from the MN with HoA rather than
CoA as the source address
- CN switches to routing through home agent
- After completion of RR and BU/BAck, CN returns to RO at new CoA

This could reduce post-L2 handover packet drop during RR and binding update
at the expense of some additional RTT latency on the traffic flow, but
requires only minor code changes in the existing RR/RO algorithm. It would,
however, defeat localized handover optimization measures such as FMIP or
Layer 2 handover optimization such as the tunneling protocols utilized by
WLAN switches. So there should probably be a flag in the HOTI/COTI
indicating whether the CN should do this or not, which the MN sets if
localized handover optimization is not in effect.

Does 3775 say anything about when to switch back to routing through the home
agent?

            jak

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 22 Mar 2005 23:04:08 +0200 (EET)

Hi again,

Maybe I forgot to mention this in my previous emails:

Please consider also the scenario (not discussed) where the two endpoints
are mobile:
OMIPv6 can easily be extended (if needed) to improve the security, in
parallel with the (more) significant reduction in the amount of signalling
(still useless) -generated by both endpoints- that can be offered.

Regards,

Wassim H.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Mar 2005 15:56:51 +0100

Wassim Haddad wrote:
>  since you're talking about "fostering" some kind of trust between
> the CN and the MN so the MN's previous behavior should be taken into
> account. Based on that, I think your solution is just a first piece
> of a bigger and probably more interesting solution. So does it make
> sense to standardise it from now or do you intend to standardize each
> improvement in the future?

Hi Wassim, hi all.

Indeed, there are possible enhancement to simple CBA, e.g., to better 
support applications where more data goes from the CN to the MN than the 
opposite way.  The MN may not get sufficient credit for a handover with 
such applications.  Yet, these enhancements are more complex, so they 
will continue to be discussed in Mobopts for a while.

Simple CBA, however, should be ready for publication at this point.

It turns out that asymmetric traffic patterns are actually not that bad, 
even with simple CBA.  E.g., TCP downloads work quite fine given 
appropriate aging intervals. (As I mentioned earlier, credit is aged 
every once in a while to prevent the MN from collecting credit over 
extensive periods.  Such aging can be implemented without timers, don't 
worry.  Also, it's only a right-shift operation.)

Here is a brief calculation that I discussed with Greg (Daley) during 
IETF 62:

Assume a PMTU of 1500 bytes.  Say, the CN sends full-sized TCP segments, 
and the MN sends a TCP ACK without any TCP options for every second 
segment.  This is the worst asymmetry that can happen with TCP (given 
PMTU = 1500 bytes).  Further assume, that the nodes need 500ms for the 
concurrent CoA test.

Given and consumed credit equals the size of packets (in bytes) received 
and sent by the CN, respectively.

The question is how long the MN needs to collect credit before simple 
CBA allows it to do an optimized handover.  So, what's the ratio between 
the size of packets that the CN sends and the size of packets that the 
MN sends?

The CN sends two full-sized TCP segments.  This is 3000 bytes or 3000 
credits.

The MN sends a TCP ACK upon reception of the second TCP segment.  This 
ACK is composed as follows:

    IPv6 header (40 bytes)
    Destination Options Extension Header (24 bytes)
       HoA Option
       Padding
    TCP ACK (20 bytes)

Hence, the entire packet is 84 bytes big, and worth 84 credits.

The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow is 
thus 3000 bytes / 84 bytes = 35.7.  The MN therefore needs at least 
500ms * 35.7 = 17.9 seconds between two successive handovers for 
acquiring sufficient credit for a 500-ms concurrent CoA test.

The aging interval should be no shorter than 2 * 17.9 = 35.7 seconds, 
however, if the credit is cut in half after each such interval.  (Folks 
were talking about 30-seconds to 1-minute aging intervals anyway.)

Note that the assumed RTT of 500ms just for a concurrent CoA test is 
quite long.  In many realistic scenarios will the RTT be lower.  But 
that fine since we are talking about a worst case here.  Moreover, the 
MN may have more to say than just ACK's.  And it gets credit for 
duplicate ACK's, too.

Enough math.

- Christian

Wassim Haddad wrote:
>>>> A CoA moves from unverified to verified state once the CN
>>>> receives evidence that the MN is indeed reachable at this CoA.
>>>> In Mobile IPv6, this happens through reception of a standard
>>>> Binding Update message (for which the BAD Authenticator's
>>>> correctness depends on a successful CoA test).
>>> 
>>>> Now, the CN sends packets to an unverified CoA only if the MN
>>>> has sufficient credit.  The credit is reduced for each packet
>>>> sent to an unverified CoA.  These rules do not apply to
>>>> verified CoA's.
>>> 
>> entirely inside the CN.  Hence, the MN does not know how much
>> credit it has.  In fact, the MN may not even be aware at all that
>> CBA is happening at the CN's side.
>> 
>> The only thing the MN knows is that the CN supports CGA-OMIPv6 or
>> EBU, so that it can start sending packets to the CN from a new,
>> unverified CoA.  These packets are not dangerous; they are not
>> redirected.
>> 
>> packets to the MN (at the unverified CoA).  In this direction,
>> packets *are* redirected, so the CN wants to be careful.
>> 
>> There is no need for the MN to know how much credit it has.  It
>> will eventually find out anyway whether or not the CN sends packets
>> to its unverified CoA.
> 
> 
>>> => Sorry for asking this question but IMHO, something is missing
>>> from the equation. Don't you think that it may make sense to
>>> consider that a MN who has "well behaved" for the last 10
>>> handovers deserves a "slightly" better treatement than another MN
>>> who has performed only 1 or 2 handovers...? Is there any impact
>>> from the type of application itself on the number or "value" of
>>> the credit?
>> 
>> simple rule to remain convincing. Including into the credit formula
>> the number of handovers, and some sort of metric for the MN's
>> behavior during those handovers, would make things more complex
>> while diluting the primary goal to rule out amplification.
> 
> 
>  since you're talking about "fostering" some kind of trust between
> the CN and the MN so the MN's previous behavior should be taken into
> account. Based on that, I think your solution is just a first piece
> of a bigger and probably more interesting solution. So does it make
> sense to standardise it from now or do you intend to standardize each
> improvement in the future?
> 
> 
> Wassim H.
> 
> 
> 
>> Wassim Haddad wrote:
>> 
>>>>>> introduces two "modes".  In the "simple mode" (let's call
>>>>>> it so for now), the CN gives credit to a MN for packets
>>>>>> received from the MN.  The CN reduces the credit for
>>>>>> packets that it sends to it at an unverified CoA (for which
>>>>>> a *concurrent* CoA test is still in progress) of the MN.
>>>>>> This is the easiest way to rule out any amplified flooding
>>>>>> attacks that malicious MN's may otherwise use their
>>>>>> unverified CoA's for.
>>>>> 
>>>>> => Can you please explain more on this? For example what
>>>>> happens after I get enough high credits from the CN? Does
>>>>> this mean that I won't have to do the CoTI/CoT messages in
>>>>> the future? Or I can simply increase the delay to do it?
>>>> 
>>>> A CoA can be in one of two states: verified or unverified.  A
>>>> new CoA is unverified from the time the CN gets to know this
>>>> CoA up to the time the CN receives evidence that the MN is
>>>> indeed reachable at this CoA.  This makes sense only when the
>>>> CN learns about the new CoA *before* the CoA test.  This is why
>>>> we need the additional EBU message in Mobile IPv6 in order to
>>>> inform the CN about the new CoA *before* the CoA test starts.
>>> 
>>> 
>>> => Ok
>>> 
>>> 
>>> 
>>>> A CoA moves from unverified to verified state once the CN
>>>> receives evidence that the MN is indeed reachable at this CoA.
>>>> In Mobile IPv6, this happens through reception of a standard
>>>> Binding Update message (for which the BAD Authenticator's
>>>> correctness depends on a successful CoA  test).
>>> 
>>> 
>>>> Now, the CN sends packets to an unverified CoA only if the MN
>>>> has sufficient credit.  The credit is reduced for each packet
>>>> sent to an unverified CoA.  These rules do not apply to
>>>> verified CoA's.
>>> 
>>> 
>>>> message's IPv6 header.  This can also be done with the CoTI
>>>> message used in CGA-OMIPv6.
>>> 
>>> 
>>> => OK
>>> 
>>> 
>>> 
>>>>> provided for each packet and the _number_ of previous
>>>>> handover also?
>>>> 
>>> => Sorry for asking this question but IMHO, something is missing
>>> from the equation. Don't you think that it may make sense to
>>> consider that a MN  who has "well behaved" for the last 10
>>> handovers deserves a "slightly" better treatement than another MN
>>> who has performed only 1 or 2 handovers...? Is there any impact
>>> from the type of application itself on the number or "value" of
>>> the credit?
>>> 
>>> 
>>> 
>>> => IMHO, things will become more clear to all of us if you can
>>> write please 1 or 2 pages just on the simple mode. But yes this
>>> was
>> 
>> helpful... Thanks!
>> 
>>> 
>>> Wassim H.
>>> 
>>> 
>>> 
>>> 
>>>> Wassim Haddad wrote:
>>>> 
>>>>>>> I have high reliance that the basic schemes are solid,
>>>>>>> even if there's certainly work left for a number of I-D
>>>>>>> revision cycles. CGA has been around longer than base RR,
>>>>>>> and if you take all the advanced asymmetric flow stuff
>>>>>>> away from CBA, you get a very simple scheme.
>>>>>> 
>>>>>> introduces two "modes".  In the "simple mode" (let's call
>>>>>> it so for now), the CN gives credit to a MN for packets
>>>>>> received from the MN.  The CN reduces the credit for
>>>>>> packets that it sends to it at an unverified CoA (for
>> 
>> which a
>> 
>>>>>> *concurrent* CoA test is still in progress) of the MN.
>>>>>> This is the easiest way to rule out any amplified flooding
>>>>>> attacks that malicious MN's may otherwise use their
>>>>>> unverified CoA's for.
>>>>> 
>>>>> 
>>>>> get enough high credits from the CN? Does this mean that I
>>>>> won't
>> 
>> have to
>> 
>>>>> do the CoTI/CoT messages in the future? Or I can simply
>>>>> increase the
>>>> 
>>>> delay
>>>> 
>>>>> to do it?
>>>>> 
>>>>> provided for each packet and the _number_ of previous
>>>>> handover also?
>>>>> 
>>>>> 
>>>>> 
>>>>>> Kame-Shisa Mobile IPv6.  Also, the simple mode is
>>>>>> transparent to the MN; only the CN
>> 
>> needs
>> 
>>>>>> to implement it.
>>>>> 
>>>>> 
>>>>>> In the "advanced mode", the CN gives a MN credit for
>>>>>> packets that
>> 
>> the MN
>> 
>>>>>> has received from it (i.e., for packets going into the
>>>>>> opposite direction than in simple mode).  The advantage
>>>>>> here is that the same communication direction is used for
>>>>>> increasing and decreasing the credit.  Applications with
>>>>>> asymmetric traffic streams like TCP
>> 
>> downloads
>> 
>>>>>>  mechanism, CoA spot checks. CoA spot checks require
>>>>>> support from the MN, however.
>>>>>> 
>>>>>> Due to the additional complexity and the loss of
>>>>>> transparency, Jari's suggestion (and Gabriel's earlier
>>>>>> suggestion) is to standardize the simple CBA mode, and
>>>>>> leave the advanced CBA mode to Mobopts.  I do support this
>>>>>> approach, but I should add that I am a co-author of CBA.
>>>>> 
>>>>> 
>>>>>> integrate simple CBA to HIP mobility, too, as decided at
>>>>>> IETF 62.
>>>>> 
>>>>>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Mar 2005 16:41:38 +0100

Hi James.

 > - CN receives HOTI or COTI -or- a packet
 > from the MN with HoA rather than CoA as the source address

Ok, I see what you meant.  Yes, you need some (minor) changes to RFC
3775 in any case.  In the end, one probably ends up using something
equivalent to Early Binding Updates where the EBU/EBA messages are
integrated with the CoTI/CoT messages.

What bothers me more is this:  If you use reception of a HoTI or CoTI
message as indication to the CN that it should switch to the MN's HoA,
an attacker could send the HoTI or CoTI on behalf of a MN to redirect
the MN's packets as well.  That would be some new kind of DoS attack.
It's not so dangerous, because packets will reach the MN eventually, but
it increases the HA's workload as well as packet-propagation delays.

So what we need is an early message that both authenticates the MN (like
the EBU) and suggests to the CN that it should now switch to the HoA.

Anyway, if the optimization is to work, we need to modify both the CN
and the MN implementation.  After all, we not only want the CN to
temporarily divert packets to the HoA, but we also want the MN to tunnel
packets though its HA as soon as the RR procedure begins rather than
halting the packets until they can be route-optimized after BU dispatch.

For this early message to provide authentication, it could carry a BAD
similar to the EBU (or standard BU) message.  For computing the
Authenticator, however, one would require a fresh Home Keygen Token, so
the HoA test probably needs to be performed proactively (which is
possible with RFC 3775).  And then we are back to Early Binding Updates
where the EBU/EBA messages are integrated with the CoTI/CoT messages. ;)

> Does 3775 say anything about when to switch back to routing through
> the home agent?

Only when a binding-cache entry expires, as far as I know.

- Christian

James Kempf wrote:
>> Well, it *would* work:  If you use Early Binding Update, then the
>> MN sends the EBU message when it makes the L2 handover.  The EBU
>> message tells the CN about the new CoA irrespective of the flow of
>> data packets. If you use CGA-OMIPv6, there would have to be some
>> early registration of a new CoA, too, in order to allow the CoA
>> test to become concurrent with normal communications.  (Tell me if
>> I am missing something.)
> 
> What I meant by "it won't work" is it won't work with standard RO/RR
> as described in RFC 3775. Of course it will work if there's a signal
> that a handover has occured, such as the EBU for EBU/CBA. But even
> with standard RR, the CN could use the HOTI or COTI to switch back to
> routing through home agent.
> 
> Here's an example:
> 
 > - CN receives HOTI or COTI -or- a packet
> from the MN with HoA rather than CoA as the source address 
> This could reduce post-L2 handover packet drop during RR and binding
> update at the expense of some additional RTT latency on the traffic
> flow, but requires only minor code changes in the existing RR/RO
> algorithm. It would, however, defeat localized handover optimization
> measures such as FMIP or Layer 2 handover optimization such as the
> tunneling protocols utilized by WLAN switches. So there should
> probably be a flag in the HOTI/COTI indicating whether the CN should
> do this or not, which the MN sets if localized handover optimization
> is not in effect.
> 
> Does 3775 say anything about when to switch back to routing through
> the home agent?
> 
> jak

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Mar 2005 17:45:58 +0200

> the EBU) and suggests to the CN that it should now switch to the HoA.

Right. Any scheme that attempts to take away the care-of tests
seems to need something like this.

> Only when a binding-cache entry expires, as far as I know.

Yes.

--Jari

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 23 Mar 2005 17:47:17 +0200 (EET)

> will continue to be discussed in Mobopts for a while.

=> OK so the current solution -based so far on counting packets- depends
on the type of application. Again I would suggest *please* that you write
one or two pages to explain the current proposal. IMHO, the draft is a bit
complicated.

Thanks,

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 23 Mar 2005 18:04:43 +0200 (EET)

> integrated with the CoTI/CoT messages.

=> Note that in OMIPv6 you have this feature among others.

> the MN's packets as well.

=> An attacker cannot send a HoTI in OMIPv6 and will have to think a bit
before sending a CoTI (with Keep flow bit set) if it wants it to work.

Regards,

Wassim H.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Mar 2005 17:06:58 +0100

Hi Wassim.

 > => OK so the current solution -based so far on counting packets-
 > depends on the type of application.

It doesn't depend on the application.  But in some special cases, the CN 
may not be able to route-optimize packets for some *part* of the 
concurrent CoA test (as this might lead to amplification).  Note that 
the alternative -- i.e., not using CBA -- is not to route-optimize 
packets during the *entire* concurrent CoA test.

>                            Again I would suggest *please* that you
> write one or two pages to explain the current proposal. IMHO, the
> draft is a bit complicated.

Ok.  Let's say it's a bit "all-encompassing". ;)

- Christian

Wassim Haddad wrote:
>>> => IMHO, even if it makes things more complex but it gives more
>>> sense since you're talking about "fostering" some kind of trust
>>> between the CN and the MN so the MN's previous behavior should be
>>> taken into account. Based on that, I think your solution is just
>>> a first piece of a bigger and probably more interesting solution.
>>> So does it make sense to standardise it from now or do you intend
>>> to standardize each improvement in the future?
>> 
>> Hi Wassim, hi all.
>> 
>> Indeed, there are possible enhancement to simple CBA, e.g., to
>> better support applications where more data goes from the CN to the
>> MN than the opposite way.  The MN may not get sufficient credit for
>> a handover with such applications.  Yet, these enhancements are
>> more complex, so they will continue to be discussed in Mobopts for
>> a while.
> 
> => OK so the current solution -based so far on counting packets-
> depends on the type of application. Again I would suggest *please*
> that you write one or two pages to explain the current proposal.
> IMHO, the draft is a bit complicated.
> 
> Thanks,
> 
> Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 23 Mar 2005 18:18:50 +0200 (EET)

On Wed, 23 Mar 2005, Christian Vogt wrote:

> > Again I would suggest *please* that you write one or two pages to
> > explain the current proposal. IMHO, the draft is a bit complicated.
>

=> Hmm. Is it really difficult to write a proposal for thee lines of code
on one one or two pages espcially when it is about counting packets?!!!
Or that it may appear _too simple_?? :)
If it is the last one then I think we'll all be able to better work on it
so I encourage you and PLEASE DO IT!

Wassim H.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Mar 2005 17:48:16 +0100

Hi Wassim,

your suggestion sounds reasonable to me.  Binding CGA-OMIPv6 and CBA 
together makes a lot of sense.  And as you say that CGA-OMIPv6 is 
essential so some operators, working on the combination in Mipshop would 
definitely be of benefit.  (But it's not me who can decide that.)

- Christian

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 23 Mar 2005 18:52:03 +0200 (EET)

> definitely be of benefit.  (But it's not me who can decide that.)

=> Ok Thanks.

Wassim H.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Mar 2005 18:04:47 +0100

> so I encourage you and PLEASE DO IT!

Yes, I will.

- Christian

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Mar 2005 09:46:42 -0800

Christian,

> it increases the HA's workload as well as packet-propagation delays.

Yes, I thought about that shortly after I sent the message.

> where the EBU/EBA messages are integrated with the CoTI/CoT messages. ;)

So it sounds to me like, for standardization purposes, the bottom-line,
simplest modification that we could make to RFC 3775 would be to incorporate
something like EBU that would allow the CN to obtain a verified early
notification of change that would then let it move traffic back to the HoA.
The MN's traffic would thereby not be dropped (except for any traffic in
transit when the HOTI is sent). Do you agree?

In the meantime, perhaps we can get the details sorted out about CBA/OMIPv6
and perhaps an experimental draft that people could implement and test.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 23 Mar 2005 11:15:11 -0800

Folks,

Thanks for the excellent exchange so far. At this point, based on what I've
seen, I'd like to share with you how I'm seeing things.

MN-AR security
	seems like there is sufficient interest and this item is
	narrow enough to warrant further work on the SeND key
	reuse method as well as to develop a AAA-based solution.
	Whereas we believe there may be some IPR-issues to clarify
	with the SeND based approach (in spite of Jim's interpretation)
	we don't have the same clarity with respect to the AAA approach.
	Please come forward with your IPR disclosures on this. This is not
	optional.
	
	looking at 2 PS documents.

FMIPv6 itself
	I'd postpone this item given that we don't have a clear understandiung
	of what the exact relationship with DNA, CARD, 802.21 and the forthcoming
	neighborhood discovery is (and heck, there's even a proposal for dhcp).
	I'm inclined not to include it for now
	until we know more, and look into it again until a few months have
	gone by and we have a better grasp of the security and the discovery
	portions. The former to continue here, the latter to continue elsewhere
	(e.g., mobopts).

FMIP-over-cdma
	This experimental document is a useful exercise to better understand
	deployment considerations and the above issues. It's also good in that
	it encourages another SDO to seriously think about this, even if it is
	in a preliminary manner (I don't believe they have firms and urgent
	deployment plans). I have heard of at least two groups of folks in
	the working group interested in this. You know who you are, and you
	should work together on one document. Highly desirable: go through the
	regular channels (ietf liaisons) and produce a document from 3GPP2
	on this subject.

	looking at one informational document

MN-MAP security for HMIPv6
	I'd like to think that such an item could be included, but we do need to see
	a draft on this subject in very short order. Conceptually, it does not seem
	a much more difficult problem than MN-AR security, so depending on how quickly
	the relevant draft can be produced, this could be entertained. It seems to me
	that without this piece in place, talking about other HMIP work in MIPSHOP
	is premature (but it should continue elsewhere). Like FMIP, other work could
	be taken on later on.

	perhaps (if a first solid draft appears shortly) one PS document

RO issues
	Not clear how much of EBU is new and how much is just further language on
	rfc 3775. At any rate, it does seem like a CGA-based scheme could be
	worked on (heck, the basic concept has been around for ages), using
	omip as a starting point. Highly desirable: go through the ietf channels
	and using the proper liaisons obtain a message from the SDOs reputedly
	interested in this item. This document would have the precondition for
	CBA (authenticated notification of CoA change to the CN). Ideally, we'd
	have a very simple CBA scheme in place as well.  Both of these mechanism
	would be optional (i.e., we're not in the business of replacing RR).

	looking at one PS document.

This gives us a lot already, perhaps too much:
	(up to) 4 PS documents (perhaps 3)
	1 informational document

I don't think we want to take on any more load for now. As we complete
items, we will look into it (as we are doing now).

This may not be everybody's favorite list, but hopefully it works reasonably well
(or at least *maximizes the distribution of unhappiness*, as Brian put it at the plenary).

comments? close enough, way off?

-gabriel

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 23 Mar 2005 11:52:03 -0800

Hi Gabriel,

>     portions. The former to continue here, the latter to continue 
Clearly, I am a bit surprised at this. We would work on 2 PS documents 
for MN - AR
security but not on the spec for which those two PS documents are meant 
for?

Also, I don't think the relationship wrt other work is unclear.

DNA: works for reactive FMIP when no neighborhood information is available
CARD: re-uses FMIP messages for MN - AR interaction. (This is in the 
CARD spec)
802.21: Provides triggers in a "Media-Independent" way. Should help FMIP.

What am I missing here? I didn't hear anyone express the "lack of 
understanding"
as you put it. But I remember Jim Kempf saying some work can be done on 
Neighborhood
discovery in MobOpts.

Also, if folks want to work on extensions of FMIP (e.g., dhcp 
extensions), it is
up to them. That cannot be the reason to deduce that there is less clarity.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Mar 2005 13:27:44 -0800

Gab,

Here's a couple of suggestions to reduce the number of items:

1) I'd like to see some data first on proposed RO enhancements before
starting any PS work on anything other than simple enhancements to the
current RR protocol. I believe 3GPP2 has stated that they are happy with RR
as stands, so I see no tearing hurry to standardize alternatives at this
time. Since getting such data and comparing has been elusive in IETF, I
think this is still an IRTF item. I think the authors of the two contenders
could be encouraged to look at a combined design, and provide some data on
it once they have agreement.

2)  Of the security alternatives mentioned in the discussion for HMIP,
aggregate security is unacceptable because it does not provide the access
network with protection against a mobile node that obtains the certificate
of a roaming partner and presents itself as a client of  the roaming partner
when it is not. IKEv2 with EAP authentication using the network access
credentials would work, but only for a particular limited set of deployment
circumstances. CGA would work but only if address configuration uses CGA
(and there's the usual IPR considerations). So I think there's still need
for more work on this in MOBOPTS, until we get a draft or drafts like we've
got for FMIP.

My 0.02 yuan.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Mar 2005 14:05:55 -0800

Gab,

Rereading this, I'm confused about why you didn't propose to move FMIP to
MIPSHOP for PS work, and, assuming you didn't, why you then are proposing
FMIP-over-CDMA2K for MIPSHOP.

I believe with the security now understood that FMIP is ready for PS work
(if not yet for PS). We're planning on doing the neighborhood discovery work
in MOBOPTS, independently from FMIP because neighborhood discovery must work
for 802.21 too. So that shouldn't impact how FMIP is done.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 23 Mar 2005 15:02:07 -0800

I strongly agree with Jim on 1).

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Mar 2005 10:24:08 +0200

Hi James,

>it once they have agreement.
Well, I think the question about the exact performance data
is very interesting. But its important to understand what
knowledge we have and don't have about the performance.
One thing we actually do know very well and don't need
to measure is the theoretical performance. For instance,
We know that CGA removes the need for per-movement
home address tests. The draft provides some data about
the impact of this in terms of amount of signaling under
different conditions. For instance, in the "stationary
mobile node" (!) case the savings are obviously significant.
In the fast moving mobile node case the savings are roughly
50% over a longer period of time (when the cost of the
initial setup has been amortized). In some cases this can
be beyond 50% if a proactive home tests a la RFC 3775
is applied and the movement pattern happens to lead
to unnecessary tests.

These were in terms of number of messages. We also know
that latency is impacted. For instance, when the home
address test is eliminated then you get rid of one of
the parallel roundtrips in RR, which has an impact when
the roundtrip via home network is longer than to the CN.

We also know pretty well the theoretical performance of
CBA. As you know, we've also run some calculations using
TCP or HTTP traffic.

What is it then that we don't know well? As far as I can
see the primary open question mark is what exact
traffic patterns applications have in general, and
how well these fit to the opportunities provided by
our enhancements. We also can't accurately predict
what typical network topologies are going to be, say
in terms of home vs. direct route lengths. But while we
don't know these exactly, I do believe we have all the
basic understanding already. That is, we know very
well that an application of a particular type will benefit
from a certain enhancement and another type of an
application does not (e.g. very asymmetric and CBA).
Its just that we don't know what fractions of Internet
usage in mobile scenarios is going to be what kind of
applications. But this is a general problem, affecting
almost everything that we do, starting from RO itself,
fixed-key RR, local repair schemes, the whole thing.

In conclusion, I think we actually know quite a bit about
the performance, and what we don't know... it may not
necessarily be related to just what we are suggesting
here. I don't want to be the only one who is subjected to
the requirement to understand the full traffic patterns
before we can produce a new function that we know
will be useful in certain cases.

(Also, lets not talk too much about what other SDOs may
or may not want. We are at the IETF and this is our
technology. If there are WG members and vendors who
support something we should do it. And yes, many people,
including myself, are quite happy with RR. That doesn't
mean that there's no room for improvement or that it
works well under all circumstances.)

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Thu, 24 Mar 2005 17:46:45 -0800

> I believe 3GPP2 has stated that they are happy with RR
> time.

Could this be because they are not using it? :-)

Alper

---

From: Takeshi Ogawa <[email-masked]>
Date: Thu, 24 Mar 2005 19:04:14 +0900

Hi Gabriel,

I agree with Rajeev on "FMIPv6 itself".

I proposed a new dhcp-extension for fast handovers in last 
mobopts meeting that require no handover specific function 
on access routers. Combining it and "tunnel buffering" in HA 
proposed by Moor, seamless handovers can be achieved. I 
suppose it would be useful in a specific circumstance where 
it is difficult to add new functions to access routers in a 
service area.

However, except the such circumstance, I believe current 
FMIP itself has no major issues and it is solid enough to be 
PS. Many groups including us have verified its basic 
feasibility in their test systems, and we are looking 
forward to it being PS soon.

I hear dna people chose two approaches, one is adding new 
function to access routers and getting best DNA, and the 
other is using current access routers and getting better DNA.

I suppose we can go similar way.

-Takeshi.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Mar 2005 09:49:09 -0800

Hi Jari,

> CBA. As you know, we've also run some calculations using

So one issue here is what the performance/operation of a combined protocol
would be like. What would be the interactions?

> will be useful in certain cases.

I think your characterization of "what we don't know" points up one of the
reasons why I believe it is premature to be talking about a PS draft. I
don't see any real demand for a new RO security algorithm at this point,
because nobody is using deployed MIP6 to generate the kind of traffic that
would provide the answers to these questions. I believe that PS work in IETF
should address a specific market or deployment demand (I know that others
might disagree). Or were you proposing that the work be moved to MIPSHOP and
advanced as Experimental? And, if Experimental is acceptable, why not
advance the drafts in MOBOPTS?

> works well under all circumstances.)

The point of mentioning other SDOs was merely to indicate that there is
really no market or deployment demand for alternative RO security algorithms
at this point. Other SDOs often generate such demand, because they are often
more driven by business considerations than IETF is (sometimes to the
detriment of their technology, unfortunately). The two that the MIP6 WG are
considering are fairly obvious, relatively simple, and therefore a safe bet
for PS. I agree that IETF needs to decide for itself what kind of technology
it wants to develop.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 24 Mar 2005 10:48:02 -0800

> security but not on the spec for which those two PS documents are meant 

never said we wouldn't. only not initially. if a spec has work items
A and B to be done, and we decide to work on A as a clear item. Why would
the spec then be ready? We need to also work on B, and then the spec
can progress. More on 'B' below...

> as you put it. But I remember Jim Kempf saying some work can be done on 

neighborhood discovery was only one of the items he mentioned.

>> the Layer 2 information to determine whether it has moved.

this is one proposal: remove PrRtXXX msgs from base draft

>> design item here to merge the PrxyRtXXX messages and CARD.

another proposal, merge CARD and PrRtXXX. another item mentioned is that fmip
should at least mention DNA. it currently does not, although this may not
be a big issue.

>> Discovery". This draft, when it is more mature, would be another item that

this was the neighborhood proposal.

i'm not saying i necessarily agree
with all his proposals, but i don't agree with you when you say that
neighborhood discovery was the only thing he mentioned.

Rajeev, did you really forget about items like the above? Others have
also expressed the CARD vs FMIP issue (some have called it "schizoid").

when i see messages like the above, my interpretation is that there is some
confusion.

if we were to standardize fmip today, what would it look like
exactly? i don't see any urgency or anybody breaething down our necks for us
to decide that *today*.

3pgg2 is starting to make noises. fine, let's encourage those noises and
revisit in paris. what i don't want to see is another card vs PrRtXX debate
*while* we're working on the PS for FMIP. i'd ideally like to see those
debates arrive at a resolution as a precondition to start working on the PS
document.

it seems like you have an idea of what a PS fmip should look like. that's
great, and i'd encourage you to submit the corresponding individual draft
asap. we'll iron out the details and once it seems to be stable, we'll
convert it to a WG item.

> up to them. That cannot be the reason to deduce that there is less clarity.

agree on thsi part.

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 24 Mar 2005 10:55:35 -0800

> as stands, so I see no tearing hurry to standardize alternatives at this

i'm not sure i see any "tearing hurry" to standardize *anything* in this
working group.

> it once they have agreement.

jari responded on this, yes there is some data.

> (and there's the usual IPR considerations). So I think there's still need

these considerations apply to the SeND derived key for MN-AR as well. i know
you claim that the SeND license covers that, but i will only believe it when
we have the legal indication as none of us are lawyers.

yes, the operational implications of using CGA's are not clearly understood and
might affect deployment independently of any licensing issues.

> for more work on this in MOBOPTS, until we get a draft or drafts like we've

i'm seeing this as a potential item, depending on whether a draft can be produced
in short order by the interested parties and deemed acceptable by the WG.

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 24 Mar 2005 10:59:02 -0800

James Kempf wrote:
> MIPSHOP for PS work, and, assuming you didn't, 

i didn't for now, based on views expressed by folks like yourself.
see my previous message to rajeev.

> why you then are proposing

i don't have clear indications as to what their interest is. but it seems like it is
preliminary at best, so involving them in such an informational document seems
fine. if they were close to starting specification work, it would be different.
we need to know where they are...

-gabriel

>>Thanks for the excellent exchange so far. At this point, based on what
> 
> I've
> 
>>I'd like to think that such an item could be included, but we do need to
> 
> see
> 
>>a draft on this subject in very short order. Conceptually, it does not
> 
> seem
> 
>>a much more difficult problem than MN-AR security, so depending on how
> 
> quickly
> 
>>the relevant draft can be produced, this could be entertained. It seems to
> 
> me
> 
>>is premature (but it should continue elsewhere). Like FMIP, other work
> 
> could
> 
>>be taken on later on.
>>
>>This may not be everybody's favorite list, but hopefully it works
> 
> reasonably well
> 
>>(or at least *maximizes the distribution of unhappiness*, as Brian put it
> 
> at the plenary).
> 

-- 
Gabriel Montenegro (Sun Microsystems Laboratories)
16 Network Circle, UMPK16-157       Email: [email-masked]
Willow Road at Bayfront Expressway  Office: +1 650 786 6270  (sun internal: x86270)
Menlo Park, CA 94025, USA           Fax:    +1 650 786 7671

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Mar 2005 11:30:18 -0800

Gab,

It sounds to me like you are looking for a draft or something resolving the
CARD v.s. PrxyRtXX issue, is that it? If so, I think this should be fairly
easy to come up with. We already have a draft underway (unfortunately, not
released yet) that lifts the CARD information elements out of the IP
transport, for 802.21. Defining an IP transport specifically that unifies
PrxyRtXX and the CARD MN-AR transport should be straightforward.

>From the partitioning of documentation standpoint, it might make sense to
bundle FMIP and a merged MN-AR IP transport, since then both would be in the
same place which would make referencing easier (trying to go between RFCs
when doing any design work is a nightmare, why can't we have hyperlinks?).
The only reason I could see separating them is if we anticipated that there
would be a different transport used (and that includes L2.5 potentially),
but even then the merged MN-AR IP transport could be made optional in a PS
FMIP draft.

Do you (or anyone else for that matter) have opinions on this? And, please,
let's not discuss this issue based on history, let's discuss it on what the
right functional architecture and partitioning of documentation should be,
OK?

            jak

PS: There is also the issue of the inter-AR CARD transport ,which is bundled
with the MN-AR transport in the CARD RFC. Since Seamoby was unable to come
to a conclusion about the right way to provision CARD information to the
ARs, the inter-AR transport is left without any way to say how the CARD
information gets to the routers in the first place. I think this issue is
still undefined enough that it probaby should be kept in MOBOPTS, and that
the inter-AR CARD transport should probably be separated from the MN-AR CARD
transport.

----- Original Message ----- 
From: "gabriel montenegro" <[email-masked]>
To: "Rajeev Koodli" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 24, 2005 10:48 AM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

subnets.
the
both
current
that

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 24 Mar 2005 11:34:47 -0800

> neighborhood discovery was only one of the items he mentioned.
did you see Jim's e-mail on this he sent yesterday?

> neighborhood discovery was the only thing he mentioned.
Ok. Jim should speak up and clarify.

> also expressed the CARD vs FMIP issue (some have called it "schizoid").
I don't see anything fundamental that would be a show stopper for FMIP 
here.
If others disagree, I would like them to state it. I am also assuming 
that all the
documents will go through the natural rev cycle, and I don't see  FMIP 
taking
more than the fair share especially because it has  completed the EXP 
round, and
folks have implemented it, as you and others have noted on the ML.

> when i see messages like the above, my interpretation is that there is 
I guess you would agree that it would be better to make informed rational
decisions than to use paranoia.

> exactly? i don't see any urgency or anybody breaething down our necks 
How do you like to justify applying this logic to _all_ the topics you 
have suggested?

> debates arrive at a resolution as a precondition to start working on 
I am beginning to think this CARD vs PrRt* matter is being over-blown.
I would like CARD proponents to come forward and state if they see a problem
in moving FMIP to PS.

> asap. we'll iron out the details and once it seems to be stable, we'll
If you would like to go this way, we should do that for _all_ topics.

-Rajeev

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 25 Mar 2005 15:15:40 -0800

James Kempf wrote:
> CARD v.s. PrxyRtXX issue, is that it? 

yes

> If so, I think this should be fairly
> easy to come up with. 

as you allude to below, the issues may be more at level 9 than anywhere else.

> We already have a draft underway (unfortunately, not

this would be great. i take your position as representing the seamoby
point of view?

> but even then the merged MN-AR IP transport could be made optional in a PS

sure, a merged transport makes sense. what about merging the information elements
as well? there seems to be two ways of describing candidate ARs, two ways
of codifying the L2 address, two ways of codifying the L3 addr, etc.
shouldn't there be only one?

would such a unified information element set live in a separate document?

> right functional architecture and partitioning of documentation should be,

right.

> the inter-AR CARD transport should probably be separated from the MN-AR CARD

sounds reasonable.

-gabriel

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 25 Mar 2005 16:52:37 -0800

> shouldn't there be only one?
Gabriel: in case you do not have sufficient context behind CARD.. The 
data that CARD
collects goes into a TAR (target ar) selection. FMIP uses Proxy messages 
to learn NAR
IP parameters. CARD supports FMIP transport.

" 4.4 CARD Protocol Message Piggybacking on the MN-AR Interface

   CARD supports another mode of CAR information distribution, in which 
   the capabilities are distributed piggybacked on fast handover 
   protocol messages. To allow MNs and ARs appending the ICMP-option 
   type CARD Request and CARD Reply (Section 5.1.2) to the ICMP-type 
   Fast Mobile IPv6 [Kood03] signaling messages, the MN and AR should 
   know about the signaling peer's capability for CARD protocol message 
   piggybacking...."

I have had discussions with CARD editors to arrive at this a while ago.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Mar 2005 10:12:51 -0800

> this would be great. i take your position as representing the seamoby

My "position" is to get something useful for 802.21, so that there is some
hope of deployment. I'm not interested in seeing another RFC that nobody
implements or deploys.

> would such a unified information element set live in a separate document?

Yes, that's the idea. Rajeev and I are discussing it.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 28 Mar 2005 10:30:57 -0800

>Yes, that's the idea. Rajeev and I are discussing it.
This is along the lines of what MobOpts could provide for IEEE 802.21.
The transport messages themselves are protocol-specific.

-Rajeev

---

From: Greg Daley <[email-masked]>
Date: Tue, 29 Mar 2005 11:51:08 +1000

Hi Rajeev,

Sorry about the delayed reply,

> MIPSHOP should focus on a narrowly scoped charter. We get done

I agree that a closely focussed charter needs to be worked out.

I disagree that the RR optimizations should be research track.

Simply put, there are some bugs to iron out in each of
the proposals  [OMIPv6, EBU, CBA].

There is in each a core idea which is well understood though,
and needs a small amount of time in IRTF, before becoming
purely engineering effort.

The IRTF time is simply to clarify which components belong
to which technique, and outline what's required and out-of-scope
for each.  This should aid understanding and allow for more
succinct development of tasks for standardization.

I'll try to publish my ideas about this onto the IRTF-mobopts
list in order to clarify these points.

Greg

---

From: Greg Daley <[email-masked]>
Date: Tue, 29 Mar 2005 12:03:47 +1000

Hi Vijay,

Vijay Devarapalli wrote:
[chop]
> solutions standardized in the IETF as proposed standards.

I think it is OK to have multiple protocols looking at different
aspects of a problem.

Optional protocols work well when there's no requirement for
them from the access infrastructure, and they can be negotiated
once (at session startup) and used for the lifetime of an
end-to-end communication.  Both EBU and OMIPv6 can do this
easily.

I actually thin that OMIPv6 and EBU look at different parts of
the RR issue.   OMIPv6 doesn't do CoTI/CoT optimization very well
(Wassim disagrees though ;), EBU has a hole (with a similar
work-around solution) where it relies on pre-existing trust of
the Home Address.

The benefits though of each solution are orthogonal and highly 
complementary.

OMIPv6 (primarily) reduces Home address tests, and allows long-term
     security associations for home addresses.

EBU (with some rationalization of messages) can reduce Care of tests,
     without incurring additonal signaling cost.

Either or both could be used by consenting pairs of hosts.

Why not standardize both of them?

RR is clearly not fast enough now for real-time applications.

Greg

---

From: Greg Daley <[email-masked]>
Date: Tue, 29 Mar 2005 12:14:58 +1000

Hi James,

> come up with a draft merging the two?

I don't think you'll ever see that, and it may be unnecessary
(creating an artificial barrier to advancement).

The goals of each are separate, so they should be separate
documents.

HMIPv6 and FMIPv6 are separate, right?

Greg

---

From: Greg Daley <[email-masked]>
Date: Tue, 29 Mar 2005 12:29:08 +1000

Hi James,

> would work for bidirectional flows like VoIP.

Transient increases in RTT latency == Jitter.

Please let's agree that this is a bad, bad idea for VoIP.

The existing text in OMIPv6 which suggests this is my primary
issue with the current document.

Conceptually, OMIPv6 home redirection is using the network as
a buffer in the same way that mercury delay lines were used
in early computers as memory.

It's better to just send the packets to the new CoA, if we
have enough reason to believe the MN is there for a short time
(for example if OMIPv6 proves that this is the same Home Address,
or a Home Test is current)

I'll tackle this later on in a post to MOBOPTS.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Mar 2005 18:31:37 -0800

> Why not standardize both of them?

simple. nobody has yet convinced me that they are needed.

> RR is clearly not fast enough now for real-time applications.

and OMIPv6 and EBU are fast enough for real-time applications?
I would like to see some data supporting this. I hope you
werent planning to do real time applications with just base
MIPv6. ;) return routability was not designed with real-time
applications in mind. have you considered FMIPv6 or HMIPv6?
(tongue-in-cheek ;)

Vijay

---

From: Greg Daley <[email-masked]>
Date: Tue, 29 Mar 2005 12:38:52 +1000

Hi Vijay, all,

We have a paper in submission which has some figures for EBU
(amongst other things).

I'll discuss it woth my co-authors, but we should be able to
provide a preprint to people upon request.

Greg

---

From: Greg Daley <[email-masked]>
Date: Tue, 29 Mar 2005 13:34:33 +1000

Yes.

I've not found any deployed networks to test on though :P

Seriously though, HMIPv6 and FMIPv6 are overlay rouyting services
provided by the access network.  What if we wish to have good
performance when these aren't available?

RO is used when there's sufficient difference between the
MN-CN RTT and the MN-HA RTT (or even MN-HA-CN RTT) to warrant
sending packets directly.  This decision is already made on the
MN.

Currently the cost in lost packets and handover delay is higher
for RO, due to RR.  Reducing this cost is valuable.

Greg

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 28 Mar 2005 23:39:31 -0800

Rajeev Koodli wrote:
>      CARD supports another mode of CAR information distribution, in 
> which   the capabilities are distributed piggybacked on fast handover   
> protocol messages. To allow MNs and ARs appending the ICMP-option   type 
> CARD Request and CARD Reply (Section 5.1.2) to the ICMP-type   Fast 
> Mobile IPv6 [Kood03] signaling messages, the MN and AR should   know 
> about the signaling peer's capability for CARD protocol message   
> piggybacking...."
> 

Rajeev, thank for the info, but I'm not sure I see an explicit
answer to my question (it may be in there somewhere, but I'm dense).
The question was:

    "shouldn't there be only one?"

I don't see a "yes" or a "no" or something like it in this message.

> James Kempf wrote:
[line left out in your message] shouldn't there be only one?
> This is along the lines of what MobOpts could provide for IEEE 802.21.

 From this, I gather that (no interpretation, based on what you're saying above):

- both you and James agree that such a unified element set is a good idea and
   are working on one

- this unified set of information elements should live in a separate document
   from FMIPv6

So this is a "yes" to my question above.

- Would such a unified set of information elements imply any changes to the
   existing information elements in FMIPv6?

Even if it doesn't, wouldn't the subset of them that currently in FMIPv6 need
to be lifted into this new document? FMIPv6 would refer to that document
for its information elements ( a subset of the whole thing).

Presumably, in this new document, no duplication would exist. For example,
instead of having both of these:

  - FMIPv6 Link-layer Address (LLA) Option (sectin  6.4.3)
  - CARD L2 ID Sub-Option (section 5.1.3.1)

One should one have only one way of codifying the link-layer information.
Same for other common information elements.

I *believe* this is what both of you agreed to. Please correct
if this is wrong.

thanks,

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Tue, 29 Mar 2005 08:56:24 -0800

Greg,

The problem is that any RO security protocol must be incorporated into the
CN. It is not likely that all the CN's in the IPv6 world will have more than
one or possibly two such protocols. If there is more than one standardized
protocol, then either the nodes that use it are likely to be restricted to
some small subset of the nodes in the IPv6 Internet, or there needs to be
some kind of negotiation between the MN and the CN about which one to use.
If there is a negotiation, there is always the potential for bidding down
attacks.

RFC 1958 Section 3.2 says (and I quote):

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

I believe this is wise advice, in this case.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: "Wassim Haddad" <[email-masked]>; "gabriel montenegro"
<[email-masked]>; <[email-masked]>
Sent: Monday, March 28, 2005 6:03 PM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

---

From: "James Kempf" <[email-masked]>
Date: Tue, 29 Mar 2005 08:59:15 -0800

But FMIP and HMIP perform functionally separate tasks. I don't see such a
substantial difference between the RO security protocols. It's primarily a
matter of performance. I think OMIPv6 solves the residual attack, which
might be a reason to consider it.

If you want an analogy, try Prereg and Postreg in LLH. They essentially
solve the same problem.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Vijay Devarapalli"
<[email-masked]>; <[email-masked]>
Sent: Monday, March 28, 2005 6:14 PM
Subject: Re: RR enhancements (Was: Re: [Mipshop] MIPSHOP discussion on new
itemsand milestones)

---

From: "James Kempf" <[email-masked]>
Date: Tue, 29 Mar 2005 09:03:23 -0800

> applications in mind. have you considered FMIPv6 or HMIPv6?

I agree with Vijay here.

The only reason I can see for any additional work on RR-based algorithms is
to get rid of the residual attacks.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 29 Mar 2005 16:57:01 -0800

> - both you and James agree that such a unified element set is a good 
Yes, especially for 802.21.

> - this unified set of information elements should live in a separate 
Yes, because there is _no_ "information elements" thing in FMIPv6 right 
now.

> So this is a "yes" to my question above.
See above.

>   existing information elements in FMIPv6?
No.

> for its information elements ( a subset of the whole thing).
The process of performing "inverse ND" for an AP Address to obtain target
subnet information is *basic* to FMIPv6. Any other property of the AP
that a MN may be interested, e.g., to perform a target AR selection, is 
suitable
for the "information elements" draft. So, I don't think anything from 
FMIPv6
needs to be lifted into a new document. The LLA option format should be
made consistent (see below).

It is important to delineate the (offlink) inverse ND operation that FMIPv6
performs from the process of  neighborhood discovery for target AR 
selection.
The former needs to be in the FMIP base spec for it to operate without
depending on a particular AR selection method.

> I *believe* this is what both of you agreed to. Please correct
Moving forward, we can specify a single option format as we revise
FMIPv6 towards PS. CARD can use the same format when it comes
for PS.

In sum, the FMIPv6 LLA option format can be revised to be consistent.
The "information elements" draft can be useful for 802.21, and possibly
for CARD as well.

Hope this helps.

-Rajeev

---

From: Greg Daley <[email-masked]>
Date: Wed, 30 Mar 2005 13:46:58 +1000

Hi James,

> I believe this is wise advice, in this case.

Yes it is wise advice.

Currently though, there is a protocol which was acknowledged to be
"good enough" to bid down to in RR.  The CN IPSec draft gets away with
the bid-down issue because it leaves things for pre-configured trust
associations.

There are two issues though:  Speed of handover and security
association lifetime (which happens to reduce signaling or handover
delay).

EBU clearly does only the first. Clearly, failure to negotiate EBU
is well within the appropriate behaviour of the CN, and is not a
bidding down attack in and of itself.

It can be argued that OMIPv6 only really does the second well
(please bear with me on this).  So only OMIPv6 is a security
protocol, and is subject to bidding down attacks.

So I don't think EBU and OMIPv6 duplicate each other, but clearly
theres' overlap between the HoTI/HoT, OMIPv6 and CNIPSec.

The discussion previously held when MIPv6 was at draft 14 about
SA creation seemed to indicate that IKE wasn't going to be a general
solution.  Therefore I guess there's enough experience to look at the
cost/benefits of OMIPv6 in removing the home test.

If the authors of the OMIPv6 draft have some computational cost figures
of generating a CGA and establishing a long-life kbm, then this will
help.

Then we can see if there's sufficient benefit.  It's worth considering
that only one encryption mechanism was a MUST for ESP, and it's now been
dropped from the specification.   If there are mechanisms which are
clearly better than the one we've got (for example if the IPR is
eventually cleared up), it may be necessary to upgrade to these in the
future, just as implementations started dropping default support for
DES and shifted to 3DES.

Greg

---

From: Greg Daley <[email-masked]>
Date: Wed, 30 Mar 2005 14:02:27 +1000

Hi James,

>>applications in mind. have you considered FMIPv6 or HMIPv6?

Apologies to Vijay, to whom I sent the following (off-list)
text response.

---
You're right if you mean that OMIPv6 or EBU are not sufficient
for real time handover.

They may be necessary though in some environments.

The non-predictive handover process in 802.11 is held to
ransom today by scanning and probe times.

I've read papers which mention that they can hide 60ms
of outage in a G.729 voice stream using CELP.

So I guess we can lose up to 60ms of RTP frames,
in a handover. The CN has to then be updated within this duration.

If the L2 + L3 handover time can be brought within that
budget, acceptable VoIP quality may be acheiveable.

If the L2 handover delay can be reduced, there's still a
requirement to have expedited signaling at L3.

DNA and Opti-DAD are applicable to the reactive scenario (these
are fairly achievable as sub 20ms usual case in WLAN), so the
next most important costs then are the peer (or HA) signaling.

OMIPv6 removes Home Test.  This is necessary for the reactive case.
EBU reduces the cost of Binding signaling and keeps RTT uniform
(assuming similar local access networks).

I'm not sure if this is convincing, but it's my reasoning.

---

> to get rid of the residual attacks.

I really have to disagree, and I'd really like to know why
you're thinking about it this way.

I think you've been one of the people who has encouraged people to
look at ways of achieving HMIPv6 without modifications to routers.

Well, HMIPv6 gives some signaling benefit, but relies on modified
routers today.  EBU and OMIPv6 have a signaling benefit without
infrastructure reliance.

I think that people are to be encouraged to generate solutions to
handover delays without requiring heavy infrastructure
modifications.   Three years ago, with the delays in movement detection
and DAD, I would have agreed that the effort wasn't warranted.
The situation is changing today.

Sure, they won't have the same performance as FMIPv6, but they may
provide better performance in the case of prediction or tunnel
setup failure.

They'll also work on corporate LANs and hotspots which may not have
accurate neighbour maps.

Once again, it's an opinion,

Greg

---

From: Christian Vogt <[email-masked]>
Date: Wed, 30 Mar 2005 10:03:00 +0200

> So it sounds to me like, for standardization purposes, the
> bottom-line, simplest modification that we could make to RFC 3775
> would be to incorporate
> The MN's traffic would thereby not be dropped (except for any traffic
> in transit when the HOTI is sent). Do you agree?

Hi James,

sorry for the huge delay.

Yes, I do agree.  Adding this early message is a simple optimization to
RFC 3775 which fits nicely together with the existing possibility to do
proactive HoA tests.

We could also leave it up to the CN implementation what to do upon
reception of the EBU.  The CN could divert packets through the HoA,
buffer the packets until reception of the (standard) BU, or just drop
the packets.  A CN who understands the EBU should, however, discontinue
to send packets to a stale CoA, of course.

An optimized MN (i.e., one that sends EBU's) should also be prepared to
receive packets through the HA-to-MN tunnel during handover.  So we
might want to add a brief statement in sections 11.3.3 (4th paragraph)
11.7.2 (6th paragraph) saying that such tunneled packets should not be
considered a trigger to invoke RR again.

 > In the meantime, perhaps we can get the details sorted out about
 > CBA/OMIPv6 and perhaps an experimental draft that people could
 > implement and test.

Yes, sounds good.

- Christian

James Kempf wrote:
> Christian,
> 
> 
>> What bothers me more is this:  If you use reception of a HoTI or
>> CoTI message as indication to the CN that it should switch to the
>> MN's HoA, an attacker could send the HoTI or CoTI on behalf of a MN
>> to redirect the MN's packets as well.  That would be some new kind
>> of DoS attack. It's not so dangerous, because packets will reach
>> the MN eventually, but it increases the HA's workload as well as
>> packet-propagation delays.
>> 
> 
> 
>> So what we need is an early message that both authenticates the MN
>> (like the EBU) and suggests to the CN that it should now switch to
>> the HoA.
>> 
>> Anyway, if the optimization is to work, we need to modify both the
>> CN and the MN implementation.  After all, we not only want the CN
>> to temporarily divert packets to the HoA, but we also want the MN
>> to tunnel packets though its HA as soon as the RR procedure begins
>> rather than halting the packets until they can be route-optimized
>> after BU dispatch.
>> 
>> For this early message to provide authentication, it could carry a
>> BAD similar to the EBU (or standard BU) message.  For computing the
>>  Authenticator, however, one would require a fresh Home Keygen
>> Token, so the HoA test probably needs to be performed proactively
>> (which is possible with RFC 3775).  And then we are back to Early
>> Binding Updates where the EBU/EBA messages are integrated with the
>> CoTI/CoT messages. ;)
>> 
> 
> 
> So it sounds to me like, for standardization purposes, the
> bottom-line, simplest modification that we could make to RFC 3775
> would be to incorporate something like EBU that would allow the CN to
> obtain a verified early notification of change that would then let it
> move traffic back to the HoA. The MN's traffic would thereby not be
> dropped (except for any traffic in transit when the HOTI is sent). Do
> you agree?
> 
> In the meantime, perhaps we can get the details sorted out about
> CBA/OMIPv6 and perhaps an experimental draft that people could
> implement and test.
> 
> jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 30 Mar 2005 09:47:15 -0800

Rajeev,

> >   existing information elements in FMIPv6?

Actually, I disagree. Please see below.

> made consistent (see below).

This "inverse ND" is also defined in CARD. There, it is called "reverse
address translation" (Section 3.1). In fact, CARD is designed to work for
IPv4 as well, which should help for your FMIPv4 draft. With a modified
version of CARD appropriate for both FMIP and 802.21, there is one mechanism
to do this for both IPv4, IPv6 and 802.21, rather than one for IPv4 and one
for IPv6 and one for 802, as would be the case if the "reverse address
translation" mechanism were duplicated in two drafts, the FMIPv4 and FMIPv6
draft, and a separate one for other neighborhood information.

In addition, certain parts of  "inverse ND" as defined in FMIP have been
superceded by recent events. As defined by the FMIP draft, "inverse ND"
includes both discovery of neighboring subnet prefix  and router information
through mapping from AP to AR address and support for pre-handover duplicate
address detection. The latter is now obsolete. With the progression of
optimistic DAD towards PS (it is likely to get a PS RFC number before FMIP
does), there is no need for pre-handover duplicate address detection. It
complicates the protocol and is not possible anyway in the only case that
really matters right now, 802.11, because 802.11 does not have predictive
handover. It might be possible on 802.16, which does have predictive
handover as one option, but I believe it makes sense to simplify the
protocol and use optimistic DAD since I don't see any real difference from a
technical standpoint. In fact, Rajeev, if I remember correctly I believe
your original individual draft for an FMIP predecessor had optimistic DAD in
it. Do you see any problem with using optimistic DAD now, other than it
would involve a change in the text of the current FMIPv6 specification?

Therefore, IMHO, going forward, the only the part of the "inverse ND"
operation that is really necessary to define is the neighborhood discovery
part and that can be done by having the same information elements to convey
the AR address, subnet prefix, and AP address information from the AR to the
MN as for other neighborhood information, and define a transport for that at
the IP layer.

> depending on a particular AR selection method.

Can you explain why the format and definition of the information elements
involved in conveying the address and prefix information for "inverse ND" or
"reverse address translation" need to be any different than those for other
candidate access router characteristics, since they will be conveyed in the
same manner from the AR to the MN?

> The "information elements" draft can be useful for 802.21, and possibly

I don't see either CARD or FMIPv6 moving forward to PS as they currently
stand. As I've stated before, what I think we want is a clean functional
architecture, where the functions and interfaces are cleanly separated and
we reuse mechanisms from other IETF PS RFCs and drafts where appropriate.
What I would like to see is the following:

1) A transport independent information element format like EAP that can be
used by 802.21, but also by FMIPv4 and FMIPv6 to convey neighborhood
information about neighboring subnets from the AR to the MN upon MN request
(and also possibly pushed by the AR, but we would need to do some more
design on that). The information includes AR subnet information (like prefix
lists), AP link addresses, and other information appropriate to address
configuration on the neighboring link, which, today, are defined in both
CARD and FMIP.

2) A protocol based on FBU/FBAck/FNA to allow change in the local routing
through setting up a short-term tunnel from the previous AR to the MN's new
CoA.

3) A protocol to convey the neighborhood information from the AR to the MN
at the IP level, probably a set of request/reply ICMP messages merging the
PrxyRtXXX messages and CARD MN-AR messages in some fashion.

I have no objection to bundling 2) and 3) in one document for PS and calling
it FMIP, but I believe 1) needs to be a standalone document in order that it
be usable by 802.21.

            jak

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 30 Mar 2005 10:04:43 -0800

Greg,

> future, just as implementations started dropping default support for

I think there is a difference between the ESP case and this one. ESP always
had the ability to negotiate encryption algorithms, Mobile IPv6 never had
that for RO security. While there are now three different RO security
protocols (RR, preconfigured key, and IPsec), arguably, IPsec was always an
option and therfore Francis' draft is just clarifying what is possible and
how to do it if you want. RR was developed because IPsec wasn't considered
viable in the general case. The preconfigured key option was included in the
charter for historical reasons, because it is very simple, but it seems to
have a fairly limited (perhaps too limited to be of much interest at all,
IMHO) deployment profile.

What we are talking about with CBA and OMIPv6 essentially is a collection of
algorithms that would, in some sense, replace RR for a general purpose
security protocol. Right now, as I've said before, I don't see any big
deployment demand for a replacement. What I think we don't want (and perhaps
I am wrong on this) is two or three replacements for RR. If we are going to
do an ROSecurityNG I think we need to take the time to get it right from a
technical standpoint, and resolve any peripherial issues such as IPR, and
discuss problems with backward compatibility such as bidding down. There
needs to be a clear and compelling case why ROSecurityNG is better than RR.
Frankly, I can't see that case right now. What I see is people who've come
up with some admittedly cool technology pushing their specific solutions for
PS work in Mipshop. As Jari has said, each of the proposed solutions has
different strong and weak points, and therefore I don't see any clear reason
why one or the other should be chosen.

My 0.02 bhat.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 30 Mar 2005 10:47:25 -0800

Hi Greg,

> Apologies to Vijay, to whom I sent the following (off-list)
My apologies to Vijay as well :-)

I just wanted to point out few things.

- when no neighbor map information is available, you can still
   send FBU from the new link to the previous AR. When DNA
   and Optimistic DAD are available, the performance should be better.
   So, it is inaccurate to characterize FMIP as "prediction-based" only.

- there are proposals in IEEE on optimizing scan delays via neighbor
  reports as well as neighbor graphs that provide the map. Folks more
  involved on this can provide better input. So, using
  such information in WLAN is a very distinct possibility. And, we had
  a long discussion in MIPSHOP when revising FMIP-over-WLAN
  on separating scan and join, and I believe we have captured the 
essence of it
  in the current version.

- a protocol like FMIP can be deployed *re-using* HA functionality
  on a router (BU/BAck, BCE, tunneling,..). One could call it "heavy 
infrastructure",
  but then so would be MIPv6, RR, RR++ etc. The bare-bone approach would 
work without
  neighbor map even today. With neighbor maps (e.g., in WLAN), it would 
work too,
  but such a deployment cannot be interpreted to be a "heavy" requirement
  from FMIP. It is a choice.

My 2 cents..

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 30 Mar 2005 11:09:27 -0800

Greg,

>From the work we've done here at DCL, I've been convinced that reducing
handover packet drop is better addressed by technologies, such as FMIP, that
change the local routing so packets are tunneled from the previous AR while
the MN is coming up on the new AR. There's a certain amount of market
acceptance of this, since the wireless switch companies such as Aruba and
Airespace in fact do that for "IP mobility" using inter-switch tunnels,
though they tunnel at L2. That's why I am not such a big fan of technologies
such as CBA. I think the impact for real time traffic will be fairly minimal
for the additional complexity. The argument that CBA proponents make is that
not every router will have FMIP installed in it, but I think this misses the
point. As the deployment patterns of wireless switches is showing, the
capability will be there for those routers where it matters. For those where
it doesn't, there will be a gap in the realtime flow, but is that any
different from current cell networks where a dropout occurs if there's a
misconfigured BS? Bottom line is that we can probably do better than current
cell networks if the right network is in place, and if it isn't, it won't be
much worse.

The other argument involving handover optimization is reducing the amount of
signaling. RR has considerable signaling overhead, even if the MN isn't
moving. This argument is more compelling, at least for the "standing still
MN" case. The case of reducing signaling on handover is less compelling,
since localized mobility management technologies, such as HMIP, can do that
too, modulo the deployment argument, by simply reducing the number of
handovers.

The most compelling reason to do ROSecurityNG to me is removing the residual
threat. No handover optimization technology can achieve that. So I see this
as the key requirement for an ROSecurityNG solution.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; "Wassim Haddad"
<[email-masked]>; "gabriel montenegro" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 29, 2005 8:02 PM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 30 Mar 2005 11:12:54 -0800

Hi Jim,

I think we are mostly in sync regarding avoiding duplication of packet 
formats.
Your understanding of FMIP "inverse ND" also providing pre-handover 
duplicate
address detection support is incorrect. The Proxy messages do not 
involve any state
or correspondence with the NAR for duplicate address detection. (You may 
still be
remembering an older version of the draft from [mobile ip] days).

>it FMIP, but I believe 1) needs to be a standalone document in order that it
This matches my thinking. I see 2) and 3) as different sections in the 
same spec however.

Regarding 1): Let me contact IEEE 802.21 folks and figure out exactly 
what is needed.
In any case, we can use a unified packet format for the LLA option.

Is this a way forward?

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 30 Mar 2005 11:40:43 -0800

Hi Rajeev,

It sounds like we are in agreement.

Gab, can we agree to move FMIP into MIPSHOP? Given the interest shown by
CDMA2K in FMIP, I think it makes sense to do the work in IETF.

            jak

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 30 Mar 2005 22:49:01 +0300 (EEST)

On Wed, 30 Mar 2005, James Kempf wrote:

> MN" case.

=> Note that this particular issue gets worse when the two endpoints are
mobile (which IMHO won't be a rare scenario for mobility). Besides exchanging
data traffic, the two MNs will also have in parallel a "signaling traffic
exchange" session! OMIPv6 eliminates these signaling messages and provides better
insurance that the two endpoints own actually their home addresses by
using CGA technology on *both* sides.

Regards,

Wassim H.

> The case of reducing signaling on handover is less compelling,

---

From: Greg Daley <[email-masked]>
Date: Thu, 31 Mar 2005 15:08:09 +1000

Hi James,

> IMHO) deployment profile.

Actually, Mobile IPv6 has always had a capability to negotiate RO, 
through acceptance or rejection of Home Test Initiation messages.
The MN falls back to home tunnels if there's no valid response (or
a response indicating that the mobility header is misunderstood).

The mechanism to negotiate particular levels of service is therefore
already (at least partially) available.

I guess that's a side issue though.

> needs to be a clear and compelling case why ROSecurityNG is better than RR.

I agree with you. There may be a better way to do RO security than
OMIPv6.  I don't think we know if there is a generally applicable one
though.

As you probably know, I'm a fan of good enough timely solutions.
If there's sufficient confidence with a set (perhaps a set of one)
technologies for RO security, then it may be valid to proceed down
this track.

Does this mean that (the whole of) RO security/negotiation is put
into the IRTF though?

I think that we'd get a lot better buy-in from other groups and areas
if there are concrete charter milestones which discuss, develop and
standardize these things.

That may mean the initial analysis in IRTF, but I'd prefer that there's
a path forward within IETF for this work.

> why one or the other should be chosen.

Well the technology was cool and new a while ago.  Personally, I don't
have an agenda to push, except to see signaling durations come down
(which is important as I don't have FMIPv6 routers, and conceivably
my host won't have time to negotiate a security association with one
in the future...).

For the protocols which aren't specifically related to RO security, I
agree.

> My 0.02 bhat.

My .02 Pacific Pesos.

Greg.

---

From: Greg Daley <[email-masked]>
Date: Thu, 31 Mar 2005 15:48:40 +1000

Hi Rajeev,

You know I'm not trying to minimize the value of FMIPv6.
I was being loose with my terms.

>   So, it is inaccurate to characterize FMIP as "prediction-based" only.

Certainly FMIPv6 is applicable to reactive situations, but only if the
router is an FMIPv6 router.

In many situations this is not a valid assumption today, and tomorrow,
the quality of the FMIPv6 availability assumption will be highly network
or technology dependent (at least in the short-medium term).

This is why I mentioned DNA for reactive scenarios, which uses RA.

>  on separating scan and join, and I believe we have captured the essence 
> of it
>  in the current version.

This works really well in the case that the neighbour maps can be shared
amongst APs.  In most cases this will be the case for intra-subnet
movement, rather than inter-subnet movement (which is what is really
needed for IP).

Otherwise, the configuration of neighbour maps in IEEE is exactly the
same as prefix/router maps in IETF.

That is: it will work with managed networks.

FMIPv6's separation of scan and join is very important, and makes sense.

There's no magic bullet coming from the IEEE L2 network side which
will fix this generally though.

>  from FMIP. It is a choice.

RR++ doesn't need to be heavy infrastructure. It's an opt-in
technology (like TCP improvements).  We all know that the economics
and opportunities for consumer device upgrades are different to
those for edge telco networks.

If there's a technology which allows individual handsets to get better
performance without explicit support from the network, then that's a 
valid optimization.

> My 2 cents..

Always appreciated,

Greg

---

From: Greg Daley <[email-masked]>
Date: Thu, 31 Mar 2005 17:00:04 +1000

Hi James,

> cell networks if the right network is in place, and if it isn't, it won't be

It's good to have this perspective on the issue.

Firstly, it's worth saying that the additional complexity isn't
that great. Admittedly I've not implemented CBA, but apparently
code is coming out in Kame Shima which shows it is very simple and
small (at least in the transparent - no spot check version).
 From the EBU point of view, Eric in our lab implemented a simulation
of this (yes, I know, but it's fairly realistic) and it was < 50 LOC
with the proactive home test.

So the benefit comes down to performance:  What's the cost
(in delay, packet loss) of communicating directly with a peer CN
with and without EBU, whether or not there is reactive FMIPv6?

Since the signaling is in both cases, a single packet (either to the
origin AR or to the [nearby] CN), I can't see that FMIPv6 buys a lot
in this case.

At least the MN knows that its CN has EBU capability before it sends
the packet. The same cannot be said for FBU reception (and the 
uncertainty cost is greater).

If EBU and CBA can be shown to be useful, why not let people work on
it and standardize it?

> too, modulo the deployment argument, by simply reducing the number of

Well, HMIPv6 has its own problems (data plane overheads, MTU issues,
security), even modulo the deployment discussion.

I never thought we were going to stop work on mobility solutions
after we got FMIPv6 and HMIPv6 to experimental (or PS...).

The experience in the Mobopts group has shown that there's continued
interest in the area.  What's clear is that there will be talk about
R/LMM for a very long time (some of it the same talk heard before).

I'm not sure that we need to delve into these issues forever, but I'd
guess that saying local tunnels and LMM are the end is a bit premature.

Please clarify if that's not what you meant.

> as the key requirement for an ROSecurityNG solution.

This is a key requirement.  Is it in MIPSHOP, or too early?

Well as mentioned before, I still think that there are two goals.

* Fast Handover Signaling,

* Robust, widely deployable ROSecurity(NG).

I'm not sure if you agree, but I guess that the case for the first
can be made in IRTF, with work proceeding in IETF upon people showing
that there's some interest in the work, and some (at least mild)
benefit for the cost.

Greg

---

From: Greg Daley <[email-masked]>
Date: Thu, 31 Mar 2005 17:08:07 +1000

Hi Christian,

> to send packets to a stale CoA, of course.

I'm actually in disagreement here (surprise).

The CN shouldn't be in control of which destination the MN's data
gets sent to, that should at least be requested by the MN.

The CN should be in control of whether the binding cache state changes.

If the MN is on the old network, it may still send EBUs even if it has
multiple interfaces.  therefore reception of data on the old network
is going to be less disruptive than sending packets to home in some
cases.

> considered a trigger to invoke RR again.

That's fair enough.

>  > CBA/OMIPv6 and perhaps an experimental draft that people could

Certainly, I think that it's worthwhile pursuing EBU/CBA rather than
just redirection to home.

As mentioned before, the MN could easily specify which behaviour it
prefers (unverified CoA or HoA).  It may always be possible to
successfully request home redirection, but it may be possible that
the CN doesn't accept EBU to an unconfirmed address.

Greg

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 10:35:40 +0300

Hi James,

Regarding backward compatibility and bidding down: as you
might remember, this was extensively discussed while we
worked on RFC 3775. We know in fact quite well how to
negotiate additional RR schemes or other additional features
on top of the base specification. The main scheme for this
is informing the peer about our support for X in a message
that we send (e.g. a new moboption within a HOTI) and get
back a an acknowledgement about the willingness to do
it in a response (e.g. another moboption). The option handling
rules in RFC 3775 have been constructed precisely to make
extensions like this possible.

(When there are multiple choices, the mobile node 'offers'
what it has, and its the task of the correspondent node
to pick the one that it likes best.)

We also made a deliberate decision in RFC 3775 to NOT
support zero-config secure negotiation, and expected to
rely on configuration instead to limit bidding down
attacks, if necessary. This was partly because protection was,
uh, impossible in zero-config schemes, and partly because it was
deemed unnecessary. It was felt to be unnecessary,
because local policies can be used to make local decisions
about what a particular node should accept. For instance,
this is already being used in Charlie's fixed key scheme,
as a local policy controls that this node does not want to
do any other RR scheme than the fixed key scheme*.

You might worry if this affects the security benefits of
new RR schemes. Well, it all depends on how you turn
it on. If you turn it on as optional, then there are some
vulnerabilities left. However, there are still significant security
advantages, such as attackers not being able to remove
your CGA-based entry if you already have it. This resembles
pretty much SEND/ND mixed mode model. But of course
I could decide that in my home network, I  only want to turn
on CGA and not base RR, even if my box supported both.
But, I don't think this is the main driver for these
proposals, people just want to get some optimization and
security benefits as optional enhancements.

In conclusion I believe we know very well how to do this, and
people are already doing it for various MIPv6 extensions. I
admit that we can only provide limited support for bidding
down attacks. But that's because of deliberate decisions
at the time that RFC 3775 was designed, and I'd argue its
impossible to go beyond those limitations. Lets not reopen
that old discussion; zero-config schemes have some limitations.

--Jari

* The only thing that I'm not sure of is how Francis's
scheme is negotiated on because it involves multiple
layers. But that's not the problem we are discussing here.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 10:58:46 +0300

>IMHO) deployment profile.
You could just as well argue that IPsec was dismissed
as an option and now we are bringing it back. (With relatively
thin arguments, at least compared to the throughness of this
discussion. I like thorough discussion.)

And yes, I have the same feeling about the interest level for
preconfigured key option.

Let me rephrase the arguments slightly differently. I apologize
the use of sarcasm to highlight a point, but I want to get to the
bottom of this issue. Any resemblance to actual arguments
made on the list is purely coincidental ;-)

So we are basically advancing three RR schemes already, one of
which is standard, another one which was earlier dismissed
on technical grounds, and one which can't realistically be
deployed at all. And we do not want a new generally
deployable RR scheme because (a) we might invent something
better later and we don't want to commit to a new RR scheme
just yet (even if we have recently adopted two already), and
(b) we don't know how to negotiate a new scheme (even if
we do know, and even if we already have to do it for the
three methods we have), (c) we don't need any new
RR schemes (even if we are already advancing many),
and (d) we need more time to look at this in the IRTF
(even if none of the other things needed to do that,
and we are talking about one of the oldest RR
schemes).

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Thu, 31 Mar 2005 10:45:30 +0200

Hi Greg,

ok, let's see.

After a handover, the MN can do one of three things...

Case (1):  If the MN wants the CN to temporarily redirect packets to the 
HoA, it can just send a standard BU with lifetime == 0 and CoA == HoA. 
(I think this message should have a HoA destination option and a 
Alternate CoA option, both carrying the HoA?  See 5th paragraph on page 
133, RFC 3775...)

Case (2):  If the MN wants the CN to start sending packets to the new, 
unverified CoA immediately, it will have to send an EBU.

Case (3):  If the MN wants the CN to continue sending packets to the old 
CoA, it simply refrains from sending any early message, but does the CoA 
test (plus the HoA test if this has not already been done on a proactive 
basis), and subsequently sends a standard BU with positive lifetime.

This leaves the choice of where packets go to with the MN.

In cases (1) and (2) can the MN do a proactive HoA test (which it needs 
for both the standard BU with zero lifetime and the EBU) and, 
subsequently, a concurrent CoA test followed by a standard BU with 
positive lifetime.

Case (2) is where CBA comes into play.  CBA may lead the CN to deny a 
particular EBU.  (There is no default fallback option in such a case. 
Probably, the CN should drop packets until it receives the standard BU 
rather than sending them to the HoA?)

- Christian

   "Not everything that is faced can be changed, but nothing
    can be changed until it is faced." (James Baldwin)

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 12:17:38 +0300

Hi Christian,

> rather than sending them to the HoA?)

Well... I guess that would depend on whether the mobile node moved
because it felt it had another better address available, or because it
had really lost the previous address. If the mobile node still can receive
traffic at a previous care of address, then sending stuff to that address
would probably make more sense than either dropping or sending via
home agent.

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Thu, 31 Mar 2005 12:14:47 +0200

Hi Jari,

you are right.

I was looking for a general fallback solution.  But indeed, sending the 
packets to the old CoA, in case sending them to the unverified in 
unacceptable, is probably the better approach anyway.  At least from the 
MN's perspective.  The CN wastes some resources if a MN cannot receive 
the packets at the old CoA, but well, who cares...

We could specify a mechanism for the MN to request a fallback solution. 
  But IMO things get too complex then, so we shouldn't do this.

- Christian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 13:27:07 +0300

Christian Vogt wrote:

> I was looking for a general fallback solution.  But indeed, sending 
> the packets to the old CoA, in case sending them to the unverified in 
> unacceptable, is probably the better approach anyway.  At least from 
> the MN's perspective.  The CN wastes some resources if a MN cannot 
> receive the packets at the old CoA, but well, who cares...
>
> We could specify a mechanism for the MN to request a fallback 
> solution.  But IMO things get too complex then, so we shouldn't do this.
>
Yes, I tend to agree. I would note that this conclusion would simplify
CBA/CGA quite a bit, because you could concentrate only on doing
the credit thing or the home address test thing, and packet redirection
as such would work based on RFC 3775 mechanisms (if needed at all,
and I think Greg argued it might not make sense in a lot of cases).

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 31 Mar 2005 09:51:07 -0800

Greg,

> gets sent to, that should at least be requested by the MN.

It's not the MN's data and it's not the CN's data, IMHO. I suppose one could
look at is as the data from the CN being the CN's data to the MN and vice
versa, but I think it's really a bidirectional conversation, even in the
streaming media case, because there will be some control traffic coming back
from the MN.

I think it really shouldn't matter which end takes action to fix things up,
as long as the information that something is wrong can be verified as
reliable. This viewpoint is informed somewhat by considering the mobile to
mobile case, which I feel is likely to be very common in the future. In that
case, both sides are MNs.

> The CN should be in control of whether the binding cache state changes.

Of course, the binding cache is on the CN. What is important, and what I
believe Christian was getting at, is that the information about whether it
should change is reliable.

> is going to be less disruptive than sending packets to home in some

I'm not sure I follow you there. Are you saying that the MN on the old
network will have a single care-of  bound to multiple interfaces? Or a
single home? I can see the latter impacting the MN-CN connection at the IP
level, but the former should be hidden from the IP level, since whether the
packets come out one link interface or the other won't be visible on the
other side of the access router.

> the CN doesn't accept EBU to an unconfirmed address.

Sure.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 21:21:01 +0300

Hi James,

>case, both sides are MNs.
I tend to agree. I don't think we should decide this based on
a view of who owns the streams in some sense. More useful
considerations are protocol related, such as which peer is actually
in the position to easiest do something about the matter. Or can
do it in a reliable way. Or who knows the factors that affect the
decision. In any case, the communication between the two
nodes is really a shared matter.

--Jari

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 31 Mar 2005 11:07:32 -0800

Hi Greg,

> router is an FMIPv6 router.
You mean the previous router can also support HA functionality right?

As I mentioned, without any prediction, the MN can send FBU (which
is a BU with different Type number) to the previous AR. When you have
DNA and optDAD, the FBU should go out faster.

I don't see an FMIP router being different from a temporary HA for the
reactive case. If you only care for reactive handovers, you can do that
with the HA functionality extended for temporary tunnels for fast handovers.

> or technology dependent (at least in the short-medium term).
Right, it depends on whether an HA itself is available on the router.

> This is why I mentioned DNA for reactive scenarios, which uses RA.
I believe DNA should be useful for FMIP! Once the MN discovers
subnet movement, becomes IP-enabled, it can send FBU to the
previous router. I think DNA should help in sending FBU faster.

> movement, rather than inter-subnet movement (which is what is really
I don't see any reason why maps cannot be shared between subnets.

> will fix this generally though.
Products in market can do handovers within tens of milliseconds. We can do
in slightly more time with off-the-shelf prism2 cards and host ap driver.

> those for edge telco networks.
My point is if you consider HA functionality as heavy infrastructure, 
then so
is MIPv6, RR and RR+. And, you can do reactive fast handovers today
using HA functionality.

Just as you would like to consider DNA, Fast RA, optDAD and RR+, I would
like you to also consider DNA, Fast RA, optDAD and FBU. If the former is not
heavy infrastructure, I don't see how the latter is.

The latter also has the advantage of not having to do RR+ with _each_ CN
in order to minimize latency :-)

> performance without explicit support from the network, then that's a 
Would you consider HA acceptable in this equation? (I guess you have 
too, but
I am just checking).

-Rajeev

---

From: Greg Daley <[email-masked]>
Date: Fri, 01 Apr 2005 10:38:54 +1000

Hi Rajeev,

I get the feeling we're talking about completely different things
and are only just touching at the edge.

This could be a cause of misunderstanding.

> You mean the previous router can also support HA functionality right?

No, not really.

The issue isn't about the capabilities of the previous access router,
which are well known (the MN was just there).  The issue is the
requirement for a tunnel endpoint in the new AR, and the ability to
process FBU messages.

The issue is that the MN doesn't know (because prediction failed)
that the AR supports this.  Perhaps we can learn this upon our visit,
but this would either require probes or use of an existing information
service like RA or DHC (I guess RA could be used).

> DNA and optDAD, the FBU should go out faster.

Absolutely.  My assumption previously was about knowledge of whether
FBU could be sent to an AR.

> with the HA functionality extended for temporary tunnels for fast 

Yes. I can see that.  There are a few tricks with ND caches may not be
easy.  Do you have any idea how hard it was to keep the caches clean 
from your group's implementation?

> previous router. I think DNA should help in sending FBU faster.

Oh OK, I think we were talking at cross purposes.

That clears things up a lot.

> I don't see any reason why maps cannot be shared between subnets.

There's no reason why they can't.  It's just that they won't without
explicit management.

> in slightly more time with off-the-shelf prism2 cards and host ap driver.

This is all working on the host side though.  It's not like there's
a set of procedures which is going to allow APs to share cross
link boundary information without management.

> in order to minimize latency :-)

But you know which CNs are Route Optimized and you know which ones
will benefit...

There's no network upgrade (apart from the DNA and FastRA of course ;),
and the host is in control regardless of the network's infrstructure.

I will consider them.  There are tradeoffs in each case.

I don't really think that the costs are terribly high in this case,
as the optimization and security model for RR+ is conversation based and
end-to-end.

> Would you consider HA acceptable in this equation? (I guess you have 

I guess that I'm arguing for a new view of the technology, in addition
to the established view with is based on (local/regional) HAs.  I'm not
trying to get rid of the existing work.

In some cases it may take a different set of tricks to achieve good
performance.

Greg

---

From: Greg Daley <[email-masked]>
Date: Fri, 01 Apr 2005 11:01:48 +1000

Hi James,

:)

I thought the MN would be able to indicate whether it is better to send
the data to one address or another, considering that it has recently
changed access networks, and the CN's existing knowledge about path
properties are out of date.

The MN doesn't necessarily know much about the path other than what
it has learned through DNA though, since this is likely to be first
packet to expore the path.

> case, both sides are MNs.

Agreed, This is likely to be one of the most interesting cases.

> should change is reliable.

Fair enough.
> other side of the access router.

I'm actually talking about having a single home address, with two
separate CoAs, one of which is old and one new.

The MN sends an Early Binding Update to the CN telling it to use the
new CoA (instead of the old one).  In some cases, the reception of
packets at the old CoA is possible, even though the MN would prefer
the binding to change.  In some environments (say with CBA) there's not
going to be a convincing reason for the CN to send packets to the
unverified new CoA, so falling back to transmitting to the old CoA is
at least as good as changing the binding to drop packets.

Greg