IPSecME Working Group A. Yamaya
Internet-Draft K. Ueki
Intended Status: Informational T. Murai
Expires: January 30, 2014 Furukawa Network Solution
T. Ohya
NTT
T. Yamagata
KDDI
July 30, 2013
Simple VPN solution using Multi-point Security Association
draft-yamaya-ipsecme-mpsa-02
Abstract
This document describes the over-lay network solution by utilizing
dynamically established IPsec multi-point Security Association (SA)
without individual connection.
Multi-point SA technology provides the simplified mechanism of the
Auto Discovery and Configuration function. This is applicable for
any IPsec tunnels such as IPv4 over IPv4, IPv4 over IPv6, IPv6 over
IPv4 and IPv6 over IPv6.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 30, 2014.
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
A. Yamaya Expires January 30, 2014 [Page 1]
Internet-Draft Multi-Point SA July 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conformance list . . . . . . . . . . . . . . . . . . . . . 5
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Sequence . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Extended format . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Vendor ID . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. MPSA_PUT . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Multi-point SA Management . . . . . . . . . . . . . . . . 11
3.3.1. Gateway . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. CPE . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
A. Yamaya Expires January 30, 2014 [Page 2]
Internet-Draft Multi-Point SA July 2013
1. Introduction
As described in the problem statement document [ad-vpn-problem],
dynamic, secure and scalable system for establishing SAs is needed.
With multi-point SA, an endpoint automatically discovers other
endpoint. In this draft, an endpoint means an inexpensive CPE, which
can hardly establish large number of IPsec sessions simultaneously.
The CPEs also share a multi-point SA within the same group, and there
is no individual connection between them.
Scalability issue becomes serious in the service, such as triple play
which requires large number of sessions at the same time. MPSA
enables large scale simultaneous sessions even with inexpensive CPEs,
and can avoid scalability issue.
The latency between CPEs can be minimized because of stateless shared
multipoint SA, MPSA is suitable for video and voice services which is
very sensitive to latency.
It can avoid the exhaustive configuration for CPEs and gateways. No
reconfiguration is needed when a new CPE is added, removed, or
changed. It can avoid high load on the gateways.
1.1. Terminology
Multi-point SA - This is similar to Dynamic Full Mesh topology
described in [ad-vpn-problem]; direct connections exist in a hub and
spoke manner, but only one SA for data transfer is shared with all
CPEs.
1.2. Conventions Used in This Document
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].
2. Motivation
There are two major topologies - Star topology and full-mesh topology
- to communicate securely on over-lay network by using IPsec.
Figure.1 shows star topology. The number of IPsec connection is the
same as the number of CPEs (CPE). Authentication, Authorization and
Accounting (AAA) of each CPE can be achieved on the gateway.
The problem of the star topology is all the traffic go through the
gateway, then it causes high load and latency.
A. Yamaya Expires January 30, 2014 [Page 3]
Internet-Draft Multi-Point SA July 2013
+---------------------------------------------+
| IPsec Gateway |
| |
| +--------------(A<->C)--------------+ |
| | +---(A<->B)---+ +---(B<->C)---+ | |
+---:|-|:-----------:|---|:-----------:|-|:---+
:| |: :| |: :| |:
:| |: :| |: :| |:
:| |: :| |: :| |:
+---:v-v:---+ :| |: +---:v-v:---+
| | :| |: | |
| CPE_A | :| |: | CPE_C |
| | :| |: | |
+-----------+ +--:v---v:--+ +-----------+
| |
| CPE_B |
| |
+-----------+
Figure 1
Figure.2 shows Full-mesh topology. There is no gateways. Each CPE
establishes IPsec connection independently. The latency on this
topology is relatively low compared to star topology.
In large system, there are huge number ((N^2-N)/2) of IPsec
connections. AAA of each CPE is hard to manage in this topology.
Moreover, when a CPE is added, removed or changed, reconfiguration is
needed for all rest of the CPEs.
+-----------+ +-----------+
| |.....................| |
| CPE_A <-------(A<->C)-------> CPE_C |
| |.....................| |
+---: ^ :---+ +---: ^ :---+
: | : : | :
: | : +-----------+ : | :
: | :........| |........: | :
: +-(A<->B)--> CPE_B <--(B<->C)-+ :
:............| |............:
+-----------+
Figure 2
The solution in this document eliminates the problems listed above.
Figure 3 shows topology of multi-point SA. Traffic between CPEs does
not go through the gateway, low latency, AAA of each CPE can be
achieved, the number of IPsec connection is almost same as star
A. Yamaya Expires January 30, 2014 [Page 4]
Internet-Draft Multi-Point SA July 2013
topology, and no reconfiguration is needed for all the rest of CPEs
even when a CPE is added, removed or changed.
+---------------------------------------------+
| IPsec Gateway |
| |
+---: | :------------: | :------------: | :---+
: | : : | : : | :
: | : : | : : | :
----------------------------------------- SA to distribute
: | : : | : : | : Multi-point SA
: | : : | : : | :
+---: v :---+ +---: v :---+ +---: v :---+
| | | | | |
| CPE_A | | CPE_B | | CPE_C |
| | | | | |
+--- ^ ^ ---+ +--- ^ ^ ---+ +--- ^ ^ ---+
.....| |..............| |..............| |.....
| | | | | | \
| +----(A<->B)---+ +---(B<->C)----+ | Multi-point SA
+--------------(A<->C)--------------+ for data transfer
.............................................../
Figure 3
2.1. Conformance list
This section describes the levels of conformance of the MPSA to the
requirement described in [ad-vpn-problem] section 4.1. As listed
below, almost all the requirement are covered in MPSA except (5) and
(8).
(1)Yes: With MPSA, gateways and CPEs can minimize configuration
changes when a new gateway or CPE is added, removed or changed.
The topology changes need not require configuration changes in
other CPEs.
(2)Yes: MPSA peers can allow IPsec Tunnels to be setup with other
members of the MPSA without any configuration changes, even when
peer addresses get updated every time the device comes up.
(3)Yes: With MPSA, gateways can allow for the operation of tunneling
and Routing protocols operating over CPE-to-CPE IPsec Tunnels with
minimal or no, configuration impact.
(4)Yes: In the full mesh and dynamic full mesh topology, CPEs can
allow for direct communication with other CPE gateways and CPEs.
In the star topology mode, direct communication between CPEs can
be disallowed.
(5)Yes/No: MPSA compromises the requirement of the description of
"Any of the ADVPN Peers MUST NOT have a way to get the long term
A. Yamaya Expires January 30, 2014 [Page 5]
Internet-Draft Multi-Point SA July 2013
authentication credentials for any other ADVPN Peers.", but does
not satisfy the requirement of the description of "The compromise
of an Endpoint MUST NOT affect the security of communications
between other ADVPN Peers." because of the shared SA.
(6)Yes: With MPSA, gateways can allow for seamless handoff of
sessions in case CPEs are roaming.
(7)Yes: Gateways allow for easy handoff of a session to another
gateway.
(8)No: Currently, MPSA does not allow the communications behind the
NAT boxes.
(9)Yes: Changes such as establishing a new IPsec SA can be reportable
and manageable.
(10)Yes: CPEs and gateways from different organizations SHOULD be
able to connect to each other.
(11)Yes: The administrator of the MPSA can allow which tunnels are
allowed to be setup.
(12)Yes: The MPSA solution is able to scale for multicast traffic.
(13)Yes: The MPSA solution allows for easy monitoring, logging and
reporting of the dynamic changes.
(14)Yes: MPSA supports L3VPN as an application protected by the IPsec
Tunnels.
(15)Yes: MPSA solution allows the enforcement of per peer QoS.
3. Procedure
3.1. Sequence
The multi-point SA capability of the remote host is determined by an
exchange of Vendor ID payloads. In the IKE_SA_INIT exchange, the
Vendor ID payload for this specification is sent if the multi-point
SA is used.
CPE Gateway
----------- -----------
HDR, SAi1, KEi,
Ni, V(MPSA) -->
<-- HDR, SAr1, KEr,
Nr, [CERTREQ,] V(MPSA)
MPSA: multi-point SA
The initial exchange (including IKE_AUTH) is same as [IKEV2], other
than Vendor ID payload included in IKE_SA_INIT.
After the initial exchange has finished successfully, a new
INFORMATIONAL exchange is used to distribute multi-point SA to the
CPE, with the Notify payload of MPSA_PUT that includes cryptographic
algorithm, nonce, keying material, SPI and so on. Keys for multi-
A. Yamaya Expires January 30, 2014 [Page 6]
Internet-Draft Multi-Point SA July 2013
point SA is generated according to the contents of the Notify payload
by the CPE. The response of the Notify payload has empty Encrypted
payload.
CPE Gateway
----------- -----------
<-- HDR, SK {N(MPSA_PUT)}
HDR, SK {} -->
3.2. Extended format
3.2.1. Vendor ID
This document defines a new Vendor ID. The content of the payload is
described below.
"multi-point SA"
3.2.2. MPSA_PUT
This document defines a new Notify Message Type MPSA_PUT. The Notify
Message Type of MPSA_PUT is 40960. Notification Data of MPSA_PUT has
a Proposal-substructure-like format. It consists of Transform-
substructure-like structures that have following data.
Description Trans. Reference
Type
-------------------------------------------------------
Encryption Algorithm (ENCR) 1 RFC5996
Pseudorandom Function (PRF) 2 RFC5996
Integrity Algorithm (INTEG) 3 RFC5996
Nonce (NONCE) 241
SK_d (SKD) 242
Lifetime (LIFE) 243
Rollover time 1 (ROLL1) 244
Rollover time 2 (ROLL2) 245
o Nonce - For Transform Type 241, the Transform ID is 1. The
attribute contains actual nonce value with attribute type 16384.
The size of the Nonce Data is between 16 and 256 octets.
Name Number
---------------------------------------------------
NONCE_NONCE 1
Attribute Type Value Attribute Format
------------------------------------------------------------
Nonce Value 16384 TLV
A. Yamaya Expires January 30, 2014 [Page 7]
Internet-Draft Multi-Point SA July 2013
o SK_d - For Transform Type 242, the Transform ID is 1. The
attribute contains actual SK_d value with attribute type 16385.
The length of SK_d Data is the preferred key length of the PRF.
Name Number
---------------------------------------------------
SKD_SK_D 1
Attribute Type Value Attribute Format
------------------------------------------------------------
SK_d Value 16385 TLV
o Lifetime - For For Transform Type 243, the Transform ID is 1. The
attribute contains actual lifetime value with attribute type
16386. The length of Lifetime Value is 4 octets. Lifetime is
stored in seconds as effective time of the multi-point SA.
Name Number
---------------------------------------------------
LIFE_LIFETIME 1
Attribute Type Value Attribute Format
------------------------------------------------------------
Lifetime Value 16386 TLV
o Rollover time 1 - For Transform Type 244, the Transform ID is 1.
The attribute contains actual rollover time 1 value with attribute
type 16387. The length of Rollover time 1 Value is 4 octets.
Rollover time 1 defines activation time delay for new outbound
multi-point SA.
Name Number
---------------------------------------------------
ROLL1_ROLLOVER1 1
Attribute Type Value Attribute Format
------------------------------------------------------------
Rollover1 Value 16387 TLV
o Rollover time 2 - For Transform Type 245, the Transform ID is 1.
The attribute contains actual rollover time 2 value with attribute
type 16388. The length of Rollover time 2 Value is 4 octets.
Rollover time 2 defines deactivation time delay for old inbound
multi-point SA.
Name Number
---------------------------------------------------
ROLL2_ROLLOVER2 1
A. Yamaya Expires January 30, 2014 [Page 8]
Internet-Draft Multi-Point SA July 2013
Attribute Type Value Attribute Format
------------------------------------------------------------
Rollover2 Value 16388 TLV
Therefore, the format of the MPSA_PUT of the Notify Message is
described below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
A. Yamaya Expires January 30, 2014 [Page 9]
Internet-Draft Multi-Point SA July 2013
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following example shows a N(MPSA_PUT) notification message. The
SPIs in the Proposal-like and Tranform-like substructure are the same
value. Following values are defined by the example.
Protocol: ESP
ENCR: AES-CBC (256bits)
PRF: SHA-1
INTEG: HAMC-SHA-1-96
NONCE: 241
SKD: 242
LIFE: 243
ROLL1: 244
ROLL2: 245
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 (last) |C| RESERVED | Payload Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notify | 3 (ESP) | SPI Size = 4 | MPSA_PUT |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 0 (last) | RESERVED | Proposal Length |
Pro- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
posal-| Prop Num = 1 | 3 (ESP) | SPI Size = 4 |Num Transforms|
like +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ENCR | 1 (ENCR) | RESERVED | 12 (ENCR_AES_CBC) |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\|1| 14 (Key Length) | 256 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
PRF +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\| 2 (PRF) | RESERVED | 2 (PRF_HMAC_SHA1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
INTEG +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\| 3 (INTEG) | RESERVED | 2 (AUTH_HMAC_SHA1_96) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A. Yamaya Expires January 30, 2014 [Page 10]
Internet-Draft Multi-Point SA July 2013
/ | 241 (NONCE) | RESERVED | 1 |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NONCE |0| 16384 (Nonce) | Attribute Length |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | |
\ ~ [Nonce] ~
\| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | 242 (SKD) | RESERVED | 1 |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SKD |0| 16385 (SK_d) | Attribute Length |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | |
\ ~ [SK_d] ~
\| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | 243 (LIFE) | RESERVED | 1 |
LIFE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ |0| 16386 (Lifetime) | Attribute Length = 4 |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\| [Lifetime] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | 244 (ROLL1) | RESERVED | 1 |
ROLL1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ |0| 16386 (Lifetime) | Attribute Length = 4 |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\| [RolloverTime1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| 3 | RESERVED | Transform Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | 245 (ROLL2) | RESERVED | 1 |
ROLL2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ |0| 16386 (Lifetime) | Attribute Length = 4 |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\| [RolloverTime2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3. Multi-point SA Management
3.3.1. Gateway
Gateway generates a multi-point SA for a group before connecting to
A. Yamaya Expires January 30, 2014 [Page 11]
Internet-Draft Multi-Point SA July 2013
any CPEs.
After the initial exchanges have finished, Gateway distributes the
same multi-point SA information to CPEs within the group by sending
N(MPSA_PUT).
SPI and Nonce is generated similar way of [IKEv2]. SK_d is generated
from random numbers similar to Nonce.
The same SPI value is stored to Notify payload and Proposal-like
substructure.
The multi-point SA will not be negotiated between gateway and CPE,
but will be notified from gateway to CPE one way.
Gateway initiates rekey before Lifetime expiration. As the Lifetime,
gateway notifies the effective time left of the multi-point SA.
3.3.2. CPE
After the initial exchange has finished, CPE obtains multi-point SA
information by receiving N(MPSA_PUT) from gateway. The keys for the
multi-point SA are generated in the same procedure described in
[IKEv2], except Ni | Nr is replaced by Nonce.
Therefore, KEYMAT is derived by PRF listed below.
KEYMAT = prf+(SK_d, Nonce)
The multi-point SA is protected in a cryptographic manner by ENCR and
INTEG which uses the generated keys.
The SPI value for the multi-point SA is the same of its in Notify
message.
CPE uses the same multi-point SA as both inbound and outbound SAs.
CPE deletes both of inbound and outbound SA when Lifetime is
expired.
Rollover time 1, 2 have no meaning when no old multi-point SA exists.
3.3.3. Rekeying
Rekeying should be finished before Lifetime expiration of current
multi-point SA. Rekeying of multi-point SA will be performed as
follows.
A. Yamaya Expires January 30, 2014 [Page 12]
Internet-Draft Multi-Point SA July 2013
- Gateway generates a new multi-point SA
- Gateway distributes a new multi-point SA to all CPEs within the
group
- CPE replaces the current multi-point SA to new one
CPE replaces multi-point SA using rollover method like [GDOI].
3.4. Forwarding
Each CPE sends and receives encapsulated packets using the multi-
point SA.
The destination address of encapsulated packet will be determined
with routing information, which can achieved by static configuration
or route exchange mechanism such as BGP on encapsulated environment
described in [MESH].
It is applicable for any IPsec tunnels such as IPv4 over IPv4, IPv4
over IPv6, IPv6 over IPv4 and IPv6 over IPv6.
4. Security Considerations
5. IANA Considerations
This memo includes no request to IANA.
6. References
6.1. Normative References
[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
6.2. Informative References
[GDOI] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
[MESH] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[ad-vpn-problem] Hanna, S., and V. Manral, "Auto Discovery VPN
Problem Statement and Requirements" draft-ietf-ipsecme-ad-
vpn-problem-03 (work in progress), December 17, 2012
Authors' Addresses
A. Yamaya Expires January 30, 2014 [Page 13]
Internet-Draft Multi-Point SA July 2013
Arifumi Yamaya
Furukawa Network Solution Corp.
5-1-9, Higashi-Yawata, Hiratsuka
Kanagawa 254-0016, JAPAN
Email: yamaya@fnsc.co.jp
Ken Ueki
Furukawa Network Solution Corp.
5-1-9, Higashi-Yawata, Hiratsuka
Kanagawa 254-0016, JAPAN
Email: ueki@fnsc.co.jp
Tomoki Murai
Furukawa Network Solution Corp.
5-1-9, Higashi-Yawata, Hiratsuka
Kanagawa 254-0016, JAPAN
Email: murai@fnsc.co.jp
Takafumi Ohya
NTT West Corporation
1-2-31, Sonezaki Kita-Ku
Osaka 530-0057, JAPAN
Email: t.ohya@rdc.west.ntt.co.jp
Tomohiro Yamagata
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: to-yamagata@kddi.com
A. Yamaya Expires January 30, 2014 [Page 14]