Network Working Group                                        R. Gagliano
Internet-Draft                                                  K. Patel
Intended status: Standards Track                                 B. Weis
Expires: July 4, 2012                                      Cisco Systems
                                                           March 5, 2012


       BGPSEC router key roll-over as an alternative to beaconing
                 draft-rogaglia-sidr-bgpsec-rollover-00

Abstract

   The current BGPSEC draft documents do not specifies a key roll-over
   process for routers.  This document describes a possible key roll-
   over process and explores its impact to mitigate replay attacks and
   eliminate the need for beaconing in BGPSEC.

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 http://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 July 4, 2012.

Copyright Notice

   Copyright (c) 2012 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.



Gagliano, et al.          Expires July 4, 2012                  [Page 1]


Internet-Draft              BGPSEC roll-over                January 2012


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Key Roll-over in BGPSEC  . . . . . . . . . . . . . . . . . . .  5
     3.1.  A proposed process for BGPSEC key roll-over  . . . . . . .  5
   4.  BGPSEC key rollover as a measure against replays attacks
       in BGPSEC  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  BGPSEC beaconing challenges  . . . . . . . . . . . . . . .  7
     4.2.  BGPSEC Re-play attack window requirement . . . . . . . . .  7
     4.3.  BGPSEC key rollover as a mechanism to protect against
           replay attacks . . . . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
































Gagliano, et al.          Expires July 4, 2012                  [Page 2]


Internet-Draft              BGPSEC roll-over                January 2012


1.  Requirements notation

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














































Gagliano, et al.          Expires July 4, 2012                  [Page 3]


Internet-Draft              BGPSEC roll-over                January 2012


2.  Introduction

   In BGPSEC, a key roll-over (or re-keying) is the process of changing
   the router's key pair, issuing the correspondent new End-Entity
   certificates and revoke the old one.  This process will need to
   happen at regular intervals normally due to local policies at each
   network.

   During a roll-over process, a router needs to generate BGP UPDATE
   messages in order to signal the new key to be used to its neighbors.
   So, intuitively, a frequent key roll-over process has similar effects
   as the beaconing process proposed by the BGPSEC base documents to
   protect a BGPSEC attribute against a re-play attack.  However, there
   are a number of operational details to be considered if the expire
   time field in the BGPSEC attribute is removed.

   This document details a possible key roll-over process in BGPSEC and
   explores the operational environment where key roll-overs could be
   used as a protection against a re-play attach against BGPSEC
































Gagliano, et al.          Expires July 4, 2012                  [Page 4]


Internet-Draft              BGPSEC roll-over                January 2012


3.  Key Roll-over in BGPSEC

   The key roll-over process in BGPSEC has not been well defined yet.
   However, this will be a mandatory process due to some of the
   following causes:

   BGPSEC scheduled roll-over:  BGPSEC certificates have an expiration
         date (NotValidAfter).  Although it is possible to generate a
         new certificate without changing the key pair, it is normally
         good practice to adopt the policy of using a new key pair in
         every roll-over event.

   BGPSEC certificate fields changes:  A BGPSEC certificate field's
         information (such as the ASN or the Subject) may need to be
         changed.  The normal process requires the roll-over of the old
         certificate with a new key pair and the revocation of the old
         certificate.

   BGPSEC emergency roll-over  Some special circumstances (such as a
         compromised key) may require the roll-over of a BGPSEC
         certificate.

   It should be clear at this point that a key roll-over process is
   required for BGPSEC.  The next section describes how this process may
   be implemented.

