Re: [secdir] secdir review of draft-ietf-roll-urban-routing-reqs-02

[Tim Winter <[e-mail]>]

Sandra, reviewers,

Please find my additional comments inline.

Thanks,

-Tim



Mischa Dohler wrote:
> Dear Sandra,
>
> Many thanks for having taken your time to read and comment on the
> document. You can find my comments in-line. I would expect that my
> co-authors will also reply asap. (Tim, I think you need to have a look
> at this since it mainly relates to the part written by you. Thanks!)
>
> Thanks and kind regards,
> Mischa.
>
> _____________________________
>
> Dr Mischa Dohler
> Senior Researcher
> CTTC, Barcelona
>
> Tel: [phone]
> Fax: [phone]
> Mob: [phone]
>
> www.cttc.es/home/mdohler
> _____________________________
>
>
>
>
> Sandra Murphy wrote:
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG. These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>
>> The document covers the requirements for routing in low power and
>> lossy networks in urban environments.  It covers the basics of that
>> territory, defining terms and limitations of the networks being
>> considered, and the requirements that produces for routing in that
>> setting.
>>
>>
>> The security considerations section covers the services that one
>> would expect to see covered.  Unfortunately, I was continually
>> confused as to whether the discussion of security requirements was
>> focused on the security of the routing or the security of the data
>> that was being routed.
>
> MISCHA: I am not sure I understand this confusion. We are ultimately
> interested in securing the data. If this involves securing the route,
> the establishment of the route, the maintenance of the route, among
> others, so be it. Generally, since we are dealing with routing specs
> in this document, we have tried to focus the security requirements on
> everything related to routing. However, in the introduction of the
> document, we have possibly alluded to more general security
> considerations too (which is maybe why you got confused).
>
Tim:  In covering the basics of the territory, the document does contain
informative text that goes beyond the specifics of routing
requirements.  The intent is to provide a useful background to the
routing solution designer with regard to the unique nature and
challenges of the Urban LLN scenario.  In this spirit the Security
Considerations section does contain some general informative text, as
cited below, which does refer explicitly to security of data traffic. 
However it is not the intent of such informative text to be interpreted
as security requirements for the routing solution as such.  Where we do
intend to focus on specific considerations that have implications for
security provided by the routing solution we have used the normative
language "MUST", "SHOULD", ...  So it is the intent that whenever such
normative language is encountered within the Security Considerations
section that the reader may interpret this directly as a routing
protocol related security requirement.



>>
>> The following text from the security considerations section is an
>> example:
>>
>>    A secure communication in a wireless network encompasses three main
>>    elements, i.e. confidentiality (encryption of data), integrity
>>    (correctness of data), and authentication (legitimacy of data).
>>
>>    Authentication can e.g. be violated if external sources insert
>>    incorrect data packets; integrity can e.g. be violated if nodes start
>>    to break down and hence commence measuring and relaying data
>>    incorrectly.  Nonetheless, some sensor readings as well as the
>>    actuator control signals need to be confidential.
>>
>> There are concerns in routing protocols about the authenticity and
>> integrity of the contents of the routing protocol messages - the
>> *control* data, not the sensor and actuator data.  A need for
>> confidentiality of the routing protocol message content is not as
>> generally accepted, and this paragraph seems to be considering the
>> confidentiality of the data traffic, not the control traffic.
>
> MISCHA: This section had been written by Tim Winters, so he will be of
> greater help to reply.
Tim:  Please refer above response.  This text is intended as informative
background.



