Summary

  • Revision 03 of the GROW working-group Internet-Draft Current Options for Securing Global Routing adds a section on configuration paradigms. It contrasts staged, atomic commits with systems that execute each command as it is entered. The draft remains an active Internet-Draft, not an approved RFC or an incident report.
  • Its example is a route-map permit rule that becomes active before a later set large-community add 65536:0:0 instruction. If that permit sits before a rule rejecting upstream-learned routes, exports to peers can begin in the gap. The concern is an intermediate state, even when the eventual configuration looks correct.

Imagine a change ticket containing two lines: permit a route and attach a Large Community. In the ticket, those lines form one intended operation. On a router that executes commands immediately, they may be two separate production events. The first can alter BGP export before the second is present. That distinction is the news in the 2 October revision of draft-ietf-grow-routing-ops-sec-inform, a GROW working-group draft whose IESG state is still I-D Exists and whose intended status is Informational.

The new section, “Impact of the Configuration Paradigm,” explicitly contrasts transaction-based interfaces that stage and commit a change atomically with immediate-execution interfaces. Its example is unusually concrete. A route-map rule begins with action permit; a later command adds Large Community 65536:0:0. When the new rule is placed before a reject rule for routes learned from upstream networks, the temporary permit can pass those routes toward peers. The draft describes a possible route leak, not an observed leak at a named network. The numerical community is part of the example, not evidence that it alone controls export or makes a route safe.

The revision is important for what it does and does not newly say. Revision 02 already warned, in its prefix-filter consistency section, that non-atomic updates may temporarily admit unwanted prefixes or leave a policy inconsistent after an incomplete edit. The new revision elevates the issue to a general configuration-paradigm section and illustrates an ordering hazard in a route map. It would be inaccurate to claim that GROW discovered non-atomic changes only now, or that this draft prescribes one product's change procedure.

RFC 8212 supplies another useful limit. It requires explicit EBGP import and export policies and default rejection when no policy is present. But its own security discussion says this does not prevent an incorrect explicit configuration. A briefly active permit is still explicit policy. “We have default reject” is therefore not a receipt that every intermediate edit to an attached policy was safe. Conversely, this draft does not prove that any particular platform exhibits the example; an operator must test the platform's commit and policy-attachment semantics.

The governance unit is the sequence of reachable production states. An accepted command, a complete intended route map, and the neighbor receiving only authorized advertisements are three different facts. A final diff proves the second more readily than the first or third. A controlled change can prebuild and inspect a replacement policy where the platform permits it, then test how its reference is switched and inspect advertisements after cutover. Even a reference swap must not be assumed atomic merely because it is one line. These are operating deductions from the draft's failure mode, not new IETF requirements.

The draft calls itself a non-exhaustive inventory and says it neither judges the efficacy of every technique nor prescribes one implementation. That restraint matters. Its strongest contribution here is to move the question from “does the target configuration contain a reject?” to “could the route ever be exported while we are reaching that target?” No source inspected establishes an actual leak, a vendor defect, a deployed exposure rate or the success of a universal mitigation.

Sources