What Is PA-ORF? The Beginner's Guide to the BGP Filter That Stops Path Attributes Leaking

CodexFuse Team · 2026-11-05T17:50:51.846Z · 22 min read min read

What Is PA-ORF? The Beginner's Guide to the BGP Filter That Stops Path Attributes Leaking

What Is PA-ORF?

What is PA-ORF? PA-ORF stands for Path Attribute Outbound Route Filter, and it is a proposed BGP extension that lets a BGP speaker ask its peer to suppress, remove, refine, or constrain selected path attributes when that peer builds outbound UPDATE messages. The proposal lives in the individual Internet-Draft draft-wang-idr-path-attribute-orf-01, written by Aijun Wang of China Telecom with Changwang Lin of New H3C Technologies and Shunwan Zhuang of Huawei, and dated 3 November 2026 (posted to the datatracker on 2 November 2026).

In plain English, PA-ORF is a polite request a router sends to its neighbour: "Keep advertising the route to me, but leave this piece of metadata out of it." The route itself still arrives. Only the unwanted attribute is stripped, refined, or held back.

PA-ORF is a work in progress, not an adopted standard, and it expires on 7 May 2027 unless a new revision replaces it. No router vendor has announced support, no implementation exists in public, and the draft itself says it is inappropriate to cite Internet-Drafts as anything other than work in progress.

That matters because the internet's routing system runs on trust between peers. BGP speakers exchange routes, and each route carries path attributes that describe the path.

When an attribute is only meaningful inside one network but gets forwarded everywhere anyway, it can leak information, confuse route selection, or even crash a router. PA-ORF is the first standard mechanism that would let the receiving side ask for the attribute to be removed at the source.

Debugging a deployment often starts with checking whether the files on the server are the ones you think they are, and the SHA-256 hash generator is a free tool for exactly that check. And because BGP runs on the machines that serve your traffic, VPS hosting is the natural companion topic: a private server you control is where routing policy, and one day possibly PA-ORF, actually lives.

What Is "Attribute Escape"? The Leak PA-ORF Is Trying to Stop

Attribute escape is the name Jeff Haas gave the problem in a companion draft from June 2026: path attributes that were only ever meant to work inside one network get carried beyond their intended scope by routers that do not understand them. The leak happens because of a rule written into BGP itself more than twenty years ago. The PA-ORF BGP proposal targets exactly this leak.

RFC 4271, the BGP standard from January 2006, says that when a router receives an attribute it does not recognise, and that attribute is marked Optional Transitive, the router SHOULD accept the path and MUST pass the attribute along to its peers, setting a Partial flag. The rule exists for a good reason: it lets new BGP features roll out gradually without upgrading every router on the internet first.

The side effect is that an attribute can be blindly forwarded from autonomous system to autonomous system, across the whole internet, by routers that have no idea what it means. Haas's draft warns that escaped attributes can disclose sensitive information, cause improper routing, blackhole traffic, and in the worst case crash a router's BGP stack, because a malformed attribute is grounds for a BGP session reset under RFC 4271, and the reset hits the router that merely forwarded the route, not the one that created the bad attribute.

The clearest example comes from the Tunnel Encapsulation Attribute, known as TEA and defined in RFC 9012. TEA tells routers how to tunnel traffic, and it is meant to be stripped at eBGP boundaries by default. But a boundary router that does not understand TEA cannot strip it, so TEA crosses into the neighbouring network, whose routers may then use those tunnel instructions inside their own network.

Today's answer to this problem is local export policy: operators configure their own routers to strip unwanted attributes at administrative boundaries. That works, but the draft points out that those policies are locally configured, hard to coordinate dynamically, and often vendor-specific.

There is no standard mechanism by which a receiving speaker can request that a peer avoid sending a selected class of path attributes while continuing to advertise the associated route. PA-ORF is that mechanism.

How Does BGP Carry Path Attributes?

