Subject: [Anima] use of RPL info security considerations and ANIMA use of RPL

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Apr 2017 15:25:02 -0400

This document has past WGLC, and is in Shepherd process.
I call attention to the Security Considerations of using IPIP headers,
as I reference ANIMA's ACP document.
Generally, I expect there to be a VRF-style "firewall" between the ACP
and the production network, with the ACP operating essentially as
a non-connected network (using ULAs).

There is still a concern that big iron could be exploited to send DDoS
attacks against other parts of the ISP; but at least IPIP headers won't make
this worse.  And given ULAs, and BCP38, the ACP can't be used to attack
other parts of the Internet.  Or perhaps, if the device is sufficiently
compromised to originate such an attack, they could just use the
production interfaces.

https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-10&url2=draft-ietf-roll-useofrplinfo-14

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 6 Apr 2017 21:05:27 +0200

Thanks Michael

A) One aside question for curiosity. The doc is stating :

 ...IPv6 architecture as outlined in [RFC2460].  Extensions may not be added or removed
 except by the sender or the receiver

Is this actually stated anywhere in RFC2460 ? I could not find it. RFC7045 says:

  There was no provision for forwarding nodes to modify them, remove them, insert them,
  or use them to affect forwarding behaviour.

"There was no provision" is not the same as "it is not permitted by the architecture".
A place where only explicitly enumerated options are legal is kinda... oppressive ? ;-))

B) Wrt to the core problem

- The ACP draft should get text to explain how it should protect itself against
  IP-in-IP packet attacks. 

  Agreed ?

  Suggested text for the "security considerations" section:

  The ACL uses RPL as its routing protocol. RPL may leverage IPv6-in-IPv6 encapsulation. 
  Forged RPL IPv6-in-IPv6 packets are a candidate attack against ACP nodes. See also
  [draft-ietf-roll-useofrplinfo].

  Unless RPL for the ACP or any future ACP mechanism do require reception and processing
  of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6-to-IPv6 packet targeted
  to their ACP address.

  When using the default ACP profile of RPL in the ACP (see section ....), IPv6-in-IPv6
  encapsulation is not required by RPL.

  When reception/processing of IPv6-in-IPv6 packets is required for RPL, only
  IPv6-in-IPv6 packets with an ACP address from the same autonomic domain should be
  accepted.

  See also [draft-ietf-roll-useofrplinfo]

--  Also:

  If the ACP can not trust an ASA to not behave malicious or to be disruptive malfunctioning
  traffic from an ASA into the ACP should be filtered such that only known necessary traffic
  for that ASA should be permitted into the ACP.

- I hope that pointing to your draft and the paragraphs about "ASAs behaving badly"
  is sufficient to score ACP the "good neighbor" medal. If not, i welcome any additional
  suggestions.

If no feedback received, suggested text will be in ACP-07 ;-)

Cheers
   Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Apr 2017 08:37:51 +1200

> A place where only explicitly enumerated options are legal is kinda... oppressive ? ;-))

This is an ultra-hot topic in 6man, but the current text of 2460bis, accepted by the AD
and probably going soon to the IESG, is very clear: no dynamic insertions or deletions
of headers. This was definitely the intention of the authors (for which I can refer
you to email from Steve Deering in 1995). Long story, probably 500 emails on this
topic over the last few years, since the segment routing people decided they wanted
to insert headers.

It's not over yet. "Insertion of IPv6 Segment Routing Headers in a Controlled Domain"
(draft-voyer-6man-extension-header-insertion) may develop into something and *would*
be applicable to the ACP. But for now, header insertion is not an option.

>   of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6-to-IPv6 packet targeted

I'm still not clear what the attack is. This rule seems to be saying "don't act as a
protocol 41 tunnel end point by default." But who would do that anyway? If you aren't
configured as a tunnel end point, protocol 41 is /dev/null. If you are configured
as a tunnel end point, you know what to do with the packet by definition. Don't act
as a GRE end point by default either. In fact, if you get any packet you don't understand,
drop it.

What are we saying here that's new?
 
>   encapsulation is not required by RPL.

Therefore, we aren't configured to deal with it.
 
