Subject: [mobile-ip] RE: Is RR only enough ?

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 5 Jan 2002 12:50:07 +0100

Erik and Mike

I'll try to save BW and answer you in one email.

First to answer Mike, I'm not sure if we can say
MITM is acceptable and put a blanket statement
on that. I think it is more accurate to go with
the context of adding no harm since I believe
that the "MITM attacks are ok" statement was made
in this context, but I might have misunderstood.
So MITM attacks that can happen today are ok, but
I would assume that new ones are not. 
I'll try to answer Erik's comments below. 

  > Yes this is a possible attack.
  > 
  > But you seem to be implicitly claiming that this is worse 
  > than today's
  > IPv4 network with an attacker on the path between the 
  > communicating nodes.

=> Yes that's correct.

  > That is the argument I don't understand i.e. why is this 
  > any more harmful
  > than the MiTM attacking every TCP connection and UDP 
  > "session"? The MiTM

=> Well, this is a much simpler attack. That is, assuming
the MITM is in the right location, this attack
is easily done by one BU and steals all connections. 
Furthermore, if the MITM happens to be close enough
to the HA, he can do this attack for all MNs served
by that HA (assuming that he is close enough so
that most of the traffic addressed to the HA will
be seen by him). 

I would assume that in the cases you mention, the
MITM would have to do more work to be able
to steal a TCP connection for example. Actually
I don't know how the MITM can 'steal' the TCP 
connection in the scenario you mention. Please
note that I'm talking about stealing the existing
conneciton (receiving the information addressed
to the MN), rather than modifying packets and 
causing the connection to be dropped.

  > So why is it worse?
 
=> So to summarise my points above, I think it's
worse because:

- From a single location the MITM can steal _all_
the MN connections with a CN (and possibly more
than one CN). This is done without launching
any DoS attacks on the MN which gives the MITM
less work to do.

- MITM can also steal most of the MN's connections 
to CNs he's aware of, provided he's close enough
to the HA.

- This attack is specific to MIPv6 and clearly
due to the BU. 

The last point is probably not showing why it's
worse but simply for clarification.

Hesham

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 5 Jan 2002 19:16:29 +0100 (CET)

> is easily done by one BU and steals all connections.

So your point is that the attack program that a hacker needs to write
would be significantly shorter and easier to develop?
You're probably right, but I don't think that means there is more harm - once
the attack software is written and distributed to the attackers out there
they can cause the same amount of harm.
 
> that most of the traffic addressed to the HA will

Yes, but this doesn't seem any more different than an attacker close to
the border router of e.g. sun.com being able to be a MiTM for most
of the traffic to/from all of Sun.

> causing the connection to be dropped.

I depends what the attacker want to do.
For instance with the TCP packet stream in both directions the attacker
can easily respond to a HTTP get from the MN to the CN which 
completely different data, while consuming the actual HTTP response from the
CN.

Perhaps the set of attacks are more limited when the attacker is on path
for only one direction due to assymetries in the routes. (I haven't thought
this through in detail.)

In the BU case for RR schemes we know I think it is sufficient for the
attacker to see packets from the CN to the MN and then be able to respond to
those packets with the MN's Home Address as the source i.e. the attacker
doesn't need to be on the path for packets from the MN/HA to the CN.
But this doesn't seem to be a significant different IMHO.

> any DoS attacks on the MN which gives the MITM

In the TCP MiTM case I don't think a DoS attack is needed on the MN.
The attacker on path is presumably capable of supressing packets from
being delivered as was as injecting its own (spoofed) packets.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 5 Jan 2002 19:22:54 +0100 (CET)

Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 5 Jan 2002 19:18:33 +0100 (CET)

Erik

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 06 Jan 2002 15:30:00 +0200

Erik, Hesham and others,

On the question of whether RR alone could provide security
that is in par with IPv4 security, I think I have came up
with an attack scenario that RR alone does not block (see
below).  However, this attack is certainly fairly far fetched,
and I _personally_ could imagine that being vulnerable to
this one _might_ be acceptable.

The attack scenario:

Let us consider an attacker A, a corrensponding node CN, and
a pre-selected mobile node MN whose home address is HoA.
Now, A has decided to steal all traffic that CN will
initiate towards MN.  To do so, it somehow arranges itself
_once_ to the path between CN and MN's HA.  It may do this,
for example, by visiting the network where CN is located,
where MN's HA is located, or any network in between.

