BGP Extensions for Source Address Validation Networks (BGP SAVNET)

Introduction Source address validation (SAV) is essential for preventing source address spoofing attacks (e.g., DDoS based on source address spoofing ) and tracing back network attackers. For a network, SAV mechanisms can be deployed on edge routers or aggregation routers for validating the packets from the connected subnets or neighboring ASes . ACL-based ingress filtering can be used for SAV, which, however, has high operational overhead problems in dynamic networks and also has limited capacity of rules. Many SAV mechanisms, such as strict uRPF, loose uRPF, and EFP-uRPF , leverage routing information to automatically generate SAV rules. The rules indicate the wanted incoming directions of source addresses. The packets with specified source addresses but from unwanted directions will be considered invalid . However, there may be inaccurate validation problems under asymmetric routing . This is because these uRPF mechanisms are "single-point" designs. They leverage the local FIB or local RIB table to determine the incoming interfaces for source addresses, which may not match the real incoming directions. That is, purely relying on the original IGP or BGP protocols to obtain routing information for SAV rule generation cannot well meet the requirement of accurate validation. This document proposes an extension of BGP protocol for SAV, i.e., BGP SAVNET. Unlike existing "single-point" mechanisms, BGP SAVNET allows coordination between the routers within the network or the ASes outside the network by propagating SAV-related information through extended BGP messages. The propagated information can provide more accurate source address information and incoming direction information than the local FIB and RIB tables. The routers with BGP SAVNET can automatically generate accurate SAV rules with reduced operational overhead. The BGP SAVNET protocol is suitable to generating SAV rules for both IPv4 and IPv6 addresses. The SAV rules can be used for validating any native IP packets or IP-encapsulated packets.

Terminology SAV: Source address validation, an approach to preventing source address spoofing. SAV Rule: The rule that indicates the valid incoming interfaces for a specific source prefix. SAV Table: The table or data structure that implements the SAV rules and is used for source address validation in the data plane. SPA: Source prefix advertisement, i.e., the process for advertising the origin source addresses/prefixes of a router or an AS. SPD: Source path discovery, i.e., the process for discovering the real incoming directions of particular source addresses/prefixes.

Requirements Language 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.

BGP Protocol Relationship The BGP extensions for BGP SAVNET follow a backward compatible manner without impacting existing BGP functions. New BGP SAVNET subsequent address families will be introduced under the IPv4 address family and the IPv6 address family, respectively. The BGP UPDATE message (specifically the MP_REACH_NLRI and the MP_UNREACH_NLRI attributes) and the BGP Refresh message will be extended. AFI and SAFI can be used for distinguishing the BGP SAVNET messages from other messages. A few existing path attributes such as Originator_ID and Clister_list or new defined path attributes MAY be used for BGP SAVNET. Actually, most existing path attributes are not necessarily required for BGP SAVNET. However, if the unnecessary path attributes are carried in BGP updates, they will be accepted, validated, and propagated consistent with the BGP protocol.

BGP SAVNET Solution

Application Scenarios and Goals BGP SAVNET aims to generate accurate SAV rules for most use cases including asymmetric routing. An SAV rule indicates the valid incoming interfaces for a specific source address/prefix. A router with BGP SVANET will locally maintain a SAV table storing the SAV rules. The SAV table can be used for validating data packets. shows the application scenarios where BGP SAVNET will enable SAV in data plane. There are generally two kinds of scenarios: SAV within an AS and SAV between ASes. SAV within an AS can prevent local customer networks (subnets or stub ASes) from generating source address spoofed packets and block external packets with internal source addresses. SAV rules are generated without any cooperations or interactions (such as prefix advertisements) between the local AS and subnets/other ASes. In contrast, SAV between ASes aims to checking the external packets spoofing other ASes' source addresses. Cooperations or interactions between the local AS and other ASes are required.

SAV within an AS
- Edge/Border routers: SAV can be deployed at '*' or '#' for checking the validity of the packets from customer networks and Internet.
- Aggregation routers: Aggregation routers can do validation at 'x' for any arrival packets.
SAV between ASes
- Border routers connecting other ASes: SAV can be deployed at '#' for checking the validity of the packets from other ASes.

BGP SAVNET application scenarios

SAV within an AS: Solution for Edge/Border Routers shows a comprehensive example of application scenarios which includes different kinds of external interfaces. On the edge routers that connect to customers, BGP SAVNET can be enabled at access interfaces for validating outbound packets from subnets or stub ASes. On the border router, BGP SAVENT also can be applied at the external interfaces for validating the inbound packets from the Internet.

