Subject: RE: Allocating a bit in the RFC2374 Interface Identifier

From: "Glenn Morrow"<[email-masked]>
Date: Fri, 22 Mar 2002 01:05:04 -0600

For now, let's assume that Bob is told A but Bob doesn't know if who sent it
to him is on the level. I.e. he doesn't know if A is correct and he doesn't
know if A has been modified by a third party en-route.  

Bob also doesn't know if someone between the topologically correct routing
infrastructure of A has been compromised either. For instance, someone on
A's true network is pretending to be the mobile's HA or just snooping. I
guess another scenario is someone on Bob's network is pretending to be a
router along the path or snooping, etc.. i.e. any MITM.

There is another case of MITM where two nodes could be in collusion, posing
as A and its home network, as well, but they have pretty much given up on
that as the same affects could occur for non mobile nodes, already, if the
routing infrastructure was somehow compromised.

They are also concerned about DDoS attack such as pounding the CN with such
requests to generate public keys etc.. for this SA establishment process.
The "keep it simple" approach is simply RR, return routability i.e. trust
that there is no MiTM. But it doesn't protect as well against some MITM
attacks and so this has been labeled as weak vs. strong.

Note that A would also benefit from knowing that he  actually contacted Bob
and someone wasn't impersonating Bob due to a MITM situation.

Overall, I find this amusing as they are both not bullet proof against MITM
due to existing security holes in IP itself - not that the fixes would be
acceptable as anything more than a BCP. So a few folks are pushing a
"better" encumbered solution with the hopes that at least this BCP for IP
holes will be created as well at some point to close the other holes.

Then we have the credentials and infrastructure proponents i.e. trust an
application trust network, AAA; however, this simply transfers the MITM
problem to another route and everyone keeps arguing about just what the AAA
is or should be.

Then we have to "trust the routers themselves proponents" that assume that
the routers close to A both in A's home network and in the visited network
somehow know that A is doing the right thing. But this would involve these
routers being involved in the signaling and require some sort of
infrastructureless and scalable edge to edge SAs. This relies on a great
deal of trust for these route updates as you mention but it really would
rely on the same trust that the networks are built with today. The ways to
set up and cache these SAs without more infrastructure is a contentious
issue that results in a battle between the people who make servers vs.
people who make routers. Much of the same arguments against RSVP are used to
thwart such concepts. Also with Monet and Manet, the question of trusting
routers is being portrayed as unprofitable and not necessarily trustworthy.
We are also a long way away from this IMHO. The infrstucture solution
investors would fight such a thing tooth and nail.

Then we have the let's do something completely different folks i.e. the
Per-host DNS with no caching, IIP, 8+8ers and HIPpies - not that I would
want to stop any research on these topics. I still think we are just getting
started on this Internet thing.

I have a sneaking suspicion that equivalent strong security mechanisms exist
and are comparable end to end - "better" solutions yet do not require these
interface changes; however, this may seem to be a rather non-productive task
to some for something that is optional anyway. I suspect that these
solutions might be encumbered as well and these folks don't really want to
try to impose some sort of encumbered solution in the IETF. 

Keep in mind that for the solution to be effective it should also have hooks
to work with infrastructure-based solutions as well. This is the "the key
generation operations can be offloaded" statements you might run into when
scanning mail archives or related documentation.

Anyway, this might end up to be the same state of affairs with IP-based VPN
security technology with different vendors having different solutions and
variants of the ESP protection etc.. Seems like some sort of broken history
record.

Then again, people might just say that RR is fine given the weaknesses of IP
already and that the infrastructure solutions can be used if you want
something stronger. This would be passing the buck to the AAA war, though.
I.e. deployment would still be a major issue.

Thanks for trying to understand the variables of the problem set - both
technical and business oriented. I hope this pretty much sums up the
conundrum for all. I think it serves to put this concept of reserving an
interface bit in perspective - not the mention issues within the whole IETF.

Glenn

> -----Original Message-----
> From: gabriel montenegro [mailto:[email-masked]]
> 
> So the trick is to convince Bob to insert into its route 
> table a host route entry for
> A at some_address. If Bob doesn't know A, I think we're 
> talking about a very
> different problem. What are you asking Bob to insert into its 
> routing table?
> 
> -gabriel
> 
> 
> 
> --------------------------------------------------------------------
> 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: Fri, 22 Mar 2002 16:35:27 +0100

