Subject: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient

From: Pekka Nikander <[email-masked]>
Date: Tue, 26 Feb 2002 15:11:37 +0200

There has been a lot of confused discussion about the so called
"one bit" method at the mobile-ip mailing list.  The purpose of
this message is to explain why the one bit is needed, and why
using just one bit does not lock us into just two options, as
some people tend to fear.

1. Why the "one bit" is needed?
===============================

There seems to be clear WG consensus that the RR-only method
is good enough for the baseline infrastructureless Mobile IPv6 BU
authorization method.  However, at the same time, there are clearly
needs to use better methods to authorize the BUs, including AAA,
PKI, and CGA based methods.

There are two basic differences between the RR method and
the other methods.  Firstly, the plain RR method does not create
any shared secret between the MN and the CN.  The rationale
here is that since it is preferable to obtain RR assurances
to both the HoA and CoA each time a BU is sent, there is little
benefit in creating such a shared secret, and creating such a
shared secret would cost in terms of computation.  The other methods
do create such a shared secret.   Secondly, even if the RR method
was extended to create a shared secret (e.g. by including a
DH exchange), the resulting shared secret would be completely
unauthenticated.  That is, the shared secret would not carry
any information about *who* was involved in creating the secret.
In the other methods, the shared secret is authenticated, in this
sense.  If AAA or PKI is used, the AAA or PKI provides some
information about the peer.  If CGA is used, the shared secret
is associated with the public key of the peer, and the key
is *strongly* associated with the Home Address.

Thus, the two differences are:

       a) RR does not create a shared secret while the other methods do

       b) even if RR was extended to create a shared secret, the
          shared secret would be unauthenticated while in the other
          methods it is authenticated.

Note that the main difference is *not* the shared secret versus not.
The fact that even sharing a secret results in unauthenticated
state is the real issue.  In other words, the RR method infers
via a leap of faith that trust in the routing infrastructure under
normal routing conditions (MN at its home link) results on
trust in a modified routing condition (MN at its CoA).  The other
methods include an explicit expression of trust (via certificates,
cryptographic bindings between addresses and public keys, etc),
and therefore they are inherently much stronger.

Now, there are two consequences from these differences:

       1. The RR method is strictly weaker than the other proposed
          methods.

       2. It is always possible to fool a peer by bidding it down to
          accept RR, unless there is provisioning against this.

The point 2. above is the so called "bidding down" argument.  Let
us try to explain this in detail, since there seems to be so much
confusion about that.  To simplify things, let us consider a
situation where we have only two BU authorization methods, for
example, "better RR", i.e. RR extended with shared secret creation,
and AAA.  We also must assume that the CN does not know the MN
a priori.

Under these circumstances, if an attacker can manouver itself into the
path between the HA and the CN, it can run RR with the CN independent
on what authorization method the MN would like to use.  (We don't
want to go to the detailed argument here, see elsewhere.)  More
importantly, though, the attacker can run RR with the CN even in
the case that there is no MN but the claimed HoA is an address of
a stationary host.  In that case the "MN" (the stationary host)
would not like to run any BU authorization at all, i.e. to use
the "most secure" BU authorization option: no BUs accepted.

This is the essense of the bidding down.  Since the CN does not
know what BU authorization method the "HoA owner" (the MN) wants
to use, it must accept RR if someone uses it.  (We know, there
are fine points on this, and we can discuss those to death.
But let's do it separately, if needed.)

The purpose of the "one bit" method is to make a difference
between RR only (or RR extended with a shared secret
creation) and the other methods.  That is, the purpose
is to reserve one bit (or bit pattern), in the IP address,
that says "RR is OK" or "RR is NOT ok".  The selection
between the other methods is another issue.  It doesn't require
any additional bits, as we will show in a moment.

What is important to understand here, though, is that it
is _necessary_ to reserve the bit in the Home Address, since
the Home Address is what identifies the peer.  Thus, all bits
in the Home Address are implicitly secure; changing any of
them does means that the attack is not against the same MN
or stationary node any more.  All the other bits in a message
must be explicitly secured, since an attacker may freely
select values for them, and such explicit securing is not
possible with RR.

2. Why the "one bit" is sufficient?
===================================

Let now assume that we have somehow weeded out the bidding
down to RR attack.  Consequently, we are in a situation where
the CN must select between a number of other methods, including
AAA, PKI, and CGA based ones.

One possible way of doing this selection would be to use more
bits than just one and encode the information again into the
Home Address.  However, this is unnecessary, since in all
these other methods

       1. the parties create a shared secret, i.e. a session integrity
          key, and

       2. the shared secret is autheticated, at least in some
          sense of authentication.

Again, the second point is the really important one.  A shared secret
created along a run of RR would be completely unauthenticated.   [With
this we mean that in RR there would be no cryptographic, or strong,
binding between the Home Address and the shared secret.  With RR there
is only authorization based on trust on the routing infrastructure, and
that is subject to Man-in-the-Middle attacks by on-path attackers.
Remember, the purpose of the whole "one bit" method is to make sure that
we can use stronger mechanisms than RR.]

The exact nature and semantics of authentication, or binding between
the Home Address and the shared secret, depends on the method used,
and if we want to go into the fine print, we must also analyze that.
But that is not the point of this note.  What is relevant is that
the authentication somehow creates a strong binding between the Home
Address and the created shared secret.

Thus, the mere fact that authentication succeeds indicates that
the mobile node, as identified by the Home Address, is willing
to use the suggested method.  Consequently, we can simply include
unsecured bits in the initial message, telling what authentication
method the MN wants to use, and let the success of the authentication
method implicitly verify the correctness of these bits.

Note that this method does not prevent "bidding aside" attacks,
i.e. attacks where an attacker is able to break one method,
say AAA, but the MN actually wants to use another method, say PKI.
In that case the attacker _is_ able to fool the CN to use AAA
instead of PKI.  There is a good question, now:  does this matter?
If (and only if) we can consider the used methods as _roughly_
equivalent, the danger of "bidding aside" is not so big.

Summary
=======

       1. RR is strictly less secure than the other suggested methods,
          but still sufficient and meets the baseline security requirements.

       2. RR does not authenticate the peer in any sense, while the
          other proposed methods do, at least in some sense.  This
          means that the other methods create a secure binding between
          the Home Address and some external information while RR does not.
          RR simply relies on the trust that the integrity of the routing
          infrastructure has not been violated.

       3. If there is no explicit authentication, and thereby no
          external information that can be trusted upon, the only information
          flowing between the MN and the CN that can be trusted is the
          Home Address.  This is actually a tautology, since the Home Address
          identifies the MN, and changing it changes the attack target.

       4. Because of this, we *must* use one or more bits of the Home
          Address to indicate when RR may be used and when it must not
          be used.  From the security point of view, it does not matter
          whether the bit or bits is a part of the interface ID or the
          routing prefix.  The information just *must* be encoded into
          the Home Address, in some way.

       5. On the other hand, we do *not* need to reserve any additional
          bits, since the other methods provide these additional
          trusted bits through authentication.

       6. This still leaves the "bidding aside" problem, but that is much
          less severe than the "bidding down" attack.  Notice that in order
          to prevent "bidding aside" (between roughly equivalent methods)
          from degenerating into "bidding down" (from more secure methods
          towards e.g. poorly configured certificate-based mechanisms),
          this would mean that some address ownership authorization
          procedures would have to be employed in all the "more secure" methods.
          For example, to employ PKI for Mobile IPv6, the PKI certificates
          must provide IPv6 addresses in SubjAltName of X.509.  Similarily,
          to use AAA, the AAA infrastructure must carry authenticated
          binding between the Home Address and the MN's key all the way from
          the Home AAA Agent to the CN.

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 26 Feb 2002 16:40:39 -0800

Hello Pekka,

thank you for the write-up. It is well-written.

I have couple of observations after reading it.

1) You state that creating a shared secret using RR would be completely
unauthenticated. While I understand what you mean, here is another point. In
today's Internet, you don't know who the peer is. So, using RR to create a shared
secret amounts to doing so with someone you don't know. However, if this secret can
ensure that you are dealing with the *same* entity that you dealt with earlier,
then that can provide pretty good mobility. Sure, having a mechanism that allows a
node to determine *who* the peer is desirable. However, that premise alone is not
sufficient to rule out the ``middle option'' (i.e., shared secret with RR) when
such an option can ensure that you are able to deal with the same peer. So, I see
three options

