Moin, Thanks, will pick this up as stated; Created a ticket for it for now.
With best regards, Tobias On Wed, 2024-02-28 at 15:34 +0100, Martin Pels wrote: > Hi, > > On 26/10/2023 15:10, Tobias Fiebig wrote: > > [..] > > > > > The global limits seem to offer no real benefit in addition to > > > per-session limits. The referenced paper mentions Per-Origin AS > > > limits, not the per-Neighbor AS limits mentioned in the draft. > > > This > > > also seems to be unimplementable, given that routers act > > > independently on prefixes they receive. > > > > I think there are two points in here: > > - The paper mentions per-origin, which i consider even more un- > > implementable than per-neighbor, which is why I restricted it to > > direct neighbors (similar to the idea of BCP38, that things > > 'should' > > be fine if everyone filters their downstreams.) > > - Your implementability point is very valid. > > > > To address both points, it might make sense to move this to a > > softer > > recommendation to "Monitoring the global number of prefixes > > ingested > > from each peer/downstream, and alerting if that number increases > > too > > quickly" or something similar; > > I think a recommendation for prefix limit monitoring and alerting for > all peers would be a good replacement of section 8.2.2. > > Section 8.2.1 already mentions placing a prefix limit on upstreams, > so > this should limit the risk of the attack described in 8.2.2 somewhat. > But it will have to be combined with monitoring, so that a customer > AS > does not cut itself off if the BGP table on all of their upstreams > eventually grows too large. > > Kind regards, > Martin > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