>   IPv6-in-IPv6 packets with an ACP address from the same autonomic domain should be

Yes. But it does seem a bit obvious, frankly. Also, I can't imagine a use case.
I can imagine a use case where packets addressed from and to an ACP address arrive
encapsulated in a non-ACP packet, because we are connecting two ACP clouds
over a non-ACP tunnel, but in that case the tunnel end point will not be visible
in the ACP VRF anyway.

>   for that ASA should be permitted into the ACP.

I don't know how to turn that into software. Also, we have explicitly punted on ASA
authorization so far. (This is why I put register_asa() in the GRASP API, to provide
a hook where we can add authorization. But even that will tell us nothing about the
ASA's traffic profile. You could conceivably require that all ASA traffic is GRASP
traffic, but that seems like (a) an annoying restriction and (b) means including
CBOR and GRASP parsing into the ACP filtering code.

So I think this a non-starter.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Apr 2017 17:22:48 -0400

> Is this actually stated anywhere in RFC2460 ? I could not find

Yes, unclearly.  Subject to rfc2460bis being returned to the 6man WG to make
sure that the text is clearer.

    > - The ACP draft should get text to explain how it should protect itself against

Yes.

    > of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6-to-IPv6 packet targeted

That's not enough. An attacker could just send frames at the router
targetting an ACP address via a normal port.

It's that the ACP routers should run the ACP in a VRF, and SHOULD NOT
exchange traffic with other VRFs, including "The Internet"

    > encapsulation is not required by RPL.

So, we are going to run in storing mode, so we never need RH3 headers.
If all senders (including nodes in the NOC which do not speak ACP...) include
RPI headers (which is used for loop-detection), then all is well. Otherwise,
we have to insert RPI HbH headers, which requires an IPIP header.

    > IPv6-in-IPv6 packets with an ACP address from the same autonomic domain should be

yes.

    > is sufficient to score ACP the "good neighbor" medal. If not, i welcome any additional

Yes, I think so.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Apr 2017 17:31:43 -0400

> as a GRE end point by default either. In fact, if you get any packet you don't understand,

Because we have to insert RPI header with an IPIP header, that means that
every RPL router node needs to be will to accept IPIP packets addressed to
it.   It should find IPouter.dst = ME, and IPinner.dst = ME.
(with IPouter.src being the device that inserted the IPIP header,
and IPinner.src being the original source of the packet).

*IF* the ACP router has some "clients" (i.e. VMs inside it), it may want
to do IPIP encap/decap for the client machines.

    > over a non-ACP tunnel, but in that case the tunnel end point will not be visible

Agreed.
The point in the security considerations is to make it really clear that
traffic should not pass via the ACP to the Internet.

Imagine a compromised machine (a desktop in the NOC!!!) that can send IPIP
traffic via the ACP to a backbone router, which will then decapsulate it
(ignoring our words), and sending it out to the Internet at 100Gb/s speeds?
This is the issue that I want to make sure the "considerations" point out.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Apr 2017 10:04:21 +1200

Comment at the end..

> This is the issue that I want to make sure the "considerations" point out.

Absolutely. And it could be a BYOD in the NOC that manages to join the ACP,
even. We really do need to tackle node and ASA authorization in Phase 2.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 7 Apr 2017 00:12:27 +0200

> sure that the text is clearer.

(P)roblem (o)f (o)ther (p)eople ;-)

> exchange traffic with other VRFs, including "The Internet"

Puuh... first you sneak in the RPL finger, now you want me to give you the whole
security arm... sure ;-). How about this:

To maintain the desired traffic isolation of the ACP, the VRF used for the ACP MUST be
set up so that no traffic can be exchanged with other VRF.  Configuration in other VRFs
(such as extranet route configuration) must not allow to change this.

> we have to insert RPI HbH headers, which requires an IPIP header.

Hmm.. in the implementations i have seen, i do not think RPI headers where used
by senders. And that seemed to be working fine. Is it a MUST ? If so which section/rfc ?

>     > is sufficient to score ACP the "good neighbor" medal. If not, i welcome any additional

Thanks!
    Toerless

-- 
---
[email-masked]