>>
>> Later the focus returns to the security of the routing protocol itself:
>>
>>    The U-LLN MUST be protected against attempts to inject false or
>>    modified packets.  For example, an attacker SHOULD be prevented from
>>    manipulating or disabling the routing function by compromising
>>    routing update messages.  Moreover, it SHOULD NOT be possible to
>>    coerce the network into routing packets which have been modified in
>>    transit.  To this end the routing protocol(s) MUST support message
>>    integrity.
>>
>> The impact on availability of the forwarding service is typically a
>> concern for routing protocols and is not mentioned here.  Can routing
>> produce a data traffic forwarding path that loops?  Can the routing
>> protocol be subverted to the point that routing protocol messages are
>> consuming the available resources?  Etc.
>
> MISCHA: I am confused in how your text relates to our text cited
> above. Are you proposing additions or modifications, or is it just a
> list of loose comments? Tim, maybe you should add a paragraph covering
> these comments ...
Tim:  The above cited text is addressing the ability of an attacker to
actively `hijack' the routing protocol.  The paragraph following the
cited paragraph does offer some consideration of denial of service
attacks in general:
          Other important issues may arise in the context of Denial of
Service (DoS)
          attacks, malicious address space allocations, advertisement of
          variable addresses, a wrong neighborhood, external attacks
aimed at
          injecting dummy traffic to drain the network power, etc.

Perhaps we could add to this following paragraph a sentence to clarify
the requirement, e.g.:
          "The routing protocol(s) MUST support defense against DoS
attacks and other attempts to cause the routing protocol(s) mechanisms
to maliciously consume the limited resources of LLN nodes, e.g. by
constructing forwarding loops or causing excessive routing protocol
overhead traffic, etc."



>>
>>                     Mechanisms MUST be in place to deny any rogue node
>>    which attempts to take advantage of self-configuration and self-
>>    organization procedures.  Such attacks may attempt, for example, to
>>    cause denial of service, drain the energy of power constrained
>>    devices, or to hijack the routing mechanism.  A node MUST
>>    authenticate itself to a trusted node that is already associated with
>>    the U-LLN before any self-configuration or self-organization is
>>    allowed to proceed.
>>
>>
>> This seems to be addressing the possibility of a legitimate node
>> behaving badly.  But the requirement that a node must authenticate
>> itself only prevents bad behavior from outsiders, not insiders.  
>
> MISCHA: In my understanding, this is what you can do with
> authentication. Other mechanisms are needed to cover the case you
> mentioned, even though it is a marginal scenario in my opinion.
Tim: Yes, here we are explicitly concerned with outsiders, i.e. a node
who is unable to authenticate to the network.  With regard to poorly
behaved inside nodes, we do have the previously mentioned discussion
regarding Denial of Service attacks via manipulation of the routing
protocol(s), and we do describe some considerations to be given nodes
that may demonstrate egoistic conduct.



> Further
>> comment - self-organization and self-configuration had previously
>> referred to configuration or organization of a network, not a single
>> node.  Does this mean that a node must authenticate before it can
>> participate in the network self-organization?  And of course the
>> chicken-and-egg problem - before the network has self-organized, how
>> can the nodes reach a trusted node. 
>
> MISCHA: Yes, indeed, it is advantageous that a node authenticates
> first and then takes part in the organization process. Several
> authentication attempts are of course needed until each node reaches
> an authenticated node or is in its one-hop neighborhood, but this
> seems to be part of the game to facilitate a secure network.
>
> Must *every* node authenticate before
>> self-organization can proceed?  Or does self-organization spread
>> outwards incrementally from the trusted node?
>>
>
> MISCHA: The former and the latter are not exclusive to me - I am not
> sure I understood correctly.
>
Tim:  Perhaps it is instructive to think of the network as `growing'
around a seed router.  The processes of self-organization may be
periodically (or continuously) invoked, e.g. as a normal procedure of
the network to respond to changes in topology, appearance and removal of
nodes, etc.  The chicken-and-egg problem can be resolved then thusly: 
Consider that a trusted authenticated (to some entity with authority to
manage the network) access router (LBR) is deployed.  Subsequently nodes
within range of the LBR may authenticate and engage in a process of
autonomous self-configuration and self-organization, yielding a network
segment that now includes the LBR and a handful of authenticated (i.e.
trusted) nodes.  The envelope of trust may now be extended to nodes that
are able to directly communicate with the LBR.  As the network grows the
self-organization mechanisms can take into account the topology of the
trusted nodes.
It is not necessarily the case, e.g. that all nodes must first become
known and authenticated before self organization can proceed.  So as
unauthenticated nodes encounter the boundary of a network that the wish
to join, that network should already have established the degree of
self-organization necessary to at least authenticate the new node, and
subsequently allow the node to begin participation (and consume the
resources of the network required) in self-configuration and
self-organization processes.



