John Scudder and the Standards Work Behind BGP Origin Validation

Summary

John Scudder's IETF profile and named work on RFC 6811, RFC 7606, and RFC 7854 connect him to three distinct operational controls: validating a route's claimed origin, limiting the collateral damage of malformed BGP updates, and exposing route state to monitoring systems.
Those controls improve the evidence available to operators, but none guarantees correct deployment, universal filtering, uninterrupted reachability, or a secure global routing system; the decisive layer remains implementation, local policy, current resource data, and observed network behavior.

A routing record rather than a general biography

Profiles of Internet engineers can easily become lists of employers, titles, working groups, and documents. Such lists establish proximity to important systems, but they do not explain what a person actually worked on, what operational constraint the work addressed, or how the resulting mechanism behaves when routers exchange routes.

John Scudder's public record supports a more specific account. His IETF Datatracker profile says that he began in network operations on the NSFNET at Merit Network and later focused on routing protocol design and implementation, particularly BGP. The profile also records service as a co-chair of several IETF working groups, a former Routing Area Director, a member of the Routing Directorate, and a named author or editor on a long series of routing documents.

That profile is useful person-level evidence, but it is not the final evidence for protocol behavior. The stronger operational record comes from the documents that define particular controls:

RFC 6811, co-authored by Pradosh Mohapatra, John Scudder, David Ward, Randy Bush, and Rob Austein, describes BGP Prefix Origin Validation.
RFC 7606, edited by Enke Chen and John Scudder with Pradosh Mohapatra and Keyur Patel, revises how BGP implementations handle malformed UPDATE attributes.
RFC 7854, edited by Scudder with Rex Fernando and Stephen Stuart, defines the BGP Monitoring Protocol.

These documents cover different failure surfaces. Origin validation asks whether a route's originating autonomous system is consistent with authenticated number-resource data. Revised error handling asks how a router should contain a malformed update without unnecessarily discarding unrelated valid routes. BMP asks how a router can export route views and session events to a monitoring station.

The documents do not establish that Scudder alone designed these mechanisms. They are collaborative IETF products whose operational results depend on co-authors, working groups, implementers, vendors, deployers, and network operators. They also do not prove universal adoption or any measured reduction in incidents.

The legitimate subject is narrower and more useful: what these person-attributed standards reveal about making distributed routing states more inspectable, bounded, and recoverable.

BGP depends on claims that routers can compare

The Border Gateway Protocol carries reachability information among autonomous systems. A BGP route associates an address prefix with path information and attributes that influence how routers select and propagate paths. At Internet scale, this process is distributed. There is no single device that computes every path, no global transaction that commits every routing decision at once, and no authority that can make every operator accept the same policy merely by publishing a statement.

Every received route is therefore a claim presented to a local routing system.

The claim includes at least a destination prefix and an AS path. The last relevant AS in that path is treated as the origin for origin-validation purposes. The receiving network can compare that claim with other evidence, including:

authenticated resource records;
locally configured import policy;
Internet Routing Registry data;
RPKI-derived Validated ROA Payloads;
customer and peer agreements;
observed changes at external collectors;
previous route state and incident context.

None of these signals is the router itself. Each is an input to the operator's decision.

This distinction is important because number-resource records are often described in language that makes a registry sound like a routing controller. A registry can record who holds an address block or autonomous system number. A Route Origin Authorization can state which AS is authorized to originate a prefix. A local RPKI cache can make validated data available to a BGP speaker. The router still applies software behavior and local policy to a received announcement.

A record can be correct while a network is unreachable. A route can be visible while the corresponding registry or contact data is stale. A validation state can be calculated correctly while local policy does nothing with it. A monitoring feed can carry accurate events while no operator responds.

The value of the record is not that it replaces operations. The value is that it gives operations a stable claim to compare with running code.

RFC 6811 turns resource data into a routing state

RFC 6811 addresses a specific question: can a BGP speaker classify whether the AS claiming to originate a prefix is authorized by the relevant prefix holder?

The document describes a mechanism based on processed RPKI data. Resource certificates represent IP address and AS number resources. Route Origin Authorizations associate address blocks with autonomous systems. A relying system validates and processes those objects. A router can then receive a simplified local set of Validated ROA Payloads, often called VRPs.