BGP is the protocol that stitches the internet's autonomous systems together, and it moves routing information in UPDATE messages. One UPDATE can advertise new routes, withdraw old ones, or do both at once. Each route it advertises carries path attributes, which are the metadata describing the path: where the route came from, which networks it crossed, and any extra instructions attached to it.

Every path attribute is a triple of a type, a length, and a value. The type itself starts with a flags octet, and two of its bits decide the attribute's fate: the Optional bit says whether every BGP implementation must understand it, and the Transitive bit says whether a router that does not understand it should pass it along anyway.

RFC 4271 sorts attributes into four categories. Well-known mandatory attributes, such as ORIGIN, AS_PATH, and NEXT_HOP, must be present in every UPDATE and understood by every implementation. Well-known discretionary attributes, such as LOCAL_PREF, must be understood but need not be present.

Optional transitive attributes may be absent, but if a router does not recognise one, it must pass it on. Optional non-transitive attributes may be absent, and an unrecognised one is quietly dropped.

The third row is the whole story. Optional transitive is the category that carries the leak, because the MUST-pass rule turns every router on a path into an unwitting courier for attributes it cannot read. PA-ORF targets exactly that category, while leaving the other three untouched.

What Is an Outbound Route Filter?

A BGP outbound route filter, or ORF, is an older idea that PA-ORF builds on. RFC 5291, published in August 2008, defines a mechanism that lets a BGP speaker send a set of filters to its peer, which the peer then uses to constrain its outbound routing updates. The filters travel inside ROUTE-REFRESH messages, and they live only as long as the BGP session does.

Classic ORF answers one question about whole routes: should this route be advertised to this peer at all? A router can say "only send me routes matching this prefix list" and its peer will hold back the rest. That saves bandwidth and processing, because unwanted updates are never generated in the first place.

PA-ORF asks a different question about the inside of a route: send me the route, but leave this attribute out of it. The two ideas share the same machinery, the ORF capability negotiation and the ROUTE-REFRESH transport from RFC 5291, and PA-ORF introduces no new BGP path attribute and no new BGP message type. It simply defines four new filter types that operate on attributes instead of on routes.

The age gap is worth noting. RFC 5291 is from August 2008, which makes the ORF framework 18 years and 3 months old when the PA-ORF revision appeared in November 2026.

The transitive-attribute rule it works around is older still: RFC 4271 dates to January 2006, 20 years and 10 months before PA-ORF. Both rules predate most of the attributes that now escape through them.

PA-ORF also joins a wave of new protocol drafts being explained on this site. What Cuback is covers the ACK-driven rewrite of TCP congestion control, another November 2026 draft that reworks a decades-old mechanism without replacing it.

The Four PA-ORF Types at a Glance

The draft defines four filter types, and it asks IANA for the ORF type values 67 to 70 for them. Those numbers are requested, not assigned, and the four new registries the draft asks IANA to create do not exist yet. Only the first type is effectively required: an implementation that supports the specification SHOULD support the Attribute Type filter, while support for the other three is optional unless a deployment profile demands it.

Every PA-ORF entry carries the same common shape: an action (add, remove, or remove all), a match (permit or deny), a disposition that says what happens to matching attributes, and a sequence number, with lower values evaluated first. When two filters disagree, the most specific one wins: the subtype filter beats the type filter, which beats the unknown-attribute filter, which beats the propagation-scope filter.

Path Attribute Type ORF: Drop the Whole Attribute

The Path Attribute Type ORF is the coarse-grained filter, and it is the one the draft expects every implementation to support. The receiving router names a BGP path attribute by its IANA type code and asks the peer to strip the entire attribute from outbound UPDATEs for that address family.

The route itself still gets advertised. Only the attribute disappears. The draft's example is a router at an inter-domain boundary that wants the reachability information but not a domain-specific Segment Routing attribute that belongs to the neighbouring network's interior.

There is one guard rail. If the attribute is mandatory, or removing it would make the UPDATE invalid, the sender must not emit a broken advertisement. In that case it should suppress the route or fall back to local policy instead of sending an UPDATE that violates the protocol.

Path Attribute Subtype ORF: Drop Just One Piece Inside