i) RR only
ii) RR with shared secret, and
ii) RR with shared secret established via peer authentication

2) There are options other than the 1-bit method available to allow a CN to
determine that it should not RR. For instance, a CN can be statically configured to
not accept RR (and only accept AAA-based solution). Where would that fit in your
analysis ?

Comments?

BTW, I have some comments on Jari Arkko's bidding down text, where I will refer to
the bit method.

Regards,

-Rajeev

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 26 Feb 2002 17:08:10 -0800

Pekka,

Thanks for defining the term bidding down. Seems the
definition has varied among the discussing people, where
at least my definition has refered to the union of bidding
down and bidding aside. The classification of BU authorization
methods you have provided is important and thoroughly
presented.

However, for now, let me address just two points.

- Is routing identity encoding by 1 bit in host number
  really the only way to let CN know of MN's minimal BU
  authorization method? Perhaps to let CN know the policy by
  local configuration could be alternatives? If a local
  configuration were considered as an additive alternative,
  it could straightforwardly also support bidding aside
  unlike the 1 bit, woulnd't it?

- While fully agreeing on the significant conceptual
  difference between bidding down and aside, I would like
  to better understand the issue why bidding aside is
  insignificant. Basically, is there no difference
  in level of security or desirability of authorization
  among the higher class methods? One could have

  - key lengths are significantly different (60 vs 1000 bits)
  - the authorization is derived from a separate registration
    identity (associated with the routing identity like in
    your PKI example) or directly from the routing identity
  - different non-security related policy reasons to mandate
    a method (e.g., AAA-based) in a certain network, for example.

  What about a practical case there is a "lemon" amongst
  the multiple methods available among the higher class
  of methods. If this would be the weakest link among
  the set of methods in this class, wouldn't that make security
  of the whole class shrink to that level without a bidding
  aside method to "shut down" such a method?

BR,

-Jari M

---

From: Erik Anderlind <[email-masked]>
Date: Tue, 26 Feb 2002 21:07:09 -0500

Hi Rajeev and Pekka,
To restate Rajeev's comments in slightly different
way: A way to use "dynamic RR secrets"

If a random identifier is included in a RR "challenge"
from the CN, this random value can be used both to verify 
the immediate "response" and a future BU request from the
same MN. (Ps: It is the CN that needs to verify that the new COA 
can be used.)

Example:
For the first BU msg a CN receives from a MN, the CN would need 
to verify both RR to the home address (home address ownership test) and 
RR to the COA (ensure not a DoS attack). By using different
random values in each of these tests, a Man-in-the-middle needs be 
be on both paths for both tests to pass. Subsequent BUs could use one or
the other of these random values to prove beyond reasonable doubt that
this is a valid BU (CN could immediately update cache, so that 
handover is fast, and run the RR scheme in the background to confirm ).

Saving these random values obviously increases state in the CN and
MN caches. It is however soft state. If state info is 
lost/overwritten, either revert to sending data through HA, 
or perform new RR tests. It might even be possible to store only 
one value in the CN cache and have a smart alg for locally 
generating the other.

To Rajeev's 2nd question:
I am a little lost on the 1-bit issue. It seems the preference for
accepting RR or not, only needs to be in BU messages, so 
overhead doesn't seem a large consideration. Why not 
add a 1 byte BU message option that allows all supported address 
verification options to be conveyed at once - it seems we will 
need that type of a message
field in the negotiation phase following a 1-bit "not set" anyhow.
(Is there a problem creating this type of 1 byte option to the BU
option?)
...Erik

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 27 Feb 2002 11:56:16 +0200

Rajeev,

Thanks for your excellent questions and observations.