While being at the path between CN and MN's HA, the attacker
creates a binding (and a corresponding BSA) at CN.  This will
succeed, since A knows MN's home address and it can foil the
RR test.  As a result, CN believes that MN is currently located
at the adddress given by A, and therefor whenever it sends
packets to MN, it will send them to the attacker.  Thus, A
is able to steal all connections initiated by CN towards MN.
Furthermore, if CN does not check the return routability
of the MN's home address if there is already an existing BSA,
then the attacker can keep up the faulty binding as long as it
wishes, simply by renewing the binding and BSA periodically.
To renew, it no longer needs to be at the path between the CN
and the MN's HA.

Discussion:

This attack is not present in IPv4 since in this scenario the
attacker steals all traffic _beforehand_, and does not need to
be on the vulnerable path later when the communication session
is actually initiated.  Thus, there is a potential class of
attackers that may be able to launch this attack but that could
not attack under the current IPv4 architecture.

This attack is most effective if the discussed MN is not
actually a mobile node but a stationary node.  In that case
the node will never send binding updates or home address options.
As a result, the attacker may be able to renew the faulty
binding and BSA for long times.  Furthermore, even if the node
initiates a connection, the CN will send replies to the
attacker, allowing the attacker to spy or DoS this connection
as well.  Still further, if the attacker performs the same
attack against both parties, it may establish itself as full
MitM for all future communications between the parties.

In a way, this is a variant of the "future attack" that I
described at the 50th IETF SAAG meeting, see
http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf

If we consider stationary nodes communicating with CNs,
i.e. about generic non-mobile-ipv6 traffic, this attack
appears to be most devious.  Since the nodes do not assume
their peer to have a binding for them, they have hard time in
determining that there actually is one.  If the attacker is
careful enough, it may get along for long times.  Thus, the
only protection here is that the attacker actually needs _once_
to get access to the vulnerable path between the CN and the HoA.

Let us consider this "_once_ at the vulnerable path requirement."
If all the links involved are physically protected, i.e. if the
links do not accept unauthenticated nodes, the only realistic
threat that I see is the attacker breaking in into _some_other_
computer at one of the links.  For example, if the CN is a web
server at a DMZ, and the DMZ also contains e.g. a poorly administered
Linux-login box, just breaking in to that Linux box could make
it possible to initiate the required faulty bindings at the CN.
As a consequence, once it is found out that the Linux box has
been compromised, the CN must be cleared of any bindings, just
to be sure.

Whether this risk is considered large enough to mandate using CGAs,
i.e. potentially IPR protected technology, goes beyond my apprehension.
But I certainly think there seems to be reason to make CGAs a
preferred and recommended practise, and to be recommended that
bindings that have not been protected with CGA should have relatively
short lifetime, and not be renewable without full RR test upon renewal.

--Pekka Nikander

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 6 Jan 2002 17:45:49 +0200

I agree that this attack exists and seems to be beyond what regular
IPv4 holes allowed.

There seems to be a few differences with respect to v6+RR vs. v4.
What Pekka describes is an attack where the attacker can move
the effect of the attack forwards in time. There's also another attack
where the attacker can move most of actual attack work elsewhere.
For instance, instead of bombing a third party himself, if he is on the
home - CN path, he can create a falso binding entry at the CN, and
have the CN send all or most packets towards the victim. In this
attack we move the attack in space, not time. Interestingly, this
particular attack seems to apply to CGA as well in a limited fashion,
since you can still bomb a network with CGA even if host bombing
can't be performed. (Protocols like CAM-DH use RR to verify the correctness
of the upper part of the address and CGA for the lower part.)

As for the significance of Pekka's and other attacks, I'm not sure
what to say yet. It does seem bad that one has to worry about
past breaches and not just the current state of the network.  On the other
hand, rules about maximum BCE lifetimes may help here. We've
also heard arguments that on a local LAN most of the threats are
already present (but not in a permanent way as described by Pekka),
and that we are already dependent on routers doing their job.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 7 Jan 2002 19:33:10 +0100 (CET)

> To renew, it no longer needs to be at the path between the CN

Yes, this is a valid attack when there is a BSA.
If the BSA can be refreshed without re-verifying the RR property then the
BSA and binding can be maintained forever without the attacker having to
reappear on the path.

> short lifetime, and not be renewable without full RR test upon renewal.

