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

Versions: 00 01 02 03 04 05 06 07 08 09 draft-ietf-idr-tunnel-encaps

Operational Security                                     G. Van de Velde
Internet-Draft                                                  K. Patel
Updates: 792, 4443 (if approved)                           Cisco Systems
Intended status: Standards Track                            May 24, 2012
Expires: November 25, 2012


                          BGP Remote-Next-Hop
                draft-vandevelde-idr-remote-next-hop-00

Abstract

   The BGP Remote-Next-Hop optional transitive attribute, provides an
   additional level of recursive route-lookup.  The BGP Remote-Next-Hop
   attribute can be used, both on the public Internet infrastructure and
   within public or private Autonomous Systems (AS).  The usage of BGP
   Remote-Next-Hop operates as ships-in-the-night and does not require
   any capability exchange for any BGP Session.  BGP Remote-Next-Hop is
   providing the distribution of one or more Location Identifiers
   assigned to a particular BGP prefix or an NLRI.  To secure the BGP
   prefix or NLRI entry BGP security mechanisms, either RPKI or other
   BGP mechanisms can be utilized.

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 November 25, 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



Van de Velde & Patel    Expires November 25, 2012               [Page 1]


Internet-Draft             BGP Remote-Next-Hop                  May 2012


   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
     1.2.  Option Format: BGP Remote-Next-Hop  . . . . . . . . . . . . 3
       1.2.1.  BGP Option Type . . . . . . . . . . . . . . . . . . . . 3
       1.2.2.  Option Format . . . . . . . . . . . . . . . . . . . . . 4
       1.2.3.  Remote-Next-Hop Attribute Format  . . . . . . . . . . . 4
     1.3.  Usage Guidelines  . . . . . . . . . . . . . . . . . . . . . 5
       1.3.1.  Networks that do NOT support BGP Next-Hop-Attribute . . 5
       1.3.2.  Multi-homing for IPv6 . . . . . . . . . . . . . . . . . 5
       1.3.3.  Mapping Technology to compliment LISP . . . . . . . . . 6
       1.3.4.  Network Overlay Infrastructure  . . . . . . . . . . . . 6
       1.3.5.  Reduction of the Routing Forwarding Information
               Base  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
     3.1.  Privacy Considerations  . . . . . . . . . . . . . . . . . . 7
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



















Van de Velde & Patel    Expires November 25, 2012               [Page 2]


Internet-Draft             BGP Remote-Next-Hop                  May 2012


1.  Introduction

   Each IP address (v4 or v6) represents a location and an identity.
   This is captured and developed by Locator Identity Split Protocol
   (LISP) and additionally documented by rfc6227 (Design Goals for
   Scalable Internet Routing) to scale the Internet.

   The optional transitive BGP Remote-Next-Hop attribute provides a
   mapping to complement and support mapping technologies (i.e.  LISP)
   by using using BGP to distribute either a single or a set of locators
   attached to each entry in the BGP table.  Based upon this locater
   information (the BGP Remote-Next-Hop) an overlay tunnel can be
   utilized and created.  This overlay tunnel could be any type of IPv4-
   in-IPv4, IPv6-in-IPv4, IPv4-in-IPv6 or IPv6-in-IPv6,

   If a recipient node has no awareness or does not understand the BGP
   Remote-Next-Hop attribute then traditional BGP routing can be used as
   fallback mechanism.  If the recipient node does understand the BGP
   Remote-Next-Hop attribute, then an overlay tunnel could be created
   i.e a LISP or IPoGRE tunnel.

   In addition, existing BGP security mechanisms can be used to verify
   the correctness of the BGP update including the validity of the BGP
   Remote-Next-Hop attribute.  This will make sure that recipients of
   the BGP NLRI update which understand BGP Remote-Next-Hop, are not by
   accident tunneling to a malicious intermediate hop instead of the
   rightful BGP end-point.

   This note is defining the attribute for usage on Inter-AS and
   Intra-AS environments.

   Note that the Address Family (AF) of the NLRI exchanged is intended
   to be independent of the Address Family of the BGP Remote-Next-Hop
   attribute; hence the BGP Remote-Next-Hop attribute can be used within
   and between AF environments.

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

1.2.  Option Format: BGP Remote-Next-Hop

1.2.1.  BGP Option Type

   Optional Transitive




Van de Velde & Patel    Expires November 25, 2012               [Page 3]


Internet-Draft             BGP Remote-Next-Hop                  May 2012


1.2.2.  Option Format

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |  Attr. Flags  |Attr. Type Code|
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  | BGP Remote-Next-Hop Attribute |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Bit 0: Set to 1 (Optional Attribute);

   Bit 1: Set to 1 (Transitional Attribute);

   Bit 2: Partial bit of the attribute;

   Depending on the size and entries within the BGP Remote-Next-Hop the
   attribute may be complete (set to 0) or partial (set to 1);

   Bit 3: Extended Length bit;

   Set to 0 if non-extended;

   Set to 1 if Extended length;

   Bit 4 to 7 Set to 0;

   Bit 8 to 15: Set to BGP Remote-Next-Hop attribute.  Value to be
   defined by IANA;

