[oops. resending with fixed address for pascal] Adding Pascal explicity because i may be confused about various RPL things here:
I may be wrong, but it looks to me as if MichaelRs comments and reference to this new draft about RPL IPinIP header stuff makes it sound as if we MUST somehow support these IPinIP headers in ACP: https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-10&url2=draft-ietf-roll-useofrplinfo-14 Also, during the last IETF, i think MichaelR said something to the extend that the "profile" defined for RPL via the latest -06 version should rather go into some form of RPL profile draft.... But if i remember correctly, Pascal told me there is no such "RPPL profile" draft format. When i discussed with Pascal, he reconfirmed to me that the approach/profile choosen for RPL in the Cisco IOS implementation of ACP should be perfetly RPL standards compliant - and it does not do any IPinIP header extensions. This is something i would prefer as the mandatory minimum ACP requirements because i am fearful of asking all type of equipment to support RPL routing protocol specific IPinIP header processing. I am not even sure if i could today expect to get this IPinIP header processing in all linux that i might expect on native ANI devices, but given how we're unlikely allowed for some intervening device to insert/delete those headers, the use of IPinIP headers would eliminate the option to easily set up extensions ("autonomic connect") to the ACP in a NOC - into pre-existing management devices with the "What The F**K is RPL" TCP/IP stack. Not using IPinIP headers does of course come at the limitation of - if i understand it correctly - a single instance with a single (active) root. As long as we can have automatic root election so that we have root redundancy, i think this is a sufficient minimum functionality for ACP. It would be great to bring in as much as possible of that IPinIP support via SHOULD, but i am not 100% clear how this can be done: - It seems to be easy to make IPinIP support SHOULD for endpoints. Such an endpoint could only use the default instance/root of RPL. Right ? - It is less clear to me if/how its possible to introduce partial support for IPinIP on transit nodes. I am hping that RPL can automatically figure out that additional instances/dodags can only work across paths where all transit nodes support IPinIP. Then the problem is solved. If this si something RPL can not singnal, then it seems as if a transit node without IPinIP support would kill non-default instance/transit paths. - I am very interested to make non IPinIP capable transit nodes sufficient for MUST ACP requirements because i am quite sure that a relevant part of HW accelerated forwarding engines will not support IPinIP routing, so any mandatory introduction of IPinIP would kill HW acceleration for ACP. Which IMHO would make me ask to rethink the choice of ACP default routing protocol. So... Q1: Do we agree on this direction ? Q2: How can we finalize the sufficient/necessary text mods to ACP to express this ? (profile definition etc..) Thanks a lot! Toerless On Fri, Apr 07, 2017 at 10:04:21AM +1200, Brian E Carpenter wrote: > Comment at the end.. > > On 07/04/2017 09:31, Michael Richardson wrote: > > > > Brian E Carpenter <[email protected]> wrote: > > >> 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. > > > > 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. > > > > >> 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. > > > > 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. > > 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
