Subject: RE: Using "a bit" as a protection against bidding down / for some thing else

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 4 Apr 2002 17:10:24 +0200

> > However, what Erik and the MIPv6 Design Team suggested is that
  > > 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.

=> How can yahoo.com reliably know any possible 
client??

Hesham
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Thu, 04 Apr 2002 10:35:50 -0500

> => How can yahoo.com reliably know any possible client?

if yahoo.com thinks there's any value at all in the client's IP address,
they're deluded.  

the only way to reliably know a client is if the client presents you with 
cryptographic proof that they sent that message, and you trust the keying 
material on which that proof is based.
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Thu, 04 Apr 2002 22:48:17 +0700

Date:        Thu, 4 Apr 2002 17:10:24 +0200 
    From:        "Hesham Soliman (ERA)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | => How can yahoo.com reliably know any possible client??

It most likely can't, but why exactly is yahoo.com going to care?

The assumptions required to mount a plausible case where the bidding
down scenario (as interesting a theoretical problem as it is) can
actually apply in some way, and especially where allocating an address
bit to help avoid id would work, are simply out of this world.

That said, of the two current proposals to define a bit to have special
meaning in the IID part of an address, this one is much more rational
than the other one - that is, to have a bit that says "this IID is
unique".   That one is even more absurd.

Let's just return all the bits in the IID part of the address to whoevevr
has been delegated the relevant prefix, to use however they like (with
guidance to implementations on how they should behave by default for best
interoperability).

kre

---

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

Keith,

> material on which that proof is based.

I completely agree with you if the goal is to know *who* the
client is, for any reasonable meaning of *who*.  But that is
*NOT* the goal.  For MIPv6, the *final* goal is to learn if
the client is *authorized* to create bindings, i.e. source
routes, for the _home address_ that it is using.  The process
to learn whether it is authorized or not is basically a two
step process:

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

   Step 2.  Use the authorization mechanism to detect if
            the client is really authorized.

It was an _explicit_ IESG requirement that the authorization
mechanism MUST NOT rely on trusted third parties, i.e. on
a security infrastructure.  Hence the "infrastructureless"
methods.

If we want to take the security-infrastructureless route,
we have little to build up but the routing infrastructure
and the addresses.

(The secure ND case does not apply for an arbitrary client
  for contacting yahoo.com.  I'm too tired to try to think
  generally right now, and to work out more generic examples.)

--Pekka Nikander

---

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

Keith,

> material on which that proof is based.

Well stated!

            jak

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Apr 2002 13:17:07 -0500

> For MIPv6, the *final* goal is to learn if
> routes, for the _home address_ that it is using.
...
> a security infrastructure.  Hence the "infrastructureless"

in that case, I think the solution is the null set.  because none of:

- the fact that traffic from a client appears to come from an address
- the fact that the client appears to respond to traffic sent to
  an address
- the fact that a client claims to be authorized to make assertions
  about an address

are suitable as verification that a client is authorized to make
assertions about that address.  such authorizations are *inherently*
made by third parties - i.e. network administrators who are responsible
for assigning addresses for use by clients.  the *only* way to verify
client assertions about address bindings is to verify that the client 
has been given the authority to make such assertions by the party who 
is reponsible for doling out those addresses - and the only way to do 
that (that scales) is to rely on some security infrastructure.  

such infrastructure doesn't have to involve a "trusted third party" 
(in the sense of a "third party" that is unrelated to the 
participating parties and whose only function is to mediate trust)
but an infrastructure that involves the parties who have the authority
to make assertions about addresses (from IANA down to the site level
via the RIRs and ISPs) is inherently necessary to address the problem
you claim to be trying to solve.

Keith

---

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

Keith Moore wrote:

> has been given the authority

I think I disagree about the third party part.

First, it turns out that return routability _is_ strong enough to
correspond roughly to the (current) security of the IPv6 Internet. This
would imply that that traffic coming from an address and apparently
responding to an address _can_ be used to make decisions about whether
a binding can be accepted or not. Similarly, CGA is somewhat stronger
than this and interestingly the nodes give an authority to themselves,
in a manner that others can verify this. (Subject to bidding down attacks
of course if we don't know what scheme to follow.)

Read more from http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt

Jari

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Apr 2002 14:40:20 -0500

> correspond roughly to the (current) security of the IPv6 Internet.

I don't doubt that.  But then why are we worrying about MitM attacks
in one case and not in the other?

Keith

---

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

> in one case and not in the other?

Are you asking why we worry about MitM for RR but not for the stronger
cases? Well, one answer is that there is a difference in the security
level of RR and CGA, as an example. But the main worry is that if
we happen to succeed in improving the overall security of IPv6 in
the future, RR might became the weakest link. The link that I gave
you make a security analysis as a "diff" to the current situation,
and if the current situation changes...

Anyway, this volume of e-mails on this thread is tiring at least
myself and perhaps we should just end this discussion for now as
we don't appear to be on a path to consensus. It's probably best
to get the mentioned draft out, and deal with all the points that
have been raised, and then get back to the issue.

Jari

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Apr 2002 15:13:48 -0500

> cases?

no, I'm saying that if all we're trying to do with MIPv6 is equal the 
current security of the IPv6 internet, why do we care about MitM?
Because the current IPv6 internet is clearly vulnerable to connection
hijacking, impersonation, etc. via MitM.
--------------------------------------------------------------------
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: gabriel montenegro <[email-masked]>
Date: Fri, 05 Apr 2002 11:11:21 +0200

Jari Arkko wrote:

> It's probably best

I just submitted the draft:

Abstract

   Mobile IPv6 uses "return routability" to secure route optimization.
   Even after using this procedure, there are residual threats for which
   other stronger methods provide protection.  Since these are optional,
   and return routability is the default, an attacker may engage in
   "bidding down" attacks.  These attacks aim at coercing participants
   in Mobile IPv6 route optimization to forgo the stronger methods for
   the default return routability.  This document discusses what the
   participants in route optimization can do to deter or alleviate
   bidding down attacks: the "step down" procedure for the mobile node
   and the "bit method" at the correspondent node.

Before the official announcement you can also find it at:

  http://www.piuha.net/~jarkko/publications/mipv6/draft-montenegro-mipv6sec-bit-method-00.txt

tnx,

-gabriel