Subject: Re: Using "a bit" as a protection against bidding down / for something else

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Apr 2002 16:18:07 +0200

"Hesham Soliman (ERA)" wrote:
...
> The scenario Brian mentioned
> will not be an issue for bidding down attacks
> related to mobility. 

Can you explain? I don't see why you can't have an evil MitM 
intercepting binding updates and bidding them down.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 03 Apr 2002 18:17:49 +0300

Brian,

> intercepting binding updates and bidding them down.

This is really a question of perception and threat model.

Technically you are right.  An evil MitM can intercept
binding updates and bid them down.  However, the evil
MitM can do worse things, like prevent communication
altogether.  It can also perform a "classic" MitM attack,
changing message contents on the fly.

The goal of MIPv6 security is not to protect against
"classic" MitM attacks.  It is designed to secure
mobility signalling, i.e. messages that change a node's
(CNs) internal routing information.  That is, the goal
is to prevent false bindings from being created at a CN,
and thereby prevent traffic diversion and DoS, among other
things.

Now, the design goal for the MIPv6 security design was
"do no harm", meaning that MIPv6 must not make Internet
any less secure than it is already now.  From that point
of view, the selected MIPv6 security mechanism, Return
Routability (RR), is approaching the goal from below.
That is, it still allows "time shifting" attacks where
an attacker is able to create a binding when a Mobile Node
is not active, and thereby prevent the legitimite MN from
communicating with the CN once it becomes active.  (There
are also other DoS concerns involved where other hosts or
parts of the network become victims of DDoS attacks.)
Now, RR reaches the goal by reducing the time window
for the "time shifting" attacks to a few minutes.

Thus, RR as such, is insecure.  A MitM can break it easily.
Now, one goal of the "bit method" was to reserve some footing
for the more secure protocols.  That is, if we assume that
there are two types of mobile nodes, "weak" ones and "strong"
ones, but only one type of corresponding nodes, ones that
are able to act either as "weak" or "strong", the bit method
does indeed seem to create some footing.

When a "strong" MN talks to the CN, a MitM can still prevent
all communications between the MN and the CN and it can change
MN's address into a "weak" one on packets flowing MN->CN
and back to the "strong" one on packets flowing on CN->MN.

However, if we consider our security goal, that doesn't matter.
Our goal was prevent the creation of false bindings.  The
MitM cannot create a false binding for the MN at the CN, and
it cannot fool the MN to believe that it has succesfully
created a binding at the CN.

The crusial assumptions here are the following:

  1.  We want to prevent the MitM from creating bindings
      for some addresses even if it is able to break
      the "weak" method.  This creates some footage for
      the "strong" methods.

  2.  The MNs make an a priori decision whether they want
      to use a strong or the weak method.

  3.  Our goal is to allow the MN to securely indicate
      the CN whether it wants to use the "weak" or "strong"
      method.

Now, under these specific conditions the "bit method" seems
to work.  Not perfectly, but well enough.   On the other hand,
the bit method *cannot* be used as a generic bidding down
protection, as I mistakenly thought for a couple of weeks.
And of course it is possible that there is still some flaw
in my thinking and/or in the explanation above.  If that is
the case, I'd be happy if you or anyone could please point
that out.

Well, personally I consider the bit method as a gross
hack, and really wish that we can create something better.
The need is there.  We just need a method.

--Pekka Nikander

---

From: Bob Hinden <[email-masked]>
Date: Wed, 03 Apr 2002 11:32:24 -0800

Pekka,

This is staring to sound a lot more like a research project than something 
the IETF should be considering standardizing now.  I wonder if it might be 
better to complete the research and then decide the best way to signal it's 
usage (e.g., bit, control protocols, etc.).

Bob

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Apr 2002 23:27:05 +0300

Bob Hinden wrote:

> This is staring to sound a lot more like a research project than 
> something the IETF should be considering standardizing now.  I wonder if 
> it might be better to complete the research and then decide the best way 
> to signal it's usage (e.g., bit, control protocols, etc.).

This would be otherwise fine, but I'm not sure what we should do
with MIPv6 in the mean time. I share your and Pekka's concerns
about the method, but we're not proposing it for its own sake.
We just feel uneasy about deploying an infrastructureless security
method that modifies routing in all nodes of the v6 Internet, and
never being able to exchange it for a newer one. Note that I believe
the current method (RR) is secure enough, so suggesting that we find
a better method doesn't help much -- I'd still like to be able to update
it, should need arise.

Jari
P.S. Control protocols are clearly out of the question in this case,
because their contents can be changed (something about the addresses
can also be changed, but not without directing the attack somewhere
else).

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Apr 2002 13:49:55 -0800

> The need is there.  We just need a method.

The bit method is not only a gross hack, it is entirely unnecessary. All
it provides is an optimization for the receiver to decide if a CGA check
is worth the effort, and for nodes that are aware enough to look for the
bit they could just as easily check every IID. In fact if they really
care, they have to check every IID just to make sure there was no
tampering. If they do check there is no opportunity to bid down since
the source is in control of deciding to generate a CGA to begin with,
and the receiver is in control of deciding if a CGA was received. If a
CGA is not necessary, what value did the bit provide? (a minor time
saving at the receiver) If a CGA is necessary and the key didn't match,
what value did the bit provide? (absolutely nothing) If a CGA is
necessary and the key did match, what value did the bit provide? (wasted
time checking a bit then deciding to run the hash) On the other hand, if
the bit did exist, how many opportunities are there for an intermediary
to flip it and disrupt the expectations at either end? As the lengthy
discussion on the list shows, this proposal for a bit actually generates
more problems than it solves.

