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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