BGP SAVNET application scenarios In general, there are four types of external interface:

Single-homing interface. When a customer network has only one uplink connects to the upper-layer network, the connected interface at the edge of upper-layer network can be defined as a "Sigle-homing interface", which corresponds to Intf.1 and Intf.4 in .
Complete Multi-homing interface. When a customer network has dual or multiple uplinks that connect to a single upper-layer network with BGP SAVNET deployed, the connected interfaces at the edge router of upper-layer network are called "Complete Multi-homing interface", which corresponds to Intf.2 and Intf.3 in .
Incomplete multi-homing interface. when a customer network has dual or multiple uplinks, all of which are not connected to a single upper-layer network, the interfaces at the edge of upper-layer network are called the "Incomplete Multi-homing interface", which corresponds to Intf.5 in . Specifically, Incomplete Multi-home interface exists in circumstances where source prefixes cannot be fully acknowledged, such as when only a portion of interfaces in upper-layer AS is BGP SAVNET enabled, or these interfaces belong to different upper-layer ASes.
Internet interface. It's the external interfaces that connected to the Internet on border routers. Typically, a network contains multiple internet interfaces for load balancing, which corresponds to Intf.6 and Intf.7 as shown in .

In order to perform accurate validation on different types of external interface, two typical modes are provided: "Interface-based prefix allowlist" and "Interface-based prefix blocklist" . For interfaces that can learn all its legitimate source prefixes, the" Interface-based prefix allowlist" mode is recommended. For interfaces that cannot learn all its legitimate source prefixes, but in turns know the source prefixes that are surely not allowed, the "Interface-based prefix blocklist" mode is suitable. For the first two type of interfaces in the example scenario shown in , which are defined as "Single-homing interface" and "Complete Multi-homing interface", the "Interface-based prefix allowlist" mode is suitable. In this case, the allowlist should contain all source prefixes of the connected subnets or stub ASes. The key challenge to fulfill a complete list is to solve asymmetric routing problem in multi-homing scenarios, and the legacy uRPF approach is not sufficient. For the last two types of interfaces in the example scenario, which are defined as "Incomplete multi-homing interface" and "Internet interface", the "Interface-based prefix blocklist" mode is suitable. For a specific interface, its blocklist could contain the prefixes that are learned from other interfaces, such as "Single-homing interface" or "Complete Multi-homing interface". The key challenge in this case is how to maintain the source prefixes blocklist dynamically and efficiently. To address these two challenges mentioned above, BGP SAVNET is introduced in this document. The primary idea is to allow routers to advertise SAV-related information on the control plane, thus automatically generate accurate SAV rules on the data plane. The information advertised by BGP SAVNET requires to be concise and efficient. The main goal is to generate source prefixes allowlist/blocklist on border routers or edge routers. The corresponding solution consists of one major process, which is named Source Prefix Advertisement (SPA). During the SPA procedure, the router will advertise its local source prefixes information with the MIIG-type, MIIG-tag, and Prefix attributes:

BGP SAVNET defines the Multi-homing Interface Group Type (MIIG-Type) to indicate the exact type of each external interface, which should be one of the four types mentioned above. MIIG-type determines the local validation mode of the interface (i.e., interface-based prefix allowlist/blocklist), and also assists remote peer route in generating prefixes allowlist/blocklist.
BGP SAVNET defines the Multi-homing Interface Group Tag (MIIG-Tag) to identify customers. It is an identifier that represents a customer subnet, a lower-layer stub AS or the internet. In the design, different customer subnets/stub ASes use different MIIG-tag values, while the internet usually takes the same MIIG-tag value.
In BGP SAVENT, the MIIG-Type and MIIT-Tag work together to generate source prefixes list on remote peer routers. On the remote router, source prefixes in SPA message that take the same MIIG-Type and same MIIT-Tag value as one of its local interfaces, will be recognized as legitimate prefixes of that interface.
BGP SAVNET also defines the "Prefix attribute" to indicate the "Source" and "Dest" type of a prefix. "Source" attribute represents whether all origin interfaces of the prefix are known and learned. "Dest" attribute indicates whether route for this prefix exists in local RIB of this SPA advertising router. "Prefix Attribute" values are determined by the "MIIT-Type" of the prefixes in typical cases. For example, prefixes belonging to "Single-homing interface" and "Complete Multi-homing interface" will take both "Source" type value and "Dest" type value, while prefixes of "Incomplete multi-homing interface" and "Internet interface" are only assigned "Dest" type value. However, in same special cases, the prefix attribute value needs to be specified. For example, in the direct server return (DSR) scenario , the hidden prefix should be a "Source" type prefix but not a "Dest" type prefix, as it's not a reachable prefix in local routing table. Normally, the "Prefix attribute" value is set manually in this special hidden prefix scenario.