In the grand scheme of things, the minor optimization for a receiver to
avoid the cpu burden of checking a hash is really a bad reason to chew
up a bit which carries no other value. As far as I can tell the CGA
mechanism is just another way to generate a 3041 IID, and it is up to
the end points to decide if they want to impose a higher level semantic
to that bit string. Using a bit doesn't help them decide since the
source could just as easily use a non-CGA 3041 IID as clear the bit. Any
clueful receiver would get the hint that a non-CGA 3041 IID meant the
sender didn't care about securing this address, while a CGA based one
meant it did care.

Just get over the idea of using a bit, it is a very bad idea ...
Tony

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Apr 2002 00:07:11 +0300

Tony Hain wrote:

> and the receiver is in control of deciding if a CGA was received.

Unfortunately, it is not possible to verify the CGA property just by
looking at an address -- you also need to have the input parameters
for the check IID == hash(pk) to be possible. That is, the public key
must be communicated from the mn to the cn. If you know you use CGA this
is easy and requires no security for the transfer. However, if it is
optional to use CGA, then an attacker could simply claim to the CN
that no public key was used. CN simply doesn't know if this is true
or not; the address itself can't be verified without a parameter.

Jari

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Apr 2002 15:09:12 -0800

> or not; the address itself can't be verified without a parameter.

You just argued for my point. If there is a way for the attacker to
indicate that no public key was used (clearing the bit for example) then
they will do that and you didn't help your cause. If the CN checked that
the IID agreed with the PK in every case, if no PK was available
obviously it fails, and if one was available it will either pass or fail
as appropriate. A bit didn't help make that decision easier.

The fundemental decision comes down to; does the MN generate a CGA, and
send a PK to the CN, or not. If it does the CN has what it needs to
verify the IID, and if it doesn't then the receiver might waste a few
cycles deciding that the IID is not based on a PK. The action the
receiver takes at that point will be exactly the same as if it had seen
the proposed bit cleared. THE BIT PROVIDES NO VALUE TO THIS PROCESS.

Tony

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 09:28:27 +0300

Tony,

I agree with you that the "bit method" is not a good method.
On the effective value of the method I have to *disagree*, though.
There is, however, a need to divide the IP addresses into two
sets:

   1. Addresses for which CGA (or something similar) is *required*.

   2. Addresses for which CGA (or somethign similar) is not used
      or is optional.

The reason for this is the "bidding down" attack.

> the proposed bit cleared. THE BIT PROVIDES NO VALUE TO THIS PROCESS.

Here I have to *strongly* disagree.

The "bit" is one method for providing protection against the
bidding down attack.  It effectively creates two IP address spaces,
those for which the receiver *requires* CGA, and those for which it
does not.

If we do *not* do this distinction, a Man-in-the-Middle can claim,
for *any* IP address, that CGA (or something similar) is not used.
That reduces the security of all addresses to the same base line,
effectively creating a situation where CGA (or similar) does not
provide any additional value at all.  Ergo, *something* that divides
the IP address set into two distinct sets *is* needed, or otherwise
CGA and related methods bring no additional value.

If everybody agrees that CGA (and any security that is *not* based
on an external infrastructure but on "intrinsic cryptography")
is a bad idea, then fine with me.  Let's forget this discussion.
But then we are effectively saying that zero-configuration security
is a bad idea and we don't want it.

Thus, this all is really about zero-configuration security.  Such
security, by nature, is never "strong" by the strict definition of
strong, but it can be *much* stronger than the current no-security
situation.  Basically, such security can provide quite a lot of
defence against various DoS attacks.

This two-address-space thing is only required for those recipients
that support both the current nodes with no understanding about
zero-conf security and the future nodes that do care about zero-conf
security.   As I noted before, it requires that the initiator commits
a priori either to the "weak" method or the "strong" method.

The details differ, quite a lot in fact, depending on whether
we speak about MIPv6 or something else, e.g. secure Neighbor Discovery.
But the same need: dividing the address space into two distinct sets,
is there.  Or at least that is my current understanding.  Maybe I am
wrong.

Personally, I do not believe that any bold statements help here.
At least to me, this whole zero-conf security business is so new
that at least I need to have very humble attitude here.  I learn
new issues all the time.   On the other hand, IMHO we really want
to go towards zero-conf security.  And if we do, we need some kind
of transition mechanism.  Dividing the IPv6 address space seems to
serve as an important piece of such a transition mechanisms.

Of course, there are different ways of dividing the IPv6 address
space.  If everybody thinks that using a bit in the IID is a bad
idea, then maybe we should consider distinct routing prefixes for
mobile hosts, and distinct link local addresses for secure ND.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 09:47:48 +0300

Bob,

> to signal it's usage (e.g., bit, control protocols, etc.).

You may be right that *how* exactly to *use* the bit is
more a research issue than a standardization issue.  At least
we should get much more peer-review from the security people
on CGA and any other such methods.

