Re: [Roll] Security Considerations for useofrplinfo draft

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Ines

Please see below:

I used

  *   To make my comments


All the best,

Pascal

From: Ines Robles <[e-mail]>
Sent: mercredi 30 janvier 2019 21:55
To: roll <[e-mail]>
Cc: Michael Richardson <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>
Subject: Security Considerations for useofrplinfo draft

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?



  *   There is an L2 authentication in most any cases. But if a rogue manages to get in then many attacks are possible – there is no zero trust. This is just one. Another is sending DAOs on behalf of the device.
  *   What can be done to alleviate this particular attack is SAVI, using RFC 8505 + https://tools.ietf.org/html/draft-ietf-6lo-ap-nd. The rogue will not be able to source with an address that is not registered, and the registration checks for topological correctness.


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.


  *   Same answer as above for an attack originated inside the network. For an attack originated outside, IP in IP can be used to hide inner routing headers, but RH3 is protected by its definition. Otherwise, e.g., DoS, IP in IP seems of little value.

   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.


  *   The rule of RH3 only allows strict source route operation. This is true even if an IP in IP hides an inner RH3. This does not constitute a breach. Note that IP in IP in IP in IP could be a breach that reproduces the problem of a RH0. But then, that is general to all IPv6 and not specific to this document



   Thank you very much in advance,

The authors.