]> Zhongguancun Laboratory

guoyangfei@zgclab.edu.cn

Tsinghua University

xuke@tsinghua.edu.cn

Tsinghua University

wangxiaoliang0623@foxmail.com

Network Management Research Group This document examines whether a routing-specific commitment model is useful for expressing and assessing an AS's own expected BGP behavior across administrative-domain boundaries. An Inter-Domain Routing Behavior Commitment (IRBC) is a candidate declaration. It is attributable to an issuer and applies to specific inter-domain connections, route scopes, directions, and operating conditions. Its semantics include the subject AS's connection role, the associated routing behavior, and a commitment context that defines scope, conditions, exceptions, and validity. The document distinguishes an IRBC from a general IBN intent, an interconnection service request, local routing policy, route-path authorization, and cryptographic evidence of an individual route-propagation event.

Introduction The Border Gateway Protocol (BGP) defined in enables independently administered Autonomous Systems (ASes) to exchange reachability information. Each AS determines its routing behavior through local policies, operational procedures, topology, and configuration. An AS may have expectations about how it will originate, accept, select, advertise, or propagate routes for a particular inter-domain connection. An AS operator may make statements about its routing behavior. These expectations and behaviors can be typically configured using existing routing-policy mechanisms. The issue addressed here is not the absence of mechanisms to configure or signal routing behavior. It is whether a commonly understood, issuer-attributable commitment model adds value by bringing together the identity and authority of the issuer, the AS behavior being declared, the applicable scope and conditions, and the evidence available to an external assessor. Intent-Based Networking (IBN) provides general concepts for expressing network goals at an appropriate level of abstraction and translating those goals into network actions. IBN also considers monitoring and assurance to assess whether observed network behavior remains consistent with an intent refering to . Intent classification and scope are further discussed in . These concepts provide the general foundation for this document. has considered IBN for routing and path selection, IBN for interconnection, and multi-domain intent resolution. has considered conventional IP peering and more advanced interconnection services. However, this document examines a more specific question: How can an AS make an attributable declaration about its own expected BGP routing behavior, scoped to defined inter-domain connections and route classes, so that another independently administered domain can understand the declaration and assess it against suitable routing evidence? A general network intent and a routing behavior commitment may serve different purposes. An intent typically expresses operational goals and desired outcomes for a network or service. A routing behavior commitment is a more explicit statement attributable to a particular AS or an entity authorized to act on its behalf, describing behavior for which that AS takes operational responsibility. This distinction matters in inter-domain environments. The AS that makes a declaration, the AS that consumes it, and the entity that observes routing behavior may be in different administrative domains. A remote observer may not have access to the issuer's internal policy configuration, complete routing information bases, or all Adj-RIB-Out state. Consequently, a declaration needs to identify the behavior being claimed and its scope, while an assessment needs to state what the available evidence can and cannot establish.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Inter-Domain Routing Behavior Commitment An Inter-Domain Routing Behavior Commitment (IRBC) is a candidate, issuer-attributable declaration in which an AS or an entity authorized to act on its behalf states the routing behavior that the subject AS undertakes to provide or enforce for specified inter-domain connections, route scopes, directions, and operating conditions. An IRBC may identify: (1) the subject's connection role in the specified inter-domain relationship; (2) the associated routing behavior; and (3) the commitment context that defines applicable scope, direction, conditions, exceptions, validity, and responsibility. The term commitment denotes an attributable operational statement of responsibility. It does not by itself establish that the behavior has been followed, create a legal obligation, or establish a bilateral agreement. The need for a distinct IRBC model, rather than an extension or specialization of an existing interconnection-intent representation, is a question for further.

Issuer and Subject The issuer is the entity that creates and publishes or otherwise provides an IRBC. The subject is the AS or routing domain whose behavior is described. The issuer may be the subject itself or an entity authorized to act on its behalf. A future model needs to distinguish authority over an AS number, authority over address resources, and operational authority over routing policy where those authorities differ.

Connection Role A connection role describes the functional relationship or responsibility of the subject AS with respect to a specified neighboring AS or inter-domain connection. A role is relative to the connection and may be scoped by route class or operational condition. It is not necessarily a global property of an AS and is not limited to the finite BGP Role values defined in .

Declared Behavior Declared behavior is the routing behavior specified by an IRBC. A declaration may express a required behavior, a prohibited behavior, a permitted behavior, or a preference. These categories have different semantics and MUST NOT be treated as interchangeable. The connection role provides context for the behavior but does not, by itself, determine all behavior semantics.

Commitment Context The commitment context describes the conditions under which declared behavior applies. It may include route scope, neighboring AS, direction, AFI/SAFI, time interval, operational state, exceptions, and precedence among applicable statements. It does not imply a legal contract or a reciprocal commitment by another AS.

Observed Behavior Observed behavior is information about routing activity or state obtained at a particular observation point and time. Examples include BGP UPDATE messages, Adj-RIB-In or Adj-RIB-Out information, RIB data, BMP feeds, and other operational evidence.

Evidence Evidence is information used to support or refute a claim about observed routing behavior. Evidence has provenance, collection time, observation scope, coverage, and limitations. The absence of an observation is not necessarily evidence that an event did not occur.

External Assessment External assessment is an evaluation of an IRBC by an entity that is independent of, or outside the administrative control of, the issuer. An assessment may report that available evidence supports compliance, supports a violation, or is insufficient to reach either conclusion.

Inter-Domain Routing Scenarios

Route-Class-Specific Export Commitment AS A has an eBGP connection with AS B and applies different export behavior to different route classes. For example, customer routes may be exported to B, while routes learned from another provider are not exported to B, except under a defined operational condition. AS A can implement this behavior using local import and export policy. Such a policy may also be configured and managed using existing policy models. An interconnection intent may specify the desired routing service or associated requirements. The IRBC question is whether AS A can additionally provide an attributable declaration that identifies the route classes, neighbor, direction, exceptions, and conditions for which AS A takes responsibility. An external assessor would need evidence from appropriate observation points to evaluate observed advertisements. A collector that does not observe an advertisement cannot, by that fact alone, prove that AS A did not advertise the route to another neighbor.

Conditional Backup Advertisement AS A declares that it will advertise a specified route class to backup neighbor AS C only when a defined primary-path condition is met. The commitment MUST distinguish a mandatory condition from a preference and identify the time interval and routing scope to which it applies. An external assessment requires evidence about both the advertisement to AS C and the condition claimed to trigger it. A BGP UPDATE observed at one collector may establish that an advertisement occurred at that observation point. It may not establish the complete state of AS A's internal route selection or prove that the primary path was unavailable. The assessment model MUST state when the evidence is sufficient and when the result is indeterminate.

Scope-Dependent Interconnection Behavior Two ASes may apply different routing arrangements to different route classes over what is operationally viewed as the same interconnection. calls a peering relationship "Complex" when more than one BGP Role applies between the same ASes, for example when the relationship is Provider-to-Customer for some prefixes and Peer-to-Peer for others. RFC 9234 specifies that BGP Roles are not configured on an eBGP session with a Complex peering relationship. It is worth noting that per-prefix policies may be used, but there are no in-band measures in that specification to check the correctness of the per-prefix peering configuration. This scenario may motivate a route-scope-specific declaration, but it does not establish that IRBC is necessary. The MUST identify exactly what an IRBC would add beyond the per-prefix policy, existing role and OTC behavior, and the available routing evidence. It MUST also consider whether the same requirement can be met by multiple eBGP sessions, RPA objects, or an extension of an existing interconnection-intent representation.

Control-Plane and Data-Plane Boundary An operator may state an expectation that traffic should traverse a preferred provider or path. However, an AS_PATH observed in the BGP control plane does not necessarily establish the actual data-plane forwarding path. Internal routing, tunnels, policy-based forwarding, ECMP, and other mechanisms may affect packet forwarding. The initial IRBC scope therefore focuses on BGP control-plane behavior, such as route origination, advertisement, propagation, and selected attribute handling. Data-plane commitments are outside the initial scope unless the required data-plane evidence and observation model are separately defined.

Problem Statement

From Local Policy to an Attributable External Declaration An AS can implement routing behavior using local policy, but that configuration does not automatically provide another domain with an interoperable statement of the behavior the AS claims it will perform. Conversely, a published statement does not demonstrate that the AS follows it. A model may be useful to distinguish internal policy, an externally understandable commitment, and evidence of actual behavior. The need for a distinct model MUST be evaluated against existing interconnection-intent structures and IBN assurance functions.

Issuer, Subject, and Authority A declaration can be assessed only if the assessor can identify the issuer, the AS or routing domain that is the subject, and the authority under which the declaration was made. The relevant authority may concern operation of the AS, address resources, or control of routing policy. These do not necessarily belong to the same entity. A general model MUST NOT assume that possession of an ASN or a prefix resource automatically proves authority to make every routing-policy commitment for an AS.

