



sidrops                                                            Y. Fu
Internet-Draft                                             China Telecom
Intended status: Standards Track                                 N. Geng
Expires: 28 August 2026                                           Huawei
                                                        24 February 2026


    Filtering Out RPKI Data by Type based on Enhanced SLURM Filters
               draft-fu-sidrops-enhanced-slurm-filter-05

Abstract

   Simplified Local Internet Number Resource Management with the RPKI
   (SLURM) helps operators create a local view of the global RPKI by
   generating sets of filters and assertions.  This document proposes to
   filter out RPKI data by type based on enhanced SLURM filters.  Only
   the RPKI data types that the network or routers are interested in
   will appear in the Relying Party's output.

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 28 August 2026.

Copyright Notice

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











Fu & Geng                Expires 28 August 2026                 [Page 1]

Internet-Draft           Enhanced SLURM Filters            February 2026


   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Enhanced SLURM Filters  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Design 1: Define a "matchAll" member in filters . . . . .   4
     3.2.  Design 2: RPKI Data Type Filters  . . . . . . . . . . . .   5
       3.2.1.  RPKI Data Type Filters  . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     Normative References  . . . . . . . . . . . . . . . . . . . . .   8
     Informative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Relying Party (RP) collects signed RPKI objects from global RPKI
   publication points.  The RPKI data passing RP's validation will
   appear in RP's output.  Then, the RPKI-to-Router (RTR) protocol
   [RFC6810][RFC8210][I-D.ietf-sidrops-8210bis] will synchronize the
   validated RPKI data from RP to routers.  Currently, four types of
   RPKI data including IPv4 Prefix, IPv6 Prefix, Router Key, and ASPA
   are supported in the RTR protocol.

   However, in some cases, routers may be interested in a part of RPKI
   data types, instead of all.  In such cases, synchronizing all types
   of data to routers is unreasonable.

   Furthermore, there may be more types of RPKI data in the RPKI
   repositories and RPs in the future.  Ignoring the router's
   requirements and directly synchronizing all types of data to the
   router may induce unnecessary and non-negligible transmission and
   storage overheads.  The followings are example types, and some of
   them may be possibly supported in the RPKI system in the future:

   *  Secured Routing Policy Specification Language (RPSL) [RFC7909]



Fu & Geng                Expires 28 August 2026                 [Page 2]

Internet-Draft           Enhanced SLURM Filters            February 2026


   *  Signed Prefix Lists [I-D.ietf-sidrops-rpki-prefixlist]

   *  Autonomous Systems Cones [I-D.ietf-grow-rpki-as-cones]

   *  Mapping Origin Authorizations (MOAs)
      [I-D.ietf-sidrops-moa-profile]

   *  Signed SAVNET-Peering Information (SiSPI) [I-D.chen-sidrops-sispi]

   *  Path validation with RPKI [I-D.van-beijnum-sidrops-pathrpki]

   *  Signed Groupings of Autonomous System Numbers
      [I-D.spaghetti-sidrops-rpki-asgroup]

   SLURM provides a simple way to enable an RP to establish a local and
   customized view of the RPKI ([RFC8416],
   [I-D.ietf-sidrops-aspa-slurm]).  It defines Validation Output Filters
   to filter out specific RPKI data items and Locally Added Assertions
   to add RPKI data items.  Although SLURM supports filtering out all
   IPv4 or IPv6 prefixes through the all-zero address prefixes, it does
   not support filtering out all RPKI data of other specified types.

   This document proposes enhanced SLURM filters which can filter out
   RPKI data by type.  With enhanced SLURM filters, operators can
   efficiently select which type of RPKI data need to be synchronized to
   routers.

   The proposed method requires some modifications on the SLURM-related
   process of RP software.  Upgrades of the RTR protocol implementations
   and router software implementations are not involved.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Use Case

   One of use cases is IPv6-only network.  Suppose a IPv6-only network
   wants to enable ROV on BGP border routers.  The routers are only
   interested in IPv6-related BGP validation because the routers can
   only receive IPv6 routes from neighbor ASes.  Therefore, IPv4 Prefix
   data, Router Key data, and any other data except IPv6 prefix data are
   not useful for the network.  An example of IPv6-only network is New
   China Education and Research Network (named Future Internet



Fu & Geng                Expires 28 August 2026                 [Page 3]

Internet-Draft           Enhanced SLURM Filters            February 2026


   Technology Infrastructure, FITI).

                        +------------+
                        | Rely Party |
                        +------------+
                         /          \
                        / Sync RPKI  \
                       /  data by RTR \
            +---------/----------------\---------+
      IPv6  |        /                  \        |IPv6
      routes| +----------+          +----------+ |routes
      ------->|BGP router|          |BGP router| |------>
            | +----------+          +----------+ |
            |             IPv6-only              |
            +------------------------------------+

   As described in Section Section 1, there may be more types of RPKI
   data in the RPKI repositories and RPs.  Thus, there will be more use
   cases where a network does not need all types of RPKI data in the
   future.

3.  Enhanced SLURM Filters

   This section proposes two optional designs.