However, what Erik and the MIPv6 Design Team suggested is that
the "bit" is *reserved* at this time for future use.  From
the MIPv6 point of view, it *also* acts as a safeguard against
the possible future situation where RR becomes the weakest
link in IPv6 security, e.g. because ND gets secured.  It would
allow gradual shift-out from RR at that point of time.

Basically, it looks like we are not much going anywhere:

  - The currently known alternatives to RR do not seem to
    get accepted at the MIPv6 WG due to IPR issues.
    Personally I consider it very unlikely that new similar
    methods would magically emerge without IPRs.

  - Thus, MIPv6 Route Optimization cannot move forward
    unless RR can be made secure enough.

  - It looks like some people (me included) would not like
    to see RR widely deployed *unless* there is a clear way
    out of it.  A way that does *not* require world-wide
    security infrastructure.

  - The "bit method" is one such a way, but nobody wants
    to adopt it, at least not for MIPv6 RR.

  - Ergo, MIPv6 is stuck, again.

Actually, it *may* be possible to augment RR design so that no
such external safeguard, as the bit, is needed.  We are looking
at that, right now.  Unfortunately there are some IPR issues on
that path, too, and I don't know if they can be resolved.

However, even if we could "fix" RR, that does *not* remove
the need for other zero-conf security solutions (such as
Secure ND), as I explained in the other note to Tony.

Thus, I really think that we should make such a bit
*reservation* for two reasons:  Firstly, to provide
a migration path to zero-conf security, e.g. Secure ND,
and secondly, to provide a controlled way of disabling
RR for certain *addresses*.  (Note that it must be
disabled for *addresses*, not nodes, due to MitM and
impersonation attacks.)  If it later turns out that
the reservation does not need to be used, after all,
the better.  Then release it or use it for something even
more productive.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 10:13:59 +0300

Tony, Brian, and others,

Sorry about this volume, but let me try to simplify once more.
I am now shifting quite far away from the immediate need, MIPv6,
whose issues *may*, perhaps, be solved otherwise, and argue more for
the other thing, Secure ND, and other related zero-conf security
protocols.

----------------

Firstly, assume that there is no external infrastructure that we
may rely on.  That is, we are playing zero-conf game.

Now, what we want to do is to create two playgrounds:

   1. The current non-secure playground
   2. A new zero-conf-secure playground

We can make these completely distinct.  The nodes (childs?)
in the new playground only communicate there, and the nodes
in the current one only here.  In this case there is no problem
the "zero-conf nodes" refuse to talk to the "non-secure nodes",
and that's it.

What we want to achieve, though, is a situation where the
zero-conf nodes can also talk to the non-secure nodes.
If a zero-conf node initiates the communication, this is
probably not a problem, since it needs to look up some
properties of the recipient anyway, and these properties
can include credentials that identify the recipient as a
zero-conf node.  (Maybe these credentials can also be
secured with a zero-conf method, and if so, naming seems
to *help* there, too.  But it certainly does not solve all
problems.)

The problematic case is when some stranger contacts a zero-conf
node.  It must be able to tell if that new node is a zero-conf
node or a non-secure node.  And this becomes tricky due to
the possibility of man-in-the-middle and masquerade attacks.

Relying on looking up credentials each and every time is one
possibility.  But that is inefficient; large servers are
unlikely to do that.

Naming the nodes in the playgrounds differently, as suggested,
seems to provide *some* help.  It is definitely not a panacea,
MitM and masquarading attacks can still play *some* nasty games.
However, the cannot "steal" zero-conf addresses, because
zero-conf addresses are explicitly named as zero-conf addresses
and because the attackers cannot provide the cryptographic
credentials required from zero-conf addresses.  (The latter is
an intrinsic property that defines zero-conf security addresses.)

----------------

Maybe that approaches the essense of the issue.  The issue was
initially about MIPv6 RR vs. other MIPv6 security methods.
However, the issue seems to be more and more shifting towards
this zero-conf (secure ND) vs. current situation issue.  Or so
at least in my mind, I don't know about others.

I hope that this helps, or that it at least leads us to collectively
learn something.

--Pekka Nikander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Apr 2002 11:13:43 +0200

Pekka Nikander wrote:
...
> That is, if we assume that

This I still don't understand. A header option can assert "weak"
or "strong" (or better, "algorithm ID") just as well as magic
bits in an address, without overloading the address and stealing
bits already allocated in EUI-64. A header option can also be
cryptographically authenticated. 

I fully understand why we need bidding-down protection and the
newly suggested step down procedure. I just can't see a case
for putting the required semantics in the address. 

   Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Apr 2002 12:26:36 +0300

> for putting the required semantics in the address.

The difference is that when we speak about routing-related
attacks, a modification of a header can be done by MitMs,
but if the MitMs change the addresses, the whole attack
is changed. For instance, if the intent of the attack was
to install a BCE at www.cnn.com for my laptop's traffic to
be directed somewhere else, changing the address results in
the BCE entry being installed for someone else. I.e., an
attacker can't redirect my traffic anywhere. Similarly,
if stationary nodes have the 'don't accept RR' bit on then
they will not be vulnerable to any MIPv6 based attacks.

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 04 Apr 2002 11:45:55 +0200

Brian E Carpenter wrote:

> or "strong" (or better, "algorithm ID")

