Moin, > I think extended (RFC4360) communities should also be added here. Good point. Added a ticket.
> Another point to add in this section is scrubbing communities from a > received route if the number of attached communities is excessively > high (e.g. > 100). Same; Also in the ticket. > I would suggest replacing the word "all" with "specific", or to add a > line explicitly clarifying not to scrub unknown transitive > attributes. I see how the text there is unclear. Added a ticket to fix this after 118. > 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; Then again, the attack in itself kind-of works; Well, not against most major operators, but as soon as it goes to tier 2-3, there quickly are funny cornercase-legacy-things around which die surprisingly quickly if there is a sudden GRT jump by 10-20k prefixes or more. It often boils down to walking on a very thin lines when it comes to how many additional routes can be ingested, basically playing constant catchup to find work-arounds for the next $month(s) until yet another device can finally be decomissioned. So, ultimately, I am not sure; More input appreciated. With best regards, Tobias -- 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