Routers will announce the source prefixes within the above attribute values via SPA messages. In "Single-homing interface" and "Complete Multi-homing interface" scenarios, the router should advertise all prefixes of this interface. In the other scenarios, the prefixes could be determined to be published or not on the local router. Routers with "Single-homing interface" or "Complete Multi-homing interface" will generate "Interface-based prefix allowlist", and the building approach of the allowlist is different in these two scenarios. In the case of "Single-homing interface", the allowlist can be generated only through local routing information (local RIB), without the engagement of SPA message. The method building the allowlist is, each Dest Prefix in RIB that records this interface as an outgoing interface will be added to the" Interface-based prefix allowlist". In the case of "Complete Multi-homing interface", in addition to collecting prefixes of the interface itself in local RIB, routers also need merge prefixes from received SPA message or other local interfaces into allowlist to construct a complete list. First, the prefixes in received SPA, which take the same "MIIG-Type" and "MIIG-Tag" values as the local interface, are added to the allowlist. Second, if there are multiple interfaces having the same "MIIG-Type" and "MIIG-Tag" values, they will share prefixes collected from local RIB into each other’s allowlist. Routers with "Incomplete Multi-homing interface" or "Internet interface" will generate "Interface-based prefix blocklist" for the interface. Generally, the interface-based blocklist contains prefixes that surely not enter this interface. To construct the blocklist, there are three types of situations need to be taken into consideration separately. First, the local prefixes of other "Single-homing interface" or "Complete Multi-homing interface" on the same router could be recorded into the blocklist. Second, the prefixes in received SPA message, which belongs to the remote "Single-homing interface" or "Complete Multi-homing interface", also could be added into the blocklist. Third, the prefixes from any scenario taking the "source" type attribute which may be manually configured or set by RTBH, also can be added into the blocklist, even if the prefixes belong to the "Incomplete Multi-homing interface" or "Internet interface".

SAV within an AS: Solution for Aggregation Routers The solution consists of two main processes: SPA and Source Path Discovery (SPD). Edge routers can generate SAV rules through SPA on the interfaces connecting subnets. SPA and SPD can help aggregation routers generate SAV rules on the interfaces connecting other routers. Aggregation routers are to generate SAV rules for checking the validity of recorded source prefixes and ignore the validation of unrecorded source prefixes. Each edge router can first send SPA messages for propagating its router-id and its source prefixes that need to be validated. Aggregation routers will record the mapping from router-id to source prefixes. Then, each edge router will send an SPD messages to each neighbor router. The message carries the source router-id of the edge router and the destination router-ids whose mapped source prefixes take the neighbor router as the next forwarding hop. The neighbor router (e.g., aggregation router) receiving the message will record the incoming interface of the message, and SAV rules will be generated locally by binding the source router-id's source prefixes to the recorded incoming interface. Then neighbor router will remove its own router-id from the destination router-id list and relay the message to its neighbors according to local forwarding rules. The routers receiving the message will repeat the above process until the destination router-id list is empty. More details can be found in the version-00 of .

SAV between ASes: Solution for Border Routers The solution consists of two main processes: SPA and SPD. Border routers can generate SAV rules at interfaces connecting to other ASes through SPA and SPD. Let AS X be the local AS which acts as a validation AS and generates SAV rules for other ASes. Let AS Y be one of the ASes deploying BGP SAVNET, which is named as source AS. Validation AS X will generate SAV rules for protecting the source prefixes of source AS Y. AS Y first advertise its own AS number and its own source prefixes to AS X through SPA messages. SPA is necessary because AS Y cannot learn the complete set of source prefixes of AS Y purely through BGP updates. Some hidden source prefixes that do not appear can be advertised to AS X through SPA messages. After SPA, AS Y can send SPD messages for notifying its preferred AS paths from AS Y to AS X. AS X will learn the incoming direction of AS Y's packets. Then, SAV rules can be generated. SPD can help AS X for discovering the real forwarding paths that do not match the control plane paths learned by AS X. Note that, the SAV solutions either within an AS or between ASes are under working on. The BGP SAVNET will be updated if the solutions are revised.