This works to express preference for which type of mechanism the node
wants to use for route optimization. But it does not work if what you want
to express is: "I don't want route optimization." By simply inserting the right
fields in the (potentially spoofed) packet, anybody can insert you in the
"I implement and practice route optimization" camp, and then exploit
weaknesses thereoff to attack you.

> just as well as magic

In all this, it is essential to think about the effects on unsuspecting, stationary,
legacy IPv6 nodes (let's call them non-mobile nodes).

You're right in that it is not absolutely necessary to separate "strong"
from "weak" addresses. It is enough to expect all mobile nodes to prove
cryptographically that their address is usable for "route optimization."  This has been referred to
in some previous messages, but essentially it involves deriving ALL route-optimisable
addresses to be derived from a secure hash (not necessarily of a Public Key) and require
proof of that derivation as part of the route optimisation procedure.

The problem is that the only known way to do that has IPR concerns.
There are folks working on solving those issues, but we don't know if that'll ever happen.

In the absence of that solution, the only thing we can think of is to separate
"weak" from "strong" adresses to implement the following solution:

Think of "strong" addresses as expressing 2 things to the peer:

    "(1) I do not engage in redirection operations on my address, or, if I do,
    (2) I only do so with cryptographically strong mechanisms in which I will prove to your
    satisfaction that I do have authorization to use that address"

Think of "weak" addresses as expressing one thing to the peer:

    "(3) I engage in redirection operations on my address and do not intend to
    prove conclusively that I do have authorization to use this address (e.g. RR
    is ok)"

(3) is a viable tradeoff for mobile nodes to make: yes, there are some vulnerabilities, but
they get route optimization in a lightweight manner with a mechanism free of intellectual
property.

For unsuspecting stationary nodes that are not interested in redirecting their addresses,
(3) is not a viable tradeoff. It essentially means they only get the negative side of the
tradeoff (they are now potential victims of the vulnerabilities in RR) as they are not
at all interested in the benefit (route optimization).

If we unleash RR on the world, very likely victims of route optimization attacks
are poor unsuspecting stationary nodes that may very well have no interest ( or knowledge)
whatsoever on mobility.

Mallory could just claim that address is his and insert a binding cache entry (a host route)
into any correspondent node. This will break communications between the correspondent
node and the stationary node. If, on the other hand, the correspondent node can tell it is
(1) or (2) above, this is no longer possible, as it will expect a cryptographic proof of
authorization. If the attacker can produce it, we have much more serious problems.

Another consideration is that today, weaknesses in ND may be more immediate problems
than the above attack. However, the RR attack does not necessarily make use of those
weaknesses in ND. If we ever solve these weaknesses (there's several ideas currently on
how to do this), then RR vulnerabilities will remain as the largest weakness in IPv6. And
unless we put in some mechanism to opt out of RR *from the very beginning* we will have
to live with the pollution of the RR oilspill for the entire lifetime of IPv6.

Hope this helps,

-gabriel

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 13:41:40 +0300

> cryptographically authenticated. 

I agree.  Header options can be authenticated as well as addresses.
However, there are masquarade attacks where there is only Bob
and Mallory, no Alice at all.  Alice comes only later, and when
she comes, her address has been taken.  Thus, therefore it looks
like addresses *may* also need protection, not just hosts.

> for putting the required semantics in the address. 

Well, maybe my logic (or non-logic) goes something like this:

   1. Let us assume that there are "weak" and "strong" hosts.

   2. Let us assume that there is no trusted security infrastructure.

   3. Now, the "strong" hosts want to talk to both to "weak"
      hosts and "strong" hosts, but only in a "strong" way to
      the "strong" hosts.

   4. If we can pre-label the addresses, then the "strong" hosts
      can select an address that says "strong", and the "weak"
      hosts can select an address that says "weak".

   5. I *think* that such labeling helps, under certain situations,
      but it is definitely not a panacea, as I've said many times.

Why do I think that it helps?  Since it allows a "strong" host
to immediately detect an address as a weak one, and therefore
assume that the host using that address is a weak one.

Now, as you have pointed out, a MitM can tweak addresses as
easily as any other options in the packets.  Thus, if we want
to secure *communication* between the hosts, the labeling of
addresses is not need.  However, if we want to secure *properties*
of the *addresses*, such as whether to use a source route for
a given address or not, or what is the MAC address for the
given address, labeling does seem to help.

 From my point of view, source routing (i.e. MIPv6 RO) and
neighbor discovery deal with *addresses*, not hosts.  But
maybe I have been grossly mistaken here, and maybe I need
to revise my thinking completely.

[Mobility certainly is not a property of an address but host,
but MIPv6 specifically makes binds mobility to the home
*address*, giving the home address special semantics and
reducing mobility to source routing.  Personally, I think
that is a mistake, and that something like HIP or GSE would
be better for mobility.  I have to think more about ND.]

--Pekka Nikander

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Apr 2002 08:18:41 -0500

> the "bit" is *reserved* at this time for future use.  

I think that's the wrong way to solve the problem.

either host A reliably knows the address of host B, or it doesn't.

reliably knowing the address of host B implies either prior 
configuration of A, or DNSSEC.  even the latter requires prior 
configuration of A to know DNSSEC keys or certs that allow it
to verify DNSSEC sigs on B  (the idea that just having the root 
keys will be sufficient to verify B's address is just fantasy).  

without A reliably knowing B's address, any scheme whose security 
depends on a bit from B's address is defeatable by a MitM.

and if A has prior configuration of addresses on a per-host basis, 
it can just make that extra bit part of the configuration.  the
bit doesn't have to be in the address.

OTOH if A is using DNSSEC, the problem is that the AAAA records 
don't have room for extra information.

so rather than trying to squeeze a protocol negotiation bit into 
the address, maybe folks should be trying to add the necessary
information to DNS so that it can be verified by DNSSEC.

I realize it's ugly to add more frobs to DNS, but IMHO trying to
further constrain the use of the IPv6 address space is far uglier.

Keith

---

From: "James Kempf" <[email-masked]>
Date: Thu, 4 Apr 2002 09:28:41 -0800

Pekka,

> defence against various DoS attacks.

I think you are making too strong a claim here. All that CGA does is
allow a node to know that a packet came from a node claiming to possess
a certain public key. The packet could have been rewritten in transit,
or the public key may not come from a reliable source, etc. Real end to
end security requires being able to authenticate that the packet
contents were not modified in transit, i.e. a digital signature, and
that the public key can be trusted. If a signature is used, then
Diffie-Hellman or another protocol is required, and both sides must
agree on the protocol and the parameters, e.g. p and g if Diffie-Hellman
is used, and that the public key came from a trusted source.

I think CGA is a good solution to the MIPv6 BU security problem, and
maybe for ND security as well, but I think it is prudent to not
overstate the case.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 20:52:15 +0300

> information to DNS so that it can be verified by DNSSEC.

That can be done.  For MIPv6 it just requires that we have
fully deployed secure reverse DNS.

> further constrain the use of the IPv6 address space is far uglier.

The bit method is also a performance issue.  Do we want a
server to do a DNS lookup each and every time someone
talking with it wants to do MIPv6 RO?  Do we want to include
DNS lookups in Secure ND?

--Pekka Nikander

---

From: Steve Deering <[email-masked]>
Date: Thu, 4 Apr 2002 10:13:41 -0800

At 9:47 AM +0300 4/4/02, Pekka Nikander wrote:
>Thus, I really think that we should make such a bit *reservation*...
>If it later turns out that the reservation does not need to be used,
>after all, the better.  Then release it or use it for something even
>more productive.

Pekka,

I think that making such a reservation is not *quite* as harmless as
you imply.  If I understand correctly, if we were to agree today to
reserve a bit in the IPv6 IID (or a subrange of the IID space), the
Mobile IP folks would then immediately proceed to put some language
in the Mobile IPv6 spec requiring (or forbidding) certain behavior
for packets carrying (or not carrying) IIDs from that reserved space.
If we then get a large number of deployed IPv6 nodes that conform to
that Mobile IPv6 specification, that would effectively limit any
potential future use of the reserved IID space to only those uses
that are compatible with the Mobile-IPv6-mandated behavior.

To be less abstract: if the Mobile IPv6 spec says "don't do RR for
addresses with IIDs in the reserved space", and if we get a large
installed base of nodes obeying that requirement, then we effectively
lose the ability to have RR applied to any addresses that use the
reserved IID space.  That limits what the reserved space can be used
for in the future.  Maybe that's a consequence we will decide is
acceptable, given our best current guess at the potential benefits
of the proposed crypto-IIDs, but we should be aware that a trade-off
is being made.

Designing for future extensibility is hard, and certainly requires more
than just reserving a block of space.  The fancy encoding of the Type
field in IPv6 Hop-by-Hop and Destination options is an example of the
sort of thing you probably have to do to "get it right", but I am
certainly not suggesting that we do that within the IID field!

Steve

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 4 Apr 2002 10:15:03 -0800

> those for which the receiver *requires* CGA, and those for which it

The point we are violently disagreeing on here is only the value of
using a distinct address format as the flag. The receiving application
either requires a CGA address for validation or it doesn't. There is no
inbetween here. If the receiver requires CGA for validation and does not
have a matching PK, the connection will be rejected.

> CGA and related methods bring no additional value.

The man-in-the-middle can't do anything if there are no bits to
manipulate. Either the reciever has a matching PK or it doesn't. All it
has to do is check, and there is nothing that an attacker can do to
invalidate the process.

> is a bad idea and we don't want it.

I am not saying that CGA is a bad idea. On the contrary it is a great
idea. All I am pointing out is that we don't need anything more than
RFC3041 to accomplish it.

> a priori either to the "weak" method or the "strong" method.

I am sorry, but this is misguided. Current nodes will never care about
CGA, so they won't try to verify them. New nodes can verify the
addresses, so they know the originator either cared because the CGA
matched, or didn't care or was incapable of generating a CGA. In either
case it has the appropriate info to decide to accept or reject.

> mobile hosts, and distinct link local addresses for secure ND.

All that is doing is asking for a set of bits. Bits are not the problem
here. The receiver has to check for CGA validation if it cares, so
adding bits does not help.

Tony

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 21:22:11 +0300

[I changed the subject since the topic was changed.]

James,

You are reading that I were saying more than I am,
probably since the word "security" is so ill defined.
I even catch myself using it in different meanings,
and it is sometimes very hard to unambiguosly understand
the exact meaning.

 > I think you are making too strong a claim here.

It looks like you are reading my statement somehow
differently than I am.

 > All that CGA does is allow a node to know that
 > a packet came from a node claiming to possess
 > a certain public key. The packet could have been
 > rewritten in transit, or the public key may not
 > come from a reliable source, etc.

Right, in a way.  But maybe wrong, in another way.

To be more precise, <CGA + self signed certificate
that contains the CGA address>  shows that somebody
has, once but maybe 10 years ago, taken the effort
to create a public key pair, an CGA address based
on the public key, and signed a statement containing
the CGA address using the private key corresponding
to the public key.   The security of this statement
relies on cryptographic primitives, i.e. public key
crypto and the hardness of reversing even around
60 bit one-way-function.  Thus, the security here is
an *economic* function, a function of the fact that
creating such a stament for any *given* address would
be prohibitively costly for most if not all organizations.

To say anything more than that, you have to

    a) define exact semantics for the self-signed cert, and

    b) run a cryptographic challenge-response protocol
       that provides a timeliness proof about the
       availability of the private key.