> 
  > I have three concerns about this CGA/KBA idea:
  >  - first this idea is about interface IDs, not addresses 
  > (so for Mobile
  >    IPv6 we need Return Routability too). 

=> Yes you do, but you would be able to generate
an SA. This is not the case with RR only.

  >  - second the verification implies an expensive crypto operation
  >    (typically a signature check) so the scheme is subject 
  > to trival DoS
  >    attack, especially if each packet has to be checked (so 
  > or a session
  >    key is negociated with an even more expensive and 
  > complex protocol,

=> If you want strong authentication, what else can 
you do?

Hesham

---

From: "Glenn Morrow"<[email-masked]>
Date: Mon, 25 Mar 2002 08:14:43 -0600

Brian,

I agree with your reasoning. I suspect proponents of the bidding down bit
will start using the acceptable risk argument at this point. The bit I think
should be reserved long term is already but the terminology describing it
should probably be changed.

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, March 25, 2002 4:00 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: [email-masked]; Keith Moore; Jari Arkko; Mohan Parthasarathy; Pekka
> Nikander; Pekka Savola; [email-masked]; Erik Nordmark
> Subject: Re: Allocating a bit in the RFC2374 Interface Identifier
> 
> 
> > Glenn Morrow wrote:
> > 
> > Right,
> > 
> > So do people understand why having it in the address 
> provides more protection?
> 
> No. Quoting Pekka Nikander's original description of the 
> bidding-down attack:
> 
>  Note that an active attacker at the path between Alice and 
> Bob is able
>  o 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.
> 
> This doesn't satisfy me. If the attacker is capable of 
> clearing the bit
> in the source address of packets from Alice to Bob, it is 
> equally capable
> of setting the bit in the destination address of packets from 
> Bob to Alice.
> (The proof of concept here is every NAT box sold so far.)
> So I don't see why the attacker can't conduct a complete 
> bidding-down attack
> in which Alice sees only packets with the bit set, and Bob 
> sees only packets
> with the bit cleared. Alice will believe she has asserted 
> "strong security
> available", Bob will believe the opposite, and both will be fooled.
> 
>    Brian
>  
> > Now let's assume that we did not allow just RR, this would 
> avoid the bidding down attack IFF there was only one strong method.
> > But I suspect there may be more than one strong method and 
> arguments as to which strong method is better will fourish and the
> > bidding down attack may still be protrayed as being there 
> between the strong mechanisms.
> > 
> > Again this putting the bit in the address for extra 
> protection may be in question over and over, IMHO. I.e. if a 
> field that
> > indicates which strong method to use is in place above the 
> address then it can be alterred as well using the same logic for
> > the bit being in the address now.
> > 
> > > Sent: Thursday, March 21, 2002 9:23 PM
> > > To: Keith Moore
> > > Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander; Pekka Savola;
> > > [email-masked]; Erik Nordmark
> > > Subject: Re: Allocating a bit in the RFC2374 Interface Identifier
> > >
> > >
> > > Keith Moore wrote:
> > >
> > > > > Note that the MitM can also change the IP address, 
> but if he does
> > > > > so, he is *not* attacking the original host, as the address is
> > > > > changed.
> > > >
> > > > unless of course the MitM can convince that host to take on
> > > that address
> > > > as an alias.
> > >
> > > So Mallory says that his address M is an alias for Alice's
> > > address A. Ok.
> > > What if Bob looking at A could know (yes, signalled by a 
> bit) that A
> > > it is only aliasable by very secure mechanisms. That's the
> > > whole point.
> > > Mallory would then be forced to break any of several very strong
> > > (using crypto and explicit trust relationships) mechanisms:
> > >
> > >     - AAA
> > >     - PKI
> > >     - CGA
> > >     - etc
> > >
> > > RR would definitely not be included here.
> > >
> > > -gabriel
> > >
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 25 Mar 2002 09:25:00 -0800

> 
> > Or am I missing something?
> 
> Pekka,
> 
> Perhaps the question was about the whole address and not just 
> the interface ID. You've described how the interface ID is 
> crypgraphically tied to a 
> public key.
> But this doesn't per-se prevent somebody fabricating a CGA 
> address using an arbitrary prefix.
> 
This is the case where somebody owning a given (public key, private key
pair) establishes a binding presumably, moves off to a different link
and tries to use the same interface id. Can you describe the attack
scenarios here ? If the attacker wishes to do reflection attacks, 
some other node on the old link should have the same IID which is
not very likely I guess.

> The way to avoid this for MIPv6 is to do a return routability test 
> when the CGA address is verified. The RR test would ensure that the 
> peer is reachable at the prefix. (And the RR test would 
> essentially be done as part of the challenge to have the peer 
> sign the nonce using the private
> key.)
>
Agreed.

-mohan

>    Erik

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 28 Mar 2002 10:06:48 -0800

> 
> Brian and Pekka, 
> 
>   > > I am tired, and probably the situation is more complex, 
>   > but this my initial
>   > > reaction.  It looks like in the scenario you describe 
>   > Alice and Bob
>   > > would end up running different protocols:  Alice the 
>   > strong one, which
>   > > the attacker presumedly cannot break, and Bob the 
>   > not-so-strong one,
>   > > which the attacker presumedly can break.  Thus, Bob would 
>   > end up running
>   > > the not-so-strong protocol with the attacker, but the 
>   > address used would
>   > > not be Alice's address.
>   > > 
>   > It depends on how smart the MITM is, but I think in the 
>   > simplest case,
>   > Alice will hear from pseudo-Bob "I can't support strong 
>   > security" (this
>   > will be fabricated by the MITM) so she will be bid down, 
>   > but Bob never knows
>   > about this because he falsely believes that Alice can't 
>   > support strong security.
> 
> => I have to add myself to the list of tired/jetlagged
> people :). But, in the scenario you mention, it seems to
> me that Alice will not end up talking to Bob and Bob
> will not end up talking to Alice. And both will not end
> up talking to the MITM anyway.
> In fact, If the MITM modified the first message in the,
> lets call it SA establishment, then this SA establishment
> will fail. If it was the last message that was modified
> then it will also fail because the message will be 
> inconsistent with the intial ones. So it seems to me 
> like a classic DoS attack. Nothing we can do here.
> What am I missing?
> 
I think the problem is in using the bit to convey whether you want
a secure exchange or not. And at the end of the exchange (which
effectively created a binding in the mobility case), MN thinks
it established securely with CN which it has not i.e I set the bit
to indicate I want a secure exchange with some arbitrary node (CN),
but this does not really gurantee anything. It does not matter whether
you set the bit or not. It all depends on whether MiTM will occur or
not.

