[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Secure Inter-Domain Routing                                 T. Manderson
Internet-Draft                                        terrym.net pty ltd
Intended status: Standards Track                           G. Michaelson
Expires: April 8, 2009                                             APNIC
                                                         October 5, 2008


                  RPKI Repository Retrieval Mechanism
                     draft-manderson-sidr-fetch-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 8, 2009.

Abstract

   This document proposes a mechanism for a relying party to synchronise
   a local cache of the RPKI repository using a HTTPS retrieval
   mechanism.











Manderson & Michaelson    Expires April 8, 2009                 [Page 1]

Internet-Draft                    RRRM                      October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  RPKI Repository  . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Publication Points . . . . . . . . . . . . . . . . . . . .  3
     2.3.  RPKI Manifests . . . . . . . . . . . . . . . . . . . . . .  3
     2.4.  Object URI . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.5.  CA and Manifest Relationship . . . . . . . . . . . . . . .  4
     2.6.  Traversing a RPKI Repository . . . . . . . . . . . . . . .  4
   3.  Transport Protocol . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  HTTPS  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Other Protocols  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Retrieval  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Retrieval Algorithm  . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  Post-Fetch Validated (PFV) . . . . . . . . . . . . . .  6
   5.  Client Considerations  . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Hash Comparison  . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Hash Mismatch  . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     8.1.  RRS and Manifest Integrity . . . . . . . . . . . . . . . .  8
   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 11























Manderson & Michaelson    Expires April 8, 2009                 [Page 2]

Internet-Draft                    RRRM                      October 2008


1.  Introduction

   This document details a mechanism and algorithm for a relying party
   to synchronise a local cache of RPKI objects against the collection
   of original publication points.

1.1.  Terminology

   It is assumed that the reader is familiar with the terms and concepts
   described in "Internet X.509 Public Key Infrastructure Certificate
   and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile
   for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs]
   "Manifests for the Resource Public Key Infrastructure"
   [I-D.ietf-sidr-rpki-manifests], "X.509 Extensions for IP  Addresses
   and AS Identifiers" [RFC3779], "Hypertext Transfer Protocol --
   HTTP/1.1" [RFC2616], "HTTP Over TLS" [RFC2818], and related regional
   Internet registry address management policy documents.

1.2.  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 2119.


2.  Overview

2.1.  RPKI Repository

   An RPKI Repository is a collection of RPKI Publication Points.

2.2.  Publication Points

   A Publication Point is the location where RPKI objects exist for
   public use.  The Publication Point also contains a manifest of all
   the RPKI objects that are published at that location.  The
   Publication Point URI is held in the SIA of the RPKI Certificate that
   signed the objects at that Publication Point.

2.3.  RPKI Manifests

   A manifest is a signed object, listing of all of the RPKI objects at
   a publication point in the RPKI Repository, excluding the manifest
   itself.  The manifest contains the file name and a hash of the
   contents of the RPKI object file.

   The URI to the manifest exists in the manifest SIA from the
   Certificate that signed the manifest.



Manderson & Michaelson    Expires April 8, 2009                 [Page 3]

Internet-Draft                    RRRM                      October 2008


   Manifest validation SHOULD be done according to "Manifests for the
   Resource Public Key Infrastructure" [I-D.ietf-sidr-rpki-manifests].

2.4.  Object URI

   The object location URI is constructed by using the Publish Point
   from the Signing RPKI Certificate SIA and the File (name) in the
   manifest signed by the Signing RPKI Certificate.  The exception to
   this is the Certificate Authority (CA) certificate and manifest
   relationship.

2.5.  CA and Manifest Relationship

   In the situation that the certificate in focus is the Certificate
   Authority (CA) certificate:

   o  Like all RPKI certificates [I-D.ietf-sidr-res-certs] the CA
      contains a SIA that identifies a Publish Point and a Manifest.

   o  The CA signs an End Entity (EE) Certificate for the single purpose
      of signing the CA manifest.

   o  The EE certificate has an SIA that also identifies the manifest.

2.6.  Traversing a RPKI Repository

   A generalised RPKI hierarchy structure of a resource repository,
   including the out of band collected Trust Anchor (CA), can be
   represented as:






