A possible approach to limit the potential damage would be to have some
reasonable lifetime for the BSA (1 hour? 1 day?) and require that
when the BSA is refreshed (new keys etc) the RR test is invoked.

That approach would prevent an attacker for gaining access forever.

   Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Jan 2002 23:03:58 +0100

Hi Pekka, I'm catching up with old mail.

I certainly agree that the attack you presented is valid; however, I
have one remark with respect to v4, see below.

> not attack under the current IPv4 architecture.

In the attack you describe, attacker is present either close to CN, to
HA, or on the path between them.  One thing that you don't seem to
mention is that attacker must be able not only to listen to traffic
but also to block traffic.  I mean, more than just generating fake RR
replies to CN, attacker must block CN's RR tests to reach the HA and
HA's RR replies to reach CN; otherwise CN would end up with two RR
replies (one valid and one faked) and could realize something is
wrong.  At an extreme, this equals attacker being able to physically
tamper with underlying media or sit on a router in the path CN-HA.

Now, in the v4 world, if the attacker can sit on an intermediate
router or tamper with underlying media between two communicating
parties, it can do about the same amount of damage.

Alex

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 22 Jan 2002 09:17:54 +0200

Alexandru,

> tamper with underlying media or sit on a router in the path CN-HA.

Not quite.  Remember that HA is not necessarily active in the RR
check.  That is, at least in those RR schemes that I have considered,
HA simply forwards the RR check packets to the MN, similar to any
other packets going to the MN.  Now, since we are considering a future
attack here, the HA doesn't know where the MN is, and simply drops
the RR packets.

Making the HA more active would make the future attack more difficult,
as you mention.  But it doesnt' block those variants of the future
attack where no real HA is needed, e.g. future reverse bombing.

> parties, it can do about the same amount of damage.

In most senses yes.  However, if it sits there *now* and then must
move on, the situation is different.

--Pekka Nikander

---

From: Alexandru Petrescu <[email-masked]>
Date: 23 Jan 2002 00:36:03 +0100

Hi Pekka and thank you for the reply.  Please note that I think I
understand the "future attack" you described and I mostly agree it's
important, thanks for describing it.  Only one side remark, again with
respect to v4, see below.

> move on, the situation is different.

An attacker on an intermediate router on CN-HA path could add a static
host route to MN through an alternate path.  Just add it, save
configuration and leave.  Next time packets from CN destined to MN
will go on the alternate path, without attacker being there, right?

I think it is hardly and exaggeration to say that the probability of
future attacks (as you described) is nonzero in today's v4 networks.

Just my two cents,

Alex

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jan 2002 15:25:59 +0200

>will go on the alternate path, without attacker being there, right?

Adding a static host route would require compromised router,
is this what you were thinking?

I think a more likely threat model is someone plugging in
their laptop at an Ethernet somewhere, but not necessarily
being able to get in to the routers. (Of course it is possible
to get to the routers as well, just less likely.)

Or perhaps you were thinking of ICMP redirect? I think in
v4 the redirect function only allowed other on-link
addresses as the new destination, hence this would apparently
not work.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: 23 Jan 2002 15:03:05 +0100

> is this what you were thinking?

Yes, I was thinking about compromised routers (or cutting cables).
This is needed for the future attack to succeed against RR as
described by Pekka.  And if attacker can compromise routers or cut
cables then he can launch a future attack in today's Internet too, by
changing routing tables or putting his own router in between.  Thus RR
is no worse than v4.

> to get to the routers as well, just less likely.)

This is indeed a more likely scenario.  But without access to router,
attacker can do less harm and is also in danger of being detected by
its neighbours.  Windows, Solaris and HP-UX already do that, I think.

Besides, I do not think that the future attack against RR as described
by Pekka is feasible only by plugging a laptop and using ND.

Alex

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jan 2002 10:39:15 +0200

> by Pekka is feasible only by plugging a laptop and using ND.

It is, at least under some circumstances.  Depends on how
your home network authenticates your laptop.  If it doesn't,
you can do the future attack against a particular host
by just visiting its home network, or even by tapping in
to some cable between the home network and the CN.

What is much worse, however, is that you can use the future
attack technique for bombing too.  You physically go to your
target network (or tap to a link in between), plug in your
laptop, pretend to be your own HA, establish a binding at
the CN, go away, and later let the binding to expire.
If you have active communications going on when the
binding expires (e.g. a large file transfer), the packets
start bombing to your target, and you can even keep the
TCP transfer to go on for some time by carefully sending
false ACKs.

