their downstream networks to contain only valid IP space. However, a history of hijacking incidents shows this is not always the case. The Resource Public Key Infrastructure (RPKI) is designed to authenticate route origins via cryptographic certificate chains demonstrating address block range ownership, but is not widely deployed yet. Once deployed, IP hijacking through errant issues at the origin (via both accident or intent) should be detectable and filterable. IP hijacking is sometimes used by malicious users to obtain IP addresses for use in spamming or a distributed denial-of-service (DDoS) attack. When a router promulgates flawed BGP routing information, whether that action is intentional or accidental, it is defined by the Internet Engineering Task Force (IETF) in RFC 7908 as a "route leak". Such leaks are described as "the propagation of routing announcement(s) beyond their intended scope. That is, an announcement from an Autonomous System (AS) of a learned BGP route to another AS is in violation of the intended policies of the receiver, the sender, and/or one of the ASes along the preceding AS path." Such leaks are possible because of a long-standing "…systemic vulnerability of the Border Gateway Protocol routing system…" BGP hijacking and transit-AS problems Like the TCP reset attack, session hijacking involves intrusion into an ongoing BGP session, i.e., the attacker successfully masquerades as one of the peers in a BGP session, and requires the same information needed to accomplish the reset attack. The difference is that a session hijacking attack may be designed to achieve more than simply bringing down a session between BGP peers. For example, the objective may be to change routes used by the peer, in order to facilitate eavesdropping, black holing, or traffic analysis. By default EBGP peers will attempt to add all routes received by another peer into the device's routing table and will then attempt to advertise nearly all of these routes to other EBGP peers. This can be a problem as multi-homed organizations can inadvertently advertise prefixes learned from one AS to another, causing the end customer to become the new, best-path to the prefixes in question. For example, a customer with a Cisco router peering with say AT&T and Verizon and using no filtering will automatically attempt to link the two major carriers, which could cause the providers to prefer sending some or all traffic through the customer (on perhaps a T1), instead of using high-speed dedicated