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

From: "Glenn Morrow"<[email-masked]>
Date: Fri, 22 Mar 2002 16:06:40 -0600

Gee, I guess a bidding down threat could also depend on the size of keys
used as well. Let's put a key size field in the address as well as a
signaling semantics id, too. But even with this you are still stuck with the
2 nodes in collusion MITM attack. I guess this could be used by slaves in
multiple sites to make it look like DDoS attack was coming from another node
in that site. If you want to get rid of this collusion threat you will have
to do the "plug the holes in IPv6" BCP and bring the routers into the
security and signaling picture. Even them there will likely be some risks.

I guess what I'm saying is that, "I would rather get rid of the simple RR in
order to avoid having to reserve such a permiscuous bit in order to meet the
rather arbitrary, IMO, acceptable risk qualification. If RR alone without
some sort of integrity protection does not meet the acceptable risk then it
simply shouldn't be standardized.

I do, however, agree with the forsight that reserving some space in the
identifier now is a good idea; however, there are already bits reserved in
to upper part of the address but these doen't have the same properties in
terms of scoping.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH] 

Right, 
So do people understand why having it in the address provides more
protection? 
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.

> -----Original Message----- 
> From: gabriel montenegro [mailto:[email-masked]] 
> 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 
> 
> -------------------------------------------------------------------- 
> 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: Jari Arkko <[email-masked]>
Date: Sat, 23 Mar 2002 06:25:44 +0200

Glenn Morrow wrote:

> identifier now is a good idea; however, there are already bits reserved 
> in to upper part of the address but these doen't have the same 
> properties in terms of scoping.

Well, if we could agree on the "reservation" at least then we could
move rfc 2374 bis forward and continue the "use" discussion.

Jari