Authors and WG, Note first: While there are a substantial number of comments below, it's my opinion that the document is broadly in very good shape and full of high quality material. I'd somewhat suggest a "review hackathon" and work on getting it shipped.
Thanks to the author for doing this bit of useful and difficult work. ----- Section 4.1.2 discusses defense vs. path MTU issues. In my opinion, the section correctly discusses the security implications. However, pinning MSS to too low a number has impacts on BGP convergence due to TCP performance. This is noted more often on long haul links with high latency. Section 5.3 - "too specific". Consider also discussing the use of the NO_EXPORT BGP community when these "even more specific" routes are agreed to be exchanged between cooperating providers. This can help address situations where other filters fail to catch them. Section 6 - is mentioning MANRS appropriate in here somewhere? Perversely, the longer intent is that this document serves as an input into their training. 6.1 recursion. Cute. 6.1.2 cone is used here and not defined. Since this document should be foundational for newer practioners of routing security, let's make sure this is covered. 6.1.3 - It's worth mentioning that as an operational consideration that these large filters negatively impact the performance of BGP, even when a good idea. 6.2 I suggest splitting the section on path validation into two sub-sections. This will help distinguish the deployable (soon) case of ASPA from the theoretically deployable case for bgpsec. 6.2.3 - Needs a citation to rpki-rtr rfc or bis. 6.2.x - Consider a section on RFC 9234. 6.5.1 mentions this in a policy context. 6.3 - Perhaps cite RFC 9774. 7.1 - I have mixed opinion about referring to RFC 2439 for flap damping. That RFC covers the idea, but implementations have never really implemented what's in there. The follow-on citations help. 7.2.1. prefix limits: The caveat about loss of service as part of session shutdown is possibly needed. 7.3.2 A note that AS path manipulation may be fragile in the presence of ASPA or other AS_PATH validation might be helpful. 7.5 - community scrubbing could use a special considerations section for extended communities. I'd invite the bess chairs to get someone to help write this. th 7.3.2 A note that AS path manipulation may be fragile in the presence of ASPA or other AS_PATH validation might be helpful. 7.5 - community scrubbing could use a special considerations section for extended communities. I'd invite the bess chairs to get someone to help write this. We'll likely end up with a section on maintenance similar to what John and my attribute filtering draft recommends as a registry change. And certainly the advice could be in the draft "dear IETF, come up with sane filtering policy and publish it". 7.6.1 - I'd suggest an informative reference to my attribute escape document. Depending on the time until last call, perhaps the attribute filtering document from John and myself as well - but that one hasn't matured. Note: "Removing" mandatory path attributes isn't possible without session reset. Perhaps you're meaning other forms of scrubbing? 7.6.2 I'd seek implementation references for things that fix-up headers. My experience is this old pre-RFC 7606 procedure (removed) ended up being a VERY bad idea. 8.1.2 - optimizing policy is a difficult thing to write about. This section does a fairly good job. The one geneal thing I'd suggest changing is some care about the discussion of sequentially evaluated things vs. size. As an example, the majority of prefix list implementations will evaluate on the order of the depth of the generated binary tree. Even for a fully populated tree, the evaluation work may be less expensive than a single regular expression. My general advice is to evaluate scalars prior to tree lookups prior to list or regular expression lookups. The following section does provide one bit of warning about implementations that have sequential impacts. 8.1.3 overlaps our IETF 124 hallway conversation about implementatins that do or do not have transaction semantics. Calling out this distinction might be helpful earlier in the document. For 8.5 - ibgp filtering, I suggest getting strong operator review of the recommendations here. It's incredibly easy to do bad things to your network if you implement ibgp filtering. Even if your intentions are good, inconsistent filtering may result in forwarding loops. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
