IDR G. Van de Velde
Internet-Draft K. Patel
Intended status: Standards Track D. Rao
Expires: April 25, 2013 Cisco Systems
R. Raszuk
NTT MCL Inc.
R. Bush
Internet Initiative Japan
October 22, 2012
BGP Remote-Next-Hop
draft-vandevelde-idr-remote-next-hop-03
Abstract
The BGP Remote-Next-Hop is a new optional transitive attribute
intended to facilitate automatic tunneling across an AS on a per
address family basis. The attribute carries one or more tunnel end-
points for a NLRI. Additionally, tunnel encapsulation information is
communicated to successfully setup these tunnels.
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 April 25, 2013.
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
Van de Velde, et al. Expires April 25, 2013 [Page 1]
Internet-Draft BGP Remote-Next-Hop October 2012
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop
attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. BGP Remote-Next-Hop attribute TLV Format . . . . . . . . . . . 6
4.1. Encapsulation sub-TLV for Vxlan . . . . . . . . . . . . . 7
4.2. Encapsulation sub-TLV for NVGRE . . . . . . . . . . . . . 7
5. Use Case scenarios . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Multi-homing for IPv6 . . . . . . . . . . . . . . . . . . 8
5.2. Dynamic Network Overlay Infrastructure . . . . . . . . . . 8
5.3. The Tunnel end-point is NOT the originating BGP speaker . 8
5.4. Networks that do not support BGP Remote-Next-Hop
attribute . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Networks that do NOT support BGP Remote-Next-Hop
attribute . . . . . . . . . . . . . . . . . . . . . . . . 9
6. BGP Remote-Next-Hop Community . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Protecting the validity of the BGP Remote-Next-Hop
attribute . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Van de Velde, et al. Expires April 25, 2013 [Page 2]
Internet-Draft BGP Remote-Next-Hop October 2012
1. Introduction
[RFC5512] defines an attribute attached to an NLRI to signal tunnel
end-point encapsulation information between two BGP speakers. It
assumes that the exchanged tunnel endpoint is the NLRI.
This document defines a new BGP transitive attribute known as a
Remote-Next-Hop BGP attribute for Intra-AS and Inter-AS usage which
removes that assumption.
The tunnel endpoint information and the tunnel encapsulation
information is carried within a Remote-Next-Hop BGP attribute. This
attribute is tagged on an any BGP NLRI. This way the Address Family
(AF) of the NLRI exchanged is decoupled from the tunnel SAFI address-
family defined in [RFC5512].
Van de Velde, et al. Expires April 25, 2013 [Page 3]
Internet-Draft BGP Remote-Next-Hop October 2012
2. 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 any normative meaning.
Van de Velde, et al. Expires April 25, 2013 [Page 4]
Internet-Draft BGP Remote-Next-Hop October 2012
3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop attribute
The Tunnel Encapsulation attribute [RFC5512] is based on the
principle that the tunnel end-point is the BGP speaker originating
the update and is inserted as the NLRI in the exchange, with the
consequence that it is impossible to set the endpoint it to an
arbitrary IP address.
There are use cases where it is desired that the tunnel end-point
address should be a different address, or set of addresses, than the
originating BGP speaker. The BGP Remote-Next-Hop attribute provides
the ability to have one or more different tunnel end-point addresses
from either the IPv4 and/or the IPv6 address-families.
The sub-TLVs from the Tunnel Encapsulation Attribute [RFC5512] are
reused for the BGP Next-Hop-Attribute.
Due to the intrinsic nature of both attributes, the tunnel
encapsulation end-point assumes that the tunnel end-point is both the
NLRI exchanged and the originating router, while the BGP Remote-Next-
Hop attribute is inserted for an exchanged NLRI by adding a set of
tunnel end-points, these two attributes are mutually exclusive.
Van de Velde, et al. Expires April 25, 2013 [Page 5]
Internet-Draft BGP Remote-Next-Hop October 2012
4. BGP Remote-Next-Hop attribute TLV Format
This attribute is an optional transitive attribute [RFC1771].
The BGP Remote-Next-Hop attribute is is composed of a set of Type-
Length-Value (TLV) encodings. The type code of the attribute is
(IANA to assign). Each TLV contains information corresponding to a
particular tunnel technology and tunnel end-point Address. The TLV
is structured 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr len | Tunnel Address (IPv4 or IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Parameters |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tunnel Type (2 octets): identifies the type of tunneling technology
being signaled. This document defines the following types:
- L2TPv3 over IP [RFC3931]: Tunnel Type = 1
- GRE [RFC2784]: Tunnel Type = 2
- IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7
- VXLAN: Tunnel Type = TBD by IANA
- NVGRE: Tunnel Type = TBD by IANA
Unknown types MUST be ignored and skipped upon receipt.
Length (2 octets): the total number of octets of the value field.
Tunnel Address Length - Addr len (1 octet): Length of Tunnel
Address. Set to 4 bytes for an IPv4 address and 16 bytes for an
IPv6 address.
AS Number - The AS number originating the BGP Remote-Next-Hop
attribute and is either a 2-byte AS or 4-Byte AS number
Tunnel Parameter - (variable): comprised of multiple sub-TLVs. Each sub-TLV
consists of three fields: a 1-octet type, 1-octet length, and zero
or more octets of value. The sub-TLV definitions and the sub-TLV
Van de Velde, et al. Expires April 25, 2013 [Page 6]
Internet-Draft BGP Remote-Next-Hop October 2012
data are described in depth in [RFC5512].
4.1. Encapsulation sub-TLV for Vxlan
This document defines a new encapsulation sub-TLV format defined in
[RFC5512] for Vxlan tunnels. When the tunnel type is Vxlan, the
following is the structure of the value field in the encapsulation
sub-TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Address - The MAC address that is local to the device advertising the
route. This MAC address should be included as the destination MAC address
in the inner Ethernet Header immediately following the outer Vxlan header,
in the packets destined to the advertiser. Encapsulation sub-TLV for Vxlan
is optional in case of an L2VPN safi as the MAC address would be in the
NLRI portion of the safi.
4.2. Encapsulation sub-TLV for NVGRE
This document defines a new encapsulation sub-TLV format defined in
[RFC5512] for NVGRE tunnels. When the tunnel type is NVGRE, the
following is the structure of the value field in the encapsulation
sub-TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Address - The MAC address that is local to the device advertising the
route. This MAC address should be included as the destination MAC address
in the inner Ethernet Header immediately following the outer GRE header,
in the packets destined to the advertiser. Encapsulation sub-TLV for NVGRE
is optional in case of an L2VPN safi as the MAC address would be in the
NLRI portion of the safi.
Van de Velde, et al. Expires April 25, 2013 [Page 7]
Internet-Draft BGP Remote-Next-Hop October 2012
5. Use Case scenarios
This section provides a short overview of some use-cases for the BGP
Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not
limited to the examples in this section.
5.1. Multi-homing for IPv6
When an end-user IPv6 network is multi-homed to the Internet, it may
be assigned more than a single prefix originated by various upstream
ASs. Each AS prefers to only announce a supernet of all its assigned
IPv6 prefixes, unlike IPv4 where the AS announced the end-users
assigned prefix. The goal of this BGP policy behaviour is to keep
the number of entries in the IPv6 global BGP table to a minimum, it
also it also results in well known resiliency improvements.
For example, if an end-user IPv6 is peering with 2 different Service
providers AS1 and AS2. In this case the IPv6 end-user will have at
least one prefix assigned from each of these service providers. The
devices at the IPv6 end-user will each receive an address from these
prefixes. The devices will in most cases, when building IPv6
sessions (TCP, etc...), do so with only a single IPv6 address. The
decision which IPv6 address the device will use is documented in
[RFC3484].
If one if the links between the end-user and one of the neighboring
AS's breaks, a consequence will be that a set of sessions need to be
reset, or that a section of the end-user network becomes unreachable.
With usage of the BGP-remote-Next-Hop attribute the service provider
can tunnel that packet towards an alternate BGP Remote-Next-Hop at
the end-users alternate provider and restore the network connectivity
even though the local link towards the end-user is broken.
5.2. Dynamic Network Overlay Infrastructure
With the BGP Remote-Next-Hop feature it is possible to build and
dynamically create an overlay tunneled network with privacy, traffic
isolation, and virtual private networks.
5.3. The Tunnel end-point is NOT the originating BGP speaker
Note that, in each network environment, the originating router is the
preferred tunnel end-point server. It may be that the network
administrator has deployed an independent set of tunnel end-point
servers across their network, which may or may not speak BGP. The
BGP Remote-Next-Hop attribute provides the ability to signal this via
BGP.
Van de Velde, et al. Expires April 25, 2013 [Page 8]
Internet-Draft BGP Remote-Next-Hop October 2012
5.4. Networks that do not support BGP Remote-Next-Hop attribute
If a device does not support this attribute, and receives this
attribute, then normal NLRI BGP forwarding is used as the attribute
is optional and transitive.
5.5. Networks that do NOT support BGP Remote-Next-Hop attribute
If a BGP speaker does understand this attribute, and receives this
attribute, then the BGP speaker MAY, by configuration, skip use or
not use the information within this attribute.
Van de Velde, et al. Expires April 25, 2013 [Page 9]
Internet-Draft BGP Remote-Next-Hop October 2012
6. BGP Remote-Next-Hop Community
place-holder for an BGP extension to signal valid prefixes allowed to
be considered as tunnel end-points. To be completed.
Van de Velde, et al. Expires April 25, 2013 [Page 10]
Internet-Draft BGP Remote-Next-Hop October 2012
7. IANA Considerations
This memo asks the IANA for a new BGP attribute assignment. This
memo asks the IANA to assign a new Tunnel Type for VXLAN and NVGRE
encapsulation.
Van de Velde, et al. Expires April 25, 2013 [Page 11]
Internet-Draft BGP Remote-Next-Hop October 2012
8. 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.
The distribution of Tunnel end-point address information can result
in potential DoS attacks if the information is sent by malicious
organisations. Therefore is it strongly recommended to install
traffic filters, IDSs and IPSs at the perimeter of the tunneled
network infrastructure.
8.1. Protecting the validity of the BGP Remote-Next-Hop attribute
It is possible to inject a rogue BGP Remote-Next-Hop attribute to an
NLRI resulting in Monkey-In-The-Middle attack (MITM). To avoid this
type of MITM attack, it is strongly recommended to use a technology a
mechanism to verify that for NLRI it is the expected BGP Remote-Next-
Hop. We anticipate that this can be done with an expansion of RPKI-
Based origin validation, see [I-D.ietf-sidr-pfx-validate].
This does not avoid the fact that rogue AS numbers may be inserted or
injected into the AS-Path. To achieve protection against that threat
BGP Path Validation should be used, see
[I-D.ietf-sidr-bgpsec-overview].
Van de Velde, et al. Expires April 25, 2013 [Page 12]
Internet-Draft BGP Remote-Next-Hop October 2012
9. Privacy Considerations
This proposal may introduce privacy issues, however with BGP security
mechanisms in place they should be prevented.
Van de Velde, et al. Expires April 25, 2013 [Page 13]
Internet-Draft BGP Remote-Next-Hop October 2012
10. Change Log
Initial Version: 16 May 2012
Hacked for -01: 17 July 2012
Van de Velde, et al. Expires April 25, 2013 [Page 14]
Internet-Draft BGP Remote-Next-Hop October 2012
11. References
11.1. Normative References
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009.
11.2. Informative References
[I-D.ietf-sidr-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPSEC",
draft-ietf-sidr-bgpsec-overview-02 (work in progress),
May 2012.
[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-10 (work in progress),
October 2012.
Van de Velde, et al. Expires April 25, 2013 [Page 15]
Internet-Draft BGP Remote-Next-Hop October 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:
Email: keyupate@cisco.com
Dhananjaya Rao
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95124 95134
USA
Phone:
Email: dhrao@cisco.com
Robert Raszuk
NTT MCL Inc.
101 S Ellsworth Avenue Suite 350
San Mateo, CA 94401
US
Phone:
Email: robert@raszuk.net
Van de Velde, et al. Expires April 25, 2013 [Page 16]
Internet-Draft BGP Remote-Next-Hop October 2012
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Email: randy@psg.com
Van de Velde, et al. Expires April 25, 2013 [Page 17]