idnits 2.17.1 draft-yamaya-ipsecme-mpsa-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 544 has weird spacing: '...chieved by st...' -- The document date (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 126, but not defined == Missing Reference: 'IKEV2' is mentioned on line 235, but not defined == Missing Reference: 'Nonce' is mentioned on line 441, but not defined == Missing Reference: 'Lifetime' is mentioned on line 460, but not defined == Missing Reference: 'RolloverTime1' is mentioned on line 469, but not defined == Missing Reference: 'RolloverTime2' is mentioned on line 477, but not defined == Missing Reference: 'ENCAPS' is mentioned on line 583, 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 Summary: 2 errors (**), 0 flaws (~~), 10 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: January 4, 2014 NTT 6 T. Yamagata 7 KDDI 8 S. Matsushima 9 Softbank Telecom 10 July 4, 2014 12 Simple VPN solution using Multi-point Security Association 13 draft-yamaya-ipsecme-mpsa-04 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 9, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Conformance list . . . . . . . . . . . . . . . . . . . . . 6 65 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Sequence . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Extended format . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. Vendor ID . . . . . . . . . . . . . . . . . . . . . . 8 69 3.2.2. MPSA_PUT . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3. Multi-point SA Management . . . . . . . . . . . . . . . . 13 71 3.3.1. Gateway . . . . . . . . . . . . . . . . . . . . . . . 13 72 3.3.2. CPE . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 3.3.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 14 74 3.4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 14 75 4. Peer discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.1 example of MPSA with BGP for route based VPN . . . . . . . . 15 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 5.1. Protected by MPSA . . . . . . . . . . . . . . . . . . . . . 16 79 5.2 Security issues not to be solved by MPSA . . . . . . . . . . 16 80 5.2.1 Attack from outside of the group . . . . . . . . . . . . 16 81 5.2.2 Attack from inside of the group . . . . . . . . . . . . 16 83 5.3 Forward secrecy and backward secrecy . . . . . . . . . . . . 17 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 As described in the problem statement document [ad-vpn-problem], 93 dynamic, secure and scalable system for establishing SAs is needed. 95 With multi-point SA, an endpoint automatically discovers other 96 endpoint. In this draft, an endpoint means an inexpensive CPE, which 97 can hardly establish large number of IPsec sessions simultaneously. 98 The CPEs also share a multi-point SA within the same group, and there 99 is no individual connection between them. 101 Scalability issue becomes serious in the service, such as triple play 102 which requires large number of sessions at the same time. MPSA 103 enables large scale simultaneous sessions even with inexpensive CPEs, 104 and can avoid scalability issue. 106 The latency between CPEs can be minimized because of stateless shared 107 multipoint SA, MPSA is suitable for video and voice services which is 108 very sensitive to latency. 110 It can avoid the exhaustive configuration for CPEs and gateways. No 111 reconfiguration is needed when a new CPE is added, removed, or 112 changed. It can avoid high load on the gateways. 114 1.1. Terminology 116 Multi-point SA - This is similar to Dynamic Full Mesh topology 117 described in [ad-vpn-problem]; direct connections exist in a hub and 118 spoke manner, but only one SA for data transfer is shared with all 119 CPEs. 121 1.2. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Motivation 128 There are two major topologies - Star topology and full-mesh topology 129 - to communicate securely on over-lay network by using IPsec. 131 Figure.1 shows star topology. The number of IPsec connection is the 132 same as the number of CPEs (CPE). Authentication, Authorization and 133 Accounting (AAA) of each CPE can be achieved on the gateway. 135 The problem of the star topology is all the traffic go through the 136 gateway, then it causes high load and latency. 138 +---------------------------------------------+ 139 | IPsec Gateway | 140 | | 141 | +--------------(A<->C)--------------+ | 142 | | +---(A<->B)---+ +---(B<->C)---+ | | 143 +---:|-|:-----------:|---|:-----------:|-|:---+ 144 :| |: :| |: :| |: 145 :| |: :| |: :| |: 146 :| |: :| |: :| |: 147 +---:v-v:---+ :| |: +---:v-v:---+ 148 | | :| |: | | 149 | CPE_A | :| |: | CPE_C | 150 | | :| |: | | 151 +-----------+ +--:v---v:--+ +-----------+ 152 | | 153 | CPE_B | 154 | | 155 +-----------+ 157 Figure 1 159 Figure.2 shows Full-mesh topology. There is no gateways. Each CPE 160 establishes IPsec connection independently. The latency on this 161 topology is relatively low compared to star topology. 163 In large system, there are huge number ((N^2-N)/2) of IPsec 164 connections. AAA of each CPE is hard to manage in this topology. 165 Moreover, when a CPE is added, removed or changed, reconfiguration is 166 needed for all rest of the CPEs. 168 +-----------+ +-----------+ 169 | |.....................| | 170 | CPE_A <-------(A<->C)-------> CPE_C | 171 | |.....................| | 172 +---: ^ :---+ +---: ^ :---+ 173 : | : : | : 174 : | : +-----------+ : | : 175 : | :........| |........: | : 176 : +-(A<->B)--> CPE_B <--(B<->C)-+ : 177 :............| |............: 178 +-----------+ 180 Figure 2 182 The solution in this document eliminates the problems listed above. 183 Figure 3 shows topology of multi-point SA. Traffic between CPEs does 184 not go through the gateway, low latency, AAA of each CPE can be 185 achieved, the number of IPsec connection is almost same as star 186 topology, and no reconfiguration is needed for all the rest of CPEs 187 even when a CPE is added, removed or changed. 189 +---------------------------------------------+ 190 | IPsec Gateway | 191 | | 192 +---: | :------------: | :------------: | :---+ 193 : | : : | : : | : 194 : | : : | : : | : 195 ----------------------------------------- SA to distribute 196 : | : : | : : | : Multi-point SA 197 : | : : | : : | : 198 +---: v :---+ +---: v :---+ +---: v :---+ 199 | | | | | | 200 | CPE_A | | CPE_B | | CPE_C | 201 | | | | | | 202 +--- ^ ^ ---+ +--- ^ ^ ---+ +--- ^ ^ ---+ 203 .....| |..............| |..............| |..... 204 | | | | | | \ 205 | +----(A<->B)---+ +---(B<->C)----+ | Multi-point SA 206 +--------------(A<->C)--------------+ for data transfer 207 .............................................../ 209 Figure 3 211 2.1. Conformance list 212 This section describes the levels of conformance of the MPSA to the 213 requirement described in [ad-vpn-problem] section 4.1. As listed 214 below, almost all the requirement are covered in MPSA except (5) and 215 (8). 217 3. Procedure 219 3.1. Sequence 221 The multi-point SA capability of the remote host is determined by 222 an exchange of Vendor ID payloads. In the IKE_SA_INIT exchange, 223 the Vendor ID payload for this specification is sent if the multi- 224 point SA is used. 226 CPE Gateway 227 ----------- ----------- 228 HDR, SAi1, KEi, 229 Ni, V(MPSA) --> 230 <-- HDR, SAr1, KEr, 231 Nr, [CERTREQ,] V(MPSA) 233 MPSA: multi-point SA 235 The initial exchange (including IKE_AUTH) is same as [IKEV2], 236 other than Vendor ID payload included in IKE_SA_INIT. 238 After the initial exchange has finished successfully, a new 239 INFORMATIONAL exchange is used to distribute multi-point SA to the 240 CPE, with the Notify payload of MPSA_PUT that includes 241 cryptographic algorithm, nonce, keying material, SPI and so on. 242 Keys for multi-point SA is generated according to the contents of 243 the Notify payload by the CPE. The response of the Notify payload 244 has empty Encrypted payload. 246 CPE Gateway 247 ----------- ----------- 248 <-- HDR, SK {N(MPSA_PUT)} 249 HDR, SK {} --> 251 3.2. Extended format 253 3.2.1. Vendor ID 255 This document defines a new Vendor ID. The content of the payload 256 is described below. 258 "multi-point SA" 260 3.2.2. MPSA_PUT 262 This document defines a new Notify Message Type MPSA_PUT. The 263 Notify Message Type of MPSA_PUT is 40960. Notification Data of 264 MPSA_PUT has a Proposal-substructure-like format. It consists of 265 Transform-substructure-like structures that have following data. 267 Description Trans. Reference 268 Type 269 ------------------------------------------------------- 270 Encryption Algorithm (ENCR) 1 RFC5996 271 Pseudorandom Function (PRF) 2 RFC5996 272 Integrity Algorithm (INTEG) 3 RFC5996 273 Nonce (NONCE) 241 274 SK_d (SKD) 242 275 Lifetime (LIFE) 243 276 Rollover time 1 (ROLL1) 244 277 Rollover time 2 (ROLL2) 245 279 o Nonce - For Transform Type 241, the Transform ID is 1. The 280 attribute contains actual nonce value with attribute type 16384. 281 The size of the Nonce Data is between 16 and 256 octets. 283 Name Number 284 --------------------------------------------------- 285 NONCE_NONCE 1 287 Attribute Type Value Attribute Format 288 ------------------------------------------------------------ 289 Nonce Value 16384 TLV 291 o SK_d - For Transform Type 242, the Transform ID is 1. The 292 attribute contains actual SK_d value with attribute type 16385. 293 The length of SK_d Data is the preferred key length of the PRF. 295 Name Number 296 --------------------------------------------------- 297 SKD_SK_D 1 299 Attribute Type Value Attribute Format 300 ------------------------------------------------------------ 301 SK_d Value 16385 TLV 303 o Lifetime - For For Transform Type 243, the Transform ID is 1. The 304 attribute contains actual lifetime value with attribute type 305 16386. The length of Lifetime Value is 4 octets. Lifetime is 306 stored in seconds as effective time of the multi-point SA. 308 Name Number 309 --------------------------------------------------- 310 LIFE_LIFETIME 1 312 Attribute Type Value Attribute Format 313 ------------------------------------------------------------ 314 Lifetime Value 16386 TLV 316 o Rollover time 1 - For Transform Type 244, the Transform ID is 1. 317 The attribute contains actual rollover time 1 value with attribute 318 type 16387. The length of Rollover time 1 Value is 4 octets. 319 Rollover time 1 defines activation time delay for new outbound 320 multi-point SA. 322 Name Number 323 --------------------------------------------------- 324 ROLL1_ROLLOVER1 1 326 Attribute Type Value Attribute Format 327 ------------------------------------------------------------ 328 Rollover1 Value 16387 TLV 330 o Rollover time 2 - For Transform Type 245, the Transform ID is 1. 331 The attribute contains actual rollover time 2 value with attribute 332 type 16388. The length of Rollover time 2 Value is 4 octets. 333 Rollover time 2 defines deactivation time delay for old inbound 334 multi-point SA. 336 Name Number 337 --------------------------------------------------- 338 ROLL2_ROLLOVER2 1 340 Attribute Type Value Attribute Format 341 ------------------------------------------------------------ 342 Rollover2 Value 16388 TLV 344 Therefore, the format of the MPSA_PUT of the Notify Message is 345 described below. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Next Payload |C| RESERVED | Payload Length | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Protocol ID | SPI Size | Notify Message Type | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Security Parameter Index (SPI) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | 0 (last) or 2 | RESERVED | Proposal Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Security Parameter Index (SPI) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | 0 (last) or 3 | RESERVED | Transform Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |Transform Type | RESERVED | Transform ID | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 ~ Transform Attributes ~ 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | 0 (last) or 3 | RESERVED | Transform Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |Transform Type | RESERVED | Transform ID | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 ~ Transform Attributes ~ 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 ~ ~ 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | 0 | RESERVED | Transform Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |Transform Type | RESERVED | Transform ID | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 ~ Transform Attributes ~ 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 The following example shows a N(MPSA_PUT) notification message. The 392 SPIs in the Proposal-like and Tranform-like substructure are the same 393 value. Following values are defined by the example. 395 Protocol: ESP 396 ENCR: AES-CBC (256bits) 397 PRF: SHA-1 398 INTEG: HAMC-SHA-1-96 399 NONCE: 241 400 SKD: 242 401 LIFE: 243 402 ROLL1: 244 403 ROLL2: 245 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 /| 0 (last) |C| RESERVED | Payload Length | 409 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Notify | 3 (ESP) | SPI Size = 4 | MPSA_PUT | 411 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 \| Security Parameter Index (SPI) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 /| 0 (last) | RESERVED | Proposal Length | 415 Pro- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 posal-| Prop Num = 1 | 3 (ESP) | SPI Size = 4 |Num Transforms| 417 like +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 \| Security Parameter Index (SPI) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 /| 3 | RESERVED | Transform Length | 421 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 ENCR | 1 (ENCR) | RESERVED | 12 (ENCR_AES_CBC) | 423 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 \|1| 14 (Key Length) | 256 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 /| 3 | RESERVED | Transform Length | 427 PRF +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 \| 2 (PRF) | RESERVED | 2 (PRF_HMAC_SHA1) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 /| 3 | RESERVED | Transform Length | 431 INTEG +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 \| 3 (INTEG) | RESERVED | 2 (AUTH_HMAC_SHA1_96) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 /| 3 | RESERVED | Transform Length | 435 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 / | 241 (NONCE) | RESERVED | 1 | 437 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 NONCE |0| 16384 (Nonce) | Attribute Length | 439 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 \ | | 441 \ ~ [Nonce] ~ 442 \| | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 /| 3 | RESERVED | Transform Length | 445 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 / | 242 (SKD) | RESERVED | 1 | 447 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 SKD |0| 16385 (SK_d) | Attribute Length | 449 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 \ | | 451 \ ~ [SK_d] ~ 452 \| | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 /| 3 | RESERVED | Transform Length | 455 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 / | 243 (LIFE) | RESERVED | 1 | 457 LIFE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 \ |0| 16386 (Lifetime) | Attribute Length = 4 | 459 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 \| [Lifetime] | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 /| 3 | RESERVED | Transform Length | 463 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 / | 244 (ROLL1) | RESERVED | 1 | 466 ROLL1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 \ |0| 16386 (Lifetime) | Attribute Length = 4 | 468 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 \| [RolloverTime1] | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 /| 3 | RESERVED | Transform Length | 472 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 / | 245 (ROLL2) | RESERVED | 1 | 474 ROLL2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 \ |0| 16386 (Lifetime) | Attribute Length = 4 | 476 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 \| [RolloverTime2] | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 3.3. Multi-point SA Management 482 3.3.1. Gateway 484 Gateway generates a multi-point SA for a group before connecting to 485 any CPEs. 487 After the initial exchanges have finished, Gateway distributes the 488 same multi-point SA information to CPEs within the group by sending 489 N(MPSA_PUT). 491 SPI and Nonce is generated similar way of [IKEv2]. SK_d is generated 492 from random numbers similar to Nonce. 494 The same SPI value is stored to Notify payload and Proposal-like 495 substructure. 497 The multi-point SA will not be negotiated between gateway and CPE, 498 but will be notified from gateway to CPE one way. 500 Gateway initiates rekey before Lifetime expiration. As the Lifetime, 501 gateway notifies the effective time left of the multi-point SA. 503 3.3.2. CPE 504 After the initial exchange has finished, CPE obtains multi-point SA 505 information by receiving N(MPSA_PUT) from gateway. The keys for the 506 multi-point SA are generated in the same procedure described in 507 [IKEv2], except Ni | Nr is replaced by Nonce. 509 Therefore, KEYMAT is derived by PRF listed below. 511 KEYMAT = prf+(SK_d, Nonce) 513 The multi-point SA is protected in a cryptographic manner by ENCR and 514 INTEG which uses the generated keys. 516 The SPI value for the multi-point SA is the same of its in Notify 517 message. 519 CPE uses the same multi-point SA as both inbound and outbound SAs. 521 CPE deletes both of inbound and outbound SA when Lifetime is 522 expired. 524 Rollover time 1, 2 have no meaning when no old multi-point SA exists. 526 3.3.3. Rekeying 528 Rekeying should be finished before Lifetime expiration of current 529 multi-point SA. Rekeying of multi-point SA will be performed as 530 follows. 532 - Gateway generates a new multi-point SA 533 - Gateway distributes a new multi-point SA to all CPEs within the 534 group 535 - CPE replaces the current multi-point SA to new one 537 CPE replaces multi-point SA using rollover method like [GDOI]. 539 3.4. Forwarding 540 Each CPE sends and receives encapsulated packets using the multi- 541 point SA. 543 The destination address of encapsulated packet will be determined 544 with routing information, which can achieved by static configuration 545 or route exchange mechanism such as BGP on encapsulated environment 546 described in [MESH]. 548 It is applicable for any IPsec tunnels such as IPv4 over IPv4, IPv4 549 over IPv6, IPv6 over IPv4 and IPv6 over IPv6. 551 4. Peer discovery 553 MPSA does not provide peer discovery function by itself. However, 554 other mechanism, such as BGP, can be employed with MPSA for automatic 555 peer discovery. One example is a use of BGP, described in [MESH], to 556 learn peer information as next-hops. 558 4.1 example of MPSA with BGP for route based VPN 560 Between gateway and each peer, IKE_SA and CHILD_SA are established by 561 IKEv2. On the IKE_SA, an MPSA management message (MPSA_PUT) is served 562 from the gateway to the peer. 564 On the CHILD_SA, the gateway and the peer establish a iBGP session to 565 exchange route information (NLRIs). Gateway can act as a BGP route 566 reflector (RR), which can reflect NLRIs among all iBGP peers of the 567 gateway. In other words, the peer can learn all NLRIs advertised by 568 all other peers. 570 According to [ENCAPS], each peer can advertise ESP peer address as 571 well as conventional NLRIs, all of those can be reflected by RR on 572 the gateway. 574 At this point, each peer can have all other peer addresses as well as 575 route information. The peer can decide a peer address by mean of 576 recursive route lookup from the destination address of a packet to be 577 forwarded. This decision can be made by the peer itself, without any 578 additional communication with the gateway. 580 Instead of [ENCAPS], each peer can also do it by [RNH]. Each peer 581 learns all other peer addresses by BGP Remote-Next-Hop attributes and 582 decides a peer address from a packet to be forwarded, as same as 583 using [ENCAPS]. 585 5. Security Considerations 587 MPSA uses IKEv2 to protect MPSA management message, MPSA_PUT. Thus, 588 CPEs are authenticated by IKEv2. Using a shared SA for communication 589 between CPEs, MPSA does not provide the following features. 590 - Data origin authentication 591 - Anti-replay protection 593 MPSA itself does not provide access control for user datagrams, but 594 peer discovery may be able to provide access control as well as those 595 of route based VPN. For example, using BGP for peer discovery 596 described in 4.1, access control could be provided by filtering 597 exchanged routes at the gateway. In this case, filtering by source 598 address, protocol and ports can not be achieved. If you need it, you 599 could do by other security policy rules as local setting at CPEs . 601 5.1. Protected by MPSA 603 - Authenticating CPEs and gateway Authentication is provided by IKEv2 604 with pre-shared key or RSA signature. MPSA management messages are 605 exchanged after IKEv2 negotiation. 607 - Confidentiality and integrity Packets are encapsulated by ESP, so 608 that MPSA provides confidentiality and integrity against outside of 609 the group, but does not them against members of the group 611 5.2 Security issues not to be solved by MPSA 613 5.2.1 Attack from outside of the group 615 - Anti-replay protection 616 MPSA does not provide anti-replay protection, because sequence number 617 synchronization between peers needs additional mechanism. Using a 618 closed network as a transport might be effective to mitigate this 619 kind of attacks. 621 - Leaking a IKE_SA key 622 If an attacker could sniff packets on a IKE_SA, and key of the SA 623 were leaked, the attacker may get a key of MPSA by decoding a sniffed 624 MPSA_PUT message. 626 5.2.2 Attack from inside of the group 628 If there is a malicious CPE or a CPE is hijacked by an attacker, MPSA 629 can be attacked in the following way because MPSA, including 630 cryptograghic key, is shared by all CPEs. 632 - An attacker can impersonate another CPE. A closed network that 633 prohibits source address spoofing could mitigate the impersonating. 635 - An attacker can decode packets between the other CPEs if the attacker 636 could sniff packets. 638 5.3 Forward secrecy and backward secrecy 640 MPSA MAY be rekeyed when a CPE is removed from the group, for the 641 removed CPE not to access the other CPEs communication after that, or 642 when a CPE is added from the group, for it not to do before that. If 643 not rekeyed, a removed/added CPE could access 645 5. IANA Considerations 647 This memo includes no request to IANA. 649 6. References 651 6.1. Normative References 653 [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 654 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 655 September 2010. 656 6.2. Informative References 658 [GDOI] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 659 Interpretation", RFC 6407, October 2011. 661 [MESH] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 662 Framework", RFC 5565, June 2009. 664 [ad-vpn-problem] Manral, V. and S. Hanna, "Auto-Discovery VPN Problem 665 Statement and Requirements", RFC 7018, September 2013. 667 [RNH] Van de Velde, G., Patel, K., Rao, D., Raszuk, R., and Bush, R., 668 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 669 hop-07, June 2014 671 Authors' Addresses 673 Arifumi Yamaya 674 Furukawa Network Solution Corp. 675 5-1-9, Higashi-Yawata, Hiratsuka 676 Kanagawa 254-0016, JAPAN 677 Email: yamaya@fnsc.co.jp 679 Takafumi Ohya 680 NTT Corporation 681 Nishi-shinjuku, Shinjuku-ku, 682 Tokyo 163-8019, JAPAN 683 Email: takafumi.ooya@hco.ntt.co.jp 685 Tomohiro Yamagata 686 KDDI Corporation 687 Garden Air Tower 688 Iidabashi, Chiyoda-ku, 689 Tokyo 102-8460, JAPAN 690 Email: to-yamagata@kddi.com 692 Satoru Matsushima 693 Softbank Telecom Corp. 694 1-9-1, Higashi-Shimbashi, Minato-Ku 695 Tokyo 105-7322, JAPAN 696 Email: satoru.matsushima@g.softbank.co.jp