[Roll] Security Considerations for useofrplinfo draft

[Ines Robles <[e-mail]>]

Dear all,

Please, we would like to have your opinion to address the following major
comments/questions:

Ticket: 191 https://trac.ietf.org/trac/roll/ticket/191

"Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an
   attack on another part of the LLN, while disguising the origin of the
   attack.  The mechanism can even be abused to make it appear that the
   attack is coming from outside the LLN, and unless countered, this
   could be used to mount a Distributed Denial Of Service attack upon nodes
elsewhere in the Internet.  See [DDOS-KREBS] for an example of
   such attacks already seen in the real world."

   [major] Is there any possible mitigation to this inside-the-LLN attack?
   Would authentication help -- is it even possible?


Ticket 192: https://trac.ietf.org/trac/roll/ticket/192

   " Blocking or careful filtering of IPv6-in-IPv6 traffic entering the
   LLN as described above will make sure that any attack that is mounted
   must originate from compromised nodes within the LLN.  The use of
   BCP38 filtering at the RPL root on egress traffic will both alert the
   operator to the existence of the attack, as well as drop the attack
   traffic.  As the RPL network is typically numbered from a single
   prefix, which is itself assigned by RPL, BCP38 filtering involves a
   single prefix comparison and should be trivial to automatically
   configure."

   [major] BCP38 will stop an attack, but only if the source addresses are
spoofed.  What if they're not?  Given that the attack may be hidden, and
assuming that nodes are compromised across multiple LLNs, an attacker may
not care enough to spoof the origins.

   Ticket 193: https://trac.ietf.org/trac/roll/ticket/193

   "The RH3 header usage described here can be abused in equivalent ways
   with an IPv6-in-IPv6 header to add the needed RH3 header.  As such,
   the attacker's RH3 header will not be seen by the network until it
   reaches the end host, which will decapsulate it.  An end-host SHOULD
   be suspicious about a RH3 header which has additional hops which have
   not yet been processed, and SHOULD ignore such a second RH3 header."

   [major] What does "SHOULD be suspicious" mean?  How is that a Normative
behavior?  Would being suspicious include dropping the packet or some other
similar action?  When would the router *not* be suspicious?  Why is that
not a "MUST"?

   The presence of the second RH3 means that there is a configuration
mistake somewhere else in the network.  It would be reasonable to increment
a counter in a MIB (if we had a MIB) when this occurs.  Based upon the
Postel doctrine, ignoring the extra header (not acting on it), is the best
policy. An RH3 header was not completely consumed is discussed in RFC

   https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header
with additional “non-zero Segments Left value, if the IPv6 Destination
Address is not on-link” should be dropped.  In this case, the RH3 header is
*inside* the outer IPv6-in-IPv6 header, which has then been forwarded.
   We think that this header should simply be ignored in processing the
packet.  To do otherwise (such as forwarding) would permit external
attackers to send traffic that appears to originate inside the LLN.

   What do you think?



   Thank you very much in advance,

The authors.