Le 2018-03-06 19:39, Barry Greene a écrit :
On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) <list-nanog@beufa.net> wrote: Hope one day the 3rd mode of uRPF will be something else than a plan ... uRPF is not very usefull when multi homed. And as far as I know, multi homed networks are increasing as fast as PNI development ;)
This was working microcode code when I left in 2008. Several operators tested, but none deployed (no pushing or pulling).
Yep, but saw only reference of it, but no real CLI implementation (especially on Cisco), so I guess it's not a killer feature to sell routers ;) In 2005 : https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf "A third phase is currently under way that will create a way to have strict enforcement of the uRPF check on individual ISP-ISP edges. Here, external BGP (eBGP) peer sessions will send specific prefixes to a dedicated Virtual routing and forwarding (VRF) table. This will allow uRPF to query the VRF table that contains all the routes for that specific eBGP peering session over the interface, thus verifying (authorizing) the source addresses of packets matching the advertised routes from the peered ISP" That's obviously not so sexy, but I guess the problem is on hardware performance, as the prefer method should to have a look on BGP tables, and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ? -- FABIEN VINCENT _@beufanet_
Hey, How would this work? ISP1--ISP2---ISP3 | | +-------ISP4-----+ In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4 - ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out via ISP4 ISP1 will receive traffic from ISP3 through ISP2, and that is not in the eBGP session, so prefix gets dropped. Internet is symmetric and people don't advertise consistently, so while maybe undesirable above stuff does happen. It's not obvious to me what this eBGP-routes-in-VRF and RPF-to-VRF would solve, which use case does it address which is not addressed by existing tooling. There is much cheaper feature which has worked for decades which applies better to this problem. While you generate list of prefixes ISP2 COULD announce to you, that includes the prefix ISP3 is NOT announcing, but COULD. The same prefix-list you use for BGP announcements use in your ACL. On 6 March 2018 at 23:16, Fabien VINCENT (NaNOG) <list-nanog@beufa.net> wrote:
Le 2018-03-06 19:39, Barry Greene a écrit :
On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) <list-nanog@beufa.net> wrote: Hope one day the 3rd mode of uRPF will be something else than a plan ... uRPF is not very usefull when multi homed. And as far as I know, multi homed networks are increasing as fast as PNI development ;)
This was working microcode code when I left in 2008. Several operators tested, but none deployed (no pushing or pulling).
Yep, but saw only reference of it, but no real CLI implementation (especially on Cisco), so I guess it's not a killer feature to sell routers ;)
In 2005 : https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf
"A third phase is currently under way that will create a way to have strict enforcement of the uRPF check on individual ISP-ISP edges. Here, external BGP (eBGP) peer sessions will send specific prefixes to a dedicated Virtual routing and forwarding (VRF) table. This will allow uRPF to query the VRF table that contains all the routes for that specific eBGP peering session over the interface, thus verifying (authorizing) the source addresses of packets matching the advertised routes from the peered ISP"
That's obviously not so sexy, but I guess the problem is on hardware performance, as the prefer method should to have a look on BGP tables, and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ?
-- FABIEN VINCENT _@beufanet_
-- ++ytti
Le 2018-03-07 16:19, Saku Ytti a écrit :
Hey,
How would this work?
ISP1--ISP2---ISP3 | | +-------ISP4-----+
In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4
- ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out via ISP4
ISP1 will receive traffic from ISP3 through ISP2, and that is not in the eBGP session, so prefix gets dropped.
Internet is symmetric and people don't advertise consistently, so while maybe undesirable above stuff does happen. It's not obvious to me what this eBGP-routes-in-VRF and RPF-to-VRF would solve, which use case does it address which is not addressed by existing tooling.
Internet is not symmetric ;) My problem is more simple : I'm multihomed, so I cannot use uRPF strict mode, because my traffic is not symetric. Prepend can help, but that obviously not the way of doing TE for inbound traffic, expect if you love crappy design or you multihomed is just under 10 peerings. Loose mode is not useful, because of so many parameters, default route, local-pref / med inside the network, which lead to asymetrical path. So routes not inserted in FIB. So uRPF strict mode not possible. But in loose mode, because even Tier1 are not doing any BCP 38 filters (tested and verified for all least 3 Tier1), ACL or prefix list (that's not the point of BGP hijack here), I received UDP spoofed traffic from routes I don't learned on this port. By in case my router has 2 ports, one with Level3, one with Cogent, uRPF loose mode will look at the FIB (so for all ports), not one where the packet is coming from and the BGP table facing this port + BGP table. This is exactly my idea : why should I allowed uRPF passing traffic from routes not learned on this port ?? Why if I have Cogent + Level3 and I denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get spoofed traffic from Level3 ranges over Cogent peering port ? That's just silly this kind of mode doesn't exist in uRPF ... I'm aware it's due to hardware limitation, because uRPF look into FIB, not BGP Table or RIB, but that could help denying spoofed traffic that comes over transit tier 1 because the BCP38 to the downstreams are not in place, or not automatic (I'm still thinking why Level3 as an IRR and do use it for filtering downstreams ...)
There is much cheaper feature which has worked for decades which applies better to this problem. While you generate list of prefixes ISP2 COULD announce to you, that includes the prefix ISP3 is NOT announcing, but COULD. The same prefix-list you use for BGP announcements use in your ACL.
Yeah agreee, but not usable and programmable regarding huge upstreams values (over 100, I know hw even for smaller values that will say "my ASIC is limited man").
On 6 March 2018 at 23:16, Fabien VINCENT (NaNOG) <list-nanog@beufa.net> wrote: Le 2018-03-06 19:39, Barry Greene a écrit :
On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) <list-nanog@beufa.net> wrote: Hope one day the 3rd mode of uRPF will be something else than a plan ... uRPF is not very usefull when multi homed. And as far as I know, multi homed networks are increasing as fast as PNI development ;) This was working microcode code when I left in 2008. Several operators tested, but none deployed (no pushing or pulling).
Yep, but saw only reference of it, but no real CLI implementation (especially on Cisco), so I guess it's not a killer feature to sell routers ;) In 2005 : https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf "A third phase is currently under way that will create a way to have strict enforcement of the uRPF check on individual ISP-ISP edges. Here, external BGP (eBGP) peer sessions will send specific prefixes to a dedicated Virtual routing and forwarding (VRF) table. This will allow uRPF to query the VRF table that contains all the routes for that specific eBGP peering session over the interface, thus verifying (authorizing) the source addresses of packets matching the advertised routes from the peered ISP" That's obviously not so sexy, but I guess the problem is on hardware performance, as the prefer method should to have a look on BGP tables, and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ? -- FABIEN VINCENT _@beufanet_ -- FABIEN VINCENT _@beufanet_
Hey,
This is exactly my idea : why should I allowed uRPF passing traffic from routes not learned on this port ?? Why if I have Cogent + Level3 and I denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get spoofed traffic from Level3 ranges over Cogent peering port ? That's just silly this kind of mode doesn't exist in uRPF ...
I'm aware it's due to hardware limitation, because uRPF look into FIB, not BGP Table or RIB, but that could help denying spoofed traffic that comes over transit tier 1 because the BCP38 to the downstreams are not in place, or not automatic (I'm still thinking why Level3 as an IRR and do use it for filtering downstreams ...)
I'm not at all sure what you are trying to say, but in many platforms you can write 'hints' to HW based on BGP communities or AS PATH and then use these 'hints' in ACL. Simplified view could be that you're matching AS_PATH on ACL. However if I understood your scenario right, I don't think what you propose is fixing any spoofing issues in your scenario. Only antispooffing that makes sense towards your transit provider is dropping your own source addresses. Some vendors also support 'strict feasible' which is essentially RIB instead of FIB match (But technically obviously not RIB, it's just HW gets more information about 'feasible' paths).
There is much cheaper feature which has worked for decades which applies better to this problem. While you generate list of prefixes ISP2 COULD announce to you, that includes the prefix ISP3 is NOT announcing, but COULD. The same prefix-list you use for BGP announcements use in your ACL.
Yeah agreee, but not usable and programmable regarding huge upstreams values (over 100, I know hw even for smaller values that will say "my ASIC is limited man").
Similarly it's easy to find device which can't hold DFZ in FIB, but you wouldn't buy that device as your edge box. Usually the really cheap and dense boxes are not edge capable anyhow, due to poor control-plane protection, and all proper edge boxes have large ACLs, in what I view perfectly affordable prices from Juniper, Nokia, Huawei and Cisco. Maybe 20-30k for few 100GE and what have you, likely not significant 5 year TCO on the actual company wide bottom line. -- ++ytti
I have a router that takes a long time to converge after reboot. To fix that I do not want to advertise my prefixes until the router is fully ready. But I still want to establish the BGP sessions otherwise the router will never be ready. So we program in a delay until advertising after BGP session established. Now if my peers automatically converted BGP announced prefixes into ACLs, they would blackhole any traffic that might come to this router during startup. This is obviously not good. BGP announced prefixes tells you what I can receive but not what I can send. Interpreting that any other way is abusing the protocol. You would need a new BGP extension so we could announce what we might send independent of what we want to receive. IRR generated ACL filters might work if agreeable by the peer. Regards Baldur
participants (3)
-
Baldur Norddahl -
Fabien VINCENT (NaNOG) -
Saku Ytti