The conclusion so far seems to be that if you use RR-only,
you have to limit the lifetime of bindings to something
fairly short, e.g. a few minutes.  Plus, in addition to
checking RR of CoA, you have to perform RR for the HoA, too,
either every few minutes or whenever you renew your binding.

--Pekka Nikander

---

From: Alexandru Petrescu <[email-masked]>
Date: 24 Jan 2002 17:20:40 +0100

Hi Pekka,

Pekka Nikander <[email-masked]> writes:
> You physically go to your target network (or tap to a link in
> between), plug in your laptop, pretend to be your own HA, establish
> a binding at the CN, go away, and later let the binding to expire.
> If you have active communications going on when the binding expires
> (e.g. a large file transfer), the packets start bombing to your
> target, and you can even keep the TCP transfer to go on for some
> time by carefully sending false ACKs.

This looks indeed like a feasible attack.  However this is hardly
feasible if CN is required to drop bindings when receiving two
differing BKE's (sorry I use BAKE terminology only because it's easier
for me to put names on messages).

One more thing, what is the fear of the above attack?  That the target
network gets bombed or that it's difficult to identify who provoked
it?  In the first case, you can always bomb something, no feasible
defense at protocol level.  Add new messages to secure something and
then the new entities can be bombed.  In the second case, err, I don't
know, probably this kind of impersonation is a fact of life today,
with faked source addresses in ICMP echo requests.  I guess people
find the true identities by verbal coordination, looking at log
messages, etc.

Please do not get me wrong, I'm not saying there's no need of
protection in Mobile IPv6, just trying to identify what is genuinely
new security flaw introduced by it.

Alex

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 25 Jan 2002 11:42:19 +0200

Hi Alexandru,

> for me to put names on messages).

How come?  You are acting here alone.  There is no real HA, no
real MN.  You just prented to be the HA and MN.  Where does
the CN receive the second BKE (or whatever)?

> find the true identities by verbal coordination, looking at log

The fear is that with this attack, you can turn any node (since
all nodes must presumably support basic CN operations) into a
high-amplifier DoS attack device _without_ breaking into the CN.
Sure you can bomb any network, but with this attack you can
potentially turn a few hundred innocent hosts around in the
internet into bombers, and remain yourself undetected.

Unless the attack network saves all traffic at the time you
visit their network, there is no trace whatsoever anywhere
about who you were, where and when you visited your target
network, etc.  By the time the attack is launched, the CN's
have just dropped the bindings, so they don't remember your
last address (the CoA in the last binding).  The target network
gets no hints that such an attack will appear between the time
you visit their network and the time the actual attack is
launched.  When the attack is launched, the target network
does learn the IP addresses of the bombing CNs, but those
hosts are legitimite hosts; they haven't been broken into,
and they are acting 100% according to the specs.

Thus, in your terms, the fear is that is virtually impossilbe
to identify the culprit, and that all participating CN hosts
are acting 100% correctly; they haven't been broken into.
In fact, _NO_ hosts needs to be broken into with this attack,
you just must be able to visit your target network (or some
link near your target network).  Besides, you don't need to
_block_ or change any packets, it is enough that you can receive
(eavesdrop) and send (inject) packets.

Besides, this is just one example of the possible future attacks
that are introduced.  Fortunately, by limiting the lifetimes
of RR-only bindings to short enough (few minutes), it seems that
we can mitigate the threats to an acceptable level.  On the other
hand, if we want to support long term bindings (hours or so),
CGA seems to be necessary.  Thus, the turnside of RR is that
you have to perform the RR check against both the CoA and
HoA every few minutes, and the benefit is low computational
cost.  Respectively, the benefit of CGA is that you need to
perform HoA RR just once an hour or so, and CoA check only
if you refresh or change your binding, but the computational
(and possibly IPR) cost is higher.

--Pekka Nikander

---

From: Alexandru Petrescu <[email-masked]>
Date: 25 Jan 2002 11:44:02 +0100

> the CN receive the second BKE (or whatever)?

Now I see your point, thanks.  

Ony one remark: if by "no real MN" you mean that the host to which CN
sends BKR does not understand Mobile IPv6 because it is a simple host
then this host would still reply an ICMP Parameter Problem to CN and
CN will still get two responses to its BKR.

If, on the other hand, by "no real MN" you mean that the MN is
actually switched off, then...  How much real can this be?  If you
want to deny CN's services initiated towards MN you must (1) be in the
path and (2) ensure MN is off.  Isn't it enough to just ensure (2)?

> internet into bombers, and remain yourself undetected.

Same with faked source addresses in ICMP Echo Requests.

> network, etc.

There are networks that do just that.  No need to save entire packets,
full headers with timestamps are enough.

> On the other hand, if we want to support long term bindings (hours
> or so), CGA seems to be necessary.  Thus, the turnside of RR is that
> you have to perform the RR check against both the CoA and HoA every
> few minutes, and the benefit is low computational cost.
> Respectively, the benefit of CGA is that you need to perform HoA RR
> just once an hour or so, and CoA check only if you refresh or change
> your binding, but the computational (and possibly IPR) cost is
> higher.

I entirely agree with the above.  Striking the right balance doesn't
seem easy.  Fast handovers with RR and with CGA's...

Alex

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 25 Jan 2002 13:52:42 +0200

Alexandru,

Only a small comment:

> Same with faked source addresses in ICMP Echo Requests.

Not quite.  With ICMP Echo Requests, 2-way i-trace still
reveals your location.  Secondly, ICMP Echo Requests
(or other "normal" reflection attacks) don't provide
you with the amplification factor.  That is, in this
scenario the target network is bombed with full sized
TCP packets, and the attacker keeps them flowing by
sending very small TCP ACK packets with carefully
calculated sequence numbers.  Thus, we can say that the
amplification factor is high.  2-way i-trace is much
less useful in finding out the real location of the
sender of the faked ACKs, since there are so few of them.

--Pekka

---

From: Alexandru Petrescu <[email-masked]>
Date: 25 Jan 2002 13:57:03 +0100

> sender of the faked ACKs, since there are so few of them.

So extend itrace to handle these MIP cases.  

Extend ingress filtering to disallow malicious laptops to send RR
messages for incorrect CoA/HoA.

And, TCP ACK security problem then TCP security solution (cookies?).

So many alternative ways for routing according to keys.  Or probably
those have already been explored.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jan 2002 15:14:15 +0100 (CET)

> seem easy.  Fast handovers with RR and with CGA's...

I don't understand the reference to fast handovers so just to make sure
there isn't confusion I want to offer a perhaps unneeded clairification.

Just because the max lifetime of a binding is on the order of a few minutes
shouldn't affect handover performance.
I just means that the MN and/or CN need to be able to refresh the binding
to prevent it from expiring. We have e.g. the Binding Request message for the 
CN to to this today.
So the effect of the short lifetime on existing communication is that
every few minutes there will be 5-6 BU related packets exchanged to
extend the lifetime of the binding before it expires.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jan 2002 15:24:06 +0100 (CET)

> messages for incorrect CoA/HoA.

While that avenue could be explored my views as an implementor of
this, and in particular after having added HAO support in Solaris 8
(which is being disabled by default as we speak), is that it doesn't
provide control in the right place.

As an implementor of MIPv6 correspondent nodes I want to make sure that
our boxes can't be used to cause new forms of damage to the Internet.
Therefor, I would not feel comfortable saying that "we assume that better
itrace and ingress filtering will solve this" as an argument for
not having our software apply prudent checking; as a implementor that
would sound far too much like "somebody elses problem".

Of course, I don't know what other CN implementors are thinking.

As a aside, if you look at IPPT (BoF in SLC) in addition to ITRACE
you'll find that IPPT will have more problems than ITRACE. 
There is no counterpart to 3-way ITRACE for IPPT, but instead each
node doing "unpredictable transformations" to packets need to
record hashes of those packets and make them available to the IPPT system.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 28 Jan 2002 15:57:11 +0100

> would sound far too much like "somebody elses problem".

Erik, I perfectly understand this position, and as such I support this
group's decisions with respect to future attacks.  I hope my messages,
already proven wrong, can at least help enlighten a way that shouldn't
be explored.

> Of course, I don't know what other CN implementors are thinking.

I don't know either, maybe someone from MIPL can speak out here.

Reversing your statement, I truly support the future attacks argument
in that, as an implementor of MN, I don't want CN's services to our
MN's be denied.  But also as an implementor of MN's I can say that
everything is possible; only when crypto comes in it gets rather
complex.  I'm a bit doubtful of public key operations every time MN
moves or by core network routing according to keys (in addresses).
Again, I'm not pushing, just expressing an oppinion, my last on this
subject.

