<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e., [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-guo-savnet-enhances-sav-security-00"
     ipr="trust200902">
  <front>
    <title abbrev="SAV Security">Source Address Validation enhances its
    security using blockchain</title>

    <author fullname="Xuesong Guo" initials="X." surname="Guo">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>guoxs@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Dabei Chen" initials="D." surname="Chen">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>chendabei@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Zihan Xiong" initials="Z." surname="Xiong">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>xiongzh1@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Jun Chen" initials="J." surname="Chen">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>chenjun8@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Xiaoping Liu" initials="X." surname="Liu">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>liuxp08@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <date day="9" month="March" year="2023"/>

    <!---->

    <keyword/>

    <abstract>
      <t>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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC8174"/>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>
    </section>

    <section title="Terminology">
      <t>SAV: Source Address Validation, i.e., validating the authenticity of
      a packet's source IP address.</t>

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

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

      <t>Improper block: Cases when packets with legitimate source addresses
      are improperly blocked.</t>

      <t>Improper permit: Cases when packets with spoofed source addresses are
      improperly permitted.</t>
    </section>

    <section title="Security Threats Analysis">
      <t>The main security threats to SAV come from the following areas.</t>

      <section title="RPKI">
        <t>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.</t>
      </section>

      <section title="AS Prefix Advertisements">
        <t>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.</t>
      </section>

      <section title="Malicious Router">
        <t>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.</t>
      </section>
    </section>

    <section title="Solution">
      <t>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.</t>

      <t>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.</t>

      <section title=" Replace RPKI">
        <t>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.</t>
      </section>

      <section title=" AS Prefix Advertisement Information Authentication">
        <t>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 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.</t>
      </section>

      <section title="Malicious Router Discovery">
        <t>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.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>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.</t>
    </section>

    <section title="Acknowledgments">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.3704'?>

      <?rfc include='reference.RFC.8704'?>

      <?rfc include='reference.RFC.2827'?>

      <?rfc include='reference.RFC.5210'?>
    </references>
  </back>
</rfc>