That allows you to do more, but it certainly does not allow
you to do "end-to-end security" for many meanings of that
phrase.

 > Real end to end security requires being able to authenticate that the packet

I am not quite sure what you are exactly saying, but to
the extend I understand I think that we agree.  That is,
I think that  you are basically saying that CGA as such
is not enough,  but we need a cryptographic protocol on
the top of that.  That I agree with.  What comes to
"trusted source", I am not sure.  Trust and trusted are
also terms that are a lot misused in security literature.

Indeed, the crusial issue here is trust.  However, trust
is *not* a binary, non-qualified thing.  It is a quite
complex phenomenon both in technical and psyco/sociological
sense, but let's not go there.  For now it is sufficient
to understand that Alice trusts Bob for some things but
not for others.

The issue here is that you can *choose* to trust public keys
for *certain* purposes, just based on the belief that it would
be sufficiently hard for an attacker to break the assumed
cryptographic scenario, e.g. CGA.

 > maybe for ND security as well, but I think it is prudent to not

I did not mean to overstate.  I am sorry that my original
sayings about zero-conf security could be read so.

Generic zero-conf end-to-end confidentiality and integrity
does not exist, since the *application* that requires
confidentiality and integrity has application level
access control and authorization requirements.

On the other hand, it seems to be possible to create
zero-conf security for certain signalling tasks, such
as mobility and maybe ND.  BTW, MIPv6 CGA is not the
best example of zero-conf mobility security, HIP is
a much better one.

