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 10:45:23 +0200

> One comment I would like to make about this topic, which I 
  > don't think 
  > has been addressed (no pun intended), is that this 'bit 
  > method' for addresses 
  > essentially can identify nodes which are 'potentially' 
  > mobile.  

=> Not really, since it can be used for securing ND
as well. You can definitely pick a MN by the contents
of every packet it sends when it uses RO. So, the bit
does not add anymore here than the RH or the HAO 
would. HMIPv6 has some extensions to help with
anonymity but of course they're not to be 
used on a global scale. 

Hesham

I am not a 
  > security expert, so this may not really be a threat, but my 
  > feeling is that
  > most mobile devices will probably be small devices, that are 
  > battery/processor/l2 (i.e. wireless) limited devices.  By 
  > identifying
  > nodes this way, do we open up the possibility for addition 
  > DoS attacks
  > (small device with limited processor, battery & bandwidth 
  > capacity) is
  > more susceptible to flooding attacks.  Is this an issue?
  > 
  > thanks,
  > John
  > --------------------------------------------------------------------
  > 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]
  > --------------------------------------------------------------------
  > 
--------------------------------------------------------------------
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: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 4 Apr 2002 17:58:45 +0200

> 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.

=> Just so I can understand your point, could you
say why. And I mean for the particular applications
we've been discussing (ND, MIPv6 ...etc)

  > 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.

=> I agree that it doesn't make any sense to have 
a bit in the iid that says it's globally unique. 
Historically maybe it did, but right now it's
obviously useless. 

Hesham

---

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

> > It seems to me that the important point is that a host needs
  > > to assert something about the strength of security it requires.
  > > This is a property of a host, not a property of an address.
  > > I become more and more convinced that asserting this property
  > > via an address bit is both unnecessary (it can be done by
  > > a header field that is equally subject to authentication)
  > > and undesirable (overloading).
  > >

=> Mobility is all about managing address
changes. In MIP, the identity that matters
is the address, not the host. The host has
no meaning in the context of MIP. 
So I think a cryptographically generated
address is a property of *that* address. 

Hesham

---

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

> 
  > > => 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.  

=> I was only following your statement!

  > 
  > 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.

=> Which is the whole reason for this discussion.
So I agree!

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 5 Apr 2002 13:31:27 +0200

> 
  > 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.

=> Just one point to clarify here. The bidding down
attack can take place _before_ the node has a chance
to send any pk. So the scenario you mention will only
happen when there is no bidding down during the negotiation
phase. The node does not necessarily send the pk in the 
first message. 

Hesham

  > 
  > >
  > > 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.
  > 
  > 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.
  > 
  > >
  > > 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.
  > 
  > 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.
  > 
  > >
  > > 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.
  > 
  > 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.
  > 
  > >
  > > 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.
  > 
  > 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
  > 
  > >
  > > --Pekka
  > >
  >