Re: [Roll] Security Considerations for useofrplinfo draft

[Ines Robles <[e-mail]>]

Thank you very much Pascal

On Tue, Feb 5, 2019 at 2:52 PM Pascal Thubert (pthubert) <[e-mail]>
wrote:

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