> record hashes of those packets and make them available to the IPPT

Thanks I will.

Alex

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 28 Jan 2002 18:17:39 +0100

Alexandru,

FYI with SUCV the public key operations you are talking about are not
performed
each time the MN moves but  only once, i.e. when the MN starts communicating
with the CN....they then exchange a key and use it for the following BUs.

regards,
Claude.

--

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

---

From: Alexandru Petrescu <[email-masked]>
Date: 28 Jan 2002 18:35:22 +0100

Claude Castelluccia <[email-masked]> writes:
> FYI with SUCV the public key operations you are talking about are
> not performed each time the MN moves but only once, i.e. when the MN
> starts communicating with the CN....they then exchange a key and use
> it for the following BUs.

Yes, I agree with that, I wrote in a hurry.  There's however a case
where public key operations are done often enough to worry about:
privacy and _ephem of same proposal?

Alex

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 28 Jan 2002 10:29:16 -0800

> Of course, I don't know what other CN implementors are thinking.

I would briefly just like to note (being involved implementing
some other things too) that _if_ solutions fulfilling
the security requirements can be achieved by changes in places
other than CN, it might be of interest to consider these, too. As
of the placement of the problem, if I am responsible for a filter
and a cloud of routers where I want locally to ensure optimal
traffic and that malicious things can't happen, would I not have
the same question whether somebody else (a CN) does or does
not do this for me, e.g., if a CN is just a reflector rather
than the victim potentially in my domain. This seemed one point
in your analysis on alternatives on RH?

> record hashes of those packets and make them available to the IPPT system.

BR,

-Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: 28 Jan 2002 20:25:39 +0100

> there isn't confusion I want to offer a perhaps unneeded

Erik, I'm trying to avoid generating too much text, this is why my
phrases are short.  My observation was mainly that when handing over
with change in CoAs and according to existing "fast" proposals there
is a certain number of messages involved before being able to use that
CoA.  To those messages one should potentially add RR _and_ CGA's
exchanges.  This, again IMHO, inevitably lengthens the timespan over
which my MN won't use the new CoA.  If I'm missing anything, please
correct me.

I know you already pointed that "number of messages" is an odd
criteria to compare MIP security proposals, just thought that it might
make more sense here.

> Just because the max lifetime of a binding is on the order of a few
> minutes shouldn't affect handover performance.  I just means that
> the MN and/or CN need to be able to refresh the binding to prevent
> it from expiring. We have e.g. the Binding Request message for the
> CN to to this today.  So the effect of the short lifetime on
> existing communication is that every few minutes there will be 5-6
> BU related packets exchanged to extend the lifetime of the binding
> before it expires.

Aha, I see.  I didn't think about this.

Alex

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 29 Jan 2002 10:16:45 +0100

> privacy and _ephem of same proposal?

I guess you are talking about the location privacy extension of SUCV?
In this case we propose to use ephem. HomeAddress and change it
frequently...
however i don't think it makes sense to change it while you already have
a
SA with a CN....it makes sense to change it when you starts communicating
with a
new CN and in this case you have to perform the public key operations
anyway (the SUCV
msg exchanges)...

The only additional load is on the MN that has to generate a new CGA
address...but
this operation can possibly be done by the HomeAgent as explained in the
draft/paper...

Alex, did i answer your question or did i miss something?
Claude.

--

---

From: Alexandru Petrescu <[email-masked]>
Date: 29 Jan 2002 11:08:38 +0100

Hi Claude and thank you for your reply.

I inlined some remarks.

> I guess you are talking about the location privacy extension of

Indeed.

> frequently...  however i don't think it makes sense to change it
> while you already have a SA with a CN....

In location privacy, you suggest that it's not good to reveal the Home
Address and as such you indicate using an ephemeral Home Address.
This looks valid to me.  A logical extension is that, IMHO, later on
people will think that privacy is probably to not even reveal that
ephemeral address 1 was in cell x and now it's in cell y.  This would
boil down to using a new ephemeral address everytime changing cells.
Or maybe I'm wrong.

In any case, I feel most of this is very much close to speculation and
what we need is probably implementation experience.  If anyone were to
start writing code, first would need to identify a library of public
key code, better if for kernel.

> address...but this operation can possibly be done by the HomeAgent
> as explained in the draft/paper...

I need to look at this HA offloading in detail.

