Summary

  • Kotikalapudi Sriram is named as a coauthor of RFC 6472 and RFC 9774 and as a coeditor of RFC 8205. Read together, those records show a collaborative standards path from a sender-side recommendation against AS_SET and AS_CONFED_SET to explicit sender and receiver behavior, alongside a BGPsec design built on capability negotiation, RPKI resource binding, and path validation.
  • The record also draws firm limits around what a protocol record can establish. Clearer AS_PATH semantics and signed authorization data can make routing decisions more inspectable, but the RFCs do not prove current adoption, implementation quality, data-plane forwarding, measured security improvement, or any individual's operational control.

Analysis

A Profile in Collaborative Standards Work

Kotikalapudi Sriram's role in the three documents is precise and limited. RFC 6472, published as Best Current Practice 172 in December 2011, names him with Warren Kumari as a coauthor. RFC 8205, published on the Standards Track in September 2017, names Matt Lepinski and Sriram as coeditors. RFC 9774, published on the Standards Track in May 2025, again names Sriram among a larger author group. These are public, dated records of participation in collective technical work. They are not a conventional biography.

The distinction matters because the requirements in an RFC belong to the document and the IETF consensus process. A coauthor can be credited for participating in that record; a coeditor can be credited for helping shape and present a protocol specification. Neither role makes one person the sole inventor of a mechanism, the unilateral maker of routing policy, or the operator of networks that may implement it. The available documents also do not establish Sriram's current employment, personal deployment activity, or authority over any routing decision.

Within those boundaries, the record has a coherent technical subject. The first and third documents address unordered segments in AS_PATH. The middle document specifies a signed path attribute whose value depends on explicit capabilities, identified AS numbers, valid resource certificates, and current validation data. One line removes path state that obscures origin semantics. The other defines what stronger path authorization can and cannot say. Together, they make a useful profile of work on the accuracy and operational limits of interdomain routing records.

Why Unordered Path State Became a Problem

An AS_PATH normally gives BGP speakers information about the sequence of Autonomous Systems through which a route advertisement has passed. An AS_SET is different: it is an unordered collection of AS numbers created during route aggregation. AS_CONFED_SET serves a similar purpose for member AS numbers inside a confederation. The set can preserve the fact that several ASes contributed to an aggregate without preserving a sequence among them.

RFC 6472 explains the operational cost of that ambiguity. Aggregation combines multiple routes into a new route for a less specific prefix. When an unordered set becomes part of the resulting path, the semantics of route origination can become less clear. The document connects that loss of precision to difficulty authenticating the origin of an aggregate with security systems based on certificates for IP addresses and AS identifiers. It also notes that precise path information for component prefixes is not preserved.

The document's argument is not that aggregation itself is illegitimate. It identifies a narrower issue: aggregation that produces AS_SET or AS_CONFED_SET carries state that is difficult to use in a security model requiring an unambiguous origin and an ordered authorization path. RFC 6472 reported that the relevant use was rare in the historical routing data it considered and that its routing-table benefit was very small relative to the added complexity. That is a source-dated assessment, not proof of what is visible in every network today.

This is the first operational boundary in the record. A routing attribute may record something true yet remain too ambiguous for a later security decision. Knowing that several ASes participated is not the same as knowing which AS originated an aggregate or the order in which an advertisement was authorized. More data is not automatically better data when the representation cannot answer the question a relying system must ask.

2011: A Sender-Side Recommendation

RFC 6472 responded with a recommendation to network operators. It recommended that operators stop generating new announcements containing AS_SET or AS_CONFED_SET. For routes already announced with those segment types, it said operators should withdraw them and reannounce the component prefixes without AS_SET. That procedure means undoing the earlier form of aggregation and announcing more-specific routes.

The language was deliberately bounded. The document told an operator to understand the full implications of the change. It recognized that AS_SET had served a legitimate purpose in some rare aggregation arrangements, including preserving loop protection under particular configurations. Removing the set therefore was not presented as a text substitution that could be made without considering routing policy. The recommended transition changed which prefixes would be announced and how their path information would be represented.

RFC 6472 also stopped short of defining receiver behavior. It observed that security technologies might treat routes containing the sets as infeasible and that operators might filter them, but it explicitly focused on the sender side. This separation is important in reading the later standards history. A recommendation not to create new ambiguous state is not the same rule as a requirement imposed on every sender, and it is not the same as a receiver being required to withdraw a route after encountering that state.

