Practical Inter-Domain Source Address Validation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 16 August 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [RFC5635], 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 [RFC4301] 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 [RFC2119] and indicate requirement layers for compliant CoAP implementations.¶

2. Terminology and Abbreviation

3. 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.¶

1. 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.¶
2. 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.¶
3. 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 Figure 1. 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.¶

+----------------------------------------------------------------+
|             +---------------+                +---------------+ |
|             |               |   <AS3, AS4>   |               | |
|             |      AS3      |****************|      AS4      | |
|             |               |                |               | |
|             +---------------+                +---------------+ |
|           //            *    \\                                |
|         //               *     \\       AS Community (N-1)     |
+-------//------------------*------\\----------------------------+
      //                     *       \\
    //              <AS2, AS3>*        \\
  //                           *         \\
//                              *          \\
+--------------------------------*-----------+
|                                 *          |
| +----------+                  +----------+ |
| |          |    <AS1, AS2>    |          | |
| |   AS1    |******************|   AS2    | |
| |          |                  |          | |
| +----------+                  +----------+ |
|               AS Community N               |
+--------------------------------------------+

4. 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.¶

5. 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.¶

6. 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.¶

7. Scalability

8. Security Consideration

9. IANA Consideration

TBD.¶

10. Acknowledgements

TBD.¶

Authors' Addresses