A VRP includes the prefix, a maximum prefix length, and the authorized origin AS. RFC 6811 defines how a route is compared with those entries. The result is one of three states:

Valid: at least one VRP covers the route prefix and matches the route's origin AS and permitted prefix length.
Invalid: at least one VRP covers the route prefix, but no covering VRP matches the route as announced.
NotFound: no VRP covers the route prefix.

This three-state result is an important design choice. It avoids reducing every absence of authorization data to an accusation. NotFound means the validating router lacks a covering VRP for that route. It does not mean the route is fraudulent. Invalid means the route conflicts with the available validated origin data under the specified comparison. It still does not determine, by itself, why the conflict exists.

An invalid state can arise from a mistaken or unauthorized announcement. It can also arise because the resource holder changed an origin but failed to update the ROA, because a more-specific route exceeds the permitted maximum length, or because operational and registry changes did not remain synchronized.

The state is therefore evidence, not a verdict about intent.

RFC 6811 also preserves local policy. It says that an implementation must not exclude a route from consideration merely as a side effect of the validation state unless it is explicitly configured to do so. The implementation must make the state available to routing policy, but the operator decides how to use it.

That boundary separates a shared validation method from local enforcement. The standard defines a common way to derive a state. It does not silently impose one global route-selection rule.

A valid state is not the same as a valid path

Origin validation answers a limited question. It compares the route's claimed origin with authorization data for the prefix. It does not validate every AS in the path. It does not prove that the route traveled through the intended neighbors. It does not prove that the prefix holder's systems are functioning, that traffic reaches the expected service, or that the route is commercially or operationally desirable.

A route can be origin-valid and still be affected by:

an unintended upstream path;
a route leak beyond the origin;
traffic interception elsewhere in the path;
a stale but cryptographically valid authorization;
a service outage behind a correctly originated prefix;
local preference that selects a less suitable path;
filtering or propagation differences among networks.

Conversely, an origin-invalid route can be operationally legitimate but inconsistent with an out-of-date authorization record. The correct response is still to investigate and repair the inconsistency. The invalid state is useful precisely because it exposes a mismatch that would otherwise be harder to see.

This is where the registry-as-recordkeeper model becomes practical.

The RPKI record needs uniqueness, accurate resource binding, verifiable signatures, transfer history, and current authorization data. The routing system needs implementations that retrieve and refresh the processed data, calculate states consistently, expose those states to policy, and continue behaving sensibly when caches or records change. Operators need procedures for deciding when to reject, de-preference, monitor, or temporarily tolerate a route.

The layers reinforce one another without becoming interchangeable.

RFC 6811 explicitly notes that the validation system relies on the security properties of the underlying database and distribution system. A router using corrupt, stale, or incomplete validation data can calculate a state faithfully from a bad input. Cryptographic verification protects important properties, but it does not eliminate operational responsibility for publication, revocation, synchronization, monitoring, and repair.

The result is a chain of evidence:

A resource holder or authorized party publishes a ROA.
RPKI repositories and relying-party software make validated data available.
A local cache presents VRPs to a router.
The router compares a received route with those VRPs.
Local policy uses the resulting state.
Monitoring shows what routes were accepted, selected, or changed.
Operators investigate mismatches and update records or configurations.

Failure at any point changes the operational result. No single link can claim the reliability of the whole chain.

Changes to authorization data require routing work

Resource records are not static. Networks change providers, add or remove origins, introduce more-specific announcements, transfer address space, merge systems, or retire old configurations. A route that matched yesterday can become invalid after a ROA change. A route that was invalid can become valid when the authorization is corrected.

RFC 6811 requires affected routes to be revalidated when relevant mappings are added, removed, or changed. That requirement exposes a subtle operational cost. A validation database is not merely consulted at session establishment. Its changes can cause the BGP decision process to run again for affected prefixes.

This means that a record update has consequences in the routing system, even though the registry itself does not send the route.

Operators need to know:

when new validated data arrived;
which prefixes were affected;
whether states changed;
which policy actions followed;
whether selected paths changed;
whether traffic or reachability changed unexpectedly;
whether the record change was intended.