Some path attributes are containers: they hold sub-elements such as TLVs, tunnel types, community structures, or encapsulation information. Deleting the whole container would throw away useful information along with the unwanted piece, so the Subtype filter works one level deeper.

The receiving router names a sub-element to remove and keeps the rest of the attribute intact. The draft's initial selector types cover Tunnel Type, Prefix-SID TLV Type, and BGP-LS TLV Type. The mailing-list discussion gives a concrete case: inside the Tunnel Encapsulation Attribute, a peer might accept one encapsulation type and reject another, such as a VxLAN tunnel type it has no use for.

This is the filter that drew the sharpest criticism in the IDR mailing list, because new attributes bring new sub-element types that a filter written today cannot name. The draft's answer is that the selector registry can grow alongside new attributes, and a further ORF type could cover sub-sub-TLVs if one is ever needed.

Unknown Path Attribute ORF: Drop What Nobody Understands

The Unknown Path Attribute filter matches attributes by their flag bits, typically Optional and Transitive both set, and it applies only to attributes the sending router does not recognise at outbound-processing time. If the sender does recognise the attribute, the Type or Subtype filter is the precise tool for it.

This filter is designed for administrative boundaries, route servers, and inter-domain route-reflection designs, where the operator's policy is simply "do not forward attributes nobody here understands." It is the bluntest of the four filters, and it is also the one whose purpose is hardest to explain to a sceptic: if the receiver already knows the attribute's type, why not filter by type instead?

The draft's answer is that the unknown filter catches attributes the sender cannot name, which is exactly the case where the leak is worst. A router that does not recognise an attribute cannot write a type-based rule for it, but it can still match the flag pattern and drop everything that looks unknown and transitive.

Path Attribute Propagation Scope ORF: Draw a Boundary Line

The Propagation Scope filter is the odd one out, because it works in the opposite direction from the other three. Instead of the receiver asking for something to be removed, the sender attaches a propagation boundary to an attribute it sends, telling downstream speakers how far the attribute may travel.

The draft defines five scopes. Local means do not re-advertise the attribute at all. AS means it may stay inside the receiving autonomous system.

Confederation keeps it inside the confederation. Bilateral keeps it inside the bilateral relationship and forbids redistributing it to unrelated peers. Internet means no extra restriction beyond normal BGP behaviour.

When the boundary is crossed, one of three actions applies: strip the attribute beyond the scope, suppress the route beyond the scope, or treat the route as withdrawn beyond the scope.

The mechanism is explicitly cooperative: it only binds a peer that negotiated and accepted this filter type, and a router that does not want a peer influencing its downstream behaviour should not advertise willingness to receive it.

The draft calls this type the one "intended to address the root of many Attribute Escape scenarios," because it lets the attribute's originator state the boundary instead of leaving every downstream router to guess it. MCP over MoQ is another recent draft explainer on this site, covering a different corner of the same November 2026 wave of protocol proposals.

How a PA-ORF Request Travels in Five Steps

A PA-ORF exchange follows the same shape as any ORF negotiation, with the filter applied at the very end of outbound processing. The five steps below describe one request from start to finish.

1. Two BGP speakers open a session and advertise the PA-ORF capability for each address family they care about, saying whether they can send entries, receive entries, or both. A speaker must not send PA-ORF entries for an address family unless its peer advertised willingness to receive them.
2. The receiving speaker decides which attributes it does not want, writes PA-ORF entries for them, and sends those entries to its peer inside a ROUTE-REFRESH message. Each entry names the filter type, the action, the match, and the disposition.
3. The peer installs the entries as part of its per-neighbour outbound processing state. The state lives only as long as the session does, and the entries must be re-advertised after any session reset.
4. When the peer builds its next outbound UPDATE, it runs best-path selection first, then its own local export policy, and only then applies PA-ORF. PA-ORF never overrides local policy, and a peer can request less information but cannot require the advertising speaker to send more.
5. The peer encodes the UPDATE with the filtered attributes removed, refined, or held back, and transmits it. With an immediate refresh the affected routes are re-advertised at once; with a deferred refresh the state is installed without the churn of re-advertising everything immediately.