--Pekka

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 4 Apr 2002 10:21:30 -0800

> possibility.  But that is inefficient; large servers are

This is bogus. You are claiming that looking up credentials once a
connection is inefficient, but your fundemental goal is to have those
same machines look up credentials once a connection if a magic bit is
set. This line of reasoning says that once all nodes are setting the
magic bit life will be inefficient and servers will stop providing
service.

A BIT PROVIDES NO VALUE. Either the receivers will care about CGA and
have to check, or they will let anything through.

Tony

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 21:27:19 +0300

Steve,

...

You are right, of course.  It is good that you say that
so clearly.  To me this has been too implicit, and I couldn't
have expressed it.

Just two observations:

  1. Having a switch that suddenly *allows* RR to be
     used for the reserved space is much easier than
     vise versa.  Such a switch can be a MUST in MIPv6.

  2. RO (and hence RR) is an optimization.  An optimization
     that people want, but an optimization anyway.  If
     two hosts don't do RO, they can still communicate.

--Pekka Nikander

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 4 Apr 2002 10:31:01 -0800

> they will not be vulnerable to any MIPv6 based attacks.
Given the absurdity of this claim you clearly don't understand the power
of MitM. There is nothing that directs traffic 'somewhere else', because
the bit being flipped will be routed to the same wire as the original
address. Since the MitM is capable of flipping the bit off in the src,
it can bid down the association, then on the return traffic it can flip
the bit back on in the dst. If the CN really cares about verifying an
address (which it should for any BU), it has a mechanism in the CGA to
check. A bit didn't help make that easier.

Tony

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Apr 2002 21:37:21 +0300

Folks,

I am getting tired in trying to argue for splitting
the IPv6 address space into two subsets, and for
perhaps reserving "a bit" in the IID, for the purpose
of providing footing for work on security MIPv6
and ND, and perhaps also securing other signalling
functions.

To me, the problems with end-host mobility and end-host
multihoming are just two faces of a more generic problem,
the end-point naming problem.  In that arena I am very
much in favour of Noel Chiappa's thinking.  I think
that we need a new end-point name space, and we even
have a decent candidate for that: HIP.

 From that point of view, Mobile IPv6 and CGA are
just stepping stones towards the direction that
I personally believe that we will head sooner or
later anyway.  I think that CGA and ABK are great
ideas that could make the current architecture
quite a bit more secure before doing the big transition
into separate end-point name space.

What comes to ND, securing ND is a hard matter
as long as the hosts do not have cryptographic
end-point identities.  Once they do, the problem
is *much* simpler to solve.  CGA and ABK seem to
help in this area quite much by providing a means
to still use addresses as primary end-point identifiers,
and to convert the addresses into public keys.
If we take the other approach of using public keys
as primary end-point identifiers, we do not any
more have that problem.  Or at least the problem
is different.

Thus, with these observations and expressions of
my personal beliefs, I hereby withdraw back to
my humble researcher chamber, and don't bother
your standardization work with too radical issues.

Yours sincerely,