Without that evidence, an operator may see a route disappear but lack a clear account of whether the trigger was a BGP announcement, a local policy edit, a cache refresh, or an authorization update.

Origin validation is therefore not only a filter feature. It is a state-management problem. The record, cache, router, policy, and monitoring system need timestamps and identifiers that allow an operator to reconstruct what happened.

This operational burden is one reason simplistic claims about "turning on RPKI" are insufficient. A control must be deployed, observed, and integrated into change management. The standard creates a common mechanism. The network still needs an accountable operating process.

RFC 7606 contains malformed updates instead of collapsing every route

Origin validation concerns the meaning of a route's origin claim. RFC 7606 addresses a different problem: what should happen when a BGP UPDATE contains a malformed path attribute?

The original BGP behavior often required a session reset after certain UPDATE errors. Resetting a session withdraws the routes learned over it and then requires the peers to re-establish the session and exchange routing information again. If one malformed attribute triggers that reset, unrelated valid routes learned on the same session can be disturbed.

RFC 7606 was written to reduce that collateral damage while preserving protocol correctness as far as possible. It defines a set of responses with different scope:

session reset;
disabling an address-family context where applicable;
treat-as-withdraw;
attribute discard.

The central mechanism is treat-as-withdraw. When the specified conditions apply, the router treats the routes in the malformed UPDATE as though they had been withdrawn. The session and unrelated routes can remain in place.

This is a bounded-failure design. Instead of allowing one bad message to erase all state learned across a session, the implementation contains the effect closer to the malformed information.

The phrase "bounded failure" should not be read as "no failure." The affected routes can still become unreachable or take a suboptimal path. An internal routing environment can still become inconsistent under some conditions. The standard itself discusses these trade-offs and requires diagnostic facilities so operators can identify the affected information and investigate the cause.

The mechanism narrows the blast radius. It does not remove the need for repair.

Why the distinction between withdrawal and discard matters

Treating a malformed route as withdrawn is not the same as silently discarding the UPDATE message.

BGP is an incremental protocol. A new UPDATE changes previously known state. If a router simply ignores a malformed message, it may retain an older route that the sender intended to replace or withdraw. That stale state can be worse than removing the affected route.

Treat-as-withdraw gives the receiver a defined state transition: the affected route is no longer usable. Attribute discard has a different meaning. It removes a malformed attribute but continues processing the rest of the UPDATE, and it is appropriate only when removing the attribute does not create an unsafe or misleading route-selection result.

RFC 7606 applies these responses according to the attribute and error. Malformations in key attributes such as ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, or LOCAL_PREF commonly lead to treat-as-withdraw. Some other attributes can be discarded under specified conditions. More severe or uncontainable cases can still require a reset.

The document therefore encodes a hierarchy of consequences rather than one universal reaction.

This hierarchy reflects an operational principle: preserve valid running state when the protocol can identify the damaged unit, but do not pretend that malformed information can always be repaired safely.

The implementation has to know enough about the message structure to apply the correct boundary. New BGP attribute specifications also need to state how malformations should be handled. Error containment is not an afterthought that can be added only after a deployment fails. It is part of the attribute's contract.

Scudder's role as an editor of RFC 7606 links his public record to this part of routing continuity. It does not prove that every implementation follows the document or that every session reset is avoidable. It establishes named work on a standards mechanism designed to reduce avoidable collateral routing loss.

Recovery behavior must remain observable

Containment creates a second requirement: operators must be able to see that containment happened.

If a router uses treat-as-withdraw, an affected destination may disappear without the BGP session going down. A traditional alert that watches only session state can miss the important change. The peer remains established, but one or more routes are no longer usable.

RFC 7606 calls for debugging facilities that record the malformed UPDATE and affected network-layer reachability information. This gives operators a starting point for tracing the problem toward the source and applying filters or fixes.

Useful operational evidence can include:

the peer and address family involved;
the time of the malformed UPDATE;
the affected prefixes;
the attribute and validation failure;
the chosen error-handling action;
whether alternate routes were selected;
whether the error repeated;
whether a local filter or remote correction ended the condition.

Such data can be sensitive and voluminous. It needs access control, retention limits, and careful handling. The public article does not need private router messages. The operating organization does need enough internal evidence to distinguish a contained protocol error from a broader connectivity failure.