Thanks,

Alex

---

From: Henrik Petander <[email-masked]>
Date: Tue, 29 Jan 2002 13:52:37 +0200 (EET)

> I don't know either, maybe someone from MIPL can speak out here.

Alex, I had originally a negative attitude towards RR, since it could be
easily misused to attack CNs and third parties. For this reason we have
not included BAKE in MIPL for now. I reconsidered my view on RR, when I
wrote a short paper on the vulnerabilities of BAKE as an authorization
mechanism with also some ideas on how to fix them or limit their scope. (A
preliminary version of it is available at
http://www.tml.hut.fi/~lpetande/publications/bake.ps)

IMHO RR could be used to authorize BUs, if the design takes the relevant
threats into account and there exists a way for CNs to back off from
accepting a suspicious BSA in BAKE, or a BU in N-way, and require stronger
proof of addres ownership, e.g. CGA. 

Henrik
		----------------------------------
		Henrik Petander 		
		Helsinki University of Technology,	
		GO/Core Project 
		[email-masked]
		Office: +358 (0)9 451 5846 
		GSM: +358 (0)40 741 5248	
		----------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 14:54:15 +0100 (CET)

> in your analysis on alternatives on RH?

Jari,

Perhaps the topic doesn't match the subject line any more and that is
causing confusion.

By comment was a rather general one with some references to HAO
and it didn't have much to do with RH. So I'm a bit puzzled.

In general I think you want to apply security both locally and as part
of the infrastructure (the routers and firewalls) in order to minimize
the risks. I don't think just because roads can be built better (better
visibility, less turns, etc) we should reduce the capacity of the breaks
in the individual cars; we need some of both.
 
  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 15:11:08 +0100 (CET)

> which my MN won't use the new CoA.  If I'm missing anything, please

So you are talking about both regular MIPv6 and MIPv6 with some
local mobility management it seems.

In the regular MIPv6 case the need for an RR check against the new CoA
(in order to prevent bombing attacks) adds time to the handover - 3 times
the one way delay compared to 1 times the one way delay (MN-CN) without an
RR check.
In the case of CGA where the bottom 64 bits of the CoA is the same as
the bottom 64 of the HoA then potentially one could avoid such an RR
check - without the RR check it would not be possible to bomb a host but
"merely" be able to bomb a /64 prefix (a link) with unwanted traffic.
But the most safe thing would be to always do the RR check.
In any case the CGA calculations would not need to be redone - with CGA it
makes a lot of sense to have a binding security association.

I guess there is an open question for localized mobility management around
trust issues, threat models, etc that may or may not result in a need
for a *local* RR check e.g. involving the previous AR, new AR, and MN.
But that's just utter speculation on my behalf at this point in time.
 
> criteria to compare MIP security proposals, just thought that it might

I think I pointed out that number of messages multiplied by the number of
"hops" might be an odd one.
Number of rtts, especially for packets over a high latency wireless link,
is quite important.
But assuming that the goal is to be able to refresh the binding
when not moving bthen we can let local mobility management of some form 
help optimize the when the CoA changes.

  Erik

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 29 Jan 2002 16:06:57 +0100

Hello,

> help optimize the when the CoA changes.

I wonder why "packet size" is not taken into consideration. In a radio
network packet transmission is the most power consuming thing and
power consumption linearly increases with packet size.

So, if a key establishment extension contains lots of cryptographic data,
this will:

1. Increase power consumption on hosts,
2. Increase packet loss rate, hence the actual number of packets exchanged
(and, consume more power).

I'm too pessimistic?

REgards,
pars

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 29 Jan 2002 17:28:18 +0200

> power consumption linearly increases with packet size.

It has an effect, yes. Maybe even a significant effect even for our
case if we start to include 1500 byte packets. However, the current
state of the art in e.g. cellular networks seems to be that the limiting
factor is latency, not so much power consumption.

Jari

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 29 Jan 2002 16:38:05 +0100 (MET)

Pars MUTAF <[email-masked]> writes:
    I wonder why "packet size" is not taken into consideration. In a radio
    network packet transmission is the most power consuming thing and
    power consumption linearly increases with packet size.

    I'm too pessimistic?

Power consumption does not depend linearly on packet size, since much
of the power is just powering up, running clocks, etc.

Nor is transmitting the most power consuming aspect of wireless, in
most cases it is receiving because you are in the receive state a lot
longer than you are in the transmit state (especially for a mobile).

