Internet DRAFT - draft-guo-savnet-enhances-sav-security

draft-guo-savnet-enhances-sav-security







Network Working Group                                             X. Guo
Internet-Draft                                                   D. Chen
Intended status: Informational                                  Z. Xiong
Expires: 10 September 2023                                       J. Chen
                                                                  X. Liu
                                                           China Telecom
                                                            9 March 2023


    Source Address Validation enhances its security using blockchain
               draft-guo-savnet-enhances-sav-security-00

Abstract

   The new Source Address Validation(SAV) mechanism must not introduce
   additional security vulnerabilities or risks, and the SAV mechanism
   should ensure the integrity and trusted origin of the protocol
   packets that deliver the required SAV information.  This document
   explores the use of blockchain technology to enhance the security of
   the SAV mechanism itself without modifying existing protocols to
   ensure the accuracy of the generated SAV rules.

Requirements Language

   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 8174 [RFC8174].

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 10 September 2023.







Guo, et al.             Expires 10 September 2023               [Page 1]

Internet-Draft                SAV Security                    March 2023


Copyright Notice

   Copyright (c) 2023 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Security Threats Analysis . . . . . . . . . . . . . . . . . .   3
     3.1.  RPKI  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  AS Prefix Advertisements  . . . . . . . . . . . . . . . .   3
     3.3.  Malicious Router  . . . . . . . . . . . . . . . . . . . .   4
   4.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Replace RPKI  . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  AS Prefix Advertisement Information Authentication  . . .   4
     4.3.  Malicious Router Discovery  . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   SAV rules are generated based on routing information (FIB/RIB) or
   non-routing information.  If the routing information is poisoned by
   an attacker, then there will be no way to verify the authenticity of
   the routing information and the generated SAV rules will be
   incorrect.  Many legitimate packets may be improperly discarded or
   illegal packets with spoofed source addresses may be improperly
   allowed.  Overall, SAVNET faces similar security threats to BGP, and
   if the SAV mechanism or protocol requires information exchange,
   consideration should be given to avoiding routing information
   tampering or injection.

2.  Terminology

   SAV: Source Address Validation, i.e., validating the authenticity of
   a packet's source IP address.



Guo, et al.             Expires 10 September 2023               [Page 2]

Internet-Draft                SAV Security                    March 2023


   SAV rule: The filtering rule generated by inter-domain SAV mechanisms
   that determines valid incoming interfaces for a specific source
   prefix.

   RPKI: Resource Public Key Infrastructure,an opt-in service that
   provides security for Internet routing.

   Improper block: Cases when packets with legitimate source addresses
   are improperly blocked.

   Improper permit: Cases when packets with spoofed source addresses are
   improperly permitted.

3.  Security Threats Analysis

   The main security threats to SAV come from the following areas.

3.1.  RPKI

   The basic idea of RPKI is to construct a PKI (public key
   infrastructure) to accomplish the authentication of ownership and
   usage of IP address prefixes and ASNs.  It helps routers verify the
   authenticity of BGP messages by issuing and certifying digital
   certificates and digital signatures, thus enhancing the security of
   the BGP protocol and avoiding Internet routing hijacking.  However,
   RPKI cannot resist malicious acts initiated by CAs for the benefit of
   countries and organizations, and the tree structure of RPKI has the
   defect of single point of failure, and the whole network may be
   paralyzed after the attack of high-level CAs, so RPKI has the problem
   of being centralized and tamperable.  In addition, RPKI also has a
   limited scale of global deployment due to its complex protocol
   mechanism and high processing overhead.

3.2.  AS Prefix Advertisements

   The existing routing protocols cannot guarantee the integrity of AS
   prefix advertisements and cannot authenticate whether the AS
   advertisement IP prefix authorization is legitimate.  This lack of
   authenticated unconditional trust can be used by malicious nodes to
   forge and advertise false or non-compliant AS advertisement
   information through replay attacks or message injection attacks,
   resulting in network prefix information, network topology
   information, AS path information and other key information being
   hijacked, impersonated, stolen, and tampered with by attackers, which
   in turn leads to the delivery and proliferation of false routing
   information, causing security events such as traffic eavesdropping
   and traffic black holes.




Guo, et al.             Expires 10 September 2023               [Page 3]

Internet-Draft                SAV Security                    March 2023