This is a recurring pattern across the source set. A control that changes route state also needs a record of that change. Otherwise, containment can look like unexplained loss, and validation can look like arbitrary rejection.

RFC 7854 creates a route-observation interface

RFC 7854 addresses the observability layer directly. The BGP Monitoring Protocol provides an interface through which a router can send route views, updates, peer state, and statistics to a monitoring station.

Before BMP, operators and researchers often relied on command-line screen scraping or mechanisms that did not expose all of the desired router state in a structured way. BMP defines messages that allow a monitoring station to receive:

an initial route view for monitored peers;
incremental route advertisements and withdrawals;
peer-up and peer-down events;
periodic statistics;
initiation and termination information;
route-mirroring data in supported cases.

The protocol can expose the Adj-RIB-In, meaning the routes received from a peer before or after policy depending on the configured view and supported extensions. This is different from looking only at the final route selected for forwarding. A selected route shows one outcome. The received-route view shows more of the evidence from which policy made that choice.

That distinction matters for origin validation and error handling.

If an operator sees only the selected route, it may be hard to determine which invalid, not-found, or malformed alternatives were received and rejected. A monitoring feed can preserve the sequence of peer events and route updates needed for analysis.

BMP does not make the data correct merely by transporting it. The router must generate the messages accurately. The monitoring station must authenticate or otherwise protect its collection environment according to the deployment. Time synchronization, capacity, retention, and access controls all matter. A dropped monitoring session can create a gap even while BGP forwarding continues.

Observability is an interface, not an outcome.

A monitoring feed is another operational system

BMP can carry a large volume of routing information. A full initial table from multiple peers, followed by continuous updates, creates storage and processing demands. Monitoring architecture therefore has its own capacity and failure questions:

Which peers are monitored?
Is the feed pre-policy, post-policy, or both?
Can the collector keep up during a burst?
How are duplicate or reordered observations handled?
What happens when a BMP session restarts?
How are End-of-RIB boundaries recorded?
Can the organization correlate route changes with RPKI cache and configuration changes?
Who can access peer metadata and raw updates?

These questions show why a telemetry protocol cannot be treated as a decorative dashboard feature. The monitoring path must be engineered and tested.

The protocol's unidirectional operating model also clarifies responsibility. BMP sends information from the monitored router to the station; it is not a remote route-control protocol. The collector observes. The router continues to apply BGP and local policy.

That separation reduces the risk of confusing a measurement system with a control plane, but it does not eliminate operational coupling. A misconfigured export, overloaded collector, or missing peer view can distort analysis. The monitoring system needs its own health evidence.

This is another version of the recordkeeper boundary. The collector maintains a record of route state. It does not make the route exist, and it does not decide which route the network should prefer. Its legitimacy comes from accuracy, continuity, and the ability to relate the record to a specific router, peer, time, and policy context.

Three controls, three different questions

RFC 6811, RFC 7606, and RFC 7854 can be read together because they address adjacent parts of the routing lifecycle. They should not be collapsed into one generic idea of "BGP security."

Origin validation asks:

Does authenticated resource data support the AS that this route claims as its origin?

Revised UPDATE error handling asks:

If part of this routing message is malformed, how narrowly can the receiver contain the effect while preserving protocol correctness?

BMP asks:

What route and peer state can the router expose so an external monitoring system can observe changes and diagnose behavior?

The first is a data-to-route comparison. The second is a fault-containment rule. The third is an observation channel.

An operator can deploy one without the others. That creates partial coverage. Origin validation without sufficient monitoring can reject or de-preference routes without a good investigation trail. Monitoring without validation can show an unexpected origin but leave the response entirely manual. Revised error handling without route-level alerts can preserve the session while affected prefixes quietly lose reachability.

A mature operating design combines them with local policy, change control, incident handling, and resource-record maintenance.

This combination does not require one institution to control everything. The resource holder maintains authorization. RPKI systems validate and distribute data. vendors implement protocol behavior. Operators configure local policy. Routers exchange and select routes. Monitoring systems record observations. Standards communities define interoperable mechanisms and revise them as experience exposes defects.