3.1.  A proposed process for BGPSEC key roll-over

   The BGPSEC key roll-over process should be very tighten to the key
   provisioning mechanisms that would be in place.  The key provisioning
   mechanisms for BGPSEC are not yet documented.  We will assume that
   such an automatic provisioning mechanism will be in place (a possible
   provisioning mechanism when the private key lives only inside the BGP
   speaker is the Enrollment over Secure Transport (EST).  This protocol
   will allow BGPSEC code to include automatic re-keying scripts with
   minimum development cost.

   When the same private key is shared by different routers, a mechanism
   to distribute the private key will need to be implemented.  A
   possible solution may include the transmission of the private key
   over a secure channel.  The PKIX WG has started work on this sense by
   adopting [I-D.ietf-pkix-cmc-serverkeygeneration]

   If we work under the assumption that an automatic mechanism will
   exist to rollover a BGPSEC certificate, a possible process could be:

   1.  New Certificate Pre-Publication: The first step in the rollover
       mechanism is to pre-publish the new public key.  In order to



Gagliano, et al.          Expires July 4, 2012                  [Page 5]


Internet-Draft              BGPSEC roll-over                January 2012


       accomplish this goal, the new key pair and certificate will need
       to be generated and published on the correspondent RPKI
       repository.  This process will vary in every environment as it
       will depend on where the keys are located (either in every router
       or on a centralized server), if the RPKI CA is hosted at the ISP
       or at an external party (i.e. needs to use the RPKI provisioning
       protocol) and finally if the repository is also local or hosted
       (i.e. will need to use the RPKI-Repository protocol.)

   2.  Stage Period: A stage period will be required from the time a new
       certificate is published in the RPKI global repository until the
       time it is fetched by RPKI caches around the globe.  The exact
       minimum staging time is not clear and will require experimental
       results from RPKI.  Design documents mention a lower limit of 24
       hours.  If rollovers will be done frequently and we want to avoid
       the stage period in case of emergency rollover needs, an
       administrator can always provision two certificate for every
       router.  In this case when the rollover operation is needed, the
       cache servers around the globe would already have the new keys.

   3.  Twilight: At this moment, the BGP speaker that uses the key been
       rolled-over will stop using the OLD key for signing and start
       using the NEW key.  Also, the router will generate appropriate
       BGP UPDATES just as in the typical operation of refreshing out-
       bound BGP polices.

   4.  CRL Publication: As part of the rollover process, a CA MAY decide
       that it will publish the serial number of the OLD BGPSEC
       certificate on its CRL.  It may also be the case that the CA will
       just let the certificate to expire and not update its CRL.

   5.  RPKI-Router Protocol Withdrawal: Either due to the inclusion of
       the OLD certificate serial number or the expiration of the
       certificate's validation, the RPKI cache servers around the globe
       will need to communicate to its RTR peers that the OLD
       certificate's public key is not longer valid (withdrawal
       message).  It is not documented yet what will be a router's
       reaction to a RTR withdrawal message but it should include the
       removal of any RIB entry that includes a BGPSEC attribute signed
       with that key and the generation of the correspondent BGP
       WITHDRAWS (either implicit or explicit).

   To conclude this section, we can say that the proposed rollover
   mechanism will depend on the existence of an automatic provisioning
   process for BGPSEC certificates, that it will required a staging
   mechanism given by RPKI propagation time of around 24hours and that
   it will generate BGP UPDATES for all prefixes in the router been re-
   keying.



Gagliano, et al.          Expires July 4, 2012                  [Page 6]


Internet-Draft              BGPSEC roll-over                January 2012


4.  BGPSEC key rollover as a measure against replays attacks in BGPSEC

   There are two typical measures to mitigate replay attacks: addition
   of a timestamp or addition of a serial number.  Currently BGPSEC
   offers a timestamp (expiration time) as a protection against re-play
   attacks of BGPSEC messages.  The process requires all BGP Speakers
   that originate a BGP UPDATE to beaconing the message before its
   expiration time.  This requirement changes a long standing BGP
   operation practice and the community have been searching for
   alternatives.

4.1.  BGPSEC beaconing challenges

   To be completed

4.2.  BGPSEC Re-play attack window requirement

   The BGPSEC Ops document give some ideas of requirements for the re-
   play attack in BGPSEC.  For the vast majority of the prefixes, the
   requirement will be in the order of days or weeks.  For a very small
   fraction, but critical, of the prefixes, the requirement may be in
   the order of hours.

