On 07/04/2017 07:05, Toerless Eckert wrote: > 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 ? ;-))
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. > > 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. 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? > When using the default ACP profile of RPL in the ACP (see section ....), > IPv6-in-IPv6 > encapsulation is not required by RPL. Therefore, we aren't configured to deal with it. > 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. 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. > > 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 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 > - 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 > > On Wed, Apr 05, 2017 at 03:25:02PM -0400, Michael Richardson wrote: >> >> 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 protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > > >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
