idnits 2.17.00 (12 Aug 2021) /tmp/idnits49623/draft-yamaya-ipsecme-mpsa-06.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 == Line 543 has weird spacing: '...chieved by st...' -- The document date (September 24, 2015) is 2424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 124, but not defined == Missing Reference: 'IKEV2' is mentioned on line 231, but not defined == Missing Reference: 'Nonce' is mentioned on line 438, but not defined == Missing Reference: 'Lifetime' is mentioned on line 457, but not defined == Missing Reference: 'RolloverTime1' is mentioned on line 465, but not defined == Missing Reference: 'RolloverTime2' is mentioned on line 473, but not defined ** Obsolete normative reference: RFC 5996 (ref. 'IKEv2') (Obsoleted by RFC 7296) == Outdated reference: A later version (-09) exists of draft-vandevelde-idr-remote-next-hop-07 ** Obsolete normative reference: RFC 5566 (ref. 'ENCAPS') (Obsoleted by RFC 9012) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSecME Working Group A. Yamaya 3 Internet-Draft Furukawa Network Solution 4 Intended Status: Informational T. Ohya 5 Expires: March 27, 2016 NTT 6 T. Yamagata 7 KDDI 8 S. Matsushima 9 Softbank Telecom 10 September 24, 2015 12 Simple VPN solution using Multi-point Security Association 13 draft-yamaya-ipsecme-mpsa-06 15 Abstract 17 This document describes the over-lay network solution by utilizing 18 dynamically established IPsec multi-point Security Association (SA) 19 without individual connection. 21 Multi-point SA technology provides the simplified mechanism of the 22 Auto Discovery and Configuration function. This is applicable for 23 any IPsec tunnels such as IPv4 over IPv4, IPv4 over IPv6, IPv6 over 24 IPv4 and IPv6 over IPv6. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 27, 2016. 43 Copyright and License Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Sequence . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2. Extended format . . . . . . . . . . . . . . . . . . . . . 8 67 3.2.1. Vendor ID . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.2. MPSA_PUT . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3. Multi-point SA Management . . . . . . . . . . . . . . . . 14 70 3.3.1. Controller . . . . . . . . . . . . . . . . . . . . . . 14 71 3.3.2. CPE . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 3.3.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4. Peer discovery . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.1 example of MPSA with BGP for route based VPN . . . . . . . . 16 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 5.1. Protected by MPSA . . . . . . . . . . . . . . . . . . . . . 17 78 5.2 Security issues not to be solved by MPSA . . . . . . . . . . 17 79 5.2.1 Attack from outside of the group . . . . . . . . . . . . 17 80 5.2.2 Attack from inside of the group . . . . . . . . . . . . 17 81 5.3 Forward secrecy and backward secrecy . . . . . . . . . . . . 17 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 85 6.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 As described in the problem statement document [ad-vpn-problem], 91 dynamic, secure and scalable system for establishing SAs is needed. 93 With multi-point SA, an endpoint automatically discovers other 94 endpoint. In this draft, an endpoint means an inexpensive CPE, which 95 can hardly establish large number of IPsec sessions simultaneously. 96 The CPEs also share a multi-point SA within the same group, and there 97 is no individual connection between them. 99 Scalability issue becomes serious in the service, such as triple play 100 which requires large number of sessions at the same time. MPSA 101 enables large scale simultaneous sessions even with inexpensive CPEs, 102 and can avoid scalability issue. 104 The latency between CPEs can be minimized because of stateless shared 105 multipoint SA, MPSA is suitable for video and voice services which is 106 very sensitive to latency. 108 It can avoid the exhaustive configuration for CPEs and controllers. 109 No reconfiguration is needed when a new CPE is added, removed, or 110 changed. It can avoid high load on the controllers. 112 1.1. Terminology 114 Multi-point SA - This is similar to Dynamic Full Mesh topology 115 described in [ad-vpn-problem]; direct connections exist in a hub and 116 spoke manner, but only one SA for data transfer is shared with all 117 CPEs. 119 1.2. Conventions Used in This Document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Motivation 127 There are two major topologies - Star topology and full-mesh topology 128 - to communicate securely on over-lay network by using IPsec. 130 Figure.1 shows star topology. The number of IPsec connection is the 131 same as the number of CPEs (CPE). Authentication, Authorization and 132 Accounting (AAA) of each CPE can be achieved on the gateway. 134 The problem of the star topology is all the traffic go through the 135 gateway, then it causes high load and latency. 137 +---------------------------------------------+ 138 | IPsec Gateway | 139 | | 140 | +--------------(A<->C)--------------+ | 141 | | +---(A<->B)---+ +---(B<->C)---+ | | 142 +---:|-|:-----------:|---|:-----------:|-|:---+ 143 :| |: :| |: :| |: 144 :| |: :| |: :| |: 145 :| |: :| |: :| |: 146 +---:v-v:---+ :| |: +---:v-v:---+ 147 | | :| |: | | 148 | CPE_A | :| |: | CPE_C | 149 | | :| |: | | 150 +-----------+ +--:v---v:--+ +-----------+ 151 | | 152 | CPE_B | 153 | | 154 +-----------+ 156 Figure 1 158 Figure.2 shows Full-mesh topology. There is no gateways. Each CPE 159 establishes IPsec connection independently. The latency on this 160 topology is relatively low compared to star topology. 162 In large system, there are huge number ((N^2-N)/2) of IPsec 163 connections. AAA of each CPE is hard to manage in this topology. 164 Moreover, when a CPE is added, removed or changed, reconfiguration is 165 needed for all rest of the CPEs. 167 +-----------+ +-----------+ 168 | |.....................| | 169 | CPE_A <-------(A<->C)-------> CPE_C | 170 | |.....................| | 171 +---: ^ :---+ +---: ^ :---+ 172 : | : : | : 173 : | : +-----------+ : | : 174 : | :........| |........: | : 175 : +-(A<->B)--> CPE_B <--(B<->C)-+ : 176 :............| |............: 177 +-----------+ 179 Figure 2 181 The solution in this document eliminates the problems listed above. 182 Figure 3 shows topology of multi-point SA. Traffic between CPEs does 183 not go through the controller, low latency, AAA of each CPE can be 184 achieved, the number of IPsec connection is almost same as star 185 topology, and no reconfiguration is needed for all the rest of CPEs 186 even when a CPE is added, removed or changed. MPSA controller do not 187 necessarily need to be router. It is possible to change MPSA 188 controller for a software, because a communication load which spans 189 IPsec Gateway by multi-point SA is not big. 191 +---------------------------------------------+ 192 | MPSA Controller | 193 | | 194 +---: | :------------: | :------------: | :---+ 195 : | : : | : : | : 196 : | : : | : : | : 197 ----------------------------------------- SA to distribute 198 : | : : | : : | : Multi-point SA 199 : | : : | : : | : 200 +---: v :---+ +---: v :---+ +---: v :---+ 201 | | | | | | 202 | CPE_A | | CPE_B | | CPE_C | 203 | | | | | | 204 +--- ^ ^ ---+ +--- ^ ^ ---+ +--- ^ ^ ---+ 205 .....| |..............| |..............| |..... 206 | | | | | | \ 207 | +----(A<->B)---+ +---(B<->C)----+ | Multi-point SA 208 +--------------(A<->C)--------------+ for data transfer 209 .............................................../ 211 Figure 3 213 3. Procedure 215 3.1. Sequence 217 The multi-point SA capability of the remote host is determined by 218 an exchange of Vendor ID payloads. In the IKE_SA_INIT exchange, 219 the Vendor ID payload for this specification is sent if the multi- 220 point SA is used. 222 CPE Controller 223 ----------- ----------- 224 HDR, SAi1, KEi, 225 Ni, V(MPSA) --> 226 <-- HDR, SAr1, KEr, 227 Nr, [CERTREQ,] V(MPSA) 229 MPSA: multi-point SA 231 The initial exchange (including IKE_AUTH) is same as [IKEV2], 232 other than Vendor ID payload included in IKE_SA_INIT. 234 After the initial exchange has finished successfully, a new 235 INFORMATIONAL exchange is used to distribute multi-point SA to the 236 CPE, with the Notify payload of MPSA_PUT that includes 237 cryptographic algorithm, nonce, keying material, SPI and so on. 238 Keys for multi-point SA is generated according to the contents of 239 the Notify payload by the CPE. The response of the Notify payload 240 has empty Encrypted payload. 242 CPE Controller 243 ----------- ----------- 244 <-- HDR, SK {N(MPSA_PUT)} 245 HDR, SK {} --> 247 3.2. Extended format 249 3.2.1. Vendor ID 251 This document defines a new Vendor ID. The content of the payload 252 is described below. 254 "multi-point SA" 256 3.2.2. MPSA_PUT 258 This document defines a new Notify Message Type MPSA_PUT. The 259 Notify Message Type of MPSA_PUT is 40960. Notification Data of 260 MPSA_PUT has a Proposal-substructure-like format. It consists of 261 Transform-substructure-like structures that have following data. 263 Description Trans. Reference 264 Type 265 ------------------------------------------------------- 266 Encryption Algorithm (ENCR) 1 RFC5996 267 Pseudorandom Function (PRF) 2 RFC5996 268 Integrity Algorithm (INTEG) 3 RFC5996 269 Nonce (NONCE) 241 270 SK_d (SKD) 242 271 Lifetime (LIFE) 243 272 Rollover time 1 (ROLL1) 244 273 Rollover time 2 (ROLL2) 245 275 o Nonce - For Transform Type 241, the Transform ID is 1. The 276 attribute contains actual nonce value with attribute type 16384. 277 The size of the Nonce Data is between 16 and 256 octets. 279 Name Number 280 --------------------------------------------------- 281 NONCE_NONCE 1 283 Attribute Type Value Attribute Format 284 ------------------------------------------------------------ 285 Nonce Value 16384 TLV 287 o SK_d - For Transform Type 242, the Transform ID is 1. The 288 attribute contains actual SK_d value with attribute type 16385. 289 The length of SK_d Data is the preferred key length of the PRF. 291 Name Number 292 --------------------------------------------------- 293 SKD_SK_D 1 295 Attribute Type Value Attribute Format 296 ------------------------------------------------------------ 297 SK_d Value 16385 TLV 299 o Lifetime - For For Transform Type 243, the Transform ID is 1. The 300 attribute contains actual lifetime value with attribute type 301 16386. The length of Lifetime Value is 4 octets. Lifetime is 302 stored in seconds as effective time of the multi-point SA. 304 Name Number 305 --------------------------------------------------- 306 LIFE_LIFETIME 1 308 Attribute Type Value Attribute Format 309 ------------------------------------------------------------ 310 Lifetime Value 16386 TLV 312 o Rollover time 1 - For Transform Type 244, the Transform ID is 1. 313 The attribute contains actual rollover time 1 value with attribute 314 type 16387. The length of Rollover time 1 Value is 4 octets. 315 Rollover time 1 defines activation time delay for new outbound 316 multi-point SA. 318 Name Number 319 --------------------------------------------------- 320 ROLL1_ROLLOVER1 1 322 Attribute Type Value Attribute Format 323 ------------------------------------------------------------ 324 Rollover1 Value 16387 TLV 326 o Rollover time 2 - For Transform Type 245, the Transform ID is 1. 327 The attribute contains actual rollover time 2 value with attribute 328 type 16388. The length of Rollover time 2 Value is 4 octets. 329 Rollover time 2 defines deactivation time delay for old inbound 330 multi-point SA. 332 Name Number 333 --------------------------------------------------- 334 ROLL2_ROLLOVER2 1 336 Attribute Type Value Attribute Format 337 ------------------------------------------------------------ 338 Rollover2 Value 16388 TLV 340 Therefore, the format of the MPSA_PUT of the Notify Message is 341 described below. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Next Payload |C| RESERVED | Payload Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Protocol ID | SPI Size | Notify Message Type | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Security Parameter Index (SPI) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | 0 (last) or 2 | RESERVED | Proposal Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Security Parameter Index (SPI) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | 0 (last) or 3 | RESERVED | Transform Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |Transform Type | RESERVED | Transform ID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 ~ Transform Attributes ~ 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | 0 (last) or 3 | RESERVED | Transform Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |Transform Type | RESERVED | Transform ID | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 ~ Transform Attributes ~ 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 ~ ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | 0 | RESERVED | Transform Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |Transform Type | RESERVED | Transform ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 ~ Transform Attributes ~ 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 The following example shows a N(MPSA_PUT) notification message. The 388 SPIs in the Proposal-like and Tranform-like substructure are the same 389 value. Following values are defined by the example. 391 Protocol: ESP 392 ENCR: AES-CBC (256bits) 393 PRF: SHA-1 394 INTEG: HAMC-SHA-1-96 395 NONCE: 241 396 SKD: 242 397 LIFE: 243 398 ROLL1: 244 399 ROLL2: 245 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 /| 0 (last) |C| RESERVED | Payload Length | 405 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Notify | 3 (ESP) | SPI Size = 4 | MPSA_PUT | 407 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 \| Security Parameter Index (SPI) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 /| 0 (last) | RESERVED | Proposal Length | 411 Pro- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 posal-| Prop Num = 1 | 3 (ESP) | SPI Size = 4 |Num Transforms| 413 like +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 \| Security Parameter Index (SPI) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 /| 3 | RESERVED | Transform Length | 417 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 ENCR | 1 (ENCR) | RESERVED | 12 (ENCR_AES_CBC) | 419 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 \|1| 14 (Key Length) | 256 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 /| 3 | RESERVED | Transform Length | 423 PRF +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 \| 2 (PRF) | RESERVED | 2 (PRF_HMAC_SHA1) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 /| 3 | RESERVED | Transform Length | 427 INTEG +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 \| 3 (INTEG) | RESERVED | 2 (AUTH_HMAC_SHA1_96) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 /| 3 | RESERVED | Transform Length | 432 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 / | 241 (NONCE) | RESERVED | 1 | 434 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 NONCE |0| 16384 (Nonce) | Attribute Length | 436 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 \ | | 438 \ ~ [Nonce] ~ 439 \| | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 /| 3 | RESERVED | Transform Length | 442 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 / | 242 (SKD) | RESERVED | 1 | 444 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 SKD |0| 16385 (SK_d) | Attribute Length | 446 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 \ | | 448 \ ~ [SK_d] ~ 449 \| | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 /| 3 | RESERVED | Transform Length | 452 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 / | 243 (LIFE) | RESERVED | 1 | 454 LIFE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 \ |0| 16386 (Lifetime) | Attribute Length = 4 | 456 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 \| [Lifetime] | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 /| 3 | RESERVED | Transform Length | 460 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 / | 244 (ROLL1) | RESERVED | 1 | 462 ROLL1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 \ |0| 16386 (Lifetime) | Attribute Length = 4 | 464 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 \| [RolloverTime1] | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 /| 3 | RESERVED | Transform Length | 468 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 / | 245 (ROLL2) | RESERVED | 1 | 470 ROLL2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 \ |0| 16386 (Lifetime) | Attribute Length = 4 | 472 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 \| [RolloverTime2] | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 3.3. Multi-point SA Management 478 3.3.1. Controller 480 Controller generates a multi-point SA for a group before connecting 481 to any CPEs. 483 After the initial exchanges have finished, controller distributes the 484 same multi-point SA information to CPEs within the group by sending 485 N(MPSA_PUT). 487 SPI and Nonce is generated similar way of [IKEv2]. SK_d is generated 488 from random numbers similar to Nonce. 490 The same SPI value is stored to Notify payload and Proposal-like 491 substructure. 493 The multi-point SA will not be negotiated between controller and CPE, 494 but will be notified from controller to CPE one way. 496 Controller initiates rekey before Lifetime expiration. As the 497 Lifetime, controller notifies the effective time left of the multi- 498 point SA. 500 3.3.2. CPE 502 After the initial exchange has finished, CPE obtains multi-point SA 503 information by receiving N(MPSA_PUT) from controller. The keys for 504 the multi-point SA are generated in the same procedure described in 505 [IKEv2], except Ni | Nr is replaced by Nonce. 507 Therefore, KEYMAT is derived by PRF listed below. 509 KEYMAT = prf+(SK_d, Nonce) 511 The multi-point SA is protected in a cryptographic manner by ENCR and 512 INTEG which uses the generated keys. 514 The SPI value for the multi-point SA is the same of its in Notify 515 message. 517 CPE uses the same multi-point SA as both inbound and outbound SAs. 519 CPE deletes both of inbound and outbound SA when Lifetime is 520 expired. 522 Rollover time 1, 2 have no meaning when no old multi-point SA exists. 524 3.3.3. Rekeying 526 Rekeying should be finished before Lifetime expiration of current 527 multi-point SA. Rekeying of multi-point SA will be performed as 528 follows. 530 - Controller generates a new multi-point SA 531 - Controller distributes a new multi-point SA to all CPEs within the 532 group 533 - CPE replaces the current multi-point SA to new one 535 CPE replaces multi-point SA using rollover method like [GDOI]. 537 3.4. Forwarding 539 Each CPE sends and receives encapsulated packets using the multi- 540 point SA. 542 The destination address of encapsulated packet will be determined 543 with routing information, which can achieved by static configuration 544 or route exchange mechanism such as BGP on encapsulated environment 545 described in [MESH]. 547 It is applicable for any IPsec tunnels such as IPv4 over IPv4, IPv4 548 over IPv6, IPv6 over IPv4 and IPv6 over IPv6. 550 4. Peer discovery 552 MPSA does not provide peer discovery function by itself. However, 553 other mechanism, such as BGP, can be employed with MPSA for automatic 554 peer discovery. One example is a use of BGP, described in [MESH], to 555 learn peer information as next-hops. 557 4.1 example of MPSA with BGP for route based VPN 559 Between controller and each peer, IKE_SA and CHILD_SA are established 560 by IKEv2. On the IKE_SA, an MPSA management message (MPSA_PUT) is 561 served from the controller to the peer. 563 On the CHILD_SA, the controller and the peer establish a iBGP session 564 to exchange route information (NLRIs). Controller can act as a BGP 565 route reflector (RR), which can reflect NLRIs among all iBGP peers of 566 the controller. In other words, the peer can learn all NLRIs 567 advertised by all other peers. 569 According to [ENCAPS], each peer can advertise ESP peer address as 570 well as conventional NLRIs, all of those can be reflected by RR on 571 the controller. 573 At this point, each peer can have all other peer addresses as well as 574 route information. The peer can decide a peer address by mean of 575 recursive route lookup from the destination address of a packet to be 576 forwarded. This decision can be made by the peer itself, without any 577 additional communication with the controller. 579 Instead of [ENCAPS], each peer can also do it by [RNH]. Each peer 580 learns all other peer addresses by BGP Remote-Next-Hop attributes and 581 decides a peer address from a packet to be forwarded, as same as 582 using [ENCAPS]. 584 5. Security Considerations 586 MPSA uses IKEv2 to protect MPSA management message, MPSA_PUT. Thus, 587 CPEs are authenticated by IKEv2. Using a shared SA for communication 588 between CPEs, MPSA does not provide the following features. 589 - Data origin authentication 590 - Anti-replay protection 592 MPSA itself does not provide access control for user datagrams, but 593 peer discovery may be able to provide access control as well as those 594 of route based VPN. For example, using BGP for peer discovery 595 described in 4.1, access control could be provided by filtering 596 exchanged routes at the controller. In this case, filtering by source 597 address, protocol and ports can not be achieved. If you need it, you 598 could do by other security policy rules as local setting at CPEs . 600 5.1. Protected by MPSA 602 - Authenticating CPEs and controller Authentication is provided by 603 IKEv2 with pre-shared key or RSA signature. MPSA management messages 604 are exchanged after IKEv2 negotiation. 606 - Confidentiality and integrity Packets are encapsulated by ESP, so 607 that MPSA provides confidentiality and integrity against outside of 608 the group, but does not them against members of the group 610 5.2 Security issues not to be solved by MPSA 612 5.2.1 Attack from outside of the group 614 - Anti-replay protection 615 MPSA does not provide anti-replay protection, because sequence number 616 synchronization between peers needs additional mechanism. Using a 617 closed network as a transport might be effective to mitigate this 618 kind of attacks. 620 - Leaking a IKE_SA key 621 If an attacker could sniff packets on a IKE_SA, and key of the SA 622 were leaked, the attacker may get a key of MPSA by decoding a sniffed 623 MPSA_PUT message. 625 5.2.2 Attack from inside of the group 627 If there is a malicious CPE or a CPE is hijacked by an attacker, MPSA 628 can be attacked in the following way because MPSA, including 629 cryptograghic key, is shared by all CPEs. 631 - An attacker can impersonate another CPE. A closed network that 632 prohibits source address spoofing could mitigate the impersonating. 634 - An attacker can decode packets between the other CPEs if the 635 attacker could sniff packets. 637 5.3 Forward secrecy and backward secrecy 638 MPSA MAY be rekeyed when a CPE is removed from the group, for the 639 removed CPE not to access the other CPEs communication after that, or 640 when a CPE is added from the group, for it not to do before that. If 641 not rekeyed, a removed/added CPE could access 643 5. IANA Considerations 645 This memo includes no request to IANA. 647 6. References 649 6.1. Normative References 651 [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 652 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 653 September 2010. 654 6.2. Informative References 656 [GDOI] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 657 Interpretation", RFC 6407, October 2011. 659 [MESH] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 660 Framework", RFC 5565, June 2009. 662 [ad-vpn-problem] Manral, V. and S. Hanna, "Auto-Discovery VPN Problem 663 Statement and Requirements", RFC 7018, September 2013. 665 [RNH] Van de Velde, G., Patel, K., Rao, D., Raszuk, R., and Bush, R., 666 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 667 hop-07, June 2014 669 [ENCAPS] L. Berger, R. White and E. Rosen, "BGP IPsec Tunnel 670 Encapsulation Attribute", RFC 5566, June 2009. 672 Authors' Addresses 674 Arifumi Yamaya 675 Furukawa Network Solution Corp. 676 5-1-9, Higashi-Yawata, Hiratsuka 677 Kanagawa 254-0016, JAPAN 678 Email: yamaya@fnsc.co.jp 680 Takafumi Ohya 681 NTT Corporation 682 Nishi-shinjuku, Shinjuku-ku, 683 Tokyo 163-8019, JAPAN 684 Email: takafumi.ooya@hco.ntt.co.jp 686 Tomohiro Yamagata 687 KDDI Corporation 688 Garden Air Tower 689 Iidabashi, Chiyoda-ku, 690 Tokyo 102-8460, JAPAN 691 Email: to-yamagata@kddi.com 693 Satoru Matsushima 694 Softbank Telecom Corp. 695 1-9-1, Higashi-Shimbashi, Minato-Ku 696 Tokyo 105-7322, JAPAN 697 Email: satoru.matsushima@g.softbank.co.jp