Internet DRAFT - draft-leymann-banana-signaling
draft-leymann-banana-signaling
BANANA N. Leymann
Internet Draft C. Heidemann
Intended Category: Proposed Standard Deutsche Telekom AG
M. Zhang
B. Sarikaya
Huawei
M. Cullen
Painless Security
Expires: June 29, 2018 December 26, 2017
BANdwidth Aggregation for interNet Access (BANANA)
The Control Protocol of Bonding Tunnels
draft-leymann-banana-signaling-02.txt
Abstract
There is an emerging demand for solutions to bond multiple access
links to provide subscribers with redundancy and load-sharing across
these access links. BANdwidth Aggregation for interNet Access
(BANANA) will specify such solutions.
In this document, a control protocol is specified to deliver
configuration and control information between two peering BANANA
boxes.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Leymann, et al. Expires June 29, 2018 [Page 1]
INTERNET-DRAFT BANANA Signaling December 26, 2017
Copyright and License Notice
Copyright (c) 2017 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3
3. The Single Operator Scenario . . . . . . . . . . . . . . . . . 5
4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Control Protocol Specification . . . . . . . . . . . . . . . . 7
5.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 7
5.2. Establishment of Bonding Tunnels . . . . . . . . . . . . . 10
6. The Edge to Edge Scenario . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Service Providers used to provide subscribers with separate access to
their multiple networks. It has become desirable to bond access
links to these networks together to offer access service to
subscribers. When the traffic volume exceeds the bandwidth of the
first connection, the excess amount can be offloaded to a secondary
connection. So bonding service is able to provide subscribers with
increased access capacity and improved reliability.
This memo will mainly work two scenarios out: the single operator
scenario and the edge to edge scenario. There would be mainly
implementation issues to make BANANA be applicable to more scenarios.
For the single-operator scenario, the local BANANA box is a Customer
Leymann, et al. Expires June 29, 2018 [Page 2]
INTERNET-DRAFT BANANA Signaling December 26, 2017
Premises Equipment (CPE) device initiating the two connections. The
remote BANANA box resides in the provider's networks to terminate
these bonded connections. For the edge to edge scenario, the two
peering BANANA boxes are two CPE devices which might be operated by
different providers.
This document specifies the control protocol between the two BANANA
boxes. This control protocol adopts GRE (Generic Routing
Encapsulation [RFC2890]) since GRE is widely supported in various
networks. Approaches specified in this document might also be used
by other tunneling technologies to achieve tunnel bonding. However,
such variants are out of scope for this document.
For each heterogeneous connection between the two BANANA boxes, one
GRE tunnel is set up. The local and remote BANANA box, respectively,
serve as the common termination point of the tunnels at both ends.
Those GRE tunnels are bonded together to form a logical IP link for
the subscriber. This provides an overlay: the users' IP packets
(inner IP) are encapsulated in GRE, which is in turn carried over IP
(outer IP).
A tunnel bonding solution of BANANA may support more than two tunnels
between the two BANANA boxes though the reference topologies in this
memo choose to use two tunnels between the two BANANA boxes to depict
such a solution.
2. Acronyms and Terminology
GRE: Generic Routing Encapsulation [RFC2890].
BRAS: Broadband Remote Access Server. Routes traffic to and from
broadband remote access devices such as Digital Subscriber Line
Access Multiplexers (DSLAMs) on an Internet Service Provider's
(ISP's) network.
PGW: Packet Data Network Gateway. In the Long Term Evolution (LTE)
architecture for the Evolved Packet Core (EPC), acts as an anchor
for user-plane mobility.
PDP: Packet Data Protocol. A packet transfer protocol used in
wireless GPRS (General Packet Radio Service) / HSDPA (High-Speed
Downlink Packet Access) networks.
PPPoE: Point-to-Point over Ethernet. A network protocol for
encapsulating PPP frames inside Ethernet frames.
DNS: Domain Name System. A hierarchical distributed naming system
for computers, services, or any resource connected to the Internet
Leymann, et al. Expires June 29, 2018 [Page 3]
INTERNET-DRAFT BANANA Signaling December 26, 2017
or a private network.
DHCP: Dynamic Host Configuration Protocol. A standardized network
protocol used on Internet Protocol (IP) networks for dynamically
distributing network configuration parameters, such as IP
addresses for interfaces and services.
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].
Leymann, et al. Expires June 29, 2018 [Page 4]
INTERNET-DRAFT BANANA Signaling December 26, 2017
3. The Single Operator Scenario
DNS server
branch router
+--------------+ +-----------+
+--+ | | | | ,,, ,,,,,,
| | | +-+ | | DHCP | , ,, ,
|A6|------------| | | |+-+ IP pool| , ,
| | | | | S--Tunnel 2--| | | ,, ,,
| | | +-+ |C| | ||R| ---------I ,
| | | |N| | | F--Tunnel 1--| | | ,, ,,
|A4|---A1---|A|-| | | |+-+ | ,,,,,,,,,,,
| | | |T| +-+ | | | Internet
+--+ |DHCP +-+ | | |
Host |IP pool | | |
+--------------+ +-----------+
local remote
BANANA box BANANA box
A6: The endpoint for the IPv6 address that is used for the BANANA
service by the Host.
A4: The endpoint for the IPv4 address that is used for the BANANA
service by the Host.
C: The service endpoint of the bonding service at the local
BANANA box. IP address or IP prefix of C is assigned by the
DHCP from a pool of IP addresses maintained on the remote
BANANA box.
A1: The endpoint of the Gateway on the same Local Area Network
(LAN) as the Host. The pre-configured IP address of A1 will
be translated to the IP address of C by the Network Address
Translator (NAT).
F: The local endpoint of the first tunnel (Tunnel 1) at the local
BANANA box.
S: The local endpoint of the secondary tunnel (Tunnel 2) at the
local BANANA box.
R: The common remote endpoint for Tunnel 1 and Tunnel 2 at the
remote BANANA box. The DNS server will resolve an URL
provisioned by the Service Provider to be the IP address of
R.
I: The endpoint of the destination in the Internet.
Figure 3.1: Tunnel bonding for a single operator
If a Service Provider runs multiple networks, subscribers are eager
to use those networks simultaneously for increased access capacity
rather than just using a single network. As shown by the reference
topology in Figure 3.1, the subscriber expects a significantly higher
Leymann, et al. Expires June 29, 2018 [Page 5]
INTERNET-DRAFT BANANA Signaling December 26, 2017
access bandwidth from the bonding connection than from just the first
connection. In other words, when the traffic volume exceeds the
bandwidth of the first connection, the excess amount may be offloaded
to the secondary connection.
One tunnel is established per-connection between the two BANANA boxes
(see Figure 3.1). These tunnels are bonded together as if there is a
single IP link provided between the two boxes for the subscriber who
buys the local BANANA box.
Compared to per-flow load balancing mechanisms which are widely used
nowadays, BANANA MUST support per-packet offloading approach. For
per-flow load-balancing, the maximum bandwidth that may be used by a
traffic flow is the bandwidth of an individual connection. While for
per-packet offloading, a single flow may use the added-up bandwidth
of all the connections.
Although this memo depicts the tunnel bonding solution using
reference topologies (see also Section 6) with two GRE tunnels
between the two BANANA boxes, a tunnel bonding solution can support
more than two tunnels between the two BANANA boxes.
4. Addressing
When the Host boots up, IP addresses of A4 and/or A6 will be assigned
by the DHCP from a pool of IP addresses maintained on the local
BANANA box. The Gateway IP addresses of A1 is locally configured and
will be translated into the IP address of C which is assigned by the
DHCP from a pool of IP addresses maintained on the remote BANANA box.
IPv6 address of A6 has the same prefix as C so that NAT function is
unnecessary. The DHCP message that carries the IP address of C will
be encapsulated as a GRE data packet ([BANANA-encap]) after Tunnel 1
is established.
When the local BANANA box boots up, IP addresses of F and S will be
automatically assigned by network devices connected to the local
BANANA box. As examples, if this network device is a Broadband
Remote Access Server (BRAS), the local BANANA box gets an IP address
through the Point-to-Point Protocol over Ethernet (PPPoE). If this
network device is a Packet Data Network Gateway (PGW), the local
BANANA box gets an IP address through the Packet Data Protocol (PDP).
In order to support automatic establishment of GRE tunnels, the IP
address of F or S needs to be carried by the control protocol from
the local BANANA box to the remote BANANA box.
The domain name of a remote BANANA box may be configured or obtained
via the Wide Area Network (WAN) interface of the first or secondary
connection based on gateway configuration protocols such as [TR-069].
Leymann, et al. Expires June 29, 2018 [Page 6]
INTERNET-DRAFT BANANA Signaling December 26, 2017
The resolution of the remote BANANA box's domain name is requested
via the WAN interface of the first or secondary connection. The
Domain Name System (DNS) server will reply with the IP address of R
which is assigned by DHCP from a pool of IP addresses maintained on
the remote BANANA box.
A Service Provider might deploy multiple remote BANANA boxes in one
site and place a branch router in front of these remote BANANA boxes.
The DNS server will resolve the URL to a pre-configured IP address
of this branch router instead of the IP address of R. In this way,
the tunnel setup request from the local box will reach this branch
router instead of R. This branch router will adopt anycast mechanism
to achieve load balancing and direct the tunnel setup request to one
of the remote BANANA boxes. For this case, the IP address of R needs
to be carried by the control protocol from the remote BANANA box to
the local BANANA box for the purpose of automatic establishment of
GRE tunnels.
5. Control Protocol Specification
The control protocol of BANANA is designed to exchange configuration
and control information between the two BANANA boxes, such as IP
prefixes of local links (see Section 4), the link properties and
status and the information needed by the encapsulations.
5.1. Message Formats
Messages of the control protocol are delivered as GRE encapsulated
packets and routed via the same GRE tunnels as GRE data packets. All
control messages are sent in network byte order (high-order bytes
first). The GRE Protocol Type field is used to distinguish control
packets from GRE data packets. The new GRE Protocol Type (0xB7EA) is
allocated for this purpose. GRE packets with a Protocol Type that
equals to this number will be consumed by the receiving BANANA box
rather than forward further.
The standard GRE header as per [RFC2890] with Checksum Present bit
and Sequence Number Present bit set to zero and Key Present bit set
to one is used in this memo. This means the Checksum, the Sequence
Number and the Reserved1 fields are not present. So, the format of
the GRE header for control messages of is as follows:
Leymann, et al. Expires June 29, 2018 [Page 7]
INTERNET-DRAFT BANANA Signaling December 26, 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| |1|0| Reserved0 | Ver | Protocol Type 0xB7EA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The remote BANANA box generates a random number to be carried as the
Key field of each control message by the local BANANA box. Except
the first GRE Tunnel Setup Request message, the Key field of all
control messages originated by the local BANANA box MUST be set to
this random number. The remote BANANA box uses the value of the Key
to authenticate the local BANANA box.
The general format of the entire control message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| |1|0| Reserved0 | Ver | Protocol Type 0xB7EA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MsgType|T-Type | |
+-+-+-+-+-+-+-+-+ Attributes +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1: Format of Control Messages of GRE Tunnel Bonding
o MsgType (4 bits)
Message Type. The control message family contains the following
six types of control messages (not including "Reserved"):
Control Message Family Type
========================== =========
GRE Tunnel Setup Request 1
GRE Tunnel Setup Accept 2
GRE Tunnel Setup Deny 3
GRE Tunnel Hello 4
GRE Tunnel Tear Down 5
GRE Tunnel Notify 6
Reserved 0, 7-15
- GRE Tunnel Setup Request
The local BANANA box uses the GRE Tunnel Setup Request message to
request that the remote BANANA box establishes the GRE tunnels.
Leymann, et al. Expires June 29, 2018 [Page 8]
INTERNET-DRAFT BANANA Signaling December 26, 2017
It is sent out from the local BANANA box's F and S interfaces
(see Figure 3.1).
- GRE Tunnel Setup Accept
The remote BANANA box uses the GRE Tunnel Setup Accept message as
the response to the GRE Tunnel Setup Request message. This
message indicates the acceptance of the tunnel establishment and
carries parameters of the GRE tunnels.
- GRE Tunnel Setup Deny
The remote BANANA MUST send the GRE Tunnel Setup Deny message to
the local BANANA box if the GRE Tunnel Setup Request from this
local BANANA box is denied. The local BANANA box MUST terminate
the GRE tunnel setup process as soon as it receives the GRE
Tunnel Setup Deny message.
- GRE Tunnel Hello
After the first or the second GRE tunnel is established (see
Figure 3.1), the local BANANA box begins to periodically send out
GRE Tunnel Hello messages via the tunnel; the remote BANANA box
acknowledges the local BANANA box's messages by returning GRE
Tunnel Hello messages received from the local BANANA box. This
continues until the tunnel is terminated.
- GRE Tunnel Tear Down
The remote BANANA box can terminate a GRE tunnel by sending the
GRE Tunnel Tear Down message to the local BANANA box via the
tunnel. After receiving the GRE Tunnel Tear Down message, the
local BANANA removes the IP address of R (see Figure 3.1).
- GRE Tunnel Notify
The two BANANA boxes use the GRE Tunnel Notify message, which is
transmitted through either the first or the second GRE tunnel, to
notify each other about their status regarding the two GRE
tunnels, the information for the bonding tunnels, the actions
that need to be taken, etc.
Normally, the receiver just sends the received attributes back as
the acknowledgement for each GRE Tunnel Notify message. If the
size of the attribute is too large, an acknowledgement attribute
for it need to be defined.
o T-Type (4 bits)
Tunnel Type. Set to 0001 if the control message is sent via the
first GRE tunnel. Set to 0010 if the control message is sent via
the secondary GRE tunnel. Values 0000 and values from 0011 through
1111 are reserved for future use and MUST be ignored on receipt.
Leymann, et al. Expires June 29, 2018 [Page 9]
INTERNET-DRAFT BANANA Signaling December 26, 2017
o Attributes
The Attributes field includes the attributes that need to be
carried in the control message. Each Attribute has the following
format:
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value ~ (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Attribute Type
The Attribute Type specifies the type of the attribute.
- Attribute Length
Attribute Length indicates the length of the Attribute Value in
bytes.
- Attribute Value
The Attribute Value includes the value of the attribute.
Specific attributes will be defined in [BANANA-attributes].
5.2. Establishment of Bonding Tunnels
One major goal of BANANA signaling is to enable the automatic set up
of GRE tunnels which used to be set up manually. After the IP
addresses of tunnel endpoints have been acquired, the local BANANA
box starts the following procedure to set up the bonding tunnels.
The local BANANA box will firstly set up the secondary GRE tunnel
(Tunnel 2 in Figure 3.1) and then the first GRE tunnel (Tunnel 1 in
Figure 3.1). If the secondary GRE tunnel cannot be established
successfully, the local BANANA box will not set up the first GRE
tunnel since it's more economical to transmit traffic over a raw link
than over a GRE tunnel.
The local BANANA box sends the GRE Tunnel Setup Request message to
the remote BANANA box via the endpoint S. The outer source IP
address for this message is the IP address of S, while the outer
destination IP address is the IP address of the branch router (if
anycast is not used, the outer destination IP address would be IP
address of R). The remote BANANA box with the highest priority
(e.g., the one that the local BANANA box has the least-cost path to
reach) in the group of remote BANANA boxes, which receives the GRE
Tunnel Setup Request message, will initiate the procedure for
Leymann, et al. Expires June 29, 2018 [Page 10]
INTERNET-DRAFT BANANA Signaling December 26, 2017
authentication and authorization to check whether the local BANANA
box is trusted by the network device attached to S.
If the authentication and authorization succeed, the remote BANANA
box sets the IP address of S, which is obtained from the GRE Tunnel
Setup Request message (i.e., its outer source IP address), as the
destination endpoint IP address of the secondary GRE tunnel and
replies to the endpoint of the local BANANA box's secondary GRE
tunnel with the GRE Tunnel Setup Accept message in which an IP
address of R (e.g., an IP address of a Line Card in the remote BANANA
box) and a Session ID randomly generated by the remote BANANA box are
carried as attributes. The outer source IP address for this message
is the IP address of R or the IP address of the branch router, while
the outer destination IP address is the IP address of S. Otherwise,
the remote BANANA box MUST send to the Local BANANA box's endpoint of
the secondary GRE tunnel the GRE Tunnel Setup Deny message, and the
local BANANA box MUST terminate the tunnel setup process once it
receives the GRE Tunnel Setup Deny message.
After the secondary GRE tunnel is successfully set up, the local
BANANA box will obtain the C address (see Figure 3.1) over the tunnel
from the remote BANANA box through the Dynamic Host Configuration
Protocol (DHCP). After that, the local BANANA box starts to set up
the first GRE tunnel. It sends a GRE Tunnel Setup Request message
via F, carrying the aforementioned Session ID received from the
remote BANANA box. The outer source IP address for this message is
the IP address of F, while the outer destination IP address is the IP
address of R. The remote BANANA box, which receives the GRE Tunnel
Setup Request message, will initiate the procedure for authentication
and authorization in order to check whether the local BANANA box is
trusted by the network device attached to F.
If the authentication and authorization succeed, the remote BANANA
sets the IP address of F, which is obtained from the GRE Tunnel Setup
Request message (i.e., its outer source IP address), as the
destination endpoint IP address of the GRE tunnel and replies to the
endpoint F with the GRE Tunnel Setup Accept message. The outer
source IP address for this message is the IP address of R, while the
outer destination IP address is the IP address of F. In this way,
the two tunnels with the same Session ID can be used to carry traffic
from the same user. That is to say, the two tunnels are "bonded"
together. Otherwise, if the authentication and authorization fail,
the remote BANANA box MUST send the GRE Tunnel Setup Deny message to
the tunnel endpoint F. Meanwhile, it MUST send the GRE Tunnel Tear
Down message to the tunnel endpoint S. The local BANANA box MUST
terminate the tunnel setup process once it receives the GRE Tunnel
Setup Deny message and MUST tear down the secondary GRE tunnel that
has already been set up once it receives the GRE Tunnel Tear Down
Leymann, et al. Expires June 29, 2018 [Page 11]
INTERNET-DRAFT BANANA Signaling December 26, 2017
message.
6. The Edge to Edge Scenario
DNS server DNS server
+--------------+ +--------------+
+--+ | | | | +--+
| | | +-+ | | +-+ | | |
|A6|------------| | | | | |-------------|B6|
| | | | |Sl--Tunnel 2--Sr| | | | |
| | | +-+ |C| | | |D| +-+ | | |
| | | |N| | |Fl--Tunnel 1--Fr| | |N| | | |
|A4|---A1---|A|-| | | | | |-|A|--B1-----|B4|
| | | |T| +-+ | | +-+ |T| | | |
+--+ |DHCP +-+ | | +-+ DHCP| +--+
Host |IP pool | | IP pool| Host
+--------------+ +--------------+
local remote
BANANA box BANANA box
Figure 6.1: Tunnel bonding for the edge to edge scenario
The applicability of bonding tunnels is not limited to the single
operator scenario. This section explains how bonding tunnels are
adapted to the edge to edge scenario. By and large, the adaptations
are implementation issues.
o Addressing
IP addresses of B4, B6, B1, Fr and Sr are obtained in the same way as
A4, A6, A1, Fl and Sl respectively, as in the single operator
scenario.
C and D are the service endpoints of the bonding service at the two
BANANA box respectively. IP addresses of C and D will be assigned
from the locally configured IP pool via DHCP rather than be assigned
remotely from the peering BANANA box.
Domain names of the two BANANA boxes may be configured or obtained
via [TR-069]. A query of the domain names will be resolved to the IP
address of C or D by the DNS server .
o Establishment of Bonding Tunnels
The local BANANA box will send the GRE Tunnel Setup message to the
remote BANANA box using IP address of D as the outer destination IP
address and using IP address of Sl as the outer source IP address.
Leymann, et al. Expires June 29, 2018 [Page 12]
INTERNET-DRAFT BANANA Signaling December 26, 2017
When the remote BANANA box replies the local BANANA box with the GRE
Tunnel Accept message, the outer source IP address for this message
is set to the IP address of Sr or D, while the outer destination IP
address is the IP address of Sl. In the GRE Tunnel Accept message,
the IP address of Sr, the IP address of Fr and a Session ID randomly
generated by the remote BANANA box will be carried as attributes.
Tunnel 2 would be set up between Sl and Sr.
For Tunnel 1, the local BANANA box will use the IP address of Fr as
the outer destination IP address and IP address of Fl as the outer
source IP address to send the GRE Tunnel Setup message to the remote
BANANA box. In this message, the Session ID received from the remote
BANANA box will be carried as an attribute. The remote BANANA box
will reply the local BANANA box with a GRE Tunnel Setup Accept
message. The outer source IP address for this message is the IP
address of Fr while the outer destination IP address for this message
is the IP address of Fl. Tunnel 1 would be set up between Fl and Fr.
Since Tunnel 1 and Tunnel 2 use the same Session ID, they would be
bonded together to carry traffic from the same user.
For the edge to edge scenario, a BANANA box can either be "local" or
"remote". The IP addresses of the service endpoint is used to break
the tie. The BANANA box with the smaller IP address will be regarded
as "local" while the BANANA box with the larger IP address will be
regarded as "remote".
7. Security Considerations
Malicious devices controlled by attackers may intercept the control
messages sent on the GRE tunnels. Later on, the rogue devices may
fake control messages to disrupt the GRE tunnels or attract traffic
from the target local BANANA box.
As a security feature, the Key field of the GRE header of the control
messages is generated as a 32-bit cleartext password, except for the
first GRE Setup Request message per bonding connection sent from the
local BANANA box to the remote BANANA box, whose Key field is filled
with all zeros. The remote BANANA box and the local BANANA validate
the Key value and the outer source IP address, and they discard any
packets with invalid combinations.
8. IANA Considerations
IANA need not assign anything for this memo. The GRE Protocol Type,
the Ethertype for the GRE Channel of the BANANA signaling, is set to
0xB7EA, which is under the control of the IEEE Registration
Authority. However, IANA has updated the "IEEE 802 Numbers" IANA web
page [802Type], which is of primarily historic interest.
Leymann, et al. Expires June 29, 2018 [Page 13]
INTERNET-DRAFT BANANA Signaling December 26, 2017
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>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>.
[TR-069] Broadband Forum, "CPE WAN Management Protocol", Issue: 1
Amendment 5, November 2013, <https://www.broadband-
forum.org/technical/download/ TR-069_Amendment-5.pdf>.
[BANANA-encap]
N. Leymann, C. Heidemann, et al, "BANdwidth Aggregation for
interNet Access (BANANA) The Data Plane of Bonding
Tunnels", draft-leymann-banana-data-encap, work in
progress.
[BANANA-attributes]
N. Leymann, C. Heidemann, et al, "BANdwidth Aggregation for
interNet Access (BANANA) Attributes for the Control
Protocol of Bonding Tunnels", draft-leymann-banana-
signaling-attributes, work in progress.
9.2. Informative References
[802Type] IANA, "IEEE 802 Numbers",
<http://www.iana.org/assignments/ieee-802-numbers>.
Contributors
Li Xue
Individual
Email: xueli_jas@163.com
Zhongwen Jiang
Huawei Technologies
Email: jiangzhongwen@huawei.com
Leymann, et al. Expires June 29, 2018 [Page 14]
INTERNET-DRAFT BANANA Signaling December 26, 2017
Authors' Addresses
Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21-27
Berlin 10781
Germany
Phone: +49-170-2275345
Email: n.leymann@telekom.de
Cornelius Heidemann
Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7
Darmstadt 64295
Germany
Phone: +49-6151-5812721
Email: heidemannc@telekom.de
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd.
Haidian District
Beijing 100095
China
Email: zhangmingui@huawei.com
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 3
Plano, TX 75024
United States of America
Email: sarikaya@ieee.org
Margaret Cullen
Painless Security
14 Summer St. Suite 202
Malden, MA 02148
United States of America
Email: margaret@painless-security.com
Leymann, et al. Expires June 29, 2018 [Page 15]