I notice that we have failed to explicitly express
some assumptions that we have made.  Firstly,
througout the document we have made the assumption that
if plain RR is used, the MN and CN do not have any a
priori information about each other.  Secondly, we
assume that the CN wants to do RR without *needing*
to do any extra checks from some infrastructure.
That is, since RR is designed to work when the CN does
not have any a priori knowledge about the MN, mandating
that the CN consults some external data source to learn
more information about the MN would foil the purpose
of RR.  On the other hand, this does not mean that a
_particular_ CN couldn't consult such an external
information source, if it is locally desirable.

These are fundamental assumptions, based on the
desire to produce a Mobile IPv6 security solution
that works without requiring a new infrastructure.
Remember, the fact that using just IPsec would have
required a new global PKI infrastructure was one
reason why IESG send Mobile IPv6 back.

[I have edited your line lenghts to make reading easier;
  sorry if I messed up your message by doing so.]

 > 1) You state that creating a shared secret using RR would
 > be completely unauthenticated. While I understand what you
 > mean, here is another point. In today's Internet, you don't
 > know who the peer is. So, using RR to create a shared secret
 > amounts to doing so with someone you don't know. However,
 > if this secret can ensure that you are dealing with the
 > *same* entity that you dealt with earlier, then that can
 > provide pretty good mobility. Sure, having a mechanism that
 > allows a node to determine *who* the peer is desirable.

I mostly agree with you, but there is a little twist.

In today's Internet, you don't know who your peer is.  All
you know is that your peer is able to receive packets sent
to a given IP address.  If we enhance RR with some mechanism
to create a shared secret (e.g. RR + DH), we certainly get a
shared secret with someone who is able to receive packets
at the given IP address *at the time* when the share secret
is created.  But remember that the someone does not need
to be a legitimite node at the destination address, it
can be any node between the sender and the destination.
The difference between today's situation and RR is that
in RR we do not know whether this party is able to receive
packets sent to the given address (the Home Address) later
on, unless we check it again.  That's also the reason
why we require in RR that also the reachability
of the Home Address is checked on every BU, and why we
require that the binding lifetime is relatively short.

Thus, the difference between today's Internet and RR is
in timing; *when* somebody is reachable: as long as you
communicate with him/her, or only in the beginning.  This
difference is also the reason why RR is not quite as
secure as the current practice, but only close enough.

Let me express the same argument from a different point of
view:  In today's Internet the hosts are *identified*
by the IP address (and I purposefully say identified and
not merely named).  The reason why this works so well, and
why we have fairly few connection hijacking and MitM problems,
is the fact that the routing system uses the addresses
directly.  That is, given a packet sent to a given address,
only those nodes that are at the path between the sender
and the topological location named by the address are able
to see and act on the packet.

With mobility we have to somehow break this binding, either
by introducing a new naming layer, as HIP does, or by
using two different addresses, as Mobile IP does.  This is
the source of the security problems we have.  And since
we break this binding, in RR we need to do the Home Address
reachability check fairly often.

What the other methods do, though, is that replace the
implicit binding created by the routing infrastructure
by some explicit external binding.  In CGA the new binding
is based on cryptography and computational infeasibility.
In AAA and PKI the new binding is based on trust on some
third party.

 > However, that premise alone is not sufficient to rule out
 > the ``middle option'' (i.e., shared secret with RR) when
 > such an option can ensure that you are able to deal with
 > the same peer. So, I see three options
 >
 > i) RR only
 > iii) RR with shared secret established via peer authentication

I agree with this analysis.  And I am not ruling out the
RR with share secret option.  Sure you can use it if you
want to; however, I do not see any *practical* security
difference between RR only and RR with shared secret.
RR with  some sort of authentication is clearly different,
since it would require some external property or party
to base the authentication on.

RR only relies that you check that your peer is reachable
at the Home Address each time you do RR.  In RR with
shared secret you need to do that check anyway, since
otherwise you would create a larger-than-acceptable timing
difference, compared to the current situation.  Thus, the
only added assurance you get is that the party remains the
same.  You do not get any added assurance about the
"ownership" of the Home Address; there the both methods
are similar.  I agree that if we look at the situation
from a pure security perspective, there is a difference,
clearly, since the set of possible attacks are different.
However, if we look at from a practical point of view,
considering where in the Internet the attacker must lurk
and what it must be able to do, the difference *seems to be*
fairly minor or almost nonexistent.  On the other hand,
there may be new attacks that we do not know of, such
attacks that RR only is vulnerable but RR + shared
secret is not.

 > 2) There are options other than the 1-bit method available
 > to allow a CN to determine that it should not RR. For instance,
 > a CN can be statically configured to not accept RR (and only
 > accept AAA-based solution). Where would that fit in your analysis ?

A priori configuration is always possible.  As I said above,
we forgot to emphasise that our analysis is based on the assumption
that the MN and the CN do not have any a priori knowledge
about each other.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 27 Feb 2002 12:12:40 +0200

Jari,

Let me briefly answer you excellent questions.

 >   unlike the 1 bit, woulnd't it?

As I already wrote in length in the answer to Rajeev's message,
we were only considering the situation where the MN and the
CN do not have any a priori knowledge and do not rely on some
external infrastructure.  Local configuration is always possible,
and could be classified as a priori knowledge.

 >   among the higher class methods?

There could be differences between the "higher" level
security methods.  As we stated in the analysis, we
consider "bidding aside" *less significant* (not
insignificant) for two reasons:

   1. RR is strictly less secure

   2. The other suggested methods have some kind of
      authentication, i.e. they add some external
      knowledge that we rely on, in order to determine
      that there is a binding between the MN and its
      Home Address.

But sure "bidding aside" *can* be a problem.  Local
configuration is a clear answer to that:  if a CN
does not trust on, e.g. CGA, it can turn it completely
off.  The only consequence of this is that CGA-only
MNs must either note use RO or obtain a new home address that
allows RR only.

 >   aside method to "shut down" such a method?