The security rationale was similarly cautious. RFC 6472 said future removal of rarely exercised complexity and code could decrease attack surface and simplify RPKI design and implementation. It did not report a measured reduction in incidents, a completed removal from implementations, or universal operator adoption. It established the direction and the reason for it: reduce a weakly used form of path ambiguity before building stronger security decisions on top of the path record.

2025: Explicit Rules for Senders and Receivers

RFC 9774 advanced that direction from a Best Current Practice recommendation to a Standards Track requirement. It obsoleted RFC 6472 and updated the earlier BGP and confederation specifications. Unless an operator explicitly configures otherwise during a transition, a BGP speaker must not advertise UPDATE messages containing AS_SET or AS_CONFED_SET. A speaker receiving those segment types in AS_PATH or AS4_PATH must use treat-as-withdraw error handling.

That change closes the receiver-side question left open in 2011. The sender rule prevents new set-bearing updates under normal operation. The receiver rule defines what happens when such an update still arrives. Treat-as-withdraw applies the withdrawal effect to the affected route rather than treating the malformed or prohibited path state as usable routing information. The rule makes the handling explicit, but it does not make the operational consequence invisible.

A withdrawn route may change the available path set, and the document allows an explicit transition configuration because legacy state cannot be assumed to disappear everywhere at once.

The later RFC also describes a path for aggregation without the deprecated set types. Its consistent brief aggregation procedures retain AGGREGATOR and ATOMIC_AGGREGATE where appropriate while keeping AS_SET and AS_CONFED_SET out of AS_PATH. It discusses the need to keep the origin AS unambiguous, to construct appropriate route-origin authorizations, and to avoid announcing an aggregate back to a contributing AS in ways that can create forwarding problems. This is not a claim that every aggregation can be converted automatically.

It is evidence that deprecation moves complexity into explicit design choices rather than declaring aggregation unnecessary.

RFC 9774 therefore changes both the protocol boundary and the migration burden. The protocol boundary becomes sharper: unordered sets are no longer normal AS_PATH state. The migration burden remains with implementations and operators that must find, classify, and transition any exceptions without confusing standards compliance with proof of safe local behavior. The document defines required behavior; it does not publish a census of compliant speakers or a measurement of resulting reachability.

Deprecation Narrows the Input to Routing Security

The deprecation line and BGPsec meet at a common requirement: security decisions need path state whose meaning is explicit. RFC 9774 states that BGPsec does not support AS_SET. It also explains that an AS_SET prevents a route from receiving a valid result in RPKI-based route-origin validation. An unordered collection does not provide the ordered authorization chain that BGPsec signs, and it can leave the origin of an aggregate ambiguous.

Removing AS_SET does not, by itself, create a valid signed path. It removes one representation that conflicts with the security model. A route without an AS_SET can still be unsigned, incorrectly originated, affected by stale validation data, or handled according to a local policy that does not prefer its validation state. Deprecation is therefore a prerequisite for clearer reasoning, not a certificate of correctness.

The distinction is operationally useful. A standards requirement can narrow the set of allowed representations. A security protocol can define how to authorize and validate one of those representations. An implementation must turn both into code, and an operator must decide how validation results influence routing. Skipping any layer creates an unsupported inference. Protocol cleanliness is not deployment evidence, and a signed control-plane record is not observed forwarding behavior.

Read as a sequence of decisions, the three RFCs require several different questions to be answered in order. The first is representational: does the advertised path contain an unordered set that prevents a relying system from identifying the origin or reconstructing an ordered authorization chain? The second is procedural: did the peers negotiate the capabilities needed to exchange BGPsec updates for the relevant address family and direction? The third is evidentiary: can the validator locate current certificate and origin-authorization data binding the asserted AS numbers and prefixes to the keys and permissions used in the update?

The fourth is operational: what did local policy do with the resulting status, and over what portion of the path did signed assurance remain intact? Removing AS_SET resolves only the first obstruction. It does not answer the later questions on behalf of a speaker, cache, validator, or operator.

That ordering also explains why deprecation and BGPsec should not be collapsed into a single success metric. A speaker can comply with the prohibition on set-bearing updates while exchanging ordinary unsigned BGP. A session can negotiate BGPsec while a received path still depends on validation data whose currency must be checked. A path can validate across a contiguous secured portion while becoming unsigned at the next unsupported AS. Each state is more precise than the ambiguity it replaces, but each supports a different claim.

The practical gain is the ability to locate a failure at the representation, negotiation, resource-record, validation, or policy layer instead of treating all routing-security conditions as one undifferentiated result.