Scope and Behavioral Semantics A statement such as "do not export this route" is incomplete without identifying the route, neighbor or neighbor class, address family, direction, time interval, and applicable conditions. A commitment may express a mandatory behavior, a prohibition, a permission, or a preference. These meanings are distinguishable. The model MUST also address overlapping scopes, exceptions, and conflicting statements.

Evidence and External Observability A commitment does not create the evidence required to assess it. A remote observer may have access to public BGP data, selected route collectors, a limited set of RIBs, BMP feeds, or evidence voluntarily supplied by the issuer. These sources have different coverage and trust properties. BMP defined in provides a protocol for obtaining route views from BGP speakers. Support for Adj-RIB-Out monitoring is specified in . Neither a monitoring feed nor a public collector view SHOULD be assumed to provide complete evidence for every neighbor and every route. The model MUST relate each behavior claim to the evidence needed to assess it and MUST represent observation points, time intervals, provenance, coverage, and limitations. Evidence that a route was observed at one point does not prove that it was or was not advertised to every other neighbor. A missing observation MUST NOT automatically be interpreted as proof that an event did not occur.

Unilateral and Bilateral Statements An AS may make a unilateral declaration about its own behavior. A bilateral interconnection arrangement may require corresponding declarations or an explicit agreement by both parties. A declaration from AS A cannot establish consent or a commitment by AS B. A model MUST preserve the identity and authority of each issuer and provide a way to represent disagreement or inconsistent declarations without silently treating one party's statement as authoritative for the other.

Assessment and Uncertainty The available evidence may support compliance, support a violation, or be insufficient to reach either conclusion. A binary result is therefore not always appropriate. An assessment model SHOULD distinguish:

• Compliant: the available evidence supports that the declared behavior was followed within the stated scope and assessment conditions.
• Violation: the available evidence supports that the declared behavior was not followed within the stated scope and assessment conditions.
• Indeterminate: the evidence is insufficient, incomplete, conflicting, or inapplicable to reach either conclusion.

These outcomes describe assessment confidence and evidence sufficiency. They do not imply that every routing behavior can be independently verified in all deployments.

Lifecycle and Information Disclosure Routing policies and inter-domain relationships change. A declaration may be updated, superseded, withdrawn, or become inapplicable when a connection or route scope changes. An assessor may retain stale or delayed information. A model MUST address validity, versioning, update, withdrawal, revocation, and the relationship between an observation interval and the applicable declaration version. At the same time, publishing a commitment may reveal sensitive information about topology, customers, peering, or traffic engineering. The model SHOULD identify the minimum information required for a meaningful assessment and the limits imposed by selective disclosure.

Positioning and Gap The gap is the absence of a cross-domain, attributable, scope-aware, evidence-relative framework​ for expressing and assessing an AS's own BGP behavior commitments. Specifically:

• No existing mechanism binds a behavior claim to an issuer, subject, and authority​ in a way that an external domain can verify.
• No existing mechanism scopes a behavior claim to connection, route class, direction, and condition​ with explicit semantics for mandatory, prohibited, permitted, and preferred behaviors.
• No existing mechanism defines how external evidence maps to a compliance assessment, including the explicit representation of indeterminate outcomes.

Requirements

Issuer and Subject Attribution A model SHOULD identify the issuer, the subject AS or routing domain, and the authority under which the issuer makes the declaration. It SHOULD distinguish self-issued declarations from delegated declarations and SHOULD NOT infer routing-policy authority solely from prefix ownership or ASN registration.

Self-Commitment and Party Separation A declaration SHOULD be limited to behavior for which the subject or issuer has responsibility. It MUST NOT imply that another AS has accepted a reciprocal commitment. Where a bilateral arrangement is relevant, each party's declaration and evidence SHOULD remain attributable to that party.

Routing-Specific Scope A model SHOULD support scope dimensions relevant to inter-domain routing, which may include:

• subject AS and neighboring AS or inter-domain connection
• AFI/SAFI
• prefix, prefix set, origin AS, or route class
• ingress or egress direction
• relevant BGP behavior, such as origination, advertisement, propagation, or attribute handling
• validity interval and operational conditions
• explicit exceptions and exclusions.

These dimensions are a routing-specific application of the intent scope and network scope concepts in , not a replacement for the general taxonomy.