3.1.  Design 1: Define a "matchAll" member in filters

   A SLURM file consists of a single JSON [RFC8259] object which has the
   same structure as [I-D.ietf-sidrops-aspa-slurm], except that the
   "slurmVersion" member MUST be set to 3 (TBD).  A new member called
   "matchAll" is defined for the ROA Prefix filters, BGPsec filters,
   ASPA filters, and possibly new types of filters defined in the
   future.  The value of the "matchAll" member MUST be "true".

   To filter out a specific type of RPKI data, the RP can configure
   exactly one filter of the specific type which includes the "matchAll"
   member.  If a filter includes the "matchAll" member, it may only
   optionally contain the "comment" member and SHOULD NOT include any
   other members besides "comment".  When a filter containing the
   "matchAll" member exists, no other filters of the same type should
   exist—regardless of whether those other filters contain the
   "matchAll" member or not.

   Example 1：Filter out all the VRPs with IPv4 and IPv6 Prefixes







Fu & Geng                Expires 28 August 2026                 [Page 4]

Internet-Draft           Enhanced SLURM Filters            February 2026


    "prefixFilters": [
      {
        "matchAll": true,
        "comment": "Filter out all the VRPs with IPv4 and IPv6 Prefixes"
      }
    ]

   If one want to filter either IPv4 or IPv6 prefixes, just reuse the
   existing SLURM mechanism, that is, filtering by using all-zero
   address prefixes.

   Example 1.1：Filter out all the VRPs with IPv4 Prefixes

     "prefixFilters": [
       {
         "prefix": 0.0.0.0/0,
         "comment": "Filter out all the VRPs with IPv4 Prefixes"
       }
     ]

   Example 1.2：Filter out all the VRPs with IPv6 Prefixes

     "prefixFilters": [
       {
         "prefix": ::/0,
         "comment": "Filter out all the VRPs with IPv6 Prefixes"
       }
     ]

   Example 2：Filter out all the Router Keys

     "bgpsecFilters": [
       {
         "matchAll": true,
         "comment": "Filter out all the Router Keys"
       }
     ]

3.2.  Design 2: RPKI Data Type Filters

   A SLURM file consists of a single JSON [RFC8259] object containing
   the following members:

   *  A "slurmVersion" member that MUST be set to 3 (TBD), encoded as a
      number

   *  A "validationOutputFilters" member whose value is an object.  The
      object MUST contain exactly four members:



Fu & Geng                Expires 28 August 2026                 [Page 5]

Internet-Draft           Enhanced SLURM Filters            February 2026


      -  A "prefixFilters" member, see Section 3.3.1 of [RFC8416]

      -  A "bgpsecFilters" member, see section 3.3.2 of [RFC8416]

      -  A "aspaFilters" member, see Section 3.1 of
         [I-D.ietf-sidrops-aspa-slurm]

      -  A "typeFilters" member

   *  A "locallyAddedAssertions" member whose value is an object.  The
      object MUST contain exactly three members:

      -  A "prefixAssertions" member, see Section 3.4.1 [RFC8416]

      -  A "bgpsecAssertions" member, see Section 3.4.2 [RFC8416]

      -  A "aspaAssertions" member, see Section 3.2
         [I-D.ietf-sidrops-aspa-slurm]

   The following JSON structure with JSON members represents a SLURM
   file that has no filters or assertions:

     {
       "slurmVersion": 3,
       "validationOutputFilters": {
         "aspaFilters": [],
         "bgpsecFilters": [],
         "prefixFilters": [],
         "typeFilters": []
       },
       "locallyAddedAssertions": {
         "aspaAssertions": [],
         "bgpsecAssertions": [],
         "prefixAssertions": []
       }
     }

3.2.1.  RPKI Data Type Filters

   There are currently four types of RPKI data.  More types may be
   defined in the future.

   *  IPv4 Prefix

   *  IPv6 Prefix

   *  Router Key




Fu & Geng                Expires 28 August 2026                 [Page 6]

Internet-Draft           Enhanced SLURM Filters            February 2026


   *  ASPA

   The RP can configure zero or at most four RPKI Data Type Filters
   ("Type Filter" for short).  Each Type Filter contains a single
   'rpkiDataType' and optionally a single 'comment'.

   *  The 'rpkiDataType' member MUST be one of the values, i.e., "IPv4
      Prefix", "IPv6 Prefix", "Router Key", and "ASPA".

   *  It is RECOMMENDED that an explanatory comment is included with
      each Type Filter so that it can be shown to users of the RP
      software.

   Any RPKI data item that matches any configured Type Filter MUST be
   removed from the RP's output.

   A RPKI data item is considered to match with a Type Filter if the
   following condition applies: The item is considered to match if the
   RPKI data type of the item is equal to the "rpkiDataType" value of
   Type Filter.

   The following example JSON structure represents a "typeFilter" member
   with one object as described above:

     "typeFilter": [
       {
         "rpkiDataType": "Router Key",
         "comment": "Filter out all Router Keys"
       }
     ]

   In the example, all the Router Keys will be filtered out by SLURM.

