Internet Initiative Japan & Arrcus

5147 Crystal Springs Bainbridge Island Washington 98110 US randy@psg.com

Deutsche Telekom Cisco

170 West Tasman Drive San Jose CA 95134 USA jheitz@cisco.com

A BGP speaker may perform 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 uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in only when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning.

This document does not change the protocol or semantics of of RPKI-based origin validation. It highlights an important use case of origin validation in eBGP egress policies, explaining specifics of correct implementation in this context. As the origin AS may be modified by outbound policy, policy semantics based on RPKI Origin Validation state MUST be able to be applied separately on distribution into BGP and on egress. When applied to egress policy, the effective origin AS MUST be used to determine the Origin Validation state. The effective origin AS is that which will actually be the origin AS in the announcement. It might be affected by removal of private AS(s), confederation, AS migration, etc. If there are any AS_PATH modifications resulting in origin AS change, then these MUST be taken into account.

It is assumed that the reader understands BGP, , the RPKI, , Route Origin Authorizations (ROAs), , RPKI-based Prefix Validation, , and Origin Validation Clarifications, .

BGP implementations supporting RPKI-based origin validation SHOULD provide the same policy configuration primitives for decisions based on validation state available for use in ingress, redistribution, and egress policies. When applied to egress policy, validation state MUST be determined using the effective origin AS of the route as it will (or would) be announced to the peer. The effective origin AS may differ from that of the route in the RIB due to commonly available knobs such as: removal of private ASs, AS path manipulation, confederation handling, etc. Egress policy handling can provide more robust protection for outbound eBGP than relying solely on ingress (iBGP, eBGP, connected, static, etc.) redistribution being configured and working correctly - better support for the robustness principle.

Configurations may have complex policy where the final announced origin AS may not be easily predicted before all policies have been run. Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies. An operator SHOULD be able to list what announcements are not sent to a peer because they were marked Invalid, as long as the router still has them in memory.

This document does not create security considerations beyond those of and .

This document has no IANA Considerations.