BCP 38 addendum

Wed Mar 7 19:56:53 UTC 2018

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 at 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 at 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
_ at beufanet_

-- 
FABIEN VINCENT
_ at beufanet_