>>
>>    With low computation power and scarce energy resources, U-LLNs nodes
>>    may not be able to resist any attack from high-power malicious nodes
>>    (e.g. laptops and strong radios).  However, the amount of damage
>>    generated to the whole network SHOULD be commensurate with the number
>>    of nodes physically compromised.  For example, an intruder taking
>>    control over a single node SHOULD not have total access to, or be
>>    able to completely deny service to the whole network.
>>
>> If a taken-over node does not have access to the whole network, how
>> could it have had access to the whole network before being taken
>> over? Subverted nodes generally are assumed to retain all their
>> abilities, which is why they are such a problem.  This seems to be
>> requiring that no one node ever has access to the whole network.
>
> MISCHA: Good point! Tim, I think you should only leave the reference
> to "completely deny service to the whole network".
>
Tim:  I do agree.  The subverted node can be expected to have access...
but should not be able to misbehave to a point where the network as a
whole is in jeopardy.  This observation is in the same spirit as the
prior comments on Denial of Service and misbehaving insiders.

The proposed revision would then read:
          "For example, an intruder taking control over a single node
SHOULD not be able to completely deny service to the whole network."



>>
>>
>> In the rest of the document:
>>
>> Routers are introduced, including the special category of LBR -
>>    Some routers provide access to wider infrastructures, such as the
>>    Internet, and are named Low power and lossy network Border Routers
>>    (LBRs) in that context.
>> However, in the remainder of the document, the text refers to LBRs
>> everywhere in places where it sounds like they are referring to
>> routers. Are all routers LBRs?  Do the discussions of LBRs not apply
>> to interior routers?
>>
>> There are references to "node" forwarding traffic in some places. 
>> Are all such nodes routers, or do sensors and actuators sometimes
>> forward traffic? E.g.,
>>
>>                                                                       A
>>    node must be able to send its own alerts toward an LBR while
>>    continuing to forward traffic on behalf of other devices who are also
>>    experiencing an alert condition.
>
> MISCHA: The abilities of above elements have been clearly defined in
> Sections 3.1.1.-3.1.3. Tim, please, check that we have not over-abused
> the term LBR.
>
Tim: To clarify, sensors and actuators are capable of forwarding
traffic.  LBR's are a special case of a router, as further described in
the terminology I-D draft-ietf-roll-terminology-00.  In the context of
U-LLN applications, interior routers are somewhat anonymous while LBRs
have some additional application significance.  Many application traffic
flows will source or sink at an LBR.  Many U-LLN applications will
interact with some other application co-located at or hosted beyond the
LBR.  As such, establishing how to forward traffic to the LBR from an
interior node, or vice versa, becomes a common task for the routing
protocol.
Upon review, I find that the used of `LBR' is applied consistently in
contexts where the document is discussing application specific traffic
flows and related routing implications.  In these contexts it is
appropriate to explicitly refer to the LBR as opposed to an anonymous
interior router.



>>
>> In the following text:
>>
>>    Routing within urban sensor networks SHOULD require the U-LLN nodes
>>    to dynamically compute, select and install different paths towards a
>>    same destination, depending on the nature of the traffic.  From this
>>    perspective, such nodes SHOULD inspect the contents of traffic
>>    payload for making routing and forwarding decisions: for example, the
>>    analysis of traffic payload should encourage the enforcement of
>>    forwarding policies based upon aggregation capabilities for the sake
>>    of efficiency.
>>
>> If data needs to be confidential, as mentioned in the security
>> considerations section, then the data would have to be protected hop
>> by hop, with each router/node decrypting and re-encrypting as it
>> forwarded the data, if the router/node is to inspect the contents. 
>> Is this intended?
>
> MISCHA: There is indeed a problem here, as had also been highlighted
> by Phil when he mentioned that data aggregation breaks the end-to-end
> paradigm. I am not sure what to respond here. I guess, yes, one would
> need to decrypt/re-encrypt at each hop, even though other solutions
> keep popping into my mind. Christian? Tim?
>
>
Tim:  This is a correct observation- if data are kept confidential
hop-by-hop then there is some implication as to how aggregation would
have to be performed.  This implication was similarly brought out in
Brian Carpenter's Gen-ART LC review, and I will address it further in
that response.



_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir