Practical Inter-Domain Source Address Validation

Introduction IP spoofing has been a long-recognized threat to Internet security for decades. Inter-domain source address validation (SAV) has long served as the primary defense mechanism due to its better cost-effectiveness. However, over years of effort, the deployment of inter-domain source address validation is still not optimistic. An important reason for this is the difficulty of balancing the clear security benefits of partial deployments with the scalability of large-scale deployments. uRPF , for example, routing-based schemes to filter spoofed traffic, which may result in a lack of security benefits due to the dynamic nature of routing or incomplete information caused by partial deployments. And while cryptography-based schemes such as IPsec can provide clear security gains, the additional end-to-end overhead will present new challenges in scalability. This document provides a framework of practical inter-domain SAV (PSAV). PSAV is a cryptography-based SAV to guarantee consistent security benefits. Key maintenance is performed between the source and destination ASes, and the key is used to generate packet tags to validate the authenticity of the source address. Meanwhile, in PSAV, ASes are organized as a hierarchical structure to provide scalability, in which only fully-connected key maintenance is performed between ASes on the same layer, and ASes between different layers achieve end-to-end source address validation through cross-layer validation and tag replacement. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 and indicate requirement layers for compliant CoAP implementations.

Terminology and Abbreviation

Abbreviation	Description
TA	Trust Alliance, the IPv6 network that uses the SAVA-X mechanism.
ACS	AD Control Server, the server that matains state machine with other ACS and distribute information to AER.
ABR	AS or AS community border router, which is placed at the boundary of an AS of trust alliance.
Tag	The authentic identification of source address of a packet.

PSAV Framework PSAV is a cryptography-based end-to-end inter-domain source address verification method that guarantees security benefits at partial deployment. PSAV implements inter-AS tag maintenance by establishing a hierarchical community structure that utilizes border nodes on the forwarding path for tag replacement and validation. This mainly includes the following components.

Tag generation. In PSAV, the packet tag is generated by maintaining the key between ASes and using the generation algorithm. The destination AS will validate the source address by the packet tag. The above process requires a mapping relationship between AS-IP_Prfix-Key, which will be provided based on existing Internet infrastructure, e.g., such as RPKI, ROVER, etc.
Hierarchical structure. In PSAV, AS is organized into hierarchical AS communities, which can provide good scalability by reducing the tag maintenance overhead in large-scale deployments, managing the validation responsibilities corresponding to address allocation, and shielding external community changes. To implement tag validation in AS communities, PSAV will provide corresponding tag cross-layer validation and replacement methods.
Membership configuration. AS sends join, exit, or update to all participating nodes through a specific message format, and the participating nodes further complete membership configuration by verifying the authenticity of the messages to form a distributed consensus.

A typical workflow of PSAV is shown in . AS1 joins the PSAV trust alliance with the signed join information, maintains the packet tag with AS2. After that, AS1 sends out the packet with Tag <AS1, AS2>, and AS2 validates it and replaces the Tag with <AS2, AS3>. Then AS3 validates and replaces the tag with <AS3, AS4>. After AS4 validation, confirm that the packet source address is true.

PSAV workflow example. | | | | | AS3 |****************| AS4 | | | | | | | | | +---------------+ +---------------+ | | // * \\ | | // * \\ AS Community (N-1) | +-------//------------------*------\\----------------------------+ // * \\ // * \\ // * \\ // * \\ +--------------------------------*-----------+ | * | | +----------+ +----------+ | | | | | | | | | AS1 |******************| AS2 | | | | | | | | | +----------+ +----------+ | | AS Community N | +--------------------------------------------+ ]]>

Control Plane The functions of control plane of PSAV includes AS community information management, ACS-ACS communication, and ACS-ABR communication. To eliminate the impact of routing dynamic caused by BGP or other routing protocols, PSAV requires its own AS community information management. These information of one AS includes AS Number (ASN), AS Community Number (ASCN), IP Prefix and Public Key. PSAV does not bind any methods of inter-domain mapping information, and it can both use centralized or distributed methods to maintain AS community information independently. When an AS or AS community wants to join or exit the Trust Alliance construted by all the member ASes and AS communities, it SHOULD submit an certificate signning request message containing its own information. It also needs to submit such CSR message for updating its information recorded by all members in trust alliance. The communication among ACSes is to maintain the tags used in packets in network. PSAV provides a tag generation mechanism on one-to-one state machine. In this mechanism, each AS or AS community needs one ACS. ACS negotiates initial state of the state machine with its relavent ACS. The state transfers to the next state triggered by time flies. For crossing different layer of AS communities, it is used the tag generated by the state machine maintained by AS or AS community with its direct paternal AS community in PSAV. The communication between ACS and ABR is to deliver the AS community information and tags. PSAV requires a heart-beat mechanism for service availability implemented in ACS-ACS commmunication and ACS-ABR communication. When it detects that one ACS or ABR has 'died', the other end WOULD remove its tag generation mechanism maintained with this 'died' end and sends a request message to force execute the exit trust alliance process of the other end.