Behavior Semantics A model SHOULD distinguish mandatory behavior, prohibited behavior, permitted behavior, and preferred behavior. It SHOULD define how conditional statements, exceptions, and precedence are interpreted. A preference MUST NOT be treated as a mandatory obligation, and a permission MUST NOT be treated as a requirement to perform an action. Connection roles may be included as context for a declaration. They SHOULD NOT be equated with the finite BGP Role values defined in , nor SHOULD the model redefine the protocol behavior associated with those values.

Claim-to-Evidence Relationship A model SHOULD identify, for each supported behavior claim, the evidence types that may support an assessment and the limits of those evidence types. Evidence metadata SHOULD include provenance, observation point, collection time, coverage, and integrity properties where available. The model SHOULD permit an indeterminate result when the evidence cannot support a reliable conclusion.

External Assessment A model SHOULD allow an assessor outside the issuer's administrative domain to interpret the declaration and report an assessment without assuming access to the issuer's complete internal configuration or all routing state. It SHOULD state when issuer cooperation or evidence from internal observation points is necessary.

Lifecycle and Consistency A model SHOULD address creation, publication, update, supersession, withdrawal, validity, and revocation. It SHOULD enable an assessor to identify which declaration version applies to a given observation interval and to recognize stale, conflicting, or inconsistent declarations.

Disclosure and Deployment A model SHOULD minimize unnecessary disclosure of internal policy and topology while exposing enough information to make the commitment meaningful and assessable. It SHOULD also consider partial deployment, missing declarations, unsupported behavior types, and unavailable evidence. Absence of an IRBC MUST NOT be interpreted as evidence of misbehavior.

Security Considerations An externally assessable routing behavior commitment introduces security considerations because declarations may influence how other domains interpret an AS's behavior. This document identifies issues for further and does not specify a complete security architecture. An attacker may publish a declaration while impersonating an AS operator or may publish a declaration for an AS that the issuer does not control. A future mechanism needs to authenticate the issuer and determine whether the issuer is authorized to make statements for the subject AS and declared scope. Authority over an ASN, address resources, and routing policy may be held by different entities; these forms of authority MUST NOT be conflated. A declaration may be modified, substituted, replayed, or rolled back to an earlier version. A future model needs to consider integrity protection, version identification, validity intervals, freshness, update, withdrawal, and revocation. An issuer may provide different declarations to different observers, intentionally or accidentally. A signature on an individual declaration does not by itself prevent equivocation. Further work may need to consider consistency mechanisms, auditability, or transparency services. An authentic declaration may describe behavior that the issuer does not follow. Authentication establishes the origin of a declaration, not compliance with it. Assessment requires appropriate evidence and MUST account for incomplete observation and the possibility that some behavior is not externally observable. Evidence may be forged, altered, selectively disclosed, or collected from insufficient observation points. A future framework needs to state the trust placed in routers, collectors, monitoring systems, and evidence providers. It MUST NOT treat an absence of data as proof that an event did not occur. Large numbers of declarations, overlapping scopes, or complex conditional statements may increase storage, distribution, and assessment costs. A future design SHOULD consider bounded complexity, resource limits, and input validation. Declarations may reveal topology, peering relationships, customer categories, or traffic-engineering preferences. A future design SHOULD evaluate what information MUST be disclosed to support a meaningful assessment and what information can remain internal. An assessor may apply a declaration outside its scope or confuse a preference with a mandatory behavior. A declaration by one AS MUST NOT be interpreted as proof that another AS has agreed to a reciprocal behavior. Scope, conditions, exceptions, and issuer responsibility MUST therefore be explicit.

IANA Considerations This document has no IANA actions.

References Normative References This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK] RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK] This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK] To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing. This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community. This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs. This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. This document updates RFC 4271 by defining the default behavior of a BGP speaker when there is no Import or Export Policy associated with an External BGP session. The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out. A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS. This document updates RFC 6811. This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. Intent is an abstract, high-level policy used to operate a network. An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle. This document mostly discusses the concept of network intents, but other types of intents are also considered. Specifically, this document highlights stakeholder perspectives of intent, methods to classify and encode intent, and the associated intent taxonomy; it also defines relevant intent terms where necessary, provides a foundation for intent-related research, and facilitates solution development. This document is a product of the IRTF Network Management Research Group (NMRG). This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. China Mobile China Mobile Department of Computer Science and Engineering Huawei Xidian University Telefonica Huawei This document proposes a methodology to construct an Intent-Based Networking (IBN) system. According to this methodogy, it decribes several use cases of IBN. The methodology for the IBN system includes data collection for system awareness in the IBN system and then the construction of the IBN system. This construction consists of intent translation, policy translation, policy verification, policy deployment, policy monitoring, policy validation, policy optimization, and intent report. In addition, practices are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. Finally, this document discusses three aspects for the deployment of the IBN system on the real world. They are Multi-Domain Dichotomy for IBN, the Integration of IBN and Network Digital Twin (NDT), and IBN with Artificial Intelligence (AI). Telefonica NTT Synelixis This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. BSD Software Development Yandex JetLend Internet Initiative Japan Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its transit providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. Yandex Qrator Labs Internet Initiative Japan & Arrcus, Inc. Arrcus BSD Software Development USA National Institute of Standards and Technology This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations.