3.3.  Malicious Router

   After gaining control of the legitimate router through the attack,
   the attacker disguises the malicious router as a peer node of another
   router to establish a session with that router, propagating false
   advertisement messages or tampering with legitimate advertisement
   messages, which will not only destroy the SAV function but also
   affect the entire routing domain.

4.  Solution

   As a distributed ledger system of the new generation of Internet,
   blockchain can record, encrypt and authenticate the whole life cycle
   transactions of data assets on the Internet in a distributed way.
   Its security is "endorsed" by the cryptography algorithm used by
   blockchain technology.  After verification, each transaction
   interaction process can be permanently stored in the distributed
   database (block).  Once verified, it will be shared, anonymous and
   tamper-proof, and easy to query.

   Blockchain technology, due to its natural attributes of
   decentralization, tamper-proof and traceability, is supported by
   distributed node authentication and consensus mechanisms, allowing
   any two nodes in a distributed network to reach an unmediated trust.
   Another advantage of applying blockchain to SAV is that it can add
   additional security without changing the BGP protocol, and by using
   blockchain SAV can be protected in several ways.

4.1.  Replace RPKI

   The decentralized, tamper-proof and traceability features of
   blockchain enable it to solve the centralized and tamper-proof
   problems of RPKI.  Through the two functions of resource transaction
   record and resource retrieval of blockchain's smart contract
   technology, the IP address and ASN registration and allocation
   information are recorded, and the tracking of their usage is
   supported, so as to realize the authorization authentication of IP
   address and ASN network resources, prevent the security threat of
   prefix hijacking and avoid the repeated allocation of resources.

4.2.  AS Prefix Advertisement Information Authentication

   The blockchain smart contract technology is used to record the
   process of IP address authorization.  When the AS prefix
   advertisement is required, the prefix advertisement of the source AS
   can be stored on the blockchain as transaction information.  After
   receiving the source AS advertisement information, the destination AS
   determines the integrity of the received AS advertisement information



Guo, et al.             Expires 10 September 2023               [Page 4]

Internet-Draft                SAV Security                    March 2023


   through the transaction information saved on the chain.  In this way,
   the destination AS can verify the validity of the AS advertisement
   information, and then determine whether there is any unauthorized
   change attempt, and whether the resource is repeatedly allocated, so
   as to avoid tampering with the AS advertisement information and
   prefix hijacking.

4.3.  Malicious Router Discovery

   Store the routing topology relationship in the blockchain.  When the
   AS discovers the malicious advertisement information of the AS
   through the blockchain verification, the network location of the
   malicious router can be located in a timely manner by combining the
   advertisement information source and the routing topology
   relationship stored in the blockchain to avoid the malicious router
   causing greater harm to the network.  Routing topology is stored in
   the blockchain through consensus mechanism.  Any modification and
   update of topology data in the blockchain requires the consent of
   most nodes in the blockchain network to avoid malicious modification
   of routing topology by a few malicious routers.

5.  Security Considerations

   There could be new blockchain related attacks that SAV would
   experience if blockchain were to be added into SAV's policy system.
   We will explore some of those here or in a new draft.

6.  Acknowledgments

   TBD

7.  Normative References

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

   [RFC5210]  Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "A Source Address Validation Architecture (SAVA) Testbed
              and Deployment Experience", RFC 5210,
              DOI 10.17487/RFC5210, June 2008,
              <https://www.rfc-editor.org/info/rfc5210>.




Guo, et al.             Expires 10 September 2023               [Page 5]

Internet-Draft                SAV Security                    March 2023


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,
              <https://www.rfc-editor.org/info/rfc8704>.

Authors' Addresses

   Xuesong Guo
   China Telecom
   Beijing
   China
   Email: guoxs@chinatelecom.cn


   Dabei Chen
   China Telecom
   Beijing
   China
   Email: chendabei@chinatelecom.cn


   Zihan Xiong
   China Telecom
   Beijing
   China
   Email: xiongzh1@chinatelecom.cn


   Jun Chen
   China Telecom
   Beijing
   China
   Email: chenjun8@chinatelecom.cn


   Xiaoping Liu
   China Telecom
   Beijing
   China
   Email: liuxp08@chinatelecom.cn







Guo, et al.             Expires 10 September 2023               [Page 6]