1.2.3.  Remote-Next-Hop Attribute Format

   The general format of this attribute describes the structure of the
   BGP Remote-Next-Hop attribute.  Each attribute address family MUST be
   carried in a different Remote-Next-Hop container.  (For example IPv4
   and IPv6 will each need their own container)

   Each attribute can cary multiple BGP Remote-Next-Hop addresses.


       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Family        |             Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                    BGP Remote-Next-Hop                        |



Van de Velde & Patel    Expires November 25, 2012               [Page 4]


Internet-Draft             BGP Remote-Next-Hop                  May 2012


       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The coding mentioned here is Hexadecimals.

   If Address Family is set to 0 then it are IPv4 addresses.

   If Address Family is set to 1 then it are IPv6 addresses.

   Other values are reserved for the future purposes.

   The length field is encoded in number of Octets.

   BGP Remote-Next-Hop: the BGP Remote-Next-Hop addresses.

1.3.  Usage Guidelines

   This section provides a short overview of some use-case scenarios for
   the BGP Remote-Next-Hop attribute.  The usage of the BGP Remote-Next-
   Hop attribute is not limited to the examples discussed in this
   section.

1.3.1.  Networks that do NOT support BGP Next-Hop-Attribute

   If a device does not support this attribute, then due to the Optional
   Transitive BGP character of this attribute will result that
   traditional routing is utilized with all the benefits and drawbacks.

1.3.2.  Multi-homing for IPv6

   When an IPv6 network is multi-homed towards the Internet, then it may
   be assigned with more than a single prefix.  While the aspiration for
   these different assignments is to reduce the size of the Global
   Internet Routing table, it also results in well known resiliency
   issues discussed in a few IETF Working groups (if attribute idea gets
   accepted by WG, references will be added).

   The BGP Remote-Next-Hop attribute is providing a technology to glue
   these assigned IPv6 prefixes together and avoid some of the well
   known resiliency issues.

   So, how does this concept work?

   Assume you have a Node (=Source-Node) on Network (=Source-Network)
   and you would like to send something to your peer (Destination-Node)
   which is a device in Network (Destination-Network).  With traditional
   routing a destination lookup is done, and forwarded each hop between



Van de Velde & Patel    Expires November 25, 2012               [Page 5]


Internet-Draft             BGP Remote-Next-Hop                  May 2012


   Source-Node and Destination-node.

   What the attribute BGP Remote-Next-Hop provides is that when the
   Source-Node sends a packet to the Destination-Node it can be
   specially handled by the Source-Network edge-router.  This device
   will look at the destination address of the packet, and check the BGP
   Remote-Next-Hop attribute (assuming that the edge-node supports that
   idea).  That lookup will allow a device understanding the attribute,
   to select or create a tunnel towards the destination.

   Using this will result in having organizations built Internet
   overlays.

1.3.3.  Mapping Technology to compliment LISP

   LISP, the Locator ID Split protocol, makes usage of a mapping
   technology to build up the tunnels to accommodate LISP.  What this
   BGP Remote-Next-Hop attribute is providing is that it provides a
   mechanism to distribute tunnel end-points using existing BGP
   infrastructure without the need of anybody requiring to enable it.
   As result it will be ship in the night from both BGP as LISP
   perspective.

1.3.4.  Network Overlay Infrastructure

   With the BGP Remote-Next-Hop feature it is possible to build and
   create an overlay tunneled network.  By using this attribute, it is
   possible to have individual (Internet) Networks create sessions
   between them and make sure that the Internet and serviceability
   elements are kept correctly.

1.3.5.  Reduction of the Routing Forwarding Information Base

   Right now there are about 50.000 Autonomous Systems distributed,
   which is way less as the useful entries in the existing FIB.  The
   usage of double recursive reduction has as result that even if the
   routing table stays equal size, that the FIB (Traditionally ASIC
   Based Forwarding Table) when everybody is using this technology is
   reduced. ( We would go from 400K entries to 50k entries in the FIB).


2.  IANA Considerations

   This memo asks the IANA for a new BGP Attribute assignment.







Van de Velde & Patel    Expires November 25, 2012               [Page 6]


Internet-Draft             BGP Remote-Next-Hop                  May 2012


3.  Security Considerations

   This technology could be used as technology as man in the middle
   attack, however with existing RPKI validation for BGP that risk is
   reduced.

   Additional risks are still to be analysed by the working group and
   feedbacck received on the draft

3.1.  Privacy Considerations

   This proposal could introduce privacy issues, however with BGP
   security mechanisms in place they are removed.


4.  Acknowledgements

   To be completed


5.  Change Log

   Initial Version:  16 May 2012


6.  References

6.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

6.2.  Informative References

   [RFC6227]  Li, T., "Design Goals for Scalable Internet Routing",
              RFC 6227, May 2011.






Van de Velde & Patel    Expires November 25, 2012               [Page 7]


Internet-Draft             BGP Remote-Next-Hop                  May 2012


Authors' Addresses

   Gunter Van de Velde
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Phone: +32 2704 5473
   Email: gvandeve@cisco.com


   Keyur Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95124  95134
   USA

   Phone: +32 2704 5473
   Email: keyupate@cisco.com































Van de Velde & Patel    Expires November 25, 2012               [Page 8]


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