idnits 2.17.00 (12 Aug 2021) /tmp/idnits64519/draft-leymann-banana-signaling-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 26, 2017) is 1600 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'TR-069' -- Possible downref: Normative reference to a draft: ref. 'BANANA-encap' -- Possible downref: Normative reference to a draft: ref. 'BANANA-attributes' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BANANA N. Leymann 3 Internet Draft C. Heidemann 4 Intended Category: Proposed Standard Deutsche Telekom AG 5 M. Zhang 6 B. Sarikaya 7 Huawei 8 M. Cullen 9 Painless Security 10 Expires: June 29, 2018 December 26, 2017 12 BANdwidth Aggregation for interNet Access (BANANA) 13 The Control Protocol of Bonding Tunnels 14 draft-leymann-banana-signaling-02.txt 16 Abstract 18 There is an emerging demand for solutions to bond multiple access 19 links to provide subscribers with redundancy and load-sharing across 20 these access links. BANdwidth Aggregation for interNet Access 21 (BANANA) will specify such solutions. 23 In this document, a control protocol is specified to deliver 24 configuration and control information between two peering BANANA 25 boxes. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 67 3. The Single Operator Scenario . . . . . . . . . . . . . . . . . 5 68 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Control Protocol Specification . . . . . . . . . . . . . . . . 7 70 5.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. Establishment of Bonding Tunnels . . . . . . . . . . . . . 10 72 6. The Edge to Edge Scenario . . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 78 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Service Providers used to provide subscribers with separate access to 84 their multiple networks. It has become desirable to bond access 85 links to these networks together to offer access service to 86 subscribers. When the traffic volume exceeds the bandwidth of the 87 first connection, the excess amount can be offloaded to a secondary 88 connection. So bonding service is able to provide subscribers with 89 increased access capacity and improved reliability. 91 This memo will mainly work two scenarios out: the single operator 92 scenario and the edge to edge scenario. There would be mainly 93 implementation issues to make BANANA be applicable to more scenarios. 94 For the single-operator scenario, the local BANANA box is a Customer 96 Premises Equipment (CPE) device initiating the two connections. The 97 remote BANANA box resides in the provider's networks to terminate 98 these bonded connections. For the edge to edge scenario, the two 99 peering BANANA boxes are two CPE devices which might be operated by 100 different providers. 102 This document specifies the control protocol between the two BANANA 103 boxes. This control protocol adopts GRE (Generic Routing 104 Encapsulation [RFC2890]) since GRE is widely supported in various 105 networks. Approaches specified in this document might also be used 106 by other tunneling technologies to achieve tunnel bonding. However, 107 such variants are out of scope for this document. 109 For each heterogeneous connection between the two BANANA boxes, one 110 GRE tunnel is set up. The local and remote BANANA box, respectively, 111 serve as the common termination point of the tunnels at both ends. 112 Those GRE tunnels are bonded together to form a logical IP link for 113 the subscriber. This provides an overlay: the users' IP packets 114 (inner IP) are encapsulated in GRE, which is in turn carried over IP 115 (outer IP). 117 A tunnel bonding solution of BANANA may support more than two tunnels 118 between the two BANANA boxes though the reference topologies in this 119 memo choose to use two tunnels between the two BANANA boxes to depict 120 such a solution. 122 2. Acronyms and Terminology 124 GRE: Generic Routing Encapsulation [RFC2890]. 126 BRAS: Broadband Remote Access Server. Routes traffic to and from 127 broadband remote access devices such as Digital Subscriber Line 128 Access Multiplexers (DSLAMs) on an Internet Service Provider's 129 (ISP's) network. 131 PGW: Packet Data Network Gateway. In the Long Term Evolution (LTE) 132 architecture for the Evolved Packet Core (EPC), acts as an anchor 133 for user-plane mobility. 135 PDP: Packet Data Protocol. A packet transfer protocol used in 136 wireless GPRS (General Packet Radio Service) / HSDPA (High-Speed 137 Downlink Packet Access) networks. 139 PPPoE: Point-to-Point over Ethernet. A network protocol for 140 encapsulating PPP frames inside Ethernet frames. 142 DNS: Domain Name System. A hierarchical distributed naming system 143 for computers, services, or any resource connected to the Internet 144 or a private network. 146 DHCP: Dynamic Host Configuration Protocol. A standardized network 147 protocol used on Internet Protocol (IP) networks for dynamically 148 distributing network configuration parameters, such as IP 149 addresses for interfaces and services. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 3. The Single Operator Scenario 157 DNS server 158 branch router 160 +--------------+ +-----------+ 161 +--+ | | | | ,,, ,,,,,, 162 | | | +-+ | | DHCP | , ,, , 163 |A6|------------| | | |+-+ IP pool| , , 164 | | | | | S--Tunnel 2--| | | ,, ,, 165 | | | +-+ |C| | ||R| ---------I , 166 | | | |N| | | F--Tunnel 1--| | | ,, ,, 167 |A4|---A1---|A|-| | | |+-+ | ,,,,,,,,,,, 168 | | | |T| +-+ | | | Internet 169 +--+ |DHCP +-+ | | | 170 Host |IP pool | | | 171 +--------------+ +-----------+ 172 local remote 173 BANANA box BANANA box 175 A6: The endpoint for the IPv6 address that is used for the BANANA 176 service by the Host. 177 A4: The endpoint for the IPv4 address that is used for the BANANA 178 service by the Host. 179 C: The service endpoint of the bonding service at the local 180 BANANA box. IP address or IP prefix of C is assigned by the 181 DHCP from a pool of IP addresses maintained on the remote 182 BANANA box. 183 A1: The endpoint of the Gateway on the same Local Area Network 184 (LAN) as the Host. The pre-configured IP address of A1 will 185 be translated to the IP address of C by the Network Address 186 Translator (NAT). 187 F: The local endpoint of the first tunnel (Tunnel 1) at the local 188 BANANA box. 189 S: The local endpoint of the secondary tunnel (Tunnel 2) at the 190 local BANANA box. 191 R: The common remote endpoint for Tunnel 1 and Tunnel 2 at the 192 remote BANANA box. The DNS server will resolve an URL 193 provisioned by the Service Provider to be the IP address of 194 R. 195 I: The endpoint of the destination in the Internet. 197 Figure 3.1: Tunnel bonding for a single operator 199 If a Service Provider runs multiple networks, subscribers are eager 200 to use those networks simultaneously for increased access capacity 201 rather than just using a single network. As shown by the reference 202 topology in Figure 3.1, the subscriber expects a significantly higher 203 access bandwidth from the bonding connection than from just the first 204 connection. In other words, when the traffic volume exceeds the 205 bandwidth of the first connection, the excess amount may be offloaded 206 to the secondary connection. 208 One tunnel is established per-connection between the two BANANA boxes 209 (see Figure 3.1). These tunnels are bonded together as if there is a 210 single IP link provided between the two boxes for the subscriber who 211 buys the local BANANA box. 213 Compared to per-flow load balancing mechanisms which are widely used 214 nowadays, BANANA MUST support per-packet offloading approach. For 215 per-flow load-balancing, the maximum bandwidth that may be used by a 216 traffic flow is the bandwidth of an individual connection. While for 217 per-packet offloading, a single flow may use the added-up bandwidth 218 of all the connections. 220 Although this memo depicts the tunnel bonding solution using 221 reference topologies (see also Section 6) with two GRE tunnels 222 between the two BANANA boxes, a tunnel bonding solution can support 223 more than two tunnels between the two BANANA boxes. 225 4. Addressing 227 When the Host boots up, IP addresses of A4 and/or A6 will be assigned 228 by the DHCP from a pool of IP addresses maintained on the local 229 BANANA box. The Gateway IP addresses of A1 is locally configured and 230 will be translated into the IP address of C which is assigned by the 231 DHCP from a pool of IP addresses maintained on the remote BANANA box. 232 IPv6 address of A6 has the same prefix as C so that NAT function is 233 unnecessary. The DHCP message that carries the IP address of C will 234 be encapsulated as a GRE data packet ([BANANA-encap]) after Tunnel 1 235 is established. 237 When the local BANANA box boots up, IP addresses of F and S will be 238 automatically assigned by network devices connected to the local 239 BANANA box. As examples, if this network device is a Broadband 240 Remote Access Server (BRAS), the local BANANA box gets an IP address 241 through the Point-to-Point Protocol over Ethernet (PPPoE). If this 242 network device is a Packet Data Network Gateway (PGW), the local 243 BANANA box gets an IP address through the Packet Data Protocol (PDP). 244 In order to support automatic establishment of GRE tunnels, the IP 245 address of F or S needs to be carried by the control protocol from 246 the local BANANA box to the remote BANANA box. 248 The domain name of a remote BANANA box may be configured or obtained 249 via the Wide Area Network (WAN) interface of the first or secondary 250 connection based on gateway configuration protocols such as [TR-069]. 252 The resolution of the remote BANANA box's domain name is requested 253 via the WAN interface of the first or secondary connection. The 254 Domain Name System (DNS) server will reply with the IP address of R 255 which is assigned by DHCP from a pool of IP addresses maintained on 256 the remote BANANA box. 258 A Service Provider might deploy multiple remote BANANA boxes in one 259 site and place a branch router in front of these remote BANANA boxes. 260 The DNS server will resolve the URL to a pre-configured IP address 261 of this branch router instead of the IP address of R. In this way, 262 the tunnel setup request from the local box will reach this branch 263 router instead of R. This branch router will adopt anycast mechanism 264 to achieve load balancing and direct the tunnel setup request to one 265 of the remote BANANA boxes. For this case, the IP address of R needs 266 to be carried by the control protocol from the remote BANANA box to 267 the local BANANA box for the purpose of automatic establishment of 268 GRE tunnels. 270 5. Control Protocol Specification 272 The control protocol of BANANA is designed to exchange configuration 273 and control information between the two BANANA boxes, such as IP 274 prefixes of local links (see Section 4), the link properties and 275 status and the information needed by the encapsulations. 277 5.1. Message Formats 279 Messages of the control protocol are delivered as GRE encapsulated 280 packets and routed via the same GRE tunnels as GRE data packets. All 281 control messages are sent in network byte order (high-order bytes 282 first). The GRE Protocol Type field is used to distinguish control 283 packets from GRE data packets. The new GRE Protocol Type (0xB7EA) is 284 allocated for this purpose. GRE packets with a Protocol Type that 285 equals to this number will be consumed by the receiving BANANA box 286 rather than forward further. 288 The standard GRE header as per [RFC2890] with Checksum Present bit 289 and Sequence Number Present bit set to zero and Key Present bit set 290 to one is used in this memo. This means the Checksum, the Sequence 291 Number and the Reserved1 fields are not present. So, the format of 292 the GRE header for control messages of is as follows: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |0| |1|0| Reserved0 | Ver | Protocol Type 0xB7EA | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Key | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 The remote BANANA box generates a random number to be carried as the 303 Key field of each control message by the local BANANA box. Except 304 the first GRE Tunnel Setup Request message, the Key field of all 305 control messages originated by the local BANANA box MUST be set to 306 this random number. The remote BANANA box uses the value of the Key 307 to authenticate the local BANANA box. 309 The general format of the entire control message is as follows: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |0| |1|0| Reserved0 | Ver | Protocol Type 0xB7EA | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Key | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |MsgType|T-Type | | 319 +-+-+-+-+-+-+-+-+ Attributes + 320 ~ ~ 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 5.1: Format of Control Messages of GRE Tunnel Bonding 325 o MsgType (4 bits) 326 Message Type. The control message family contains the following 327 six types of control messages (not including "Reserved"): 329 Control Message Family Type 330 ========================== ========= 331 GRE Tunnel Setup Request 1 332 GRE Tunnel Setup Accept 2 333 GRE Tunnel Setup Deny 3 334 GRE Tunnel Hello 4 335 GRE Tunnel Tear Down 5 336 GRE Tunnel Notify 6 337 Reserved 0, 7-15 339 - GRE Tunnel Setup Request 340 The local BANANA box uses the GRE Tunnel Setup Request message to 341 request that the remote BANANA box establishes the GRE tunnels. 343 It is sent out from the local BANANA box's F and S interfaces 344 (see Figure 3.1). 346 - GRE Tunnel Setup Accept 347 The remote BANANA box uses the GRE Tunnel Setup Accept message as 348 the response to the GRE Tunnel Setup Request message. This 349 message indicates the acceptance of the tunnel establishment and 350 carries parameters of the GRE tunnels. 352 - GRE Tunnel Setup Deny 353 The remote BANANA MUST send the GRE Tunnel Setup Deny message to 354 the local BANANA box if the GRE Tunnel Setup Request from this 355 local BANANA box is denied. The local BANANA box MUST terminate 356 the GRE tunnel setup process as soon as it receives the GRE 357 Tunnel Setup Deny message. 359 - GRE Tunnel Hello 360 After the first or the second GRE tunnel is established (see 361 Figure 3.1), the local BANANA box begins to periodically send out 362 GRE Tunnel Hello messages via the tunnel; the remote BANANA box 363 acknowledges the local BANANA box's messages by returning GRE 364 Tunnel Hello messages received from the local BANANA box. This 365 continues until the tunnel is terminated. 367 - GRE Tunnel Tear Down 368 The remote BANANA box can terminate a GRE tunnel by sending the 369 GRE Tunnel Tear Down message to the local BANANA box via the 370 tunnel. After receiving the GRE Tunnel Tear Down message, the 371 local BANANA removes the IP address of R (see Figure 3.1). 373 - GRE Tunnel Notify 374 The two BANANA boxes use the GRE Tunnel Notify message, which is 375 transmitted through either the first or the second GRE tunnel, to 376 notify each other about their status regarding the two GRE 377 tunnels, the information for the bonding tunnels, the actions 378 that need to be taken, etc. 380 Normally, the receiver just sends the received attributes back as 381 the acknowledgement for each GRE Tunnel Notify message. If the 382 size of the attribute is too large, an acknowledgement attribute 383 for it need to be defined. 385 o T-Type (4 bits) 386 Tunnel Type. Set to 0001 if the control message is sent via the 387 first GRE tunnel. Set to 0010 if the control message is sent via 388 the secondary GRE tunnel. Values 0000 and values from 0011 through 389 1111 are reserved for future use and MUST be ignored on receipt. 391 o Attributes 392 The Attributes field includes the attributes that need to be 393 carried in the control message. Each Attribute has the following 394 format: 396 +-+-+-+-+-+-+-+-+ 397 |Attribute Type | (1 byte) 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Attribute Length | (2 bytes) 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Attribute Value ~ (variable) 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 - Attribute Type 405 The Attribute Type specifies the type of the attribute. 407 - Attribute Length 408 Attribute Length indicates the length of the Attribute Value in 409 bytes. 411 - Attribute Value 412 The Attribute Value includes the value of the attribute. 414 Specific attributes will be defined in [BANANA-attributes]. 416 5.2. Establishment of Bonding Tunnels 418 One major goal of BANANA signaling is to enable the automatic set up 419 of GRE tunnels which used to be set up manually. After the IP 420 addresses of tunnel endpoints have been acquired, the local BANANA 421 box starts the following procedure to set up the bonding tunnels. 423 The local BANANA box will firstly set up the secondary GRE tunnel 424 (Tunnel 2 in Figure 3.1) and then the first GRE tunnel (Tunnel 1 in 425 Figure 3.1). If the secondary GRE tunnel cannot be established 426 successfully, the local BANANA box will not set up the first GRE 427 tunnel since it's more economical to transmit traffic over a raw link 428 than over a GRE tunnel. 430 The local BANANA box sends the GRE Tunnel Setup Request message to 431 the remote BANANA box via the endpoint S. The outer source IP 432 address for this message is the IP address of S, while the outer 433 destination IP address is the IP address of the branch router (if 434 anycast is not used, the outer destination IP address would be IP 435 address of R). The remote BANANA box with the highest priority 436 (e.g., the one that the local BANANA box has the least-cost path to 437 reach) in the group of remote BANANA boxes, which receives the GRE 438 Tunnel Setup Request message, will initiate the procedure for 439 authentication and authorization to check whether the local BANANA 440 box is trusted by the network device attached to S. 442 If the authentication and authorization succeed, the remote BANANA 443 box sets the IP address of S, which is obtained from the GRE Tunnel 444 Setup Request message (i.e., its outer source IP address), as the 445 destination endpoint IP address of the secondary GRE tunnel and 446 replies to the endpoint of the local BANANA box's secondary GRE 447 tunnel with the GRE Tunnel Setup Accept message in which an IP 448 address of R (e.g., an IP address of a Line Card in the remote BANANA 449 box) and a Session ID randomly generated by the remote BANANA box are 450 carried as attributes. The outer source IP address for this message 451 is the IP address of R or the IP address of the branch router, while 452 the outer destination IP address is the IP address of S. Otherwise, 453 the remote BANANA box MUST send to the Local BANANA box's endpoint of 454 the secondary GRE tunnel the GRE Tunnel Setup Deny message, and the 455 local BANANA box MUST terminate the tunnel setup process once it 456 receives the GRE Tunnel Setup Deny message. 458 After the secondary GRE tunnel is successfully set up, the local 459 BANANA box will obtain the C address (see Figure 3.1) over the tunnel 460 from the remote BANANA box through the Dynamic Host Configuration 461 Protocol (DHCP). After that, the local BANANA box starts to set up 462 the first GRE tunnel. It sends a GRE Tunnel Setup Request message 463 via F, carrying the aforementioned Session ID received from the 464 remote BANANA box. The outer source IP address for this message is 465 the IP address of F, while the outer destination IP address is the IP 466 address of R. The remote BANANA box, which receives the GRE Tunnel 467 Setup Request message, will initiate the procedure for authentication 468 and authorization in order to check whether the local BANANA box is 469 trusted by the network device attached to F. 471 If the authentication and authorization succeed, the remote BANANA 472 sets the IP address of F, which is obtained from the GRE Tunnel Setup 473 Request message (i.e., its outer source IP address), as the 474 destination endpoint IP address of the GRE tunnel and replies to the 475 endpoint F with the GRE Tunnel Setup Accept message. The outer 476 source IP address for this message is the IP address of R, while the 477 outer destination IP address is the IP address of F. In this way, 478 the two tunnels with the same Session ID can be used to carry traffic 479 from the same user. That is to say, the two tunnels are "bonded" 480 together. Otherwise, if the authentication and authorization fail, 481 the remote BANANA box MUST send the GRE Tunnel Setup Deny message to 482 the tunnel endpoint F. Meanwhile, it MUST send the GRE Tunnel Tear 483 Down message to the tunnel endpoint S. The local BANANA box MUST 484 terminate the tunnel setup process once it receives the GRE Tunnel 485 Setup Deny message and MUST tear down the secondary GRE tunnel that 486 has already been set up once it receives the GRE Tunnel Tear Down 487 message. 489 6. The Edge to Edge Scenario 491 DNS server DNS server 493 +--------------+ +--------------+ 494 +--+ | | | | +--+ 495 | | | +-+ | | +-+ | | | 496 |A6|------------| | | | | |-------------|B6| 497 | | | | |Sl--Tunnel 2--Sr| | | | | 498 | | | +-+ |C| | | |D| +-+ | | | 499 | | | |N| | |Fl--Tunnel 1--Fr| | |N| | | | 500 |A4|---A1---|A|-| | | | | |-|A|--B1-----|B4| 501 | | | |T| +-+ | | +-+ |T| | | | 502 +--+ |DHCP +-+ | | +-+ DHCP| +--+ 503 Host |IP pool | | IP pool| Host 504 +--------------+ +--------------+ 505 local remote 506 BANANA box BANANA box 508 Figure 6.1: Tunnel bonding for the edge to edge scenario 510 The applicability of bonding tunnels is not limited to the single 511 operator scenario. This section explains how bonding tunnels are 512 adapted to the edge to edge scenario. By and large, the adaptations 513 are implementation issues. 515 o Addressing 517 IP addresses of B4, B6, B1, Fr and Sr are obtained in the same way as 518 A4, A6, A1, Fl and Sl respectively, as in the single operator 519 scenario. 521 C and D are the service endpoints of the bonding service at the two 522 BANANA box respectively. IP addresses of C and D will be assigned 523 from the locally configured IP pool via DHCP rather than be assigned 524 remotely from the peering BANANA box. 526 Domain names of the two BANANA boxes may be configured or obtained 527 via [TR-069]. A query of the domain names will be resolved to the IP 528 address of C or D by the DNS server . 530 o Establishment of Bonding Tunnels 532 The local BANANA box will send the GRE Tunnel Setup message to the 533 remote BANANA box using IP address of D as the outer destination IP 534 address and using IP address of Sl as the outer source IP address. 536 When the remote BANANA box replies the local BANANA box with the GRE 537 Tunnel Accept message, the outer source IP address for this message 538 is set to the IP address of Sr or D, while the outer destination IP 539 address is the IP address of Sl. In the GRE Tunnel Accept message, 540 the IP address of Sr, the IP address of Fr and a Session ID randomly 541 generated by the remote BANANA box will be carried as attributes. 542 Tunnel 2 would be set up between Sl and Sr. 544 For Tunnel 1, the local BANANA box will use the IP address of Fr as 545 the outer destination IP address and IP address of Fl as the outer 546 source IP address to send the GRE Tunnel Setup message to the remote 547 BANANA box. In this message, the Session ID received from the remote 548 BANANA box will be carried as an attribute. The remote BANANA box 549 will reply the local BANANA box with a GRE Tunnel Setup Accept 550 message. The outer source IP address for this message is the IP 551 address of Fr while the outer destination IP address for this message 552 is the IP address of Fl. Tunnel 1 would be set up between Fl and Fr. 553 Since Tunnel 1 and Tunnel 2 use the same Session ID, they would be 554 bonded together to carry traffic from the same user. 556 For the edge to edge scenario, a BANANA box can either be "local" or 557 "remote". The IP addresses of the service endpoint is used to break 558 the tie. The BANANA box with the smaller IP address will be regarded 559 as "local" while the BANANA box with the larger IP address will be 560 regarded as "remote". 562 7. Security Considerations 564 Malicious devices controlled by attackers may intercept the control 565 messages sent on the GRE tunnels. Later on, the rogue devices may 566 fake control messages to disrupt the GRE tunnels or attract traffic 567 from the target local BANANA box. 569 As a security feature, the Key field of the GRE header of the control 570 messages is generated as a 32-bit cleartext password, except for the 571 first GRE Setup Request message per bonding connection sent from the 572 local BANANA box to the remote BANANA box, whose Key field is filled 573 with all zeros. The remote BANANA box and the local BANANA validate 574 the Key value and the outer source IP address, and they discard any 575 packets with invalid combinations. 577 8. IANA Considerations 579 IANA need not assign anything for this memo. The GRE Protocol Type, 580 the Ethertype for the GRE Channel of the BANANA signaling, is set to 581 0xB7EA, which is under the control of the IEEE Registration 582 Authority. However, IANA has updated the "IEEE 802 Numbers" IANA web 583 page [802Type], which is of primarily historic interest. 585 9. References 587 9.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, DOI 591 10.17487/RFC2119, March 1997, . 594 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 595 RFC 2890, DOI 10.17487/RFC2890, September 2000, 596 . 598 [TR-069] Broadband Forum, "CPE WAN Management Protocol", Issue: 1 599 Amendment 5, November 2013, . 602 [BANANA-encap] 603 N. Leymann, C. Heidemann, et al, "BANdwidth Aggregation for 604 interNet Access (BANANA) The Data Plane of Bonding 605 Tunnels", draft-leymann-banana-data-encap, work in 606 progress. 608 [BANANA-attributes] 609 N. Leymann, C. Heidemann, et al, "BANdwidth Aggregation for 610 interNet Access (BANANA) Attributes for the Control 611 Protocol of Bonding Tunnels", draft-leymann-banana- 612 signaling-attributes, work in progress. 614 9.2. Informative References 616 [802Type] IANA, "IEEE 802 Numbers", 617 . 619 Contributors 621 Li Xue 622 Individual 623 Email: xueli_jas@163.com 625 Zhongwen Jiang 626 Huawei Technologies 627 Email: jiangzhongwen@huawei.com 629 Authors' Addresses 631 Nicolai Leymann 632 Deutsche Telekom AG 633 Winterfeldtstrasse 21-27 634 Berlin 10781 635 Germany 636 Phone: +49-170-2275345 637 Email: n.leymann@telekom.de 639 Cornelius Heidemann 640 Deutsche Telekom AG 641 Heinrich-Hertz-Strasse 3-7 642 Darmstadt 64295 643 Germany 644 Phone: +49-6151-5812721 645 Email: heidemannc@telekom.de 647 Mingui Zhang 648 Huawei Technologies 649 No. 156 Beiqing Rd. 650 Haidian District 651 Beijing 100095 652 China 653 Email: zhangmingui@huawei.com 655 Behcet Sarikaya 656 Huawei USA 657 5340 Legacy Dr. Building 3 658 Plano, TX 75024 659 United States of America 660 Email: sarikaya@ieee.org 662 Margaret Cullen 663 Painless Security 664 14 Summer St. Suite 202 665 Malden, MA 02148 666 United States of America 667 Email: margaret@painless-security.com