Scope and Non-Goals This document focuses on the problem statement and requirements for issuer-attributable, externally assessable routing behavior commitments in inter-domain BGP environments. The following topics are outside the scope of this document:

• redefining the general concepts, taxonomy, lifecycle, or architecture of IBN
• defining a general-purpose intent language, schema, ontology, or translation engine
• defining an IBN controller, multi-domain orchestrator, policy compiler, or closed-loop automation architecture
• defining a general interconnection-intent model or replacing the work in
• defining a complete routing-policy language or replacing RPSL or Routing Policy YANG
• defining an IRBC wire format, serialization, or information model
• defining a new BGP attribute, community, capability, or AFI/SAFI
• defining an RPKI signed-object profile, trust-anchor model, or distribution protocol
• defining a universal verification algorithm or claiming that all routing behavior can be externally verified
• replacing ROA/ROV, ASPA, ASRA, RPA, BGPsec, FC-BGP, BGP Roles, or OTC
• defining data-plane forwarding commitments in the absence of a corresponding evidence model.

IBN systems may be used to generate, manage, or assess routing behavior commitments. Existing routing-security mechanisms may provide authorization or evidence relevant to an assessment. Any future protocol or information-model work requires separate analysis and coordination with the appropriate IETF or IRTF groups.

Relationship to Existing and Mechanisms This section identifies the capabilities that an IRBC model would reuse and the areas that require further investigation. It does not imply that the referenced work is deficient or that an IRBC MUST be implemented as a new protocol object.

IBN IRBC is related to IBN, but it is not a replacement for or a new version of the general IBN model. IRBC and IBN operate at different levels of abstraction and address different questions. IBN is a management paradigm that translates operator goals into network actions and closes the loop through monitoring and assurance. IRBC is a cross-domain declaration and assessment paradigm. IRBC asks how an AS can make an attributable, scoped statement about its own BGP behavior, and how an external domain can evaluate that statement using limited evidence. An IBN system MAY consume or produce IRBCs, but IRBC does not depend on an IBN system for its definition or validity. describes general IBN concepts and functions, including intent fulfillment, intent translation, orchestration, monitoring, intent compliance assessment, and the intent lifecycle. provides a methodology for classifying intents, including intent users, intent types, intent scope, network scope, abstraction, and lifecycle. This document reuses these foundations and does not define another general intent taxonomy or lifecycle. An IRBC is a routing-specific declaration associated with an AS's responsibility for its own inter-domain routing behavior. It is more explicit and technically scoped than a high-level service goal. An IBN system may derive an IRBC from an operator's intent and local policy, exchange it with another domain, and use monitoring or evidence services to assess it. Those IBN system functions are outside the definition of an IRBC. The distinction from general Intent Assurance is also specific. already describes the comparison of observed network behavior with intended behavior. The question here is how such assurance applies when the declaration is attributable to one AS, the assessor belongs to another administrative domain, and the evidence is limited to what can be obtained or trusted across that boundary. This document therefore investigates a routing-specific external-assessment problem; it does not claim to introduce the general concept of assurance. defines general IBN concepts and functions, including intent fulfillment and intent assurance. In particular, Intent Assurance compares observed network behavior with the behavior expected by an intent. provides dimensions for classifying intents, including user, type, scope, network scope, abstraction, and lifecycle. IRBC SHOULD reuse these foundations. It SHOULD NOT introduce a second general definition of intent, a competing intent taxonomy, a new generic intent-scope model, or a separate generic intent lifecycle. The routing-specific question under consideration is whether a declaration attributable to a particular AS or authorized operator, and intended to be assessed by another administrative domain, requires additional semantics beyond the general IBN concepts. discusses IBN for routing and path selection, including service-function chaining and SRv6-oriented scenarios. It also includes an IBN-for-Interconnection scenario in which one provider selects an interconnection intent and specifies target resources, another provider maps intent types to protocols or APIs and establishes or provisions the requested resources, and monitoring information is collected and analyzed during the assurance phase. This work already covers routing-related intent, interconnection fulfillment, monitoring-based assurance, and multi-domain intent considerations. IRBC MUST NOT be presented as filling a general absence of these capabilities. Its proposed focus is narrower: a declaration attributable to the subject AS about that AS's own BGP control-plane behavior, together with the evidence semantics relevant to an assessor outside the subject's administrative domain. considers the use of intents to express advanced interconnection requirements beyond traditional IP peering. It discusses interconnection intent types, an intent lifecycle, protocol aspects, and a declarative intent structure. The structure includes Expectation, Target, Condition, and Context. Its conventional IP peering example includes peer AS identification, peer IP address, peering authentication, and traffic levels. Its fulfillment and assurance procedures describe a provider requesting or specifying resources, a provider mapping intent to protocols or APIs and provisioning resources, monitoring telemetry, internal checks of committed service-level objectives, and reporting or analyzing metrics against the request. also refers to the interconnection-intent work when describing its interconnection scenario. Accordingly, IRBC MUST NOT claim novelty for cross-domain intent expression, peer identification, intent targets, conditions, context, fulfillment, or monitoring-based service assurance. The distinction investigated by IRBC is narrower and concerns the object and responsibility of the declaration. An interconnection intent can express a request, expectation, or desired service outcome involving capabilities or resources offered by another provider. An IRBC instead concerns a statement made by an AS about routing behavior for which that AS takes responsibility. The distinction is not absolute: an interconnection intent may include provider-side behavior expectations, and an IBN assurance system may assess those expectations. The question is whether a reusable AS-attributable declaration, specifically scoped to BGP behavior and designed for assessment by an external domain, provides semantics that are not adequately captured by the existing interconnection-intent model and its assurance workflow. An interconnection intent and an IRBC may be related. An interconnection intent may lead to an operator configuring behavior and issuing one or more IRBCs; an IRBC may provide a declaration that an interconnection-intent assurance process can consume. Conversely, an IRBC may exist without a preceding bilateral interconnection-intent exchange. The two concepts SHOULD NOT be assumed to be separate protocol objects until this relationship has been evaluated through concrete scenarios.