You are right in your analysis.  However, we must place this
question in the right context:  the purpose of RR is to
place a minimum baseline that ensures us *interoperability*.
Other methods can be seen as optional, providing added
security.  Since RR poses the threat of "bidding down", and
since all nodes must support RR for interoperability reasons,
we do need a built in mechanism for signalling that RR must
not be used.  This allows an MN to try to use a more secure
mechanism in the first place.  If that fails, it can always
fall back to RR through using a separate Home Address.

(Side note:  If there was another infrastructureless
way of preventing bidding down, I'd be more than happy
to use it.  I am not particularly fond of the "one bit"
method.  It just seems to be the only one that works.)

The second section in the analysis tried to point out that
it is possible to support multiple, *roughly equivalent*
methods, without requiring more bits to be reserved.  The
crusial point here is that rough equivalence.  Our understanding
on what methods are roughly equivalent and what are not may
change over time, but IMHO that can be handled through
local configuration.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 27 Feb 2002 12:23:41 +0200

Erik,

As I tried to say in my reply to Rajeev's message,
the point of the analysis was not whether RR-only
and RR-with-shared-secret are equivalent or not.
I acknowledge that our current understanding is that
they are *practically* equivalent, but that understanding
may change as we learn more.

What comes to your suggestion here ...

> one value in the CN cache and have a smart alg for locally 

... unfortunately the situation is not so simple.  What you
describe above is more or less equal with our original BAKE design.
Later on Tuomas Aura, Michael Roe and Jari Arkko analyzed the situation
more, and found new attacks that the design above does not block
adequately.  The basic issue is in timing and the ability
to use these timing problems to move attacks into the future,
and thereby making tracking the attackers considerably harder.
I think Jari Arkko documented the analysis in one of his Design
Team notes/recommendations, but I don't remember in which one.  Jari?

> (Is there a problem creating this type of 1 byte option to the BU

Such an added byte, signaling the options that the sender wants
to use, is being added to the forthcoming DT design.  Thus, the
idea is to use the "one bit" method signal whether RR may be
used or not, and an external, explicitly authenticated data field
to signal other options, including the set of more secure BU
authorization methods that the host would be willing to use.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Feb 2002 17:52:25 +0100 (CET)

Pekka,

I suspect that Rajeev's point is that the performance of RR
with shared secret is better than plain RR while keeping the security the same.
 So let me look at that in more detail.

In RR each movement takes 1.5 roundtrips
	1a/2a doing RR check on the HoA
	1b/2b doing RR check on the CoA
		and they are done in parallel
	The BU from MN to CN

With RR with shared secret the HoA check (1a/2a) does not need to be done
each time a MN moves since the established shared secret indicates to the CN
that is it the same MN.

But as you point out the the timing aspects of this means that the CN needs
to verify that the MN is reachable at the HoA at some minimum frequency of
a few minutes.
However, it doesn't have to do that HoA RR check at the time of movement.

Thus at movement (assuming a HoA RR check has been done in the last few
minutes) it simplifies to 
	1b/2b doing RR check on the CoA
	The BU from MN to CN

This is is less messages but still 1.5 roundtrip.
Of course, there are cases when the roundtrip time between CN and CoA
are significantly less than the roundtrip time one the CN-HA-MN path used
for the HoA RR check.
Taking an example out of the air:
	the roundtrip time on the wireless interface is 60 ms
	the wired roundtrip time from MN to CN is 10 ms
	the wired roundtrip time from MN to HA is 200 ms (different continent)
	and the wired roundtrip time from HA to CN is also 200ms

Thus the MN-CN rtt is 70 ms
The MN-HA-CN rtt is 460 ms

With RR the 1/2 step takes 460 ms followed by the BU one-way delay of 35 ms 
Sum 595 ms

With RR-shared-secret the 1/2 step takes 70 ms followed by the BU one-way 
delay of 35 ms
Sum 105

Thus almost a factor 6 better in this intercontinental case.

The question is how much does it cost (CPU time) to create the BSA
and for how long time case the BSA be kept.
How to compare the security of e.g. a random shared secret sent in the clear
in a packet that goes on the CN-HA-MN path (to benefit from the
encryption on the HA-MN part of the path), compared to a D-H exchange?

Can the BSA have a relatively long lifetime (hours) as long as the HoA RR 
check is performed every few minutes in order to verify the binding 
between the BSA and the HoA?

If a D-H key exchange needs to be performed every few minutes then it isn't
clear to me that the improvements in the BU time are worth while, but
if we can do something less CPU intensive every few minutes it might
very well be worth-while.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Feb 2002 09:19:16 -0800

Pekka,

I mostly agree with you, except for the following.

> to see and act on the packet.

I think a more important reason why there aren't any MiTM problems
is because it is physically hard to hijack a connection to a router.
You have to break into someone's secure installation and put a
tap on one of the router's input wires.

With 802.11 and other multiaccess wireless systems, it becomes much
easier. ARP
spoofing is very easy. In fact, if you have ever used MobileStar,
the 802.11 public access network, they have an explicit disclaimer on
their Web page that you are responsible for security, they aren't.

>On the other hand,

See draft-kempf-ipng-netaccess-threats-00.txt. The host
on the wireless link can mount a redirect attack away
from the default router and act as a MitM, if the link
is multiaccess.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 27 Feb 2002 19:23:32 +0200

> So let me look at that in more detail.

[analysis proper removed]

> Thus almost a factor 6 better in this intercontinental case.
Erik and Rejeev,

Of course I have to agree with the analysis.  If there are indeed
cases where one changes bindings at a generic CN more often than
the maximum RR binding lifetime, then setting up a BSA even with
RR leads to performance benefits.  I just wasn't thinking from
thas point of view, I just tried to make the "one bit" argument
more thorough.

The question now rises: does this possible performance difference
require any changes to the one bit analysis?  That is, if we think
that from the _security_ point of view RR-only and RR-with-shared-secret
are equivalent, can't we just use one unauthenticated bit, somewhere
in the message 1a and not in the address, to indicate whether the MN
wants to set up an RR based BSA?  I am not quite sure (too tired
right now), but I think we could do just that.

> encryption on the HA-MN part of the path), compared to a D-H exchange?