So, in the absence of MiTM attack, the bit reaches CN safely and hence
tells
CN whether MN needs  a secure exchange or not. But in the 
absence of MiTM attack, RR seems sufficient and hence the bit
is not needed. What am I missing ?

-mohan

>   > > But I start to believe that I am missing here things, 
> and that the
>   > > reality is more complex than what we thought at the MIPv6 
>   > DT.  That is,
>   > > at least we need a mechanism for Alice to securely 
> learn about the
>   > > mechanisms Bob supports.  Maybe we could use "the bit" 
>   > here, too, but
>   > > my brains just fail to analyze what happens to the 
>   > address-spoofing
>   > > MitM in that case; maybe you could perform the attack in 
>   > both directions?
>   > 
>   > Exactly
> 
> => But then we end up with Alice talking to Sam
> and Bob talking to Homer! So what ?
> 
>   > > But would that matter?  If there is an attacker that can 
>   > spoof packets
>   > > and break the less secure protocol, it can create 
>   > security associations
>   > > with the less-secure protocol anyway, be there the 
>   > legitimite peer or not.
>   > 
>   > Yes. There's a recursion here, and also a moral I think: 
>   > don't allow weak
>   > security, period.
> 
> => I used to wonder about the strength of RR only for
> MIPv6. But after a long thread with Erik, I am 
> convinced that it is as strong as the weakest 
> link. I.e. ND. So I agree with Erik's statement
> during the presentation in Minneapolis, which said
> that securing ND will make RR seem less secure.
> Hence the need for allowing this stronger mechanism
> in future. I.e. put the bit in the iid. 
> 
> Hesham
> 
>