The default and preferred disposition is attribute stripping: the route stays advertised and the selected attribute, or the selected piece of it, is omitted. Route suppression is reserved for cases where stripping would make the advertisement semantically invalid, and treating the route as withdrawn covers the cases where the advertisement cannot safely be encoded without the attribute.

That ordering, local policy first and PA-ORF second, is the draft's answer to the trust question. The advertising speaker keeps final authority over what it advertises, and the requesting speaker only ever asks for less. What MASQUE is explains another protocol in the same family of recent drafts, one that lets a client proxy traffic through a server using QUIC.

What Happens When Things Go Wrong?

PA-ORF has three dispositions, and they cover the full range from gentle to severe. Attribute stripping is the default: remove the attribute or its sub-component and keep advertising the route.

Route suppression holds back the whole route. Treating the route as withdrawn applies withdrawal semantics when the advertisement cannot safely be encoded without the attribute.

Errors are handled gently by design. A malformed PA-ORF entry must not reset the BGP session; the receiver ignores it and logs it. That is a deliberate contrast with the malformed-attribute rule in RFC 4271, where a bad attribute can force a session reset.

The security section is equally careful. A speaker should accept PA-ORF only from peers authorised to influence its outbound filtering, because a malicious or careless peer could use it to remove attributes needed for correct forwarding, suppress routes, or hide policy-relevant information.

Implementations should log installed entries so operators can see what a peer asked for. PA-ORF does not change the security properties of the underlying BGP session, and operators should treat it as a cooperative mechanism, not as a substitute for explicit policy at important administrative boundaries.

One operational warning is worth remembering. Broad PA-ORF entries combined with immediate refresh can cause many routes to be re-advertised at once, which is update churn. Deferred refresh exists to reduce that cost, and on a route reflector or route server, entries from one client apply only to advertisements to that client.

Why Some BGP Experts Push Back

PA-ORF has not had a smooth reception. The IDR mailing-list thread that ran from 25 to 31 August 2026, a seven-day debate involving exactly three people, produced no consensus, no adoption call, and no third-party supporter. The only voices besides the author were two critics, and their objections are on the record.

Robert Raszuk, writing on 27 August 2026, called the proposal "detached from reality." His argument is that if a router knows what it wants to drop, stripping it on receipt is extremely easy and cheap, so pushing the filter to the peer is pointless. Worse, it forces the peer to generate UPDATEs per neighbour, which is expensive, and it breaks BGP's trust model, because the protocol assumes a peer knows why it packs the attributes it packs. In his words, "BGP4 is not a pub-sub message bus," and the information in an attribute might be useful to someone further downstream even if the immediate receiver does not need it.

Donatas Abraitis made the engineer's version of the same point from 25 August 2026 onwards. Inbound stripping already exists in implementations, he wrote, and ORF compliance is voluntary: a peer may simply ignore the request, so "you can't trust" it. He called the subtype filter unnecessary complexity, noted that future attributes will bring sub-element types a filter written today cannot name, and asked why the unknown-attribute filter is needed at all when unknown attributes already have a type.

Raszuk narrowed his objection in a follow-up on 31 August 2026. To push a deny filter by type, the receiving speaker must already recognise the type, so the only case where PA-ORF prevents the malformed-attribute problem is where the attribute's length is malformed. He left open whether that narrow case justifies the mechanism at all.

The author's defence is that stripping at the source decreases the risk that receiving peers act on unwanted attributes, and that the propagation-scope filter solves a problem no current mechanism addresses: controlling how far an attribute travels after it leaves the originator. The November revision changed no technical content in response to the criticism; it only added two co-authors. The author has requested a 10-minute presentation slot for PA-ORF at IETF 127, in the IDR working group's Friday session on 20 November 2026, 87 days after the first draft appeared, but that slot is requested, not confirmed.