In 1999, Elisabetta Carerra, wrote a MS thesis, "Wireless Adaptation
of a security Management Protocol Suite", showing that you can do
field specific compression - and thus fit the messages into as few
radio frames as possible. In addition, she gives a detailed analysis
of IPSec over a wireless link. You can find a copy at:
    http://www.it.kth.se/~maguire/Elisabetta_Carrara-thesis-final.ps

Chip

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 29 Jan 2002 16:47:32 +0100 (MET)

For WLAN systems under 802.11 most use fixed transmit power even
though this may mean using (much) more power than actually necessary
and even though this may increase the range of interference with
others using this channel (or adjacent channels) in another cells.

Jean-Pierre Ebert of the Telecommunication Networks Lab,
Department of Electrical Engineering, Technical University of Berlin
- has written a report describing the power consumption aspect of WLAN
transmission when using an interface card which does allow you to very
the transmit power:
B. Burns and J.-P. Ebert, "Power Consumption, Throughput and Packet Error Measurements of an
IEEE 802.11 WLAN Interface", Technical Report TKN-01-007, Telecommunication Networks
Group, Technische Universität Berlin, August 2001.

http://www-tkn.ee.tu-berlin.de/publications/papers/tr_01_007.pdf

There are several related papers such as:
J.-P. Ebert and A. Wolisz, "Combined Tuning of RF Power and Medium Access Control for WLANs",
Mobile Networks & Applications, vol. 6, no. 5, pp. 417-426, September 2001, in Journal of Mobile
Networks and Applications (Monet), Netherlands.
   http://www-tkn.ee.tu-berlin.de/publications/papers/monet2000e_1.pdf

J.-P. Ebert, B. Stremmel, E. Wiederhold, and A. Wolisz, "An Energy-efficient Power Control
Approach for WLANs", Journal of Communications and Networks (JCN), vol. 2, no. 3, pp. 197-206,
September 2000, publication of Korean Institute of Communications Sciences (KICS).
   http://www-tkn.ee.tu-berlin.de/publications/papers/JCN2000.pdf

Since these effects occur with every packet you transmit and the
fraction of packets which you will transmit to negociate keys, etc. is
likely to be tiny -- I don't think that the optimization of key
exchange has any significance with respect to power consumption.
Except for latency, I'm not sure that the transmission and reception
of these packets actually has _any_ significant effects on the mobile.

Chip

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 29 Jan 2002 17:44:42 +0100

Hello,

> of the power is just powering up, running clocks, etc.

I meant power consumption due to communication...

> longer than you are in the transmit state (especially for a mobile).

I was referring to the following paper:

"Measuring and Reducing Energy Consumption of Network Interfaces
in Hand-Held Devices"
Mark Stemm and Randy H. Katz {stemm,[email-masked] Computer Science...
               IEICE Transactions on Communications, vol.E80-B, no.8, p. 1125-31

http://citeseer.nj.nec.com/stemm97measuring.html
----

BTW, thank you for the papers, I'll read them.

Regards,
pars

---

From: "James Kempf" <[email-masked]>
Date: Tue, 29 Jan 2002 09:06:50 -0800

Erik,

> help optimize the when the CoA changes.

Your calculations emphasize a point I have been trying to make for some
time:
changing CoA on every handover is expensive. Adding security to BUs will
make
it even more expensive. Now, I know there are people out there who
believe:
"If it doesn't change it's Care of Address on every handover, it isn't
Mobile IP(tm)."
I happen to believe that it is more important to get something that
performs well,
so IP can become a viable alternative for wireless real time traffic.
Thus, I believe
a mixture of handovers in which the MN changes its CoA and doesn't
should be acceptable, with the MN and maybe the network deciding
when the CoA should be changed. There is protocol in FMIPv6 now to
do just that, and it can also be done using forwarding from previous
CoA in the base spec with regular MIP.

So I don't think the impact of BU security on handover should be a
consideration.

                        jak

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 29 Jan 2002 18:15:34 +0100 (MET)

Pars MUTAF <[email-masked]>
    > Maguire:

My point is that the tranmitting of the bits in the frame is not as
dominant a source of power consumption as you might assume.

For much deeper analysis & measurments of power consumption, along
with ways to reduce power -- see the papers of Dr. Tajana Simunic, et al.
    http://akebono.stanford.edu/users/tajana/Papers.html

Chip