Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (withDISCUSS and COMMENT)

Hi Ralph;

I agree with you that this text would benefit from being more specific.
RPL requires a number of validations to happen. A deployment might
require additional policies, and use for instance L2 crypto to enforce
them. So validating a router involves security concerns, like link
access, and/or RPL security as Michael indicates. Additionally, RPL
section 13 requires a continuous link quality validation. So this refers
but is not limited to RPL sections 3.2.3 and 13.

Suggestion:

2.   An implementation SHOULD validate a router prior to selecting it
        as preferred.  This validation process is implementation and
        link type dependent, and is out of scope.  A router that
        succeeded that validation process is preferable.

=>

2.   An implementation SHOULD validate a router prior to selecting it
        as preferred.  This validation process is implementation and
        link type dependent, and is out of scope.  The validation
involves
        but is not limited to application of [RPL] sections 3.2.3 and 13
as 
        appropriate, and may involve deployment specific policies
        as well. A router that succeeded that validation process is
       preferable. 

What do you think?

Pascal

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Ralph Droms
> Sent: Tuesday, August 09, 2011 6:23 PM
> To: draft-ietf-roll-of0@tools.ietf.org
> Cc: roll@ietf.org; The IESG; roll-chairs@tools.ietf.org
> Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15:
> (withDISCUSS and COMMENT)
> 
> 
> On Aug 9, 2011, at 10:52 AM 8/9/11, Michael Richardson wrote:
> 
> >
> >>>>>> "Ralph" == Ralph Droms <rdroms.ietf@gmail.com> writes:
> >    Ralph> 5. In section 4.2.1, what does it mean to "validate a
> >    Ralph> router"?  Why would a router that passes validation
> >    Ralph> ("succeeded that validation process") only be
"preferable"?
> >
> > I think, it refers to rpl-19 section 3.2.3, to the "authenticated"
mode.
> > This mode is completely unworkable with asymmetric crypto.   I guess
I
> > need to write an ID that explains this better.
> 
> Pascal - can you confirm that section 4.2.1 refers to rpl-19 section
3.2.3?
> 
> - Ralph
> 
> > The reason why an authenticated router is only preferred is because
the
> > node might need to get online in order to actually validate things.
Any
> > node which will pass enough traffic so that a new node can validate
some
> > certificate chain is good enough.
> >
> > While a new node can do all manner of DOS attacks to prevent the
> > prospective node from validating some security properties, none of
them
> > (if you trust your crypto) are worse than having the prospective
node
> > find itself without any network.
> >
> > --
> > ]       He who is tired of Weird Al is tired of life!           |
firewalls  [
> > ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/
> |device driver[
> >   Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> > 	               then sign the petition.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll