Re: [Roll] draft-ietf-6man-rpl-routing-header-07

[Mukul Goyal <[e-mail]>]

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)" <[e-mail]>
To: "robert cragie" <[e-mail]>
Cc: "Mukul Goyal" <[e-mail]>, [e-mail], "roll" <[e-mail]>
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" <[e-mail]> 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 traceroute - 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
>> 
>> 
>