Distributed responsibility is not a weakness to disguise. It is the system that actually exists. Accountability requires making each boundary explicit.

Standards text and running code

The IETF profile lists a long period of Scudder's involvement in BGP documents, implementation, working groups, and routing review. An IETF 123 presentation attributed to him also concerns continued maintenance of the core BGP-4 specification. That supplementary record can establish participation in the maintenance discussion. It cannot prove completion, consensus, or deployment.

This boundary illustrates a broader point. Standards text matters because independent implementations need a common contract. Ambiguous behavior can produce divergent route state. Missing error rules can turn a local defect into a session-wide event. Incomplete telemetry definitions can make two collectors interpret the same router differently.

The text remains a specification. Operators encounter the implementation.

Running-code evidence includes:

whether a router calculates validation states as expected;
whether configuration exposes those states to policy;
whether malformed attributes trigger the specified response;
whether BMP emits the expected message sequence;
whether a collector reconstructs route state correctly;
whether upgrades change behavior;
whether failure tests produce bounded and diagnosable results.

Conformance testing can compare implementation behavior with the standard. Interoperability testing can compare different implementations with one another. Production observation can show how the mechanisms behave under real route volume, policy variation, and change.

Each layer can reveal defects that the previous layer did not.

A useful standards profile therefore avoids claiming that publication solved the problem. It asks what contract the document created, what operational evidence would show that the contract is being followed, and what remains local or unverified.

The person-level contribution and the institutional boundary

Scudder's record is unusually useful for a person profile because the sources link the same person to multiple concrete protocol documents and to earlier network operations. The connection is direct rather than inferred from a company title or event appearance.

The correct attribution still has limits.

RFC 6811 has multiple authors and builds on the work of the broader SIDR community, RPKI specifications, relying-party software, router implementations, and operational deployment. RFC 7606 has editors and authors, but its behavior depends on working-group review and implementation. RFC 7854 is also a collaborative document whose utility depends on router and collector ecosystems.

Scudder can be credited for the work the record names:

co-authorship of the origin-validation mechanism in RFC 6811;
editorial responsibility for revised BGP UPDATE error handling in RFC 7606;
editorial responsibility for the BGP Monitoring Protocol in RFC 7854;
recorded routing-area and working-group service;
continuing participation in BGP specification maintenance.

He should not be credited alone with:

inventing or operating all of BGP;
creating the entire RPKI system;
deploying origin validation across the Internet;
preventing a specific routing incident without evidence;
determining every operator's route policy;
guaranteeing the correctness of vendor implementations;
operating every BMP collector;
providing global routing continuity.

This is not ceremonial caution. Accurate attribution protects the operational model. If a system is collaborative and distributed, assigning the whole result to one person makes it harder to see who owns a defect or repair.

A practical operating model

The three standards suggest a practical evidence model for network operators.

1. Maintain the authorization record

The resource holder should keep ROAs aligned with intended origins and permitted prefix lengths. Changes should have an owner, review, activation time, and rollback plan. The organization should know which routes will become affected when a record changes.

2. Validate the validation supply chain

Relying-party software and caches should expose freshness, repository status, validation failures, and current VRP sets. Operators should avoid assuming that a cryptographically processed dataset is automatically complete or current.

3. Make routing policy explicit

The network should document how Valid, Invalid, and NotFound states affect import policy. Exceptions should be bounded and reviewed. A temporary exception without an owner or expiry can become permanent hidden policy.

4. Contain malformed information

Implementations should follow current error-handling behavior and expose which action was taken. Operators should test representative malformed cases in controlled environments and understand when the software still resets a session.

5. Observe received and selected state

BMP or equivalent telemetry should show enough route and peer context to explain decisions. Collection scope, pre-policy versus post-policy views, data gaps, and retention should be explicit.

6. Correlate changes

Route-state changes should be comparable with ROA updates, cache refreshes, router configuration, software versions, peer events, and policy deployments. Shared timestamps and stable identifiers make this possible.

7. Assign repair ownership

An origin mismatch may belong to the resource holder, registry workflow, RPKI publication path, relying-party system, route originator, or local policy. A malformed UPDATE may require action by a remote operator, an implementation vendor, or a local filter owner. A monitoring gap may belong to the router export, transport path, or collector.