This layered account also keeps transition exceptions bounded. An explicit exception can explain why deprecated state remains temporarily acceptable to one operator, but it does not change the semantics of the set or make that state compatible with BGPsec validation. Likewise, unsigned fallback can explain why ordinary UPDATE exchange continues after failed negotiation, but continued exchange is not evidence that secured-path assurance survived. Recording the exception beside the affected layer preserves operational continuity without relabeling the exception as compliance, validation, or successful deployment.

The distinction allows later evidence to close the exception on its own terms: removal of the set, successful capability negotiation, current resource data, or an observed policy decision.

BGPsec Starts With Negotiated Capability

RFC 8205 specifies BGPsec through an optional, non-transitive BGP path attribute called BGPsec_PATH. The attribute carries a Secure_Path and digital signatures added as an UPDATE is propagated between ASes. Its purpose is to give a receiver assurance that each AS listed in the secured path authorized propagation of the route to the next AS. Before that attribute can be exchanged, however, the peers must agree on the relevant capabilities.

The capability is directional and address-family specific. A speaker separately indicates willingness to send or receive BGPsec UPDATE messages, and the capability identifies the address family. Sending and receiving for both IPv4 and IPv6 therefore cannot be inferred from one generic declaration. The corresponding multiprotocol capability must also be present for the same address family. This makes scope part of the negotiation rather than an assumption attached later.

Four-byte AS support is another explicit dependency. RFC 8205 says a speaker announcing BGPsec capability must also announce four-byte-AS capability. If it does not, BGPsec has not been successfully negotiated and BGPsec_PATH updates must not be sent on that session. A failure to negotiate BGPsec does not necessarily end ordinary BGP: unsigned UPDATE messages may still be exchanged. An implementation should log the failure, and it must provide a way to prevent the session from being established when configured for BGPsec-only operation.

These rules draw a clear boundary between capability and aspiration. Two devices may each contain BGPsec code, but a secured exchange for a given address family still depends on compatible, correctly declared session state. Conversely, a live BGP session does not prove that BGPsec was negotiated. The observable facts are the advertised directions, versions, address families, multiprotocol support, four-byte-AS support, and the actual UPDATE attributes. The label attached to a device or service cannot replace those records.

Authorization Is Bound to Number-Resource Records

BGPsec signatures do not stand alone. RFC 8205 relies on RPKI certificates that attest to allocations of AS numbers and IP address resources. To send BGPsec_PATH updates to external peers, a speaker needs a private key corresponding to an RPKI router certificate for its AS number. To validate, a recipient needs data from valid router certificates, including the AS number, public key, and Subject Key Identifier.

That binding connects a signature to an identified routing resource. When a speaker adds a signature, the private key must correspond to a valid certificate whose AS-number resource extension includes the speaker's AS number. The Subject Key Identifier carried with a signature lets a validator locate the relevant public key record. If the required AS-number and identifier combination cannot be found among valid certificate data, the signature block cannot pass validation.

Origin authorization is related but distinct. RFC 8205 expects BGPsec to be used with origin validation and recommends that a speaker originate a secured route only when a valid Route Origin Authorization permits its AS to originate the prefix. Path validation asks whether each AS authorized propagation to the next AS. Origin validation asks whether the origin AS is authorized for the prefix. Combining them produces a stronger, more specific claim than either record alone, but the specification keeps the two validation functions conceptually separate.

The registry function here is evidentiary. Number-resource records, certificates, keys, and identifiers make an authorization claim checkable. They do not make an institution the sovereign of packet forwarding, and they do not choose a route for an operator. Accuracy, uniqueness, and timely revocation matter because the cryptographic decision depends on them. Authority over route selection remains in local policy, while the protocol defines the information that policy can examine.

Validation Depends on Current and Available Data

A validator's conclusion is a function of its current RPKI state. RFC 8205 requires affected UPDATE messages to be revalidated when the relevant RPKI state changes. A certificate can expire or be revoked; a validating cache can deliver updated router-key information; a route previously considered valid can therefore require reassessment. If the validation state changes, local policy may cause best-path selection to run again.

This makes data availability part of routing-security operations. RFC 8205 describes repository data reaching routers through local RPKI caches. It points to serial-number-based incremental updates, repository notifications, snapshots, and deltas as mechanisms for keeping a relying party synchronized. The important analytical point is not that any one transfer method guarantees continuity. It is that path validation requires an operational chain from repository state to cache to router. A correct record that cannot reach the relying system cannot inform its current decision.