BGP SAVNET Peering Models Several BGP SAVNET solutions are introduced that can be applied in different scenarios. Depending on the solution's feature, different peering models need to be taken.

Full-mesh IBGP Peering This peering model is required by the SAV solution within an AS so that the edge/border routers can generate SAV rules. In this model, routers enabling BGP SAVNET MUST establish full-mesh iBGP sessions either through direct iBGP sessions or route-reflector. The BGP SAVNET sessions can be established only when the BGP SAVNET address family has been successfully negotiated. SPA messages within an AS can be advertised through the full-mesh BGP SAVNET sessions. The extensions of BGP messages for carrying SPA messages will be introduced in .

Singe-hop IBGP Peering between Directly Connected Routers This peering model meets the requirement of the SAV solution within an AS so that the aggregation routers can generate SAV rules. In this model, routers enabling BGP SAVNET MUST establish single-hop iBGP sessions through direct point-to-point links. For each link, a single-hop iBGP session needs to be established, and the messages transmitted over the session MUST be carried by the corresponding link. SPD messages within an AS can be advertised through these sessions. The extensions of BGP messages for carrying SPD messages will be introduced in .

EBGP Peering between ASes The SAV solution between ASes requires eBGP sessions which can be single-hop or multi-hop. In this model, for the AS enabling BGP SAVNET, at least one border router in the AS MUST establish the BGP SAVNET sessions with other border routers in the neighboring or remote ASes. SPA and SPD messages between ASes will be advertised through these sessions. The extensions of BGP messages for carrying SPA and SPD messages will be introduced in .

BGP SAVNET Protocol Extension

BGP SAVNET SAFI In order to transmitting and exchanging data needed to generate an independent SAV table, the document introduces the BGP SAVNET SAFI. The value is TBD and requires IANA registration as specified in . In order for two BGP SAVNET speakers to exchange BGP SAVNET NLRI (SPA message), they MUST establish a BGP SAVNET peer and MUST exchange the Multiprotocol Extensions Capability to ensure that they are both capable of processing such NLRI properly. Two BGP SAVNET speakers MUST exchange Route Refresh Capability to ensure that they are both capable of processing the SPD message carried in the BGP Refresh message.

BGP SAVNET NLRI The BGP SAVNET NLRI is used to transmit Source Prefix (either IPv4 or IPv6) information to form a uniform Source Prefix list within a deployment domain. The BGP SAVNET NLRI TLVs are carried in BGP UPDATE messages as (1) route advertisement carried within Multiprotocol Reachable NLRI (MP_REACH_NLRI) , and (2) route withdraw carried within Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). While encoding an MP_REACH_NLRI attribute containing BGP SAVNET NLRI TLVs, the "Length of Next Hop Network Address" field SHOULD be set to 0 upon the sender. The "Network Address of Next Hop" field should not be encoded upon the sender, because it has a 0 length and MUST be ignored upon the receiver.

SPA TLVs within an AS The BGP SAVNET NLRI TLV each carries a Source Prefix and related information, therefore it is called an SPA TLV. This type of TLVs are used in SPA process within an AS. The format is shown below:

SPA TLV format The meaning of these fields are as follows:

RouteType(key): Type of the BGP SAVNET NLRI TLV, the value is 1 for SPA TLV within an AS.
Length: The length of the BGP SAVNET NLRI value, the RouteType and Length fields are excluded.
Origin router-id(key): The router ID of the originating node of the source prefix in the deployment domain.
MaskLen(key): The mask length in bits, which also indicates the valid bits of the IP Prefix field.
IP Prefix(key): IP address. The length ranges from 1 to 4 bytes for IPv4 and ranges from 1 to 16 bytes for IPv6. Format is consistent with BGP IPv4/IPv6 unicast address.
MIIG-Type(non-key): Multi-homing Ingress Interface Group type, see for details.
Flags(non-key): Bitmap, indicating the attribute flag of the SPA prefix, currently taken:
- bit 0(S bit) : source flag, indicates that the SPA prefix can be used as a source prefix.
- bit 1(D bit) : dest flag, indicates that the SPA prefix can be used as a destination prefix.
MIIG-Tag(non-key): Multi-homing Ingress Interface Group Tag. The value ranges from 1 to 0xFFFFFFFF. The value 0 is invalid and the value 0xFFFFFFFF is reserved.

Multi-homing Ingress Interface Group Type