--Pekka Nikander
   A poor researcher exhausted in the mill

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 4 Apr 2002 10:37:34 -0800

gabriel montenegro wrote:
> ..
Then they deserve it since every node is required to implement support
for CN, so they really should be aware of mobility.

Tony

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Apr 2002 21:20:46 +0300

Tony Hain wrote:

>R on the world, very likely victims of route
>>optimization attacks

Yeah. They implement CN functionality and serve mobile nodes, but
they are not required to have MN functionality and are likely unaware
that they could be "moved" by attackers.

Jari

---

From: "Arun" <[email-masked]>
Date: Fri, 5 Apr 2002 12:49:04 +0100

Hi all,
        
        I am prety new to this working group. I have a question regarding  forward progress described in the RFC 2461. At what instance of a connection , TCP or anyother connection oriented protocol will inform the IP about a forward in progress?. 

RFC 2461 says 

"  When possible, upper-layer protocols provide a positive confirmation that a connection is making "forward progress", that is,  previously sent data is known to have been delivered correctly (e.g.,   new acknowledgments were received recently).  "

    What time should IP expect this hints from the upper layer protocol ? Will it be with all the packets sent from the upper layer or do we have any mechanism like a setsockopt () so that the upper layer can inform the IP about the forward progress? Please help.

Thank You in advance

(Arun Jose)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Apr 2002 11:47:59 +0200

Pekka Nikander wrote:
...
>    Step 1.  Detect if the client wants to use the default
>             authorization mechanism, i.e. RR, or something
>             stronger.

....
>     satisfaction that I do have authorization to use that address"

I agree that embedding this semantics in the address is a way of achieving Step 1. 
But after reading lots of mail, and a preview (thanks!) of Gabriel's draft,
I'm still stuck, as Tony Hain seems to be, on why this is the only way. As far as
I can see, what is needed is a bit in the *packet*, not necessarily a bit in
the address. Whether the bit is in the address or not doesn't affect the MitM's
ability to fake it, or whether it can be cryptograhically verified.

(Note - I'm not arguing about generating the IID field itself by some
cryptographic technique as Gabriel describes. Architecturally, that 
should be 64 opaque bits anyway.)

   Brian

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 05 Apr 2002 12:12:36 +0200

Brian E Carpenter wrote:

> I'm still stuck, as Tony Hain seems to be, on why this is the only way.

It's not. We added some text at the beginning of section 3.2 of the draft to mention
other ways of doing it, but we may have missed one to clarify your question above.
But I have a question for you: when you say that it's enough to put
the bit in the packet (instead of the address) which of the two are you
implying?:

    1. Don't see what residual threats there are.
    2. I see the residual threats, but I think we can live with them.

If it's 2, then, cool, we can agree to disagree, end of thread.
If it's 1, then we can continue.

-gabriel

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 5 Apr 2002 13:26:17 +0200 (CEST)

Tony,

I wonder if this use of words like "misguided" is a case of strong words
covering up a weak argument.
Can we have a technical discussing without such adjectives please.

One of the issues here is that 5 years from now, if an MN cares about 
the security that the existing (old) MIPv6 correspondent nodes require
for BUs for that MNs home address, how can the MN express it?
If you leave this decision up to the CN things are quite different.

Perhaps you don't think it is necessary for the MN to be able to express
this.  But it is the packets to that MN that are being "redirected" by
an attacker.

  Erik

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 5 Apr 2002 10:52:22 -0800

> for BUs for that MNs home address, how can the MN express it?

The semantics of a two way protocol can't be encoded in a single
unidirectional bit.

> If you leave this decision up to the CN things are quite different.

The decision will always be up to the CN. Even with the proposed bit,
all the MN can do is indicate its expectations and hope. If the MN
really wants assurance, there will have to be a return message from the
CN that indicates how it will handle any BU. If you are into a
bi-directional protocol, address bits are not the place to encode it.

> this.  But it is the packets to that MN that are being "redirected" by

Yes, but there is nothing the MN can do about that without feedback from
the CN about how it will handle a BU. Simply setting a bit does not
assure that the CN will act acording to the MN's intentions.

In draft-montenegro-mipv6sec-bit-method-00.txt, the point in 2.1.1
   The hope is that eventually, Alice will give up and use its weak
   address, at which point, Mallory will let the traffic through,
   presumably, because it can break the protocol:
is simply bogus. If Alice cares about strong, the connection will simply
never happen in the scenario described. In reality the connection will
happen, because the premise in the preceding paragraph
   this is much simpler than rewriting Alice's address with a
   "weak" address and then sending the packet to Bob.
is also bogus. It would be much easier for Mallory to act as a NAT (and
flip the strong/weak bit) than to try to guess that some subsequent weak
address actually belonged to Alice.

The claim on pg 14 furthers this failed line of reasoning:
   Note that an active attacker on the path between Alice and Bob is
   able to clear a set bit.  However, that changes the address, and
   Alice is not going to answer to any possible replies sent by Bob.
   Thus, the bit prevents the attacker from impersonating as Alice and
   fooling Bob to use the less secure protocol.
because it assumes that the operation is unidirectional. All Mallory has
to do is act as a well understood NAT and set it back on the return path
so Alice would be none the wiser.

Tony

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Fri, 5 Apr 2002 22:19:33 +0200 (CEST)

Tony!