These are good questions, indeed.  I think Jari A. and Tuomas discussed
the latter point (D-H vs clear text secret) in depth at some point of
time, but I don't remember any more what the outcome was.  I remember that
at that time I argued that I didn't see any added value from D-H.  D-H
just requires that the attacker is an active one; sending a clear text
secret (in pieces) allows even a passive attacker to learn the secret.

> between the BSA and the HoA?

I think such a BSA could well live for quite a long time, it renewed
often enough.

> very well be worth-while.

Agreed.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Feb 2002 18:29:42 +0100 (CET)

[My context is now re-established - sorry for the side-track into
the cost-benefit tradeoffs for RR-shared-secret]

> right now), but I think we could do just that.

I agree that RR-only and RR-shared-secret should have the same
security properties so that the one-bit method doesn't need to change
as a result of introducing RR-shared-secret.

The request for a BSA for RR could e.g. be done by one unauthenticated bit
in 1a as you propose.

> I think such a BSA could well live for quite a long time, it renewed

What does "renewed" mean? A new shared secret? Or a re-verification that
an entity reachable at the HoA knows the shared secret?

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 27 Feb 2002 19:48:19 +0200

James,

[I changed the subject to better reflect what we really
  are discussing.]

> tap on one of the router's input wires.

To me that looks like the flip side of the same coin.  Since the
Internet is based on the addresses-are-identifiers system, only
routers (or local hosts doing ARP spoofing etc) are able to mishandle
packets flowing between two given addresses.  And since breaking
into routers is hard, in general, these two properties together
give us fairly good security.

To me it looks like we agree so far.  Or where is the disagreement?

My point here is, in large, that with mobility we have to break
this addresses-are-identifiers system, in one way or another.
[Alternatively we could change the routing system completely.]
Breaking the binding between locators (addresses) and connection
end-points, as such, necessarily leads to new security vulnerabilities.
The exact nature of the vulnerabilities depend on how, exactly,
we break the addresses-are-identifiers system.

> easier. ARP spoofing is very easy. 

I know and I agree.  You have changed your physical security
enviroment.  You get new vulnerabilities.  Sure.

> from the default router and act as a MitM, if the link

I have read it.  Maybe I should read it again.  But right
now I don't remember anything there that would make a
significant difference between RR-only and RR-with-shared-secret.
Oh well, yes, there is one, at least:  If an attacker is not
on the CN-HA path when the MN and CN start to communicate, but
comes there later, there definitely is a difference.

For the mobile CN's, Francis Dupond suggested long ago that
some of the BU signalling should be carried through the CN's
Home Agent, using a secure bi-directional tunnel.  That would
fix some of the security problems when the CN is at a wireless
unsecure link.

What comes to the MN link, I don't immediately see how
RR-with-shared-secret would protect the MN better than
RR-only.  But maybe I am just too tired.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 27 Feb 2002 20:03:54 +0200

>> I think such a BSA [created through RR] could well live for quite 
 >> a long time, it renewed often enough.
> 

Hmm.  I think re-verification that the peer entity is still
reachable through HoA and still knows the shared secret is
sufficient.  Creating a new shared secret would be overkill,
IMHO, and require a more complex protocol since the new
secret would need to be bound to the previous one.  Actually,
I don't immediately see how creating a new secret would
increase security.

--Pekka

---

From: Charlie P <[email-masked]>
Date: Wed, 27 Feb 2002 08:12:33 -0800

Hello Pekka,

> may change as we learn more.

RR may be equivalent in security strength to RR+shared_secret,
but (as Erik notes) the latter offers better performance because
then the mobile node can send a Binding Update with authentication
data using the shared secret.  This will improve handover performance.
If we can get better performance for the same security, then I think
we should do so.

It is also possible to use RR+shared_secret as an interim
Binding Security Association for the several hundred milliseconds
until an infrastructure identity authentication can complete.

> What you describe above is more or less equal with our original BAKE design.
>

I think that the vulnerability can be smaller with the newer design.
Moreover, this is something we can finalize later, but for now we
should just keep in mind that establishing the shared secret (perhaps
using additional protocol to minimize risk) will enable secure operation
of future Binding Updates.

Or we may decide that the vulnerability with RR+shared_secret is
no greater than the vulnerability without, or perhaps no greater than
with nonmobile nodes today ("do no harm").  There is work left to
do on this.

I can mention one final possibility that has merit.  We could arrange
that the RR+shared_secret gives a "one-time" shared_secret.  This
would help performance at the next handover, but the mobile node
would then have to run RR again for the "next" next handover.

But we can do this after March.

Comments?

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Feb 2002 11:08:36 -0800

> authorization methods that the host would be willing to use.

this is good Pekka. agree with this. the "one bit" method says
RR or non-RR and the actual strong BU authorization mechanism
is signaled through a byte in the BU.

Vijay

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 27 Feb 2002 11:20:20 -0800

Pekka,

Thanks for your sharp observations. One point was not clear,
though. Knowledge or RR and non-RR address refering to the
_same_ host is needed to provide the crucial interoperation
by RR you refer to. Providing this mapping is hard. Either
it is also a priori knowledge needed for every address for the
one bit to provide the interoperation. Or, making it implicit
cascades lots of change requirements to other places.
Comments and examples below.

> and could be classified as a priori knowledge.

There is one category of a priori knowledge not necessarily
stated in the analysis, relevant to both points in this
discussion. In order to reach a particular node and provide
the interoperation you are discussing below, a direct consequence
of identity encoding is that one needs to be aware of two
identities and them associating with the same end node.
Knowledge of this implicit association is one kind of a priori
knowledge, that is,  that two addresses mean the
particular host must be known, for the interoperation
(fallback to RR address) you describe below to work.

Making the duality implicit brings new problems. One needs
to map this to places with one reference to a host (e.g.,
address based URLs or DNS gives the IP address). If no non-RR
method is available, and an URL or DNS name maps to such
an address, what address does the CN then guess to use?
E.g., if we mandate that the other address (negating the bit)
always maps to the same host, this is a rule for DNS, etc.
Thus, either there needs to be a-priori static configuration
of the mapping in the CN or the change requirements from
making this dual address use implicit cascades to many places,
DNS being one example if using a rule speculated above.
Looking to all this change requirement now seems a lot
of undone work.