4.3.  BGPSEC key rollover as a mechanism to protect against replay
      attacks

   The question we would like to ask is: can key rollover provide us a
   similar protection against re-play attacks without the need for
   beaconing?

   The answer is that YES when the window requirement is in the order of
   days and the router re-keying is the edge router of the origin AS.
   By using re-keying, you are letting the BGPSEC certificate validation
   time as your timestamp against replay attacks.  However, the use of
   frequent key rollovers comes with an additional administrative cost
   and risks if the process fails.  As documented before, re-keying
   should be supported by automatic tools and for the great majority of
   the Internet it will be done with good lead time to correct any
   inconvenient in the process.

   For a transit AS that also originates its BGP UPDATES for its own
   prefixes, the key rollover process may generate a large number of
   UPDATE messages (even the complete DFZ).  For this reason, it is
   recommended that routers in this scenario been provisioned with two
   certificates: one to sign BGP UPDATES in transit and a second one to
   sign BGP UPDATE for prefixes originated in its AS.  Only the second
   certificate should be frequently rolled-over.




Gagliano, et al.          Expires July 4, 2012                  [Page 7]


Internet-Draft              BGPSEC roll-over                January 2012


   Advantage of Re-keying as re-play attack protection mechanism:

   1.  Does not require beaconing

   2.  All timestamps policies are maintained in RPKI

   3.  Additional administrative cost is paid by the provider that wants
       to protect its infrastructure

   4.  Can be implemented in coordination with planned topology changes
       by either origin ASes or transit ASes (if I am changing
       providers, I rollover)

   5.  Eliminates the discussion on who has the authority over the
       expiration time

   Disadvantage of Re-keying as re-play attack protection mechanism:

   1.  More administrative load due to frequent rollover, although how
       frequent is still not clear.

   2.  Minimum window size bounded by RPKI propagation time to RPKI
       caches.  If pre-provisioning done ahead of time, it means 24
       hours minimum in paper.  However, more experimentation is needed
       when RPKI and cache servers are more massively deployed.

   3.  Increases dynamic of RPKI repository

   4.  More load on RPKI caches, but they are meant to do this work.






















Gagliano, et al.          Expires July 4, 2012                  [Page 8]


Internet-Draft              BGPSEC roll-over                January 2012


5.  IANA Considerations

   No IANA considerations
















































Gagliano, et al.          Expires July 4, 2012                  [Page 9]


Internet-Draft              BGPSEC roll-over                January 2012


6.  Security Considerations

   No security considerations.
















































Gagliano, et al.          Expires July 4, 2012                 [Page 10]


Internet-Draft              BGPSEC roll-over                January 2012


7.  Acknowledgements

   None yet
















































Gagliano, et al.          Expires July 4, 2012                 [Page 11]


Internet-Draft              BGPSEC roll-over                January 2012


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008.

8.2.  Informative References

   [I-D.ietf-pkix-cmc-serverkeygeneration]
              Schaad, J., Timmel, P., and S. Turner, "CMC Extensions:
              Server Key Generation",
              draft-ietf-pkix-cmc-serverkeygeneration-00 (work in
              progress), January 2012.

   [I-D.ietf-sidr-origin-validation-signaling]
              Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R.
              Bush, "BGP Prefix Origin Validation State Extended
              Community", draft-ietf-sidr-origin-validation-signaling-00
              (work in progress), November 2010.

   [I-D.ietf-sidr-pfx-validate]
              Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation",
              draft-ietf-sidr-pfx-validate-01 (work in progress),
              February 2011.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.










Gagliano, et al.          Expires July 4, 2012                 [Page 12]


Internet-Draft              BGPSEC roll-over                January 2012


Authors' Addresses

   Roque Gagliano
   Cisco Systems
   Avenue des Uttins 5
   Rolle, VD  1180
   Switzerland

   Email: rogaglia@cisco.com


   Keyur Patel
   Cisco Systems
   170 W. Tasman Driv
   San Jose, CA  95134
   CA

   Email: keyupate@cisco.com


   Brian Weis
   Cisco Systems
   170 W. Tasman Driv
   San Jose, CA  95134
   CA

   Email: bew@cisco.com
























Gagliano, et al.          Expires July 4, 2012                 [Page 13]