One more caution belongs here. The November 2026 trigger for this article is the -01 revision, 70 days after the -00 of 25 August 2026, and the revision changed nothing technical. The concept is about two and a half months old, not a November launch, and nothing in the draft promises a product, a tool, or a deployment date.

Sources

1. Aijun Wang, Changwang Lin, Shunwan Zhuang, "Path Attribute Outbound Route Filter (PA-ORF) for BGP-4", draft-wang-idr-path-attribute-orf-01, 3 November 2026, expires 7 May 2027. https://datatracker.ietf.org/doc/draft-wang-idr-path-attribute-orf/

2. Aijun Wang, "Path Attribute Outbound Route Filter (PA-ORF) for BGP-4", draft-wang-idr-path-attribute-orf-00, 25 August 2026, expires 26 February 2027. https://datatracker.ietf.org/doc/draft-wang-idr-path-attribute-orf/00/

3. Author-tools diff between draft revisions -00 and -01, showing metadata-only changes. https://author-tools.ietf.org/iddiff?url1=draft-wang-idr-path-attribute-orf-00&url2=draft-wang-idr-path-attribute-orf-01

4. Y. Rekhter, T. Li, S. Hares (eds.), "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. https://www.rfc-editor.org/rfc/rfc4271.txt

5. E. Chen, R. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. https://www.rfc-editor.org/rfc/rfc5291.txt

6. Jeff Haas, "BGP Attribute Escape", draft-haas-idr-bgp-attribute-escape-05, June 2026, expires 13 December 2026. https://datatracker.ietf.org/doc/html/draft-haas-idr-bgp-attribute-escape

7. IETF IDR mailing-list thread, "Re: FW: New Version Notification for draft-wang-idr-path-attribute-orf-00.txt", 25-31 August 2026, including Robert Raszuk's message of 27 August 2026 and Donatas Abraitis's messages of 25-27 August 2026. https://mailarchive.ietf.org/arch/msg/idr/O-7lndwnyZd0tyW9cQ0THR4P6Zc/

8. Robert Raszuk, follow-up message in the same thread, 31 August 2026. https://mailarchive.ietf.org/arch/msg/idr/fraBbNdIrlkF7zEYmsp1Jb0CvdI/

9. Aijun Wang, request for a 10-minute PA-ORF presentation slot at IETF 127, IDR working group, 22 October 2026. https://mailarchive.ietf.org/arch/msg/idr/zY0-9NLlol9SUQkQ6ZFeA8FvIx8/

Frequently Asked Questions

What is PA-ORF in simple terms?

PA-ORF is a proposed BGP feature that lets a router ask its neighbour to leave selected path attributes out of the route updates it sends. The route still arrives, but the unwanted metadata is stripped at the source instead of being forwarded blindly across networks.

Is PA-ORF a standard yet?

No. PA-ORF is an individual Internet-Draft, revision -01, dated 3 November 2026 and expiring 7 May 2027. It has not been adopted by the IDR working group, it has no RFC number, and no router vendor has announced an implementation.

PA-ORF vs ORF: What Is the Difference?

Classic ORF, defined in RFC 5291 from 2008, filters whole routes: it answers whether a route should be advertised to a peer at all. PA-ORF filters the attributes inside a route: it answers whether a particular piece of metadata should travel with a route that is advertised anyway. Both use the same capability negotiation and ROUTE-REFRESH transport.

Why do BGP path attributes leak across networks?

RFC 4271 requires routers to pass along Optional Transitive attributes they do not recognise, with the Partial bit set. That rule lets new features roll out gradually, but it also means an attribute meant for one network can be forwarded across the whole internet by routers that cannot read it. Jeff Haas's companion draft calls this attribute escape.

Can PA-ORF break BGP routing?

It is designed not to. The default action strips only the attribute and keeps the route advertised, local export policy always runs before PA-ORF, a malformed PA-ORF entry is ignored and logged instead of resetting the session, and the draft says a speaker should accept PA-ORF entries only from authorised peers. The open criticism is different: two IDR experts argue the mechanism is unnecessary, because inbound stripping already does the same job more simply.