The RFC also recognizes that two vantage points can see different RPKI state. A signature block judged not valid upstream may be judged valid downstream if the local data differs, and stale revocation information can change the apparent result. For that reason, retaining validation information can be more accurate than erasing an unfavorable status and letting a downstream system mistake the route for merely unsigned. The protocol record should preserve what happened instead of converting uncertainty into a cleaner-looking state.

Validation work can also be deferred under exceptional load, but the deferment and status should be visible to the operator. That requirement exposes another boundary: a system that has the algorithm and keys may still face a capacity or timing constraint. Operational visibility must distinguish validated, not valid, unsigned, and not-yet-validated state. Collapsing those categories would conceal the exact condition on which local routing policy is acting.

The same discipline applies when evidence is compared across time. A certificate view, cache state, received UPDATE, validation result, and best-path decision form a useful account only when their operational intervals are known. If one element changes, the earlier conclusion may remain an accurate historical record but no longer describe the current decision. Revalidation is therefore not merely repeated computation; it is the point at which changed resource evidence is brought back into relation with routes already held by the speaker.

Preserving the old status, the trigger for reassessment, and the new result keeps that transition auditable without implying that every classification change caused a particular forwarding outcome.

Partial Deployment Limits the Reach of Assurance

RFC 8205 treats incremental deployment as a first-class limit. It describes an early stage in which BGPsec-capable ASes form contiguous groups. Routes originated and propagated inside such a group can retain cryptographic path protection across that portion. When an UPDATE reaches an AS that does not support BGPsec, the advertisement is converted back to traditional unsigned BGP before it is forwarded.

At that conversion point, assurance no longer extends across the remaining path. The secured portion is not retroactively false, but the receiver beyond the unsupported AS cannot claim end-to-end BGPsec protection merely because an earlier segment was signed. This is a practical example of bounded trust: the protection follows a chain of compatible speakers and stops when the required capability stops.

The same boundary appears in session negotiation. Missing BGPsec, multiprotocol, or four-byte-AS capability may leave an ordinary BGP session operating. Monitoring only session uptime would therefore miss the loss of secured-path semantics. A useful operational view must separate reachability, ordinary UPDATE exchange, BGPsec negotiation, validation status, and the RPKI data state used for that validation.

Nothing in the RFC establishes how large any BGPsec-capable group is today. Its partial-deployment section describes protocol behavior and expected migration shape, not a current adoption report. Nor does the document guarantee that an early adopter receives a particular commercial or reliability outcome. It states where the assurance exists, where conversion removes it, and what information remains available to local policy.

The Security Claim Stops at the Control Plane

The strongest claim in RFC 8205 is carefully framed. With origin validation, a valid BGPsec UPDATE can show that the origin AS was authorized for the prefix and that each listed AS intentionally propagated the route to the next AS according to local policy. It can also show that the UPDATE traveled through the AS sequence represented in Secure_Path.

It does not guarantee that data packets follow that path. BGPsec protects the control-plane advertisement, not every possible forwarding action. It also does not dictate route selection. An operator may use validation state as one input to local policy, and a compliant peer may propagate a route that another system considers not valid. An external receiver must perform its own validation rather than assume the sending peer made the same policy choice or had the same RPKI view.

These limits are not qualifications added from outside the protocol. They are part of its design. A precise security mechanism is valuable partly because it states what it cannot establish. Conflating UPDATE authorization with data-plane observation would turn a bounded cryptographic record into an unsupported operational claim. Conflating validation with route selection would erase the operator's policy decision. The useful result is narrower: a better authenticated account of how a route advertisement was authorized and propagated across the supported portion of the control plane.

Contribution Without Personal Control

Sriram's public role across the record is collaborative. RFC 6472 and RFC 9774 identify him as one coauthor among their respective author groups. RFC 8205 identifies him as one of two editors. The standards evolution belongs to those complete groups, reviewers, working groups, and the IETF consensus process. Implementations belong to their developers, and routing choices belong to the operators making them.

What can be attributed is sustained participation in documents that make routing state more explicit. The 2011 record isolates the cost of unordered AS path segments. The 2017 specification ties signed path authorization to negotiated capabilities and valid number-resource records while documenting partial-deployment limits. The 2025 record turns the earlier recommendation into explicit sender and receiver requirements. The continuity is visible in the documents; no private history or unverified achievement is needed to manufacture it.

The conclusion is therefore operational rather than promotional. Routing security depends on records that distinguish one resource and one state from another, on capabilities that are actually negotiated, and on validation data that remains current and available. Standards can define those boundaries. Running implementations and observed network behavior determine whether they hold in practice.

Sources