Manderson & Michaelson    Expires April 8, 2009                 [Page 4]

Internet-Draft                    RRRM                      October 2008


   CA Certificate                  CA Publication Point
   SIA --Repository------->+------------------------------+
       --Manifest-----------> manifest.cms<-------------------------+
                           |  CRL                         |         |
                           |  subord CA certs             |         |
                           |  subord multi-sign EE certs  |         |
                           |         SIA ------Repository-------+   |
                           |             ------Manifest-------+ |   |
                           |  subord 1:1 Manifest EE cert |   | |   |
                           |         SIA --Object-------------------+
                           |  subord 1:1 EE certs         |   | |
                           |         SIA --Object--+      |   | |
                           |                       |      |   | |
                           |           +-----------+      |   | |
                           |           V                  |   | |
                           |  signed Object               |   | |
                           |                              |   | |
                           +------------------------------+   | |
                                                              | |
                                        ----------------------+ |
                                        |                       |
                           +------------|---------------------+<
                           |            V                     |
                           |         manifest.cms             |
                           |         signed objects           |
                           +----------------------------------+
                                 EE Publication Point
                                 (for multi-sign EEs)




   The following broad algorithm MAY be used to traverse the hierarchy,
   starting with the Trust Anchor or CA RPKI Certificate.

   1.  Collect the manifest referenced in the id-ad-rpkiManifest
       [I-D.ietf-sidr-res-certs] Manifest AccessMethod of the SIA of the
       Certificate.

   2.  Collect, from the Publication Point, every valid object listed in
       the manifest.

   3.  For each subordinate object with id-ad-signedObjectRepository
       [I-D.ietf-sidr-res-certs] and id-ad-rpkiManifest access method
       SIA values repeat fom step 1.

   Processing of each subordinate Publish Point MAY be done in parallel,
   provided sufficient RPKI material has been collected for Manifest and



Manderson & Michaelson    Expires April 8, 2009                 [Page 5]

Internet-Draft                    RRRM                      October 2008


   RPKI validation.


3.  Transport Protocol

3.1.  HTTPS

   When transferring a RPKI objects HTTPS [RFC2818] based transfers MUST
   be used in order to ensure the integrity of the repository site or to
   encrypt the retrieval of the RPKI objects.  Various HTTPS methods MAY
   be used to minimise the number of simultaneous fetches and data
   transfers over the transport connection.  It is further recommended
   that the RRRM client make efforts to reduce the number of
   simultaneous connections such that a balance exists between the
   number of open TCP connections and the number of objects retrieved
   per connection for each publication point.

3.2.  Other Protocols

   The retrieval algorithm specified in this document can also be used
   by other protocols as an effecient way to synchronise the RPKI
   repository with a local cache, provided HTTP specifics such as (and
   not limited to) redirects, http pragma, connection behaviours and
   pipe-lining are addresed.


4.  Retrieval

4.1.  Retrieval Algorithm

   If the SIA for the Publish Point of the RPKI Certificate Authority
   (CA) Certificate or End Entity Certificate defines a HTTPS access
   method in the URI then the following algorithm MAY be used by a
   Retrieval Client for any initial and subsequent fetch of certificates
   and signed outcomes (objects) from an RPKI Repository Server (RRS).

4.1.1.  Post-Fetch Validated (PFV)

   a.  Fetch the appropriate manifest [I-D.ietf-sidr-rpki-manifests]
       from the RRS.  The RC MAY maintain the connection to the RRS with
       a persistent connection.

   b.  Confirm the manifest's validity.

       *  If the manifest is invalid, or the manifest is empty,
          terminate processing and close any RRS connections





Manderson & Michaelson    Expires April 8, 2009                 [Page 6]