> fall back to RR through using a separate Home Address.

Consequences of this discussed in the note above.

> method.  It just seems to be the only one that works.)

If one agrees the address association (one RR one non RR
address refers to the same host) represents one type of a
priori knowledge, static configuration should in principle
be an alternative.

> change over time, but IMHO that can be handled through

Agreed. If differences are later observed, local configuration
can be applied. Also, continuing from this, applicability of
local configuration to even the RR/non-RR axis later on seems
equivalently feasible.

BR,

-Jari M

---

From: Erik Anderlind <[email-masked]>
Date: Wed, 27 Feb 2002 14:29:07 -0500

Hi Vijay and Pekka,

> is signaled through a byte in the BU.

I fail to see how we would authenticate the "BU security method"
negotiation byte. The MN and CN still don't share any common 
secret. Only through use of one of the proposed binding 
security methods could one eventually authenticate the byte.

A more pragmatic approach would be for one party to propose 
the BU security binding options it is prepared to accept
(but could be modified during transfer by MitM). The other party 
chooses among these methods according to its policy preferences.
The 2nd party then attempts to run the BU security scheme. If
a MitM interfered in the negotiation, the scheme will fail and
the MN and CN can choose to
a) retry (perhaps with fewer options)
b) only communicate via HA
c) stop communication (hostile situation detected)
d) establish encryption etc

I don't see any benefit of having a 2 phase process where 
the first phase is only whether one of the RR alternatives 
is acceptable or not. Why not propose all the alternatives at once?
(We clearly believe many hosts will want more than RR.)

...Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Feb 2002 11:34:04 -0800

> security methods could one eventually authenticate the byte.

The section "2. Why the "one bit" is sufficient?" in Pekka's 
writeup explains this.

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 27 Feb 2002 13:46:22 -0800

Pekka,

Thank you for the elucidation. It is apparent that RR
with shared secret is a good option from a performance point
of view. I would only like to add that secret re-verification can
be combined (whenever necessary) with HoA RR test.

Regards,

-Rajeev

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 27 Feb 2002 16:13:42 -0800

Pekka,

To describe the remaining double identity interoperation
concern hopefully more clearly, a concrete example of the
downside of the 1-bit (identity) encoding from interoperation
viewpoint below.

[Pekka wrote]
> > Since RR poses the threat of "bidding down", and

Scenario: a legacy CN1 knows only RR, a new CN2 knows RR and a
method X. CN1 can't get interoperable address at all from DNS
because MN's name maps only to one address allowing X. The
compatibility does not work here for RO with the legacy CN1,
and MN cannot just start using a separate address for any
application.

Consider MN runs a web server and its DNS name is encoded, say,
into icon URLs on its homepage. If this name maps to the address
allowing X, MN would need a separate homepage encoding another
DNS name for RR address to serve the legacy node with RO. And so
on, for different services mapping or passing single addresses
to CNs. Here, since applications 'hard-code' single identity
for MN, RO using RR with MN does not work at all with _any_ node
after the moment MN changes its identity to the new one
requiring X. This even though MN would have another identity
for RR, e.g., to be able to do RO with legacy nodes, or by a
policy, e.g., use RR with nodes inside its firewall-protected
domain.

If MN falls back to RR, either the above effect happens with
applications, or there needs to be some 'configuration' or
implicit rule that maps the new identity to MN's RR-identity for
legacy nodes (CN switches the addresses transparently) for these
legacy CNs to be able to do RR with the X-address MN when using
those applications.

I hope the bidding down issue could be closed soon. However, the
above concern motivates that at least an alternative (static
config) would be there and that possible limitations of the
1-bit are understood and recorded, well enough to explain
how it really works for legacy support.

BR,

-Jari M

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Feb 2002 09:31:31 +0200

Jari,

This discussion is very interesting, since it leads all the
time to new observations.  My suggestion of using two home
addresses, one allowing RR and the other one not allowing RR,
was just a quick idea, without too much backing thinking.

Based on your comments I've made a few of observations.  Firstly,
if a MN uses two such Home Addresses, the two Home Addresses
cannot share a common routing prefix.  If they did, an attacker
on the path between the CN and the HA could easily block the
communication using the non-RR HoA, thereby re-creating the
bidding down situation.  Thus, in order to be effective at
all, the Home Agents used for the two-HoA method *must* be
at topologically different locations, and *must* have different
enough routing prefixes.

Secondly, we (or at least I) have concentrated on the case
where the MN contacts a CN, and wants to do RO.  Furthermore,
we have assumed that the CN wants to serve the MN in any case;
e.g., the CN could be a public server of some kind.  In that
case the CN does not have any a priori knowledge about the MN.
Furthermore, in that case there is no need for the CN to know
that the two addresses refer to the same MN.  In general,
I don't understand why there should be such a mapping in *any*
case where the MN initiates the connection.  To the CN it looks
like that first one node tries to initiate RO, and that failing,
suddenly another node tries to initiate RO.  No problem here.
Or at least I don't see any problems, maybe you do.

Thus, ...

...
 > by RR you refer to. Providing this mapping is hard. Either
...
 > (fallback to RR address) you describe below to work.

..., I disagree with these statements of yours.

To emphasise my point even more:  Most hosts in the IPv6 world
do have several addresses (a link local address, maybe a site
local address, and one or more globally routable addresses).
Nowhere in the IPv6 specs, to my knowledge (I may be wrong),
is there a requirement that a peer *should* be able to map these
different addresses to the same node.  It *may*, for sure, but
that is not a requirement, AFAIK.

Now, in the cases where the CN contants the MN, the CN *does*
have some a priori knowledge about the MN.  It needs to get
MN's address(es) from somewhere; at minimum the address(es) must
be entered by a user, but more typically it/they will be learned
from the DNS, through SIP, or though some other infrastructural
means.  If this is the case, the infrastructure could carry
information about the possibly multiple addresses the MN has,
and about the RO authorization methods it supports.  Thus, in
that case there is no real need for the one bit method.

 > .... One needs

