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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 22 Mar 2002 08:49:28 -0800

Pekka,

How do you identify those two addresses without reserving the bits ?

-mohan

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Friday, March 22, 2002 8:40 AM
> To: Hesham Soliman (ERA)
> Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander; 
> [email-masked]; Erik Nordmark
> Subject: RE: Allocating a bit in the RFC2374 Interface Identifier
> 
> 
> On Fri, 22 Mar 2002, Hesham Soliman (ERA) wrote:
> >   > > => For all those opposing the addition of the bit
> >   > > in the IID, I really hope you would carefully consider
> >   > > Jari's text above. For mechanisms designed to prove
> >   > > address ownership (relevant to securing ND, MIPv6 BUs
> >   > > and I can think of more), you MUST include the 
> >   > > distinction in the _IP_address. The IP address _is_
> >   > > the identifier relevant for this case, not the host
> >   > > name, URL or anything else. 
> >   > 
> >   > Two destination addresses, one that requires verification 
> >   > by stronger 
> >   > means, one which does not.
> > 
> > => ?? Which part of my message are you answering ?
> 
> I was just pointing out a possible alternative to reserving 
> bits in the source addresses.
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Mar 2002 14:22:08 +0200 (EET)

> How do you identify those two addresses without reserving the bits ?

"From the hip", possibly either:

 1. invent some nice mechanism and patent it.  Good riddance, or

 2. the implementations which support ABK add an extra rule in their 
destination/source address selection rules so addresses which seem to be 
ABK'ed will be tried first; this can be just a guess, something based on 
the address, a bit reserved in the IID by the ABK mechanism or whatever, 
or

 3. require manual configuration.

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Mon, 25 Mar 2002 13:50:34 +0100 (CET)

> the address, a bit reserved in the IID by the ABK mechanism or whatever, 

But I think ABK as well as CGA addresses would require communicating
in order to verify that the address is valid according to ABK or CGA.
Thus in order to choose destination and source addresses the node
would need to communicate. Seems kind of expensive.

In the case of CGA (I haven't wrapped my head around ABK yet) it seems 
feasible to do things without a bit in the address for MIPv6 if
each time a CN receives a BU, the CN would challenge the MN to prove
that it has a public key whose hash (really, hash(PK, prefix, stuff)) is
the IID.
If the MN can't prove that then either the MN is an imposter or
is it using a non-CGA IID.
Without a bit in the address the CN can't tell which of those is the case.

>  3. require manual configuration.

Eureka, that's it!! :-)

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Mar 2002 15:08:17 +0200 (EET)

> >  3. require manual configuration.

Actually, in some cases (e.g. some ND messages, to prevent spoofing), 
this wouldn't be all that big an issue :-)

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Mar 2002 22:12:33 +0200

> this wouldn't be all that big an issue :-)

Complete manual configuration in terms of who is expected to use what
level of security is probably out of question; I can't expect to inform
www.cnn.com about my preferences in any manner. However, it may be
possible to think about a single 'flag' that each node has and which
determines who strong security it can handle. But this seems to get
us into one of two undesirable positions:

First, we could allow e.g. www.cnn.com to accept different
levels, but this defeats the purpose of stronger security
since the weaker method could still be used by someone
to trick cnn into diverting your traffic somewhere else.

Second, we could be strict about the levels and only talk to
nodes that use stronger security. But this would restrict us
to a small set of nodes, RO or no RO. Assuming better than RR
security becomes necessary at some point, it's deployment would
be extremely hard (more on this in draft-aura-mipv6-bu-attacks,
section 6.2).

Do you Pekka agree, or did you have some other form of manual
configuration in mind?

Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Mar 2002 22:20:09 +0200 (EET)

> to trick cnn into diverting your traffic somewhere else.

As long as backward compatibility is a requirement, I'm not sure this can 
be worked around anyway.
 
> Do you Pekka agree, or did you have some other form of manual

Basically I was thinking only about securing some ND link-local messages, 
not on a global where some other mechanisms, e.g. IPSEC, might apply as 
well.

Another alternative is use new network prefixes for secured sites (e.g.  
2801::/16).  This strikes me to as an unscalable mechanism, though.