[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                            R. Bush
Internet-Draft                        Internet Initiative Japan & Arrcus
Intended status: Standards Track                                K. Patel
Expires: January 3, 2020                                          Arrcus
                                                            July 2, 2019


                      Origin Validation Signaling
                    draft-ymbk-sidrops-ov-signal-03

Abstract

   Within a trust boundary, e.g. an operator's PoP, it may be useful to
   have only a few central devices do full Origin Validation using the
   Resource Public Key Infrastructure, and be able to signal to an
   internal sender that a received route fails Origin Validation.  E.g.
   route reflectors could perform Origin Validation for a cluster and
   signal back to a sending client that it sent an invalid route.
   Routers capable of sending and receiving this signal can use the
   extended community described in [RFC8097].

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
   be interpreted as described in [RFC2119] only when they appear in all
   upper case.  They may also appear in lower or mixed case as English
   words, without normative meaning.

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 January 3, 2020.






Bush & Patel             Expires January 3, 2020                [Page 1]


Internet-Draft         Origin Validation Signaling             July 2019


Copyright Notice

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

1.  Introduction

   Within a routing trust boundary, e.g. an operator's Point of Presence
   (PoP), it may not be desirable or necessary for all routers to
   perform Origin Validation using the Resource Public Key
   Infrastructure (RPKI) per [RFC6811].  A good example is route
   reflectors (see [RFC4456]).

   An RPKI-enabled device, an Evaluator, SHOULD signal receipt of an
   Invalid route back to the sender by announcing that route back to the
   sender marked with the BGP Prefix Origin Validation State Extended
   Community as defined in [RFC8097] with a last octet having the value
   2, meaning "Invalid."  In the rest of this document we take the
   liberty of calling it the "community."

   We use the term "Sender" to refer to the router announcing routes to
   the device evaluating the Origin Validation of the announcements.
   Beware that the Sender receives signaling back from the Evaluator,
   which can be somewhat confusing.

   We use the term "Evaluator" to describe the device receiving routing
   announcements from senders, applying RPKI-based Origin Validation,
   and possibly signaling route Invalidity back to the sender(s).

2.  Suggested Reading

   It is assumed that the reader understands BGP, [RFC4271], the RPKI,
   [RFC6480], RPKI-based Prefix Validation, [RFC6811], and the BGP
   Prefix Origin Validation State Extended Community as described in
   [RFC8097].






Bush & Patel             Expires January 3, 2020                [Page 2]


Internet-Draft         Origin Validation Signaling             July 2019


3.  Trust Boundary

   As a general rule, we discourage 'outsourcing trust,' i.e.  letting
   others make security decisions for us.  But there are operational
   environments with a somewhat wide trust boundary, a single operator's
   PoP for example.

   This is not outsourcing trust; this is remote decision making.  It is
   not letting a third party make the decision; it is simply doing it on
   a different computer.  It's trust in a distributed system, where what
   is (sometimes) called the Policy Decision Point is not the same as
   the Policy Enforcement Point.

   As described in [RFC7115], a PoP might have a single RPKI Cache,
   hence all trust is vested in it.  So it is reasonable that routers in
   that PoP could share Origin Validation results instead of each doing
   full validation.

   An [RFC4456] Route Reflector Cluster is an obvious candidate for this
   approach.  The route reflector(s) would perform Origin Validation and
   signal an Invalid route back to the sending client.

   [RFC8097] provides the obvious signaling mechanism, the BGP Prefix
   Origin Validation State Extended Community.  The device performing OV
   SHOULD signal back to the sender by announcing the offending prefix
   marked with the extended community with the last octet having the
   value 2, indicating an Invalid route.

4.  The OV Signaling Capability

   Unfortunately, the router sending the Invalid announcement is not
   normally expecting to receive it back.  Therefore, both parties MUST
   agree on this feature by using a BGP Capability [RFC5492].

   To advertise the OV Signaling Capability to a peer, a BGP speaker
   uses BGP Capabilities Advertisement [RFC5492].  By advertising the OV
   Signaling Capability to a peer, a BGP speaker conveys that it is able
   to send, receive, and properly handle OV Signaling using the
   community.

   A peer which does not advertise this capability MUST NOT send OV
   Signaling, and BGP OV Signaling MUST NOT be sent to it.

   The OV Signaling Capability is a new BGP Capability defined with
   Capability code [TBD] and Capability length 0.






Bush & Patel             Expires January 3, 2020                [Page 3]


Internet-Draft         Origin Validation Signaling             July 2019


5.  Recommended Action

   This section assumes that the OV Signaling Capability has been
   negotiated by the sending and receiving routers.

   An Evaluating device which performs Origin Validation on a route
   received from a capable sender and finds a prefix with a particular
   origin AS to be Invalid (in the [RFC6811] sense), MUST announce that
   prefix back to the sending router from which it was received with the
   Invalid origin AS and the addition of the community with the last
   octet being 2.

   A sender receiving the returned prefix announcement so marked MUST
   treat it the way it would treat an Invalid origin that it itself
   detected.  It should withdraw all routes it had announced to that
   prefix with the Invalid origin AS.  This includes withdrawing any
   instances of additional paths with that origin AS advertised under
   [RFC7911].

   For a sender to properly evaluate the community returned by the
   evaluator, the sender MUST recognize the community before loop
   detection.  This is a change to the Phase 2 Route Selection process
   of [RFC4271] Section 9.1.2.

   If a sender originally received the Invalid route from an evaluator
   within its trust boundary with which it has negotiated the OV
   Signaling Capability, it MAY also propagate that signal to the
   original sender.

6.  Security Considerations

   As with all communities which cause semantic change, this use of the
   community may be abused as an attack vector.  Therefore the operator
   MUST configure their incoming external border to strip the community.

   As the BGP sessions are already established using whatever channel
   security the operator chooses or not, this change specifies no
   additional channel or object security.  Of course, the BGP transport
   should be protected for integrity and authentication.  TCP-MD5
   [RFC2385] is available on almost all platforms.  If more modern
   methods are available, they should be used.

   Outsourcing security is usually considered bad policy.
   Section Section 3 above discusses why that is not really the case
   here.

   Otherwise, this document does not create security considerations
   beyond those of [RFC6811].



Bush & Patel             Expires January 3, 2020                [Page 4]


Internet-Draft         Origin Validation Signaling             July 2019


7.  IANA Considerations

   This document requests the IANA assign the "OV Signaling Capability"
   to the BGP Capabilities described in Section 2.1 in the "Capability
   Codes" registry's "IETF Review" range [RFC8126]..  This document is
   the reference for the new capability.

8.  Acknowledgments

   Thanks to Steve Bellovin for a serious security review, and Rob
   Austein for a useful security snark.

9.  References

9.1.  Normative References

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

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
              1998, <http://www.rfc-editor.org/info/rfc2385>.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
              <http://www.rfc-editor.org/info/rfc4456>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <http://www.rfc-editor.org/info/rfc5492>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <http://www.rfc-editor.org/info/rfc6811>.

   [RFC7115]  Bush, R., "Origin Validation Operation Based on the
              Resource Public Key Infrastructure (RPKI)", BCP 185,
              RFC 7115, DOI 10.17487/RFC7115, January 2014,
              <http://www.rfc-editor.org/info/rfc7115>.

   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <http://www.rfc-editor.org/info/rfc7911>.



Bush & Patel             Expires January 3, 2020                [Page 5]


Internet-Draft         Origin Validation Signaling             July 2019


   [RFC8097]  Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R.
              Bush, "BGP Prefix Origin Validation State Extended
              Community", RFC 8097, DOI 10.17487/RFC8097, March 2017,
              <http://www.rfc-editor.org/info/rfc8097>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <http://www.rfc-editor.org/info/rfc8126>.

9.2.  Informative References

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <http://www.rfc-editor.org/info/rfc6480>.

Authors' Addresses

   Randy Bush
   Internet Initiative Japan & Arrcus
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   US

   Email: randy@psg.com


   Keyur Patel
   Arrcus
   2077 Gateway Place, Suite #250
   San Jose, CA  95119
   United States of America

   Email: keyur@arrcus.com












Bush & Patel             Expires January 3, 2020                [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/