Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
RFC 7909

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12

Internet Engineering Task Force (IETF)                      R. Kisteleki
Request for Comments: 7909                                      RIPE NCC
Updates: 2622, 4012                                          B. Haberman
Category: Standards Track                                        JHU APL
ISSN: 2070-1721                                                June 2016

     Securing Routing Policy Specification Language (RPSL) Objects
       with Resource Public Key Infrastructure (RPKI) Signatures

Abstract

   This document describes a method that allows parties to
   electronically sign Routing Policy Specification Language objects and
   validate such electronic signatures.  This allows relying parties to
   detect accidental or malicious modifications of such objects.  It
   also allows parties who run Internet Routing Registries or similar
   databases, but do not yet have authentication (based on Routing
   Policy System Security) of the maintainers of certain objects, to
   verify that the additions or modifications of such database objects
   are done by the legitimate holder(s) of the Internet resources
   mentioned in those objects.  This document updates RFCs 2622 and 4012
   to add the signature attribute to supported RPSL objects.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7909.

Kisteleki & Haberman         Standards Track                    [Page 1]
RFC 7909                      Securing RPSL                    June 2016

Copyright Notice

   Copyright (c) 2016 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
   (http://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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Signature Syntax and Semantics  . . . . . . . . . . . . . . .   4
     2.1.  General Attributes and Meta Information . . . . . . . . .   4
     2.2.  Signed Attributes . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Storage of the Signature Data . . . . . . . . . . . . . .   6
     2.4.  Number Resource Coverage  . . . . . . . . . . . . . . . .   6
     2.5.  Validity Time of the Signature  . . . . . . . . . . . . .   6
   3.  Signature Creation and Validation Steps . . . . . . . . . . .   6
     3.1.  Canonicalization  . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Signature Creation  . . . . . . . . . . . . . . . . . . .   8
     3.3.  Signature Validation  . . . . . . . . . . . . . . . . . .   9
   4.  Signed Object Types and Set of Signed Attributes  . . . . . .   9
   5.  Keys and Certificates Used for Signature and Verification . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Kisteleki & Haberman         Standards Track                    [Page 2]
RFC 7909                      Securing RPSL                    June 2016

1.  Introduction

   Objects stored in resource databases, like the RIPE DB, are generally
   protected by an authentication mechanism: anyone creating or
   modifying an object in the database has to have proper authorization
   to do so, and therefore has to go through an authentication procedure
   (provide a password, certificate, email signature, etc.).  However,
   for objects transferred between resource databases, the
   authentication is not guaranteed.  This means that when a Routing
   Policy Specification Language (RPSL) object is downloaded from a
   database, the consumer can reasonably claim that the object is
   authentic if it was locally created, but cannot make the same claim
   for an object imported from a different database.  Also, once such an