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

From: Sandra Murphy <[email-masked]>
Date: Thu, 4 Dec 2008 11:01:24 -0500 (Eastern Standard Time)

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.

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.

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.

                     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.  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.  Must *every* node authenticate before self-organization can 
proceed?  Or does self-organization spread outwards incrementally from the 
trusted node?

    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.

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.

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?
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Mischa Dohler <[email-masked]>
Date: Sat, 13 Dec 2008 16:19:13 +0100

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: +34 93 645 2900
Fax: +34 93 645 2901
Mob: +34 6 7909 4007

www.cttc.es/home/mdohler
_____________________________

Sandra Murphy wrote:
> 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.
> 

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).

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

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

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

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.

> 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".

> 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

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.

> 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?

---

From: Tim Winter <[email-masked]>
Date: Sat, 13 Dec 2008 16:30:44 -0500

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

> MISCHA: This section had been written by Tim Winters, so he will be of
Tim:  Please refer above response.  This text is intended as informative
background.

> 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."

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

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

>> 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."

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

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

---

From: Mischa Dohler <[email-masked]>
Date: Sun, 14 Dec 2008 10:20:18 +0100

Sandra, we will also have a separate security document some when in Q1 2009 which shall cover more or less everything you alluded to below. Regards, Mischa.

---

From: <[email-masked]>
Date: Fri, 19 Dec 2008 22:00:57 +0100

Hello Sandra,

On behalf of the authors of draft-ietf-roll-urban-routing-reqs-02.txt, we would like to thank you again for your comments.
Please find attached our response to them, along with the proposed new text for the draft and a diff file highlighting the changes.
Should you consider that the corrections do adequately answer your concerns, please let us know and we'll move the new text to become the working group next version of the document.
If they don't answer your concerns, can you please let us know of your remaining comments at your earliest convenience?
With best regards

Dominique 

-----Message d'origine-----
De : Sandra Murphy [mailto:[email-masked]] 
Envoyé : jeudi 4 décembre 2008 17:01
À : [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; BARTHEL Dominique RD-TECH-GRE; JACQUENET Christian ROSI-ITNPS-NAD-TIP
Objet : secdir review of draft-ietf-roll-urban-routing-reqs-02

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.

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.

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.

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.  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.  Must *every* node authenticate before self-organization can proceed?  Or does self-organization spread outwards incrementally from the trusted node?

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.

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

In the following text:

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?
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir