Re: BCP 38 addendum

[Saku Ytti <saku () ytti fi>]

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