If i understand well the description if your attack Mallory needs to be
present for every single packet that Bob is sending to Alice and not only
during the bidding down process.

In the scenario that you describe Alice will receive traffic from Bob
without performing "strong" exchange and hence Alice will be aware of the
presence of Mallory.

Alice requires a "strong exchange" that Mallory can  not impersonate.
Mallory can fool Bob to use a weak method but can not fool Alice that is
expecting a strong one from Bob.

/aep

-- 
--------------------------------------------------------------------------
"After a year's research, one realises it ould have been done in a week."
               				  William Henry Bragg (1862-1924)

---

From: JJ Behrens <[email-masked]>
Date: Fri, 5 Apr 2002 13:54:18 -0800

> expecting a strong one from Bob.

Sir,

You are correct, and this in mentioned on the last paragraph of page 5:

   Of course, if Alice implements the "strong" exchange, a very valid
   policy would be for it not to engage any more in "weak" exchanges.
   This simplifies Alice's protocol processing and is more secure
   because Alice avoids any risk of falling victim to a bidding down
   attack.  For a mobile node, this translates to requiring a "strong"
   mechanism for route optimization.  The mobile node simply forgoes the
   benefits of route optimization and limits itself to bidirectional...

However, I think a more important point is written in the last paragraph of 
page 3:

   For an unsuspecting stationary node that is not interested in
   redirecting its address, (3) may not be a viable tradeoff.  It
   essentially means that the node only obtains the negative side of the
   tradeoff (it becomes a potential victim of the vulnerabilities in
   RR), as it is not at all interested in the benefit (route
   optimization of its addresses).

Of course, I'm still in the process of reading the draft, so I may be wrong.

Best Regards,
-jj

-- 
Users of C++ should consider hanging themselves rather than shooting their 
legs off--it's best not to use C++ simply as a better C.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 5 Apr 2002 14:42:11 -0800

> Of course, I'm still in the process of reading the draft, so

Actually your response reminds me of the comment I intended to make
earlier. This draft really gets lost in the concept of MN/CN, &
Stationary/Mobile. Nothing personal intended, but I suspect this is due
to the perspective of the contributers.

The terms Stationary & Mobile have no business being in the document
since they are related to physical properties of the device, not the
header properties of the packets emanating from them. All the points
made about a Stationary node would apply just as well to a Mobile who
happened to be at home, and all the points about the Mobile device could
be used by Stationary that had reason to use a BU to manage
associtations across address changes.

The terms that might have a more consistent interpretation are; 'intends
to use secure MIPv6', or 'does not intend to use secure MIPv6'. Physical
properties of the device are not wrapped up in those.

The relationship of MN to CN is unidirectional.  There may be an
inverted pair of those relationships for a connection, but there is no
requirement that a pair exists or explicitly does not exist.  What
should be clear is that policies applied to each of those unidirectional
relationships must remain independent.  If Alice wants Bob to state
intent about using secure MIPv6, a real protocol is required. Trying to
overload the semantics of Alice telling Bob that she will be using
secure MIPv6 (particularly through a single bit) as a message that Bob
must reciprocate is fundamentally flawed. What if Bob had no means to
use secure MIPv6? How can Alice tell that condition from Mallory sitting
in the middle? What is to prevent Mallory from doing a double address
NAT thing where its own IID ends up being presented to Alice and Bob
along with appropriate credentials? The address is simply the wrong
place to put a single bit flag that really accomplishes nothing in the
end.

Tony

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Sat, 6 Apr 2002 00:46:33 +0200 (CEST)

> All Alice knows is that Bob is not asking for the same protection that
> Alice is. There are too many semantics being assumed about the magic
> bit. This specific response assumes that there is an implicit
> bi-directional requirement that if A sends the bit set to B, then B must
> use the same bit set in its address back to A. Yet in other messages all
> the magic bit says it that A doesn't want B to interpret any BU messages
> that can't be validated. Which is it??? Certainly there is no
> requirement for B to tell A that it shouldn't interpret a BU from it,
> since B may have a different policy at the moment.

To my understanding it is becouse Alice uses the "strong" exchange,
indicated in IID that doesn't want Bob to perform a BU with a "weak"
exchange. Bob policy is independent of this discussion, becouse Bob MUST
NOT perform a BU under those circunstances.

> If you really want a protocol then create one, don't assume that a
> single bit sent in one direction can carry the semantics of a
> bi-directional protocol. In particular for the problem being solved,
> don't ever assume that the policies have to be symmetric. All this
> mechanism is trying to do is let the CN know how to interpret a BU sent
> on behalf of the MN should be interpreted in a specific way. That is a
> unidirectional statement, but might include a feedback path to let the
> MN know if the message was received and the CN will honor it. The
> opposing unidirectional statement MUST NOT be required to have the same
> interpretation.

A feedback path is available using the status field of the Binding. So if
Bob has not resources or intentions to follow Alice wishes there is a
mechanism to provide feedback.

/aep

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 5 Apr 2002 14:02:39 -0800

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Apr 2002 10:29:52 +0200

> If it's 1, then we can continue.

I think it's
    3. I see the residual threats, and I think it's illusory to believe
       that overloading the address significantly reduces them

(for why, see Tony Hain's messages of the last couple of days).

BTW you are of course correct to insist on the non-existence of an
effective PKI for this domain. 

   Brian