4.  IANA Considerations

   This document has no IANA actions.

5.  Security Considerations

   The security considerations in Section 6 of [RFC8416] are also
   applied to this document.

Acknowledgements

   Much thanks for the valuable comments or feedback from Job Snijders,
   Jeff Haas, Ying Wang, and Randy Bush.

References



Fu & Geng                Expires 28 August 2026                 [Page 7]

Internet-Draft           Enhanced SLURM Filters            February 2026


Normative References

   [RFC8416]  Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
              Local Internet Number Resource Management with the RPKI
              (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
              <https://www.rfc-editor.org/info/rfc8416>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol", RFC 6810,
              DOI 10.17487/RFC6810, January 2013,
              <https://www.rfc-editor.org/info/rfc6810>.

   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol, Version 1",
              RFC 8210, DOI 10.17487/RFC8210, September 2017,
              <https://www.rfc-editor.org/info/rfc8210>.

   [I-D.ietf-sidrops-8210bis]
              Bush, R., Austein, R., and T. Harrison, "The Resource
              Public Key Infrastructure (RPKI) to Router Protocol,
              Version 2", Work in Progress, Internet-Draft, draft-ietf-
              sidrops-8210bis-24, 5 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              8210bis-24>.

   [I-D.ietf-sidrops-aspa-slurm]
              Snijders, J. and B. Cartwright-Cox, "Simplified Local
              Internet Number Resource Management (SLURM) with RPKI
              Autonomous System Provider Authorizations (ASPA)", Work in
              Progress, Internet-Draft, draft-ietf-sidrops-aspa-slurm-
              04, 16 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-slurm-04>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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>.




Fu & Geng                Expires 28 August 2026                 [Page 8]

Internet-Draft           Enhanced SLURM Filters            February 2026


Informative References

   [RFC7909]  Kisteleki, R. and B. Haberman, "Securing Routing Policy
              Specification Language (RPSL) Objects with Resource Public
              Key Infrastructure (RPKI) Signatures", RFC 7909,
              DOI 10.17487/RFC7909, June 2016,
              <https://www.rfc-editor.org/info/rfc7909>.

   [I-D.van-beijnum-sidrops-pathrpki]
              van Beijnum, I., "Path validation with RPKI", Work in
              Progress, Internet-Draft, draft-van-beijnum-sidrops-
              pathrpki-00, 20 June 2019,
              <https://datatracker.ietf.org/doc/html/draft-van-beijnum-
              sidrops-pathrpki-00>.

   [I-D.ietf-grow-rpki-as-cones]
              Snijders, J., stucchi-lists@glevia.com, and M. Aelmans,
              "RPKI Autonomous Systems Cones: A Profile To Define Sets
              of Autonomous Systems Numbers To Facilitate BGP
              Filtering", Work in Progress, Internet-Draft, draft-ietf-
              grow-rpki-as-cones-02, 24 April 2020,
              <https://datatracker.ietf.org/doc/html/draft-ietf-grow-
              rpki-as-cones-02>.

   [I-D.spaghetti-sidrops-rpki-asgroup]
              Snijders, J. and F. Korsbäck, "A profile for RPKI Signed
              Groupings of Autonomous System Numbers (ASGroup)", Work in
              Progress, Internet-Draft, draft-spaghetti-sidrops-rpki-
              asgroup-00, 16 November 2022,
              <https://datatracker.ietf.org/doc/html/draft-spaghetti-
              sidrops-rpki-asgroup-00>.

   [I-D.ietf-sidrops-rpki-prefixlist]
              Snijders, J. and G. Huston, "A profile for Signed Prefix
              Lists for Use in the Resource Public Key Infrastructure
              (RPKI)", Work in Progress, Internet-Draft, draft-ietf-
              sidrops-rpki-prefixlist-05, 10 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              rpki-prefixlist-05>.

   [I-D.ietf-sidrops-moa-profile]
              Xie, C., Dong, G., Li, X., Huston, G., and D. Ma, "A
              Profile for Mapping Origin Authorizations (MOAs)", Work in
              Progress, Internet-Draft, draft-ietf-sidrops-moa-profile-
              03, 11 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              moa-profile-03>.




Fu & Geng                Expires 28 August 2026                 [Page 9]

Internet-Draft           Enhanced SLURM Filters            February 2026


   [I-D.chen-sidrops-sispi]
              Chen, L., Liu, L., Li, D., and L. Qin, "A Profile of
              Signed SAVNET-Peering Information (SiSPI) Object for
              Deploying Inter-domain SAVNET", Work in Progress,
              Internet-Draft, draft-chen-sidrops-sispi-04, 14 September
              2025, <https://datatracker.ietf.org/doc/html/draft-chen-
              sidrops-sispi-04>.

Authors' Addresses

   Yu Fu
   China Telecom
   Beijing
   China
   Email: fuy44@chinatelecom.cn


   Nan Geng
   Huawei
   Beijing
   China
   Email: gengnan@huawei.com





























Fu & Geng                Expires 28 August 2026                [Page 10]
