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 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 <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