Internet-Draft                    RRRM                      October 2008


   c.  Construct a list of URIs to be retrieved by comparing hash values
       in the downloaded manifest, with the hash values of the locally
       cached object:

       *  If a local manifest does not exist then all objects contained
          in the manifest MUST be listed for retrieval.

       *  If an object entry in the downloaded manifest does not exist
          locally, the URI SHOULD be added to the retrieval list.

       *  If an object exists locally and does not appear in the
          manifest, it SHOULD be deleted from the local cache.

       *  If the hash value of the object in the downloaded manifest
          does not match the hash value of the local copy of the object,
          the URI of the object SHOULD be added to the retrieval list.

       *  If the retrieval list is empty, terminate processing and close
          any RRS connections.

   d.  Fetch the list of objects using pipe-lined GET requests.

       *  HTTP redirects SHOULD be honoured by the client and followed
          using a separate RRS connection for the object if located at a
          different RSS endpoint.

   e.  Confirm that all of the objects listed in the downloaded manifest
       have been retrieved.  Should one or more objects fail to
       retrieve, it is then a matter of local cache policy to continue
       with the intent of RPKI validating retrieved objects.  The client
       (and cache policy) should realise that it would be unlikely that
       enough RPKI information would then exist locally to fully
       validate objects from that publication point, and as such
       processing in this condition may be wasteful.  It is also
       possible that an object may have been removed from the
       publication point between retrival of the manifest and the
       attempted retrieval of the object.

   f.  Confirm the hash of the downloaded object file contents matches
       the hash stored in the downloaded manifest

       *  If the hash does not match, the object MAY be newer than the
          manifest and the object SHOULD be RPKI validated.

   g.  Close any RRS connections.

   h.  RPKI Validate the retrieved objects and store the validated
       objects in the local cache.



Manderson & Michaelson    Expires April 8, 2009                 [Page 7]

Internet-Draft                    RRRM                      October 2008


5.  Client Considerations

5.1.  Hash Comparison

   As described in the PFV algorithm, if the hash does not match, the
   object may be newer than the manifest.  It is RECOMMENDED that
   suitable warnings be generated by the retrieval client to alert to
   any issues of a hash mismatch.

5.2.  Hash Mismatch

   To minimise the occurrences of hash values that do not match, the RC
   MAY consider postponing retrieval of a RPKI Repository for some
   period of time either side of the "nextUpdate" time detailed in the
   manifest.


6.  Acknowledgements

   Due recognition needs to be given to all the individuals involved in
   the inter-RIR Resource Certificate working group.


7.  IANA Considerations

   This memo includes no request to IANA.


8.  Security Considerations

8.1.  RRS and Manifest Integrity

   A scenario exists where a malicious attack could place an invalid
   RPKI certificate on the RRS in the Publication Point prior to the
   manifest creation.  While this does not represent a high risk to the
   overall Resource Certificate system as the object will fail to
   validate, it may affect the Relying Party as:

   o  An object is extremely large and RC retrieval of the object may
      cause resource, network, or other types of congestion.

   o  Many invalid objects, which the RC must download, may affect
      overall performance or the RC or the overall Resource Certificate
      system.







Manderson & Michaelson    Expires April 8, 2009                 [Page 8]

Internet-Draft                    RRRM                      October 2008


9.  Normative References

   [I-D.huston-sidr-repos-struct]
              Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure",
              draft-huston-sidr-repos-struct-01 (work in progress),
              February 2008.

   [I-D.ietf-sidr-res-certs]
              Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates",
              draft-ietf-sidr-res-certs-13 (work in progress),
              September 2008.

   [I-D.ietf-sidr-rpki-manifests]
              Austein, R., Huston, G., Kent, S., and M. Lepinski,
              "Manifests for the Resource Public Key Infrastructure",
              draft-ietf-sidr-rpki-manifests-03 (work in progress),
              September 2008.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.


Authors' Addresses

   Terry Manderson
   terrym.net pty ltd
   AU

   Phone: +61 4 1127 5673
   Email: terry@terrym.net








Manderson & Michaelson    Expires April 8, 2009                 [Page 9]

Internet-Draft                    RRRM                      October 2008


   George Michaelson
   APNIC
   AU

   Phone: +61 7 3858 3100
   Email: ggm@apnic.net













































Manderson & Michaelson    Expires April 8, 2009                [Page 10]

Internet-Draft                    RRRM                      October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Manderson & Michaelson    Expires April 8, 2009                [Page 11]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/