BGP Policy and Policy Representation BGP policy controls route import, selection, and export . Operational guidance describes common BGP security and policy practices . RPSL provides a language for describing routing policies ; RPSLng extends this approach to IPv6 routing policy ; and the Routing Policy YANG Data Model provides a vendor-neutral model for configuring and managing routing policy . BGP Communities , Extended Communities , and Large Communities can carry operator-defined signaling information. defines default eBGP route propagation behavior when import or export policy is absent. These mechanisms demonstrate that routing policy can be configured, represented, and signaled. IRBC MUST NOT claim that routing policy cannot be expressed or that BGP has no means to carry policy-related information. The question is whether a policy representation or signal, by itself, also identifies an authorized issuer, states an externally understandable commitment for a defined scope, and provides semantics for assessing the commitment using evidence obtained from another domain. These properties depend on the applicable policy model, trust relationships, and evidence mechanisms; they are not automatically provided by the existence of a policy language or community value.

Routing-Security Mechanisms RPKI Route Origin Authorizations (ROAs) defined in provide digitally signed authorization for an AS to originate routes to specified prefixes. BGP Prefix Origin Validation defined in defines how a BGP speaker determines the origin-validation state of a route. Operational guidance for applying origin validation on eBGP export is provided by . ASPA provides signed provider-authorization information, and ASPA-based AS_PATH verification is specified in current SIDROPS work . BGPsec defined in provides cryptographic protection for AS_PATH propagation information in BGP UPDATE messages . IRBC is not a replacement for ROA/ROV, ASPA, BGPsec, BGP Roles, or OTC. Any proposed routing-behavior semantics MUST be shown to add value beyond the specific authorization and propagation properties already addressed by those mechanisms and MUST coexist with them. BGP Roles and the Only-to-Customer (OTC) defined in attribute define role negotiation and specific route-leak prevention and detection behavior. The working definition and classification of BGP route leaks are described in . defines a finite set of BGP Roles for eBGP sessions and corresponding route-propagation rules. It also identifies complex peering relationships, for which BGP Roles are not configured on a single eBGP session, and notes that per-prefix policies may be used without in-band measures to check the correctness of the per-prefix peering configuration. These details are relevant to scope-dependent routing behavior, but IRBC MUST NOT redefine BGP Role or OTC semantics.