'Re: draft-ietf-6man-rpl-routing-header-07'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: draft-ietf-6man-rpl-routing-header-07
From:       Mukul Goyal <mukul () uwm ! edu>
Date:       2011-12-23 18:33:04
Message-ID: 1431347815.744466.1324665184537.JavaMail.root () mail17 ! pantherlink ! uwm ! edu
[Download RAW message or body]

If a packet, carrying an SRH, is received over an interface not in RPL domain, it is \
discarded. Thus, an attack may only be mounted within an RPL domain.

Also, a packet, carrying an SRH, cant be sent over an interface not in RPL domain. \
So, any attack can not propagate beyond the RPL domain.

Also, whats wrong with defining RPL domain based on interfaces?

As I mentioned before, using RPL Instance as the scope of SRH is a problem. Rules on \
page 13 are difficult to meet. An RPL router has no idea whether the next hop belongs \
to the particular RPL Instance or not. If the rules are changed so that a router has \
to check if it itself belongs to the particular RPL Instance, that will be a problem \
as well. This is because routers on a source route discovered using P2P-RPL dont \
remember RPL Instance under which the route was discovered. Requiring maintenance of \
state to be part of a source route does not sound like a good idea. 

Thanks
Mukul

----- Original Message -----
From: "Jonathan Hui (johui)" <johui@cisco.com>
To: "robert cragie" <robert.cragie@gridmerge.com>
Cc: "Mukul Goyal" <mukul@uwm.edu>, ipv6@ietf.org, "roll" <roll@ietf.org>
Sent: Friday, December 23, 2011 12:17:18 PM
Subject: Re: draft-ietf-6man-rpl-routing-header-07

To alleviate some of the usual security concerns with source routing, we want to \
limit the scope if where attacks can be initiated.

Any outside attacker can fabricate a SRH and send it to a RPL router.  How do you \
prevent that without some way of limiting the scope?

Also,  Mukul's proposal is to define the scope based on interfaces.  That is not the \
same as limiting the scope to a collection of RPL routers.

--
Jonathan Hui

On Dec 23, 2011, at 10:07 AM, "Robert Cragie" <robert.cragie@gridmerge.com> wrote:

> Hi Jonathan,
> 
> Some comments and questions below.
> 
> Robert
> 
> On 22/12/2011 6:02 PM, Jonathan Hui wrote:
> > On Dec 22, 2011, at 9:24 AM, Mukul Goyal wrote:
> > 
> > > > Again, just because you received a message on an interface for which you've \
> > > > enabled RPL doesn't mean you know the message came from a router that is \
> > > > within the same RPL routing domain.  A router not running RPL could have sent \
> > > > you that message.
> > > A router not running RPL could have sent me a message carrying SRH?
> > Sure.  It could be a host as well.  Part of limiting the scope is to limit the \
> > scope of an attack.  See the Security Considerations.
> <RCC>I'm not getting this. The use of SRH is for non-storing mode, correct? And \
> only for non-storing mode? There is no current definition of partial storing mode \
> and stored mode doesn't need SRH. So the source routes are created on the DAG root \
> based on transit information obtained by DAOs. How can any router outside of the \
> RPL domain initiate a source-routed message to a node in the RPL domain? It would \
> be tunneled at the point it got to the DAG root. Therefore, by implication, \
> normally the source and destination of the message with SRH must be in the RPL \
> domain. So we need to check for exceptions - surely the rules Mukul stated are \
> sufficient?</RCC>
> > 
> > > > From Section 3.2.1 of draft-ietf-roll-rpl:
> > > The Objective Function (OF) defines how RPL nodes select and optimize
> > > routes within a RPL Instance.  The OF is identified by an Objective
> > > Code Point (OCP) within the DIO Configuration option.  An OF defines
> > > how nodes translate one or more metrics and constraints, which are
> > > themselves defined in [I-D.ietf-roll-routing-metrics], into a value
> > > called Rank, which approximates the node's distance from a DODAG
> > > root.  An OF also defines how nodes select parents.  Further details
> > > may be found in Section 14, [I-D.ietf-roll-routing-metrics],
> > > [I-D.ietf-roll-of0], and related companion specifications.
> > > 
> > > > As you state, RPL Instance maps to OF which, from the cited text, maps to \
> > > > metrics and route selection.  By transitivity, RPL Instance ID does map to \
> > > > metrics and how routes are formed.
> > > The text you quoted no where says that an OF maps to particular metric. OF0 is \
> > > metrics-independent. OF1 (draft-ietf-roll-minrank-hysteresis-of-04) applies to \
> > > any additive metric. No RPL doc says that, for a particular LLN, a particular \
> > > OF maps to a particular metric only.
> > Incorrect.  From draft-ietf-roll-routing-metrics-19:
> > 
> > The set of routing metrics and constraints used by an RPL deployment
> > is signaled along the DAG that is built according to the Objective
> > Function (rules governing how to build a DAG) and the routing metrics
> > and constraints are advertised in the DAG Information Option (DIO)
> > message specified in [I-D.ietf-roll-rpl].
> > 
> > In other words, the combination of the OCP and the metrics identified by the \
> > DODAG Root describes how to optimize the routes.  In the case of OF0, the metric \
> > is the Rank itself. 
> > > I think the following text clearly specifies what an RPL Instance is. Also, \
> > > this text clearly says that an RPL Instance ID maps to a particular OF: 
> > > rpl-19 section 3.1.2:
> > > A RPLInstanceID identifies a set of
> > > one or more Destination Oriented DAGs (DODAGs).  A network may
> > > have multiple RPLInstanceIDs, each of which defines an independent
> > > set of DODAGs, which may be optimized for different Objective
> > > Functions (OFs) and/or applications.  The set of DODAGs identified
> > > by a RPLInstanceID is called a RPL Instance.  All DODAGs in the
> > > same RPL Instance use the same OF.
> > > 
> > > This definition says an RPLInstanceID identifies a set of DAGs with a common \
> > > OF. No more and no less. A particular LLN may choose to map an OF to a \
> > > particular metric but there is no such requirement as per RPL specs.
> > You never answered my question.  Why bother having a RPL Instance ID if you don't \
> > care how the routes are optimized?  Why bother maintaining multiple paths \
> > optimized using different OFs and/or metrics?
> <RCC>
> The source route is determined by the transit options, nothing else. There is no \
> processing done at each hop - it simply forwards it to the next based on what's in \
> the SRH. So no need for RPL instance (or domain) there. You could potentially build \
> up multiple tables for each RPL instance but you would just formulate a different \
> SRH based on which table you picked. When it gets to the destination, why would the \
> OF/metric of whatever DAG it happen to transit through have any bearing on where it \
> is subsequently going? I ask this because there is no further information based on \
> the domain it has just gone through. The message originator would not even be aware \
> of any subsequent RPL domains beyond itself; it is bounded by the root and the leaf \
> routers. Unless the destination is on path between the DAG root and a leaf router, \
> an SRH will always go between the DAG root and a leaf router. I find the concept of \
> a partial SRH quite baffling even if it is for the purposes of tracerout
 e - even then at the point it emerges someway down the path, it will return a time \
exceeded error.
> 
> So basically, I am still failing to understand the need to carry RPL instance in \
> the SRH for non-storing mode. I could see its use in partial storing mode whereby \
> SRH carries it part of the way and the stored information on subsequent routers the \
> rest, but in this case surely you would put a RPL option in the inner packet and \
> tunnel? So when it emerges from the source-routed tunnel, it is ready to be \
> forwarded using RPL. <RCC>
> > 
> > > > > RPL Instance is the top level identifier of the DAGs that can be used to \
> > > > > forward the packet. It also maps to a particular OF. In my opinion and as \
> > > > > per RPL spec, RPL instance has no other significance.
> > > > See above.  RPL Instance does map to metrics.
> > > It need not.
> > You are incorrect again!
> > 
> > > > The definition I proposed was simply a collection of routers running RPL \
> > > > under the same administrative domain.  As mentioned above, that does not mean \
> > > > that every router on an interface belongs to a RPL routing domain.
> > > I think the definition you provided is sufficient. An RPL domain is a \
> > > collection of routers running RPL under the same administrative domain. Each \
> > > router in the RPL domain needs to classify all its interfaces regarding whether \
> > > they belong to the RPL domain or not. 
> > > A packet can be assumed to be coming from a router in the RPL domain if it \
> > > carries an SRH.
> > 
> > Nope.  As I stated before, that would invalidate the Security Considerations \
> > section.
> <RCC>I agree with Mukul: in normal circumstances a packet with an SRH will come \
> from a router in the RPL domain and the rules Mukul stated can be used to make sure \
> it doesn't go beyond.</RCC>
> > 
> > --
> > Jonathan Hui
> > 
> > 
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread] 