In this particular case the CN could select the RO authorization
method it wants to use, based on the addresses and other
information learned from the DNS/whatever.  What comes to address
based URLs, how likely they will be in the IPv6 world?  I don't
know, but I doubt that they would be used very often in any
other cases but where the server itself hands it over to the
client.

 > always maps to the same host, this is a rule for DNS, etc.

As you see above, I am not saying anything like that.  You just
can't have two addresses otherwise same but that one bit,
since it would allow an attacker to block the more secure
of the addresses, thereby creating another variant of
the bidding down attack.

Thus, if a MN uses two different Home Addresses, one for RR
and one for non-RR RO, the two addresses necessarily need to
be fairly independent of each other.  On the other hand, DNS
or other such infrastructure can carry the two addresses
together, just like the MN were multi-homed at the two Home
Addresses.

<snip>

Taking yet another approach, I honestly do not know how useful
the two-HoA method would be in the first place.  If a MN
does not want to use RR for security reasons, it should not
fall back to RR in any case, and rely on non-RO if it cannot
authenticate its binding updates.  On the other hand, if a
MN is willing to use RR but also supports other methods,
it could use an RR-allowing address *and* indicate in the
BU messages that it also supports stronger methods.  In that
case it exposes itself to the bidding down danger, but that
is a reasonable choice.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Feb 2002 09:37:41 +0200

Erik,

> security methods could one eventually authenticate the byte.

Vijay already answered this.  If you have further questions,
don't hesitate to ask.

...
> (We clearly believe many hosts will want more than RR.)

I didn't consider these kinds of negotiations at all when
I wrote our analysis text.  Sure you can do more advanced
negotiation than just propose one choice, take it or not.

There was quite a lot of interesting related discussion at the
ipsec list some time ago, when people were discussing various
negotiation methods for the forthcoming son-of-IKE.  If you
want to really understand the security implications of these
kinds of propose-first-and-authenticate-later methods, that
discussion would probably be a good place to start.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Feb 2002 09:50:35 +0200

Jari,

I think I answered already mostly in my previous message,
but let me briefly look at these scenarios, too.  Maybe we
can learn something new from these.  ;-)

> and MN cannot just start using a separate address for any

IMHO, if the MN's name maps only to one address that doesn't
allow RR, then that is a choice made by the MN.  It does not
want to use RR.  No more need to discuss here.  :-)

> DNS name for RR address to serve the legacy node with RO. And so

Why the MN's DNS name can't map into multiple addresses, provided
that it wants to support both RR-based and non-RR based RO?
AFAIK, several addresses is perfectly valid practise already today.
If the CN uses DNS to resolve the addresses, it anyway needs
to select which address to use.  I think Richard Draves is
working on the I-Ds discussing address selection, or maybe that
is already an RFC, I don't remember.

Thus, if the one-bit method is accepted, the address selection
I-D/RFC must be updated.  Or we need a new one explaining
the choices a "new" CN has to make.  Good new point.  :-)

> policy, e.g., use RR with nodes inside its firewall-protected

I still don't understand this "single address" business at all.
To me it has been clear for quite some time that in the IPv6
world the hosts will have multiple addresses, and it is perfectly
legal that a host thinks to be communicating with multiple peers
even though, in reality, it is talking to a single one.

> legacy CNs to be able to do RR with the X-address MN when using

I am sorry, but the text above does not make any sense to me.
I just don't understand how you are thinking.

> how it really works for legacy support.

I sure hope that the bidding down issue is closed soon, too.

Now, would you Jari, in turn, explain how you think that
static configuration could be made to scale to internet
wide operations where MNs connect to CNs, and the CNs do not
know the MNs a priori?

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Feb 2002 09:56:16 +0200

Hi Charlie,

...

...

...

...

 > Comments?

Good points.  I don't have any comments.  Or maybe one.  Whatever
we do in order to finalize MIPv6 for RFC status, IMHO we should
try to keep the base design as minimal and as simple as possible,
but leave doors wide open for various kinds of extensions and options.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Feb 2002 15:13:09 +0100 (CET)

Jari,

Correct.
The simple case is that the MN as a unit decides to use either a RR or
a non-RR address.

In the case where more flexibility is needed the MN can maintain
both types of addresses.
For communication initiated by the MN the applications and/or protocol
stack on the MN can choose between the two source addresses based on local
policy on the MN.

For communication not initiated by the MN other mechanisms can be used.
But I think there are plenty of such mechanisms that at least allow
different choice of addresses (and implied security level for BUs) based
on the "service". For example, the MN could decide which of the addresses
to register with SIP servers. The MN could have two DNS names 
(insecure.mylaptop.example vs. mylaptop.example) that map to the two different
addresses. SRV records could be used so that e.g.
	_sip._tcp.mylaptop.example gives the non-RR address
while
	_http._tcp.mylaptop.example gives the RR address

So I think common cases when MNs want different tradeoffs between
who they can use RO with (old vs. new CNs) and the security level of the BUs
can be handled. Sure, this requires additional configuration as well as 
additional code in the MNs to choose and verify the addresses used
(the latter in order to prevent a SIP connection to the RR address in the
above example). But this is a case where the MN that wants such multiple
IP address identities have to pay with some additional complexity it its
implementation, which I think is a reasoanble tradeoff.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Feb 2002 15:18:34 +0100 (CET)

Pekka,

I don't understand how that can be used to prevent  bidding down.

If the MN e.g. runs a web server on http://laptop.example
and laptop.example has both a RR and a non-RR IP address record in the DNS,
then it seems like the MN, for that service, is willing to live with the
threats of allowing RR BUs. Thus it is sufficient to have just the RR
address in the DNS as far as I can tell.

But having multiple different identifiers of the service (different URLs => 
hostnames, or different SRV records) point to different IP addresses
*plus* the MN verifying that a connection to a service uses the right
IP address for that service seems reasonable.

> the choices a "new" CN has to make.  Good new point.  :-)

If you believe my argument above then the CN never needs to choose.
Instead the MN chooses by what IP address it registers (in DNS or elsewhere)
for each service.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Feb 2002 16:46:37 +0200

Erik,

> I don't understand how that can be used to prevent  bidding down.

Forgetting that DNS itself may be insecure and attacked, IMHO
that is simple.  Basically, the CN must be able to make a distinction
between RR-allowing and RR-disallowing addresses.  Otherwise it
couldn't make the right decision when it gets an initial BU
authorization message from a previously unknown node.

Now, since the CN must be able to make the distinction, it can
inspect the addresses it receives from DNS.  If any of them
forbids RR, the CN can decide to use it, and fall back only
if it learns that it doesn't speak the MN's stronger
protocol(s).

> address in the DNS as far as I can tell.

That's a viable policy, too.

> But having multiple different identifiers of the service (different URLs => hostnames, or different SRV records) point to different IP addresses

That's a viable policy, as well.

> Instead the MN chooses by what IP address it registers (in DNS or elsewhere)

Sure it is easier if the MN makes its choice a priori, maybe
based on the service as you propose.  However, since all nodes
supporting RR must be able to make the distinction between the
two types of addresses, the third policy, suggested above,
is also viable.  Or at least I think so, maybe I am missing
something.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Feb 2002 16:21:20 +0100 (CET)

> if it learns that it doesn't speak the MN's stronger

So in this case the MN is open to any policy (it will accept RR as well
as non-RR) and it lets the CN choose. I guess this is really orthogonal
to the possible policies I listed since this could be per service
hosted on the MN as well.

> is also viable.  Or at least I think so, maybe I am missing

It was I that was missing that it might make sense to give the CN the
choice in some cases.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Thu, 28 Feb 2002 09:58:38 -0800

Erik,

> The simple case is that the MN as a unit decides to use either a RR or
I think allowing the network administrator of the network where the HA
is located to control whether
MNs that use that HA have an RR or non-RR address would be the more
common case. The MN
will get its HoA from that network anyway. Also, a network administrator
would be in a better position to
trace any attacks should they be attempted via the HA. The MN may not be
in a position to even
know if the HA is getting probed. Also, if a PKI or AAA-based solution
is in use, the home network must co-operate to provide the appropriate
cryptographic assurances.

In cases where the MN is "home-agentless", I think the model of letting
the MN choose is probably OK, but then I would assume some of those
cases will be handled by having the MN associate with a HA in the
foreign network and thus get its HoA assigned by the foreign network. If
the HA is not in the foreign network, or otherwise dynamically
negotiated, I'm not sure how the MN will get its HoA. Perhaps by acting
as its own HA?

So there is an issue here of exactly how a RR v.s. nonRR address does
get assigned. And what happens if the home network is renumbered, or the
network administrator decides to change RR v.s. nonRR policy while the
MN is away.
Presumably, that could be handled by the network renumbering support
already in MIPv6.

            jak

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 28 Feb 2002 20:44:24 +0200

> will get its HoA from that network anyway.
> get assigned. 

Case 1: The addresses come from the network manager and they
are then entered to the hosts. No problem here, the manager knows
what's best for you ;-)

Case 2: The addresses are autoconfigured. You would then have to
know what to autoconfigure, RR or non-RR. There may be something
that the node knows itself about its mobility. A stationary machine
might configure itself a non-RR address, and refuse any attempts at
mobility. Nodes that don't know would supposedly have
a default, e.g. RR. A network manager who wishes to control the
policies in a large network would have to do so in some manner. I
suppose there'd also be other security sensitive configurations, such
as which services to open in the host, whether to require IPsec for
communications, and so on. I don't think we have a standard way of
configuring these things. Sending a flag in the Router Advertisement
would not work in a secure way before we fix IPv6 control signaling
security ;-)

> And what happens if the home network is renumbered,

Nothing, if the host IDs stay the same?

Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 28 Feb 2002 12:19:41 -0800

> would not work in a secure way before we fix IPv6 control signaling

Even if the addresses are autoconfigured, the host IDs need to be
assigned to avoid collision on the home network. The MN can
run DAD before it leaves home, of course, but if we are taking
about a "special" host ID bit, the MN can't simply use its interface
identifier, can it?

> ... <network renumbering>
>

OK, so there is only the case where the network administrator
decides to change from RR to nonRR (can't see anyone going
in the other direction) or use a different nonRR, like using
CGA then starting to use PKI or AAA key distribution because 
they decide to subscribe to it.

            jak

---

From: Ajay Wanchoo <[email-masked]>
Date: Thu, 28 Feb 2002 16:22:57 -0500 (EST)

Hi,
I'm trying to identify convergence, if any between MobileIP and GPRS for
the sake of mobility support in VPNs. Some specific questions:

1. Is there any reccomendation as far as reusing VLR/HLR information in
lieu of or in tandem with the registration info maintained with the HA/FA
(assuming that the PDP Contexts could be used for customized spport for
varied MNs)
2. In case of a movement between two networks (across FA/PDSN), since
there is an explicit detection of mobility by all, except the MN, FAs and
the HA, till an advertisement is acquired by the MN, is it at all
recommended to ignore the detection noticed by the local environment and
MN (below the Mobile IP layer and except the HA and FA), or is there a
reccomended manner of propagating the info up to the MIP participants ?

3. I understand (correct me if I'm wrong) that limited forwarding may take
place from the old FA to a new FA in case of movement of an MN across two
FAs during the re-registration process(either in pure Mobile IP or some
variation, to maintain connectedness for TCP like use). Now if I'm not
mistaken some kind of forwarding also may also take place at lower levels
(in the GPRS stack at, probably the GGSN stage). Which one is the
preferred manner.

4. Each device is expected to have a globally unique ID and
each GPRS network is associated with a DNS and a DHCP server to manage its
addresses. Since a lot of issues are associated with addressing,
especially when the Mobile device is a part of a VPN and/or wishes to be a
part of a VPN which has the rest of its devices behind a NAT etc. I will
greatly appreciate pointers to where all these issues are dealt with
formally (recommendations/standards)

Thanks
Ajay