Type value 0: Unknown. Indicates that this prefix does not come from any subnets. It can be a local prefix or a local domain prefix.
Type value 1: Single-homed. Indicates that this prefix comes from a subnet that is single-homed to the local domain.
Type value 2: Complete-multi-homed. Indicates that this prefix comes from a subnet that is multi-homed to the local domain, and is connected only to the local domain.
Type value 3: Incomplete-multi-homed. Indicates that this prefix comes from a subnet that is multi-homed to the local domain and and other domains.
Type value 4: Internet-Ingress. Indicates that this prefix comes from a interface that is connected to the Internet.
Type value 5~255: Reserved for future use.

SPA TLVs between ASes This type of TLVs are used in SPA process between ASes.

SPA TLV format The meaning of these fields are as follows:

RouteType(key): Type of the BGP SAVNET NLRI TLV, the value is 2 for SPA TLV between ASes.
Length: The length of the BGP SAVNET NLRI value, the RouteType and Length fields are excluded.
Source AS Number(key): The AS number of the originating AS of this advertised source prefix.
MaskLen(key): The mask length in bits, which also indicates the valid bits of the IP Prefix field.
IP Prefix(key): IP address. The length ranges from 1 to 4 bytes for IPv4 and ranges from 1 to 16 bytes for IPv6. Format is consistent with BGP IPv4/IPv6 unicast address.
Flags(non-key): Reserved for future use.

BGP SAVNET Refresh The SPD TLV is carried in a BGP Refresh message after the BGP Refresh message body, as follows:

BGP-REFRESH with SPD TLV format By carrying an SPD TLV, a BGP SAVNET Refresh message MUST NOT be processed as a Route-Refresh (as a re-advertisement request) and SHOULD only be used in the SPD process. A BGP SAVNET Refresh message without an SPD TLV SHOULD be processed as a Route-Refresh as defined in Route Refresh Capability .

The SPD TLVs within an AS The SPD TLV carries the information that the Source Path Discovery process needed. This type of TLVs are used in SPD process within an AS. The format is shown below:

SPD TLV format The meaning of these fields are as follows:

Type: TLV Type, the value is 2 for SPD TLV.
SubType: TLV Sub-Type, value is 1 for SPD TLV within an AS.
Length: The length of the SPD TLV value, the Type, SubType and Length fields are excluded.
Sequence Number: Indicates the sequence of Source Path Discovery process. The initial value is 0 and the value increases monotonically.
Origin router-id: The router ID of the originating node of the Source Path Discovery process.
Optional Data Length: The length of the optional data field in bytes. The value can be 0 when there is no optional data.
Optional Data: In Sub-TLV format, see for details.
Dest List: List of destination router-ids, using 4-bytes route-id, indicates the destinations of this Source Path Discovery process.

The SPD TLVs between ASes This type of TLVs are used in SPD process between ASes.

SPD TLV format The meaning of these fields are as follows:

Type: TLV Type, the value is 2 for SPD TLV.
SubType: TLV Sub-Type, value is 2 for SPD TLV between an AS.
Length: The length of the SPD TLV value, the Type, SubType and Length fields are excluded.
Sequence Number: Indicates the sequence of Source Path Discovery process. The initial value is 0 and the value increases monotonically.
Origin router-id: The router ID of the originating node of the Source Path Discovery process.
Source AS Number(key): The AS number of the source AS whose source prefixes need to be validated in the validation AS.
Validation AS Number(key): The AS number of the validation AS who conducts validation for the source prefixes of source AS.
Optional Data Length: The length of the optional data field in bytes. The value can be 0 when there is no optional data.
Optional Data: In Sub-TLV format, see for details.
Neighbor AS Number List: List of neighbor AS, from which the validation AS will receive the data packets with the source prefixes of the source AS.

The SPD Optional Data Sub-TLVs Information in the Optional Data field of the SPD TLV is encoded in Sub-TLV format. The format is shown below and applies to all types of Sub-TLVs. Each type of Sub-TLV SHOULD appear no more than once in an SPD TLV.

SPD Optional Data Sub-TLV format The meaning of these fields are as follows:

Type: Sub-TLV Type. The value 1 and 2 have been taken. The sequence of values is TBD and requires IANA registration as specified in Section 9.
Length: The length of the Sub-TLV value, the Type and Length fields are excluded.

Sub-TLV Type 1: Origin Router-id List List of agent original router-ids, using 4-bytes route-id. This information is used in the SPD convergence process and can carry a maximum of 254 router-ids.

Sub-TLV Type 2: Path Router-id List List of path router-ids, using 4-bytes route-id, record all the router-id of the routers that the SPD process has passed through. This information is used to prevent loops and can carry a maximum of 254 router-ids. Currently, the above two sub-TLVs are only used in SAV within an AS.

Decision Process with BGP SAVNET The Decision Process described in works to determines a degree of preference among routes with the same prefix. The Decision Process involves many BGP Path attributes, which are not necessary for BGP SAVNET SPA and SPD process, such as next-hop attributes and IGP-metric attributes. Therefore, this document introduces a simplified Decision Process for SAVNET SAFI. The purpose of SPA is to maintain a uniform Source Prefix list, which is the mapping from original router-id to IP addresses, across all routers in the deploy domain. To ensure this, it is RECOMMENDED that all routers deploy no ingress or egress route-policies.

BGP SAVNET NLRI Selection The Decision Process described in no longer apply, and the Decision Process for BGP SAVNET NLRI are as follows:

The locally imported route is preferred over the route received from a peer.
The route received from a peer with the numerically larger originator is preferred.
The route received from a peer with the numerically larger Peer IP Address is preferred.

Self-Originated NLRI BGP SAVNET NLRI with origin router-id matching the local router-id is considered self-originated. All locally imported routes should be considered self-originated by default. Since the origin router-id is part of the NLRI key, it is very unlikely that a self-originated NLRI would be received from a peer. Unless a router-id conflict occurs due to incorrect configuration. In this case, the self-originated NLRI MUST be discarded upon the receiver, and appropriate error logging is RECOMMENDED. On the other hand, besides the route learn from peers, a BGP SAVNET speaker MUST NOT advertise NLRI which is not self-originated.

Error Handling

Process of BGP SAVNET NLRIs When a BGP SAVNET speaker receives a BGP Update containing a malformed MP_REACH_NLRI or MP_UNREACH_NLRI, it MUST ignore the received TLV and MUST NOT pass it to other BGP peers. When discarding a malformed TLV, a BGP SAVNET speaker MAY log a specific error. If duplicate NLRIs exist in a MP_REACH_NLRI or MP_UNREACH_NLRI attribute, only the last one SHOULD be used.

Process of BGP SAVNET SPA TLVs When a BGP SAVNET speaker receives an SPA TLV with an undefined type, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPA TLV with a 0 origin router-id, or the origin router-id is the same as the local router-id, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPA TLV with an invalid MaskLen field, which is out of the range 1~32 for IPv4 and 1~128 for IPv6, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPA TLV with an address field, whose length in bytes do not match with the remaining data, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPA TLV with an unsupported miig-type, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPA TLV with a miig-type 0(Unkonwn), its miig-tag must also be 0, vice versa. Otherwise this SPA TLV MUST be considered malformed. When a BGP SAVNET speaker receives a malformed SPA TLV, it MUST ignore the received TLV and MUST NOT pass it to other BGP peers. When discarding a malformed TLV, a BGP SAVNET speaker MAY log a specific error. When a BGP SAVNET speaker processes Flags in an SPA TLV, the defined bits MUST be processed and the undefined bits MUST be ignored.

Process of BGP SAVNET Refresh Each BGP Refresh message MUST contain at most one SPD TLV. When a BGP SAVNET speaker receives a BGP Refresh packet with multiple SPD TLVs, only the first one SHOULD be processed.

Process of BGP SAVNET SPD TLVs When a BGP SAVNET speaker receives an SPD TLV with an undefined type or subtype, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPD TLV with a 0 origin router-id, or the origin router-id is the same as the local router-id, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPD TLV with a 0 source AS number or validation AS number, or the source AS number equals the validation AS number, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPD TLV with an optional data sub-TLV that is an undefined type, it MUST be considered malformed. When a BGP SAVNET speaker receives an SPD TLV with a DestList field that is not a multiple of 4 in length, it MUST be considered malformed. When a BGP SAVNET speaker receives a Refresh message with a malformed SPD TLV, it MUST ignore the received message. When discarding a malformed message, a BGP SAVNET speaker MAY log a specific error. When a BGP SAVNET speaker receives an SPD TLV with a sequence number that does not match the local recorded sequence number:

If the newly received sequence number is numerically larger, the local recorded sequence number SHOULD be updated to the newly received sequence number.
If the newly received sequence number is numerically smaller, the local recorded sequence number SHOULD NOT be updated, and the BGP SAVNET speaker SHOULD log a specific error.

Management Considerations TBD

IANA Considerations The BGP SAVNET SAFIs under the IPv4 address family and the IPv6 address family need to be allocated by IANA.

Security Considerations This document does not introduce any new security considerations.

Acknowledgements TBD