The evidence should point to the owner instead of collapsing every problem into "BGP."

What the record does not show

The source set is strong for standards attribution and protocol behavior, but it has clear limits.

It does not provide a measured study of how many networks deploy each mechanism. It does not quantify incidents prevented by origin validation or treat-as-withdraw. It does not compare vendor conformance. It does not show private operational decisions from Scudder's employers. It does not establish the outcome of every working-group proposal. It does not prove that a current draft will become an RFC.

Those gaps matter. A profile can become misleading when it converts a design goal into a measured result.

For example, RFC 6811 was intended to help address origin mis-announcement. The document itself does not prove that a specific invalid route was rejected or that global routing became secure. RFC 7606 aims to reduce unnecessary session resets. Its publication does not prove that every deployed router contains malformed updates correctly. RFC 7854 defines a monitoring protocol. It does not prove that a collector sees every route or that an operator responds to every alert.

The appropriate language is procedural:

the document defines;
the implementation calculates;
the operator configures;
the collector observes;
the evidence shows;
the result remains bounded by deployment.

This language is less dramatic, but it is more faithful to the system.

Why this record matters

Internet routing reliability depends on a sequence of small, exact decisions. A prefix and origin must be represented accurately. A route must be compared with that representation. A malformed message must have a bounded response. A route-state change must be observable. An operator must decide what to do and record the repair.

Scudder's public IETF record spans those decisions in a way that generic titles do not. The NSFNET operations background gives context for a career centered on routing systems. The named RFC work supplies direct person-level evidence. The documents themselves expose both the mechanism and its limits.

Together they show a practical view of infrastructure governance.

A registry is valuable as a ledger of resources and authorization, not as a sovereign controller of routes. A standard is valuable as a common technical contract, not as proof that deployment succeeded. A monitoring protocol is valuable as an observation interface, not as a substitute for response. A person can make a substantial contribution to these systems without owning every institutional or operational outcome.

The strongest thread across the record is not advocacy for one technology. It is the attempt to make routing behavior more explicit at the points where distributed systems otherwise become opaque:

a route's origin becomes a validation state;
a malformed update becomes a bounded action;
a peer's changing route view becomes a monitoring record.

Those transformations create evidence that operators can test against reality.

The continuing work

BGP continues to evolve because the network around it continues to change. New address families, attributes, operational practices, security controls, and monitoring requirements create pressure on the core protocol. Old assumptions become visible only after diverse implementations and large networks exercise them.

Maintenance work therefore has a different character from launching a new protocol. It must preserve compatibility while removing ambiguity. It must define error behavior for cases that earlier text did not anticipate. It must distinguish changes that can be contained from those that require stronger action. It must make new state visible without overwhelming routers or collectors.

The IETF profile and supplementary presentation record connect Scudder to that continuing maintenance. The evidence supports participation and attributed technical work. It does not support a claim that one engineer controls BGP's future.

The more important conclusion is institutional and operational: the protocol remains maintainable only when specification, implementation, observation, and operator feedback stay connected.

That connection is the reality layer behind the standards.

Conclusion

John Scudder's documented work on BGP origin validation, UPDATE error handling, and monitoring provides a focused account of how Internet routing can become more accountable without pretending to become centralized.

RFC 6811 gives routers a common method for comparing an origin claim with validated resource authorization data. RFC 7606 narrows the damage caused by certain malformed updates while preserving explicit trade-offs and diagnostic needs. RFC 7854 gives monitoring systems structured access to route and peer state.

Each mechanism converts an otherwise ambiguous event into a state that can be recorded and examined. Each also stops short of deciding the whole operational outcome.

The resource record does not send the packet. The validation state does not choose policy by itself. The error response does not guarantee reachability. The monitoring feed does not perform the repair. Standards text does not prove implementation.

Scudder's person-level contribution is visible in the documents that define these boundaries. The wider result belongs to the co-authors, working groups, implementers, operators, and institutions that keep records current and systems running.

That is why the record is significant. It shows Internet infrastructure not as a set of titles or declarations, but as a chain of testable claims, bounded failure responses, and observable state.

John Scudder and the Standards Work Behind BGP Origin Validation and Routing Policy