An in-band BGP mechanism for looking-glass address discovery
draft-jaufeerally-bgp-lg-cap-01

Document Type Active Internet-Draft (individual)
Author Rayhaan Jaufeerally 
Last updated 2021-07-25
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                      R. Jaufeerally, Ed.
Internet-Draft                                                       TBD
Intended status: Informational                                 July 2021
Expires: 26 January 2022

      An in-band BGP mechanism for looking-glass address discovery
                    draft-jaufeerally-bgp-lg-cap-01

Abstract

   Autonomous Systems (ASes) that peer with one another using the Border
   Gateway Protocol (BGP) RFC 4271 [RFC4271] do not have an automated
   way to tell if the prefixes announced over a particular peering link
   are acceped by the peer.  One way in which an AS operator can verify
   acceptance of routes by a peer is using a looking glass which may be
   provided by the peer, however this introduces manual toil in the
   operation and turnup of peering links, and does not allow for
   continued validation to ensure there are no regressions.  Looking
   glasses are often manually found by browsing the website of the peer
   or via a database of peering participants.

   This document proposes a new in-band mechanism for transmitting
   administrative data between BGP peers, and defines one such use case
   for propagating looking glass addresses.  This is done via a new
   Address Family Identifier (AFI) which carries a message that we
   define here, inside the Multi Protocol (MP_REACH and MP_UNREACH) path
   attribute

   The looking glass that we expose via the proposed mechanism conforms
   to that defined in RFC 8522 [RFC8522].

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 2 January 2022.

Jaufeerally              Expires 26 January 2022                [Page 1]
Internet-Draft    In-band BGP looking glass capability         July 2021

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Advertising support for the administrative message  . . . . .   3
   3.  Format of the administrative message  . . . . . . . . . . . .   3
   4.  Looking glass payload . . . . . . . . . . . . . . . . . . . .   3
   5.  Propoagation of looking glass information . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In this document we introduce a new Address Family Identifier (AFI)
   to carry an administrative message via the existing BGP update
   message that is defined in RFC 4271 [RFC4271]

   When a peer signals support for this AFI, we define a mechanism
   through which an administrative message contained within BGP UPDATE
   path attributes can be used to propagate inforamation such as but not
   limited to a looking glass URL.

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

Jaufeerally              Expires 26 January 2022                [Page 2]
Internet-Draft    In-band BGP looking glass capability         July 2021

2.  Advertising support for the administrative message

   Peers that support sending and receiving administrative messages via
   this mechanism MUST advertise support by sending a multiprotocol
   capability advertisment, as defined in RFC 4760 section 8 [RFC4760].
   The AFI used is that assigned by IANA (Note to editor: insert the
   actual value here once assigned).

   A peer SHOULD only send the messages defined in this document to a
   peer which has advertised support for the administrative message AFI.

3.  Format of the administrative message

   The administrative message is transmitted through a BGP UPDATE
   message containing a multiprotocol reach or multiprotocol unreach
   path attribute with the AFI set to the AFI for this document (Note to
   editor: insert value here after assignment from IANA).  The SAFI
   field SHOULD be set to 0 and MUST be ignored by the recipient, as it
   is unused in this specification, and is reserved for future use.

   The payload format is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            version            |              type             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       payload (variable)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                  Figure 1

   Figure 1 shows the layout of the administrative message which is to
   be contained within the multiprotocol reahable (MP_REACH) and
   multiprotocol unreachable (MP_UNREACH) path attributes.  Each
   submessage type will define its own semantics of when MP_REACH and /
   or MP_UNREACH is to be used.

4.  Looking glass payload

   The looking glass mechanism is disemminated using a administrative
   message with a type of 1.

   The looking glass mechanism supports advertising to a BGP peer an
   HTTP endpoint at which looking glass operations such as but not
   limited to: IP prefix lookups in the RIB of the peer, ping,
   traceroute, etc.  This endpoint, in version 1 of the looking glass
   protocol, MUST conform to the standard set out in RFC 8522 [RFC8522].

Jaufeerally              Expires 26 January 2022                [Page 3]
Internet-Draft    In-band BGP looking glass capability         July 2021

   The looking glass address can be specified in one of two ways: (1) on
   the BGP peer interface itself (i.e. the looking glass can be reached
   on the address of the BGP peer router itself), (2) on a URL specified
   within the message itself.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    version    |                      ASN                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |            URL (variable length)...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Looking glass message format

   Figure 2 shows the wire format of the administrative message.  The
   first byte is the looking glass administrative payload version number
   which MUST be set to 1.  This may be updated in future revisions to
   define new functionality, so software MUST ignore paylaods with
   unrecognized version numbers.  ASN MUST be set to the autonomous
   system number of the network that is operating the looking glass.
   That is to say, if an AS is announcing its own looking glass this
   should be the ASN which is announced in the BGP OPEN message.  On the
   other hand, if this is a looking glass address propagated from
   another peer, this MUST be the ASN of the network originating the
   looking glass message.  See Section 5 for details on how propagation
   is handled.

   The URL section is a variable length field which contains the ASCII
   encoded HTTP(s) endpoint of the looking glass.

5.  Propoagation of looking glass information

   While it is useful to have a looking glass to test the connectivity
   and route acceptance of a direct peer, it is oftentimes desirable to
   know if an "upstream" peer has accepted the route as well.  Consider
   the case of a tier-2 ISP which has several uplinks to tier-1 ISPs.
   In this case, the customer of a tier-2 ISP would benefit to know
   whether their routes have been accepted by the tier-1 upstream peers,
   which may have different filtering policies, and thus have a
   different set of accepted routes.

   In the base case to advertise the looking glass of the ASN that is
   running the BGP speaker, the speaker sets the ASN field to the ASN of
   the speaker itself.

Jaufeerally              Expires 26 January 2022                [Page 4]
Internet-Draft    In-band BGP looking glass capability         July 2021

   A BGP speaker SHOULD forward looking glass addresses of a peer P_a to
   a peer P_b when a route from P_b has been announced to P_a.  This
   MUST only be done if P_a has advertised the looking glass address to
   the BGP speaker making this decision, and the forwarded URL MUST be
   the one which P_a has advertised.

6.  Acknowledgements

   The authors would like to thank the members of the GROW WG for their
   feedback on this draft.  (Note to the editor: update this in future
   revisions of the draft).

7.  IANA Considerations

   We request IANA to allocate a new address family identifier for the
   administrative message, (Note to editor: fill in here after getting
   an assignment)

   We also require a registry of types that can be contained within the
   administrative message type.  This document allocates the first
   administrative message type of 1 to be used for the looking glass
   message.  (Note to editor: add more details here.)

8.  Security Considerations

   This draft proposes a mechanism for providing more easily automatable
   access to a looking glass interface operated by a network.  The scope
   of the dissemination of these looking glass adresses is to direct
   peers which are presumed to have an interest in querying the network
   reachability information, for example as part of debugging.

   Many network operators already provide looking glass services to the
   general public, however these are usually not standardized in their
   interfaces, and moreover, are not discoverable in an automated way
   which makes scalability difficult, and thus this draft
   programatically propagates that information.

   Operators MUST treat connections to the looking glass as untrusted.
   Operators SHOULD perform apppropriate rate-limiting and MAY deny
   abusive clients as per their own policy

   Operators may operate the looking glass with an IP access control
   list in cases where access is intended only for the peer, however
   this is discouraged as running a public facing looking glass brings
   the benefit that anyone can use it to debug network issues.

9.  References

Jaufeerally              Expires 26 January 2022                [Page 5]
Internet-Draft    In-band BGP looking glass capability         July 2021

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC8522]  Stubbig, M., "Looking Glass Command Set", RFC 8522,
              DOI 10.17487/RFC8522, February 2019,
              <https://www.rfc-editor.org/info/rfc8522>.

9.2.  Informative References

Author's Address

   Rayhaan Jaufeerally (editor)
   TBD
   CH- Zurich
   Switzerland

   Email: ietf@rayhaan.ch

Jaufeerally              Expires 26 January 2022                [Page 6]