> Saku Ytti > Sent: Thursday, January 3, 2019 8:53 PM > > On Thu, 3 Jan 2019 at 22:50, Anderson, Charles R <[email protected]> wrote: > > > Thanks. I assume the same problem exists if you have VRF loopback > > interfaces inside the VPN as well (e.g. OSPF router-id loopbacks for > > the customer's VPN). So the idea is to restrict the destinations to > > ones that will never exist inside a customer-visible VRF. > > Correct. I think alternative solution is to have lo0 interface for every VRF, I've > not tested, but JunOS should consider that filter instead of main table lo0 > filter if defined. > Also in addition to the lengthy, complex and therefore often misconfigured RE filter a good practice is to have iACLs as a second layer of defence. By that I mean a policy applied on all edge interfaces allowing only selected protocols (e.g. ICMP & BGP) to talk to any of your edge addresses (reachable form a particular VRF) and deny anything else destined to these or your internal infrastructure addresses. Such filters would mitigate the attack vector mentioned above.
Oh and uRPF to not allow customers to spoof their addresses -especially for customers in internet VRF... adam _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
