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.cra...@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 --------------------------------------------------------------------