Data Plane The functions of data plane of PSAV includes prefix checking and tag processing. The tag delivered from the control plane indicates the source address of one packet is not tampered. As the tag in use is generated by one-to-one state machine pair, it MUST be completely consistent at the same time. It needs to divide the role of different interfaces of an ABR for functioning properly. In ABR, the interface takes the role of INGRESS, EGRESS, or TRUST. The INGRESS port links to the devices inside the AS or AS community, the EGRESS port links to the devices outside the AS or AS community, and the TRUST port links to the ABR inside the same AS or AS community. The INGRESS port validates and removes the tag in use. The EGRESS port adds or replaces the tag in the packet. The TRUST port does nothing to the packet. When a packet arrives at the ABR, it SHOULD be checked its source address and destination address first. If it originates and destinates the trust alliance, it MUST be tagged with a tag at the first hop and removed tag at the last hop. When this packet forwards crossing different layers of AS communities, it SHOULD be replaced with relavent tags maintained by its ACS with direct paternal ACS. In ABR, it maintains two mapping tables to record the AS community information and tags in use. The AS-Prefix mapping table preserves the ASN or ASCN and IP address prefix relationships. The AS-Tag mapping table holds the ASN or ASCN and relevant tags. When a packet is needed to add, replace, or remove tag, the ABR WOULD get the ASN or ASCN which the packet belongs to first via the source address of the packet from the AS-Prefix mapping table. The ABR WOULD obtain the tag should be used by the ASN or ASCN from the AS-Tag mapping table.

Consistency PSAV is a cryptography-based source address validation mechanism to guarantee consistent security benefits and provide scalability for different deployment scales and validation granularity. PSAV uses the hierarchical structure to reduce the size of the secret symmetric keys to cut down the maintenance overhead. Hierarchy validation filters malicious traffic as early as possible to avoid wasting network resources. PSAV also provides clear security responsibilities corresponding to IP address allocation authority.

Scalability

Compatibility Hierarchy effectively blocks external changes and provides scalability in large-scale deployments. AS the forwarding path is indepent of the tag validation by using a mechanism for crossing different layers, PSAV is a segmented end-to-end cryptography scheme essentially. So it does not need to obtain the routing information and has nothing influence on existing routing infrastructure. Meanwhile, PSAV supports that packets can pass through networks where PSAV has not yes been deployed without affecting validation as it is end-to-end validation in nature, which is guaranteeing a definite security benefit for the deployer without requiring a deployment rate.

Expansion Management On one hand, PSAV effectively isolates structural changes outside the community from internal nodes, as the hierarchical community design minimizes the impact of changes on the rest of the system. On the other hand, PSAV can be implemented with any existing distributed consensus algorithm for inter-AS consensus infrastructure. It should be noted that PSAV has no special requirements for the efficiency of this process based on the assumption that AS community information does not change frequently. Therefore, the decentralized maintenance approach can further reduce the management complexity of the expansion process.

Security Consideration

Attack towards community information The distributied method to maintain the AS community information MAY suffer from the consistency challenges, such as witch attacks and eclipse attacks. However, the situation in PSAV is different from the normal distributed consensus scenario. Due to the hierarchical structure of PSAV, the failure of consensus on local community information does not affect other non-adjacent communities in the system. At the same time, the updated community information only needs the signature confirmation of its parent, brother and child communities, which means that the attack on the special node needs to hold specific resources, which further increases the difficulty of the attack.

Attacks towards Initial Status Negotiation This is the problem posed in the PSAV implementation. As the clock-synchronized state machine will run locally after the initial status negotiation stage, the attacker can only attack on this negotiation. However, when the ACS-ACS pair or ACS-ABR pair is going to connect, the SSL/TLS will be used to guarantee security in communication. Therefore PSAV can ensure that attackers cannot obtain the initial status even if it can eavesdrop the negotiation packet online.

Tag Guessing and Key Cracking For resisting reply attack, the eventual tag used in a packet is generated by the ABR with hashing a five-tuple including the signature generated from the state machine, the source address, the destination address, the first 8-bit of payload and source address prefix length. The attacker could guess the tag and crack that key using brute force. Nevertheless, it depends on the irreversibility of a Hash function to prevent backstepping the key from the tag. Furthermore, to decrease such probability, the signature generatated from the state machine will be updated periodically.

IANA Consideration TBD.

Acknowledgements TBD.