Network Working Group T. Brunner
Internet-Draft University of Applied Sciences,
Intended status: Experimental Rapperswil
Expires: October 18, 2008 April 16, 2008
IKEv2 Mediation Extension
draft-brunner-ikev2-mediation-00
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 18, 2008.
Abstract
This document describes the IKEv2 Mediation Extension (IKE-ME), a
connectivity extension to the Internet Key Exchange IKEv2. IKE-ME
allows two peers, each behind one or more Network Address Translators
(NATs) or firewalls to establish a direct and secure connection
without the need to configure any of the intermediate network
devices. To establish this direct connection, a process similar to
Interactive Connectivity Establishment (ICE) is used.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Notation . . . . . . . . . . . . . . . . . 4
Brunner Expires October 18, 2008 [Page 1]
Internet-Draft IKE-ME April 2008
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 7
3. Mediation Connection . . . . . . . . . . . . . . . . . . . . . 11
3.1. Initial IKE Exchanges . . . . . . . . . . . . . . . . . . 11
3.2. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . 12
3.3. Obtaining Endpoints . . . . . . . . . . . . . . . . . . . 12
3.3.1. Host Endpoints . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Server Reflexive and Relayed Endpoints . . . . . . . . 12
3.3.2.1. Considerations Concerning TURN . . . . . . . . . . 13
3.3.2.2. Obtaining Server Reflexive Endpoints from
Mediation Servers . . . . . . . . . . . . . . . . 13
3.3.3. Peer Reflexive Endpoints . . . . . . . . . . . . . . . 14
3.3.4. The Base of Local Endpoints . . . . . . . . . . . . . 14
3.3.5. Prioritizing Endpoints . . . . . . . . . . . . . . . . 14
3.3.5.1. Recommended Formula . . . . . . . . . . . . . . . 15
3.3.6. Guidelines for Choosing Type and IP Address
Preferences . . . . . . . . . . . . . . . . . . . . . 15
3.3.7. Eliminating Redundant Endpoints . . . . . . . . . . . 16
3.4. Initiating a Connection . . . . . . . . . . . . . . . . . 16
3.4.1. ME_CONNECT Exchange . . . . . . . . . . . . . . . . . 16
3.4.2. Receiving a ME_CONNECT Request . . . . . . . . . . . . 18
3.4.3. Receiving a ME_CONNECT Response . . . . . . . . . . . 19
3.4.4. Timeout for the Overall Transaction . . . . . . . . . 19
4. Building Endpoint Pairs . . . . . . . . . . . . . . . . . . . 19
5. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 20
5.1. Forming Connectivity Checks . . . . . . . . . . . . . . . 22
5.1.1. ME_CONNECTAUTH . . . . . . . . . . . . . . . . . . . . 22
5.2. Responding to Connectivity Checks . . . . . . . . . . . . 23
5.3. Processing Connectivity Checks . . . . . . . . . . . . . . 26
5.3.1. Failure Cases . . . . . . . . . . . . . . . . . . . . 26
5.3.2. Success Cases . . . . . . . . . . . . . . . . . . . . 26
5.3.3. Stopping the Checks and Selecting the Endpoints . . . 27
6. Mediated Connection . . . . . . . . . . . . . . . . . . . . . 27
6.1. Initiating the Mediated Connection . . . . . . . . . . . . 27
7. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Identification Payload - Peer Identity . . . . . . . . . . 28
7.2. Notify Messages - Error Types . . . . . . . . . . . . . . 28
7.2.1. ME_CONNECT_FAILED Notify Payload . . . . . . . . . . . 28
7.3. Notify Messages - Status Types . . . . . . . . . . . . . . 28
7.3.1. ME_MEDIATION Notify Payload . . . . . . . . . . . . . 28
7.3.2. ME_ENDPOINT Notify Payloads . . . . . . . . . . . . . 28
7.3.3. ME_CALLBACK Notify Payload . . . . . . . . . . . . . . 29
7.3.4. ME_CONNECTID Notify Payload . . . . . . . . . . . . . 30
7.3.5. ME_CONNECTKEY Notify Payload . . . . . . . . . . . . . 30
7.3.6. ME_CONNECTAUTH Notify Payload . . . . . . . . . . . . 30
7.3.7. ME_RESPONSE Notify Payload . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
Brunner Expires October 18, 2008 [Page 2]
Internet-Draft IKE-ME April 2008
8.1. Trusting the Mediation Servers . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 33
A.1. Is the second ME_CONNECTKEY required? . . . . . . . . . . 33
A.2. Different NAT, Same Subnet . . . . . . . . . . . . . . . . 34
A.3. Relaying Provided by the Mediation Server . . . . . . . . 34
A.4. Compatibility/Synergy with MOBIKE . . . . . . . . . . . . 34
Appendix B. Design Decisions . . . . . . . . . . . . . . . . . . 34
B.1. Two exchanges between mediation server and second peer . . 34
B.2. Why the ME_RESPONSE Notify payload is needed . . . . . . . 34
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . . 35
C.1. Changes from -.3 to -00 . . . . . . . . . . . . . . . . . 35
C.2. Changes from -.2 to -.3 . . . . . . . . . . . . . . . . . 35
C.3. Changes from -.1 to -.2 . . . . . . . . . . . . . . . . . 35
C.4. Changes from -.0 to -.1 . . . . . . . . . . . . . . . . . 35
Brunner Expires October 18, 2008 [Page 3]
Internet-Draft IKE-ME April 2008
1. Introduction
IKEv2 [RFC4306] inherently supports the traversal of Network Address
Translators (NATs) by doing automatic NAT discovery during the IPsec
connection setup. If a NAT situation is detected, IKE floats to UDP
source and destination ports 4500 and after a CHILD_SA has been
successfully established, ESP packets encapsulated in UDP datagrams
[RFC3948] will share the same floated ports. While both IPsec and
IKEv2 are peer-to-peer protocols by their nature, NATs and firewalls
often restrict these protocols to a unidirectional mode where only
the peer on the inside is able to actively set up a connection. If
both peers are hidden by NATs or firewalls, the IKEv2 protocol
usually fails to establish IPsec connectivity.
In the area of multimedia communications the Interactive Connectivity
Establishment protocol [I-D.ietf-mmusic-ice] has been developed to
solve the NAT and firewall problems mentioned above. Unfortunately
the proposed solution is rather closely bound to the Session
Initiation Protocol (SIP) and Session Description Protocol (SDP), and
generally tends to solve problems specific to voice and/or video
media streams.
The IKEv2 Mediation Extension (IKE-ME) adapts the connectivity
establishment methods known from ICE to the IPsec domain, allowing
secure IP connections to be established in environments with multiple
NATs or firewalls.
The IKEv2 Mediation Extension protocol uses a mediation server to
locate other peers and allows them to exchange their communication
endpoints. It implements an ICE-like mechanism with a minimum impact
on the standard IKEv2 protocol. IKEv2 exchanges are used for
communication between peers and the mediation server to simplify
implementation in existing IKEv2 products.
1.1. Terminology and Notation
The following terms are used throughout this document:
Peer
A peer is an IKEv2 host that supports the protocol defined in
this document and wants to establish a direct connection with
another peer.
Mediation Server
A server is an IKEv2 host that helps peers to establish a
direct connection between them. The server has to be reachable
Brunner Expires October 18, 2008 [Page 4]
Internet-Draft IKE-ME April 2008
by all peers involved in the mediation scheme.
Transport Address
A transport address is the combination of an IP address, a
transport protocol (limited to UDP in this specification), and
a port number.
Endpoint
An endpoint is a transport address that is obtained in order to
be used in a direct connection. In addition to a plain
transport address it has a type, a priority, and a base. The
term endpoint may also be used to simply indicate the end of a
connection. The actual meaning should be clear from the
context.
Host Endpoint
An endpoint directly obtained from a local interface.
Server Reflexive Endpoint
Server reflexive endpoints are endpoints allocated on a NAT and
are learned by a method such as Session Traversal Utilities for
NAT (STUN).
Relayed Endpoint
Relayed endpoints are like remote host endpoints. Traversal
Using Relays around NAT (TURN) is a possible source for relayed
endpoints.
Peer Reflexive Endpoint
Peer reflexive endpoints are learned during connectivity
checks. See Section 5 for how this is done.
Base
The base of an endpoint is the transport address from which
messages are actually sent. For instance, a peer cannot send
messages directly from a server reflexive endpoint which it got
allocated on a NAT, but only from the host endpoint from which
it obtained the server reflexive endpoint. See Section 3.3 for
details.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Brunner Expires October 18, 2008 [Page 5]
Internet-Draft IKE-ME April 2008
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Protocol Overview
2.1. Basic Operation
In order to establish a direct connection between them, two peers
need to connect to a mediation server first. The mediation server is
required to forward the endpoints on which a peer is potentially
reachable by another peer. Figure 1 provides a general overview of
the most common situation. Peer 1 and Peer 2 want to establish a
secure direct connection between them. Since both are behind a NAT
they cannot reach one another directly - they most likely don't even
know where to try. This is where the mediation server comes into
play. It helps to locate other peers and to exchange endpoints over
which a peer may be reachable.
+-------------+
| Mediation |
| Server |
+--+-------+--+
| |
Mediation Connection | | Mediation Connection
+---------------+ +---------------+
| |
+ +-----------------------------------+ +
|/ Mediated Connection \|
+-----+-----+ +-----+-----+
| NAT 1 | | NAT 2 |
+-----+-----+ +-----+-----+
| |
+-----+-----+ Secure Connection +-----------+
| Peer 1 |===========================| Peer 2 |
+-----------+ +-----------+
Figure 1: Overview
Each peer registers itself with the mediation server in order to
announce its online presence. It does so by setting up an IKE_SA
including special mediation payloads. No CHILD_SA is established
between a peer and the mediation server because there is no need to
exchange any encrypted IP payloads.
Before a peer can connect to other peers it has to collect a number
of endpoints on which it is potentially reachable by other hosts. To
Brunner Expires October 18, 2008 [Page 6]
Internet-Draft IKE-ME April 2008
obtain endpoints an arbitrary method can be used. For instance, STUN
might be used to learn server reflexive endpoints and TURN could be
used to obtain a relayed endpoint. A client may also request a
server reflexive endpoint from the mediation server. By connecting
to the mediation server, the peer automatically gets transport
addresses allocated on the intermediate NATs. The transport address
on the NAT nearest to the mediation server is the source from which
the mediation server receives the messages from the peer. This
transport address can be requested from the mediation server and
provides a server reflexive endpoint.
If a peer requests a connection to another peer that is already
registered, the mediation server acts as a relay to allow the peers
to exchange their endpoints.
Each peer then performs connectivity checks on all available endpoint
pairs constructed by combining its own with the received endpoints.
After all path combinations have been probed and the best suited
endpoint pair has been elected, the initiating peer then goes on to
set up an IKE_SA using the standard IKEv2 protocol and including at
least one request for a CHILD_SA.
The protocol is designed to establish connectivity between peers in
any network topology. As local endpoints are included in the checks,
peers in the same (private) network can establish a connection
directly. Depending on the NAT implementation, the used hole
punching mechanism may not work. If both NAT are too restrictive, a
relayed endpoint may be used to establish an IKE_SA between the
peers.
2.2. Example Protocol Exchanges
This section illustrates some example protocol exchanges. The
notation is based on [RFC4306], Section 1.2. In addition, the
source/destination IP addresses and ports are shown for each packet:
here IP_P1, IP_P2, and IP_MS represent IP addresses used by the two
peers and the mediation server, respectively. Referring to Figure 1,
the two peers are each located behind a NAT. Thus, the modifications
on outgoing packets, as performed by the NATs, are also shown. At
this, IP_N1 and IP_N2 denote the public addresses of the NATs.
In a first step, Peer 1 connects to the mediation server starting
with an IKE_SA_INIT exchange.
Brunner Expires October 18, 2008 [Page 7]
Internet-Draft IKE-ME April 2008
Initiator Responder
----------- -----------
1) IP_P1:500 -> IP_MS:500
\--> IP_N1:1201 -> IP_MS:500
HDR, SAi1, KEi, Ni,
N(ME_MEDIATION),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
IP_MS:500 -> IP_N1:1201
<-- HDR, SAr1, KEr, Nr,
N(ME_MEDIATION),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
[,CERTREQ]
The IKEv2 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
Notify payloads are used to detect if there is any NAT between the
peer and the mediation server. The new ME_MEDIATION Notify payload
announces the request for a mediation connection. As mentioned
above, we assume that both peers are behind a NAT. Therefore Peer 1
floats to UDP port 4500 before continuing with a modified IKE_AUTH
exchange that does not contain a CHILD_SA proposal.
2) IP_P1:4500 -> IP_MS:4500
\--> IP_N1:1202 -> IP_MS:4500
HDR, SK { IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, N(ME_ENDPOINT) } -->
IP_MS:4500 -> IP_N1:1202
<-- HDR, SK { IDr, [CERT,] AUTH,
N(ME_ENDPOINT) }
The peer uses the new ME_ENDPOINT Notify payload to request a server
reflexive endpoint from the mediation server. After this exchange
Peer 1 is connected to the mediation server and thus available for
mediation with any other peer, as well as eligible to request a
mediated connection itself. Peer 2 connects to the mediation server
using the same procedure.
Brunner Expires October 18, 2008 [Page 8]
Internet-Draft IKE-ME April 2008
3) IP_P2:500 -> IP_MS:500
\--> IP_N2:1024 -> IP_MS:500
HDR, SAi1, KEi, Ni,
N(ME_MEDIATION),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
IP_MS:500 -> IP_N2:1024
<-- HDR, SAr1, KEr, Nr,
N(ME_MEDIATION),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
[,CERTREQ]
4) IP_P2:4500 -> IP_MS:4500
\--> IP_N2:1025 -> IP_MS:4500
HDR, SK { IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, N(ME_ENDPOINT) } -->
IP_MS:4500 -> IP_N2:1025
<-- HDR, SK { IDr, [CERT,] AUTH,
N(ME_ENDPOINT) }
A direct connection is initiated by Peer 1 with the transmission of a
ME_CONNECT request to the mediation server. Peers are identified by
the ID with which they authenticate against the mediation server.
So, this request includes the ID of the other peer, denoted IDp2, and
several endpoints on which Peer 1 is potentially reachable by the
other peer. Also included are a randomly generated ID and a randomly
generated key that are mainly used for the ensuing connectivity
checks.
5) IP_P1:4500 -> IP_MS:4500
\--> IP_N1:1202 -> IP_MS:4500
HDR, SK { IDp2, N(ME_CONNECTID), N(ME_CONNECTKEY),
N(ME_ENDPOINT), N(ME_ENDPOINT) } -->
IP_MS:4500 -> IP_N1:1202
<-- HDR, SK {}
The mediation server relays this ME_CONNECT request to the other
peer, but replaces the IDp payload with the ID of Peer 1.
Brunner Expires October 18, 2008 [Page 9]
Internet-Draft IKE-ME April 2008
IP_MS:4500 -> IP_N2:1025
HDR, SK { IDp1, N(ME_CONNECTID), N(ME_CONNECTKEY),
N(ME_ENDPOINT), N(ME_ENDPOINT) } -->
IP_P2:4500 -> IP_MS:4500
\--> IP_N2:1025 -> IP_MS:4500
<-- HDR, SK {}
Peer 2 answers with a ME_CONNECT exchange of its own, including the
initiating peer's ID, the connect ID, as well as its own randomly
generated key and obtained endpoints. To mark the exchange as a
response a ME_RESPONSE Notify payload is included. The mediation
server extracts this information and forwards it back to Peer 1,
again, exchanging the IDp accordingly.
6) IP_P2:4500 -> IP_MS:4500
\--> IP_N2:1025 -> IP_MS:4500
HDR, SK { IDp1, N(ME_RESPONSE), N(ME_CONNECTID),
N(ME_CONNECTKEY), N(ME_ENDPOINT),
N(ME_ENDPOINT) } -->
IP_MS:4500 -> IP_N2:1025
<-- HDR, SK {}
IP_MS:4500 -> IP_N1:1202
HDR, SK { IDp2, N(ME_RESPONSE), N(ME_CONNECTID),
N(ME_CONNECTKEY), N(ME_ENDPOINT),
N(ME_ENDPOINT) } -->
IP_P1:4500 -> IP_MS:4500
\--> IP_N1:1202 -> IP_MS:4500
<-- HDR, SK {}
Both peers now pair their own endpoints with those received from the
other end and proceed with connectivity checks. Connectivity checks
are done using unprotected INFORMATIONAL exchanges that include the
connect ID, an ME_ENDPOINT payload, and a ME_CONNECTAUTH Notify
payload, which contains a MAC to authenticate the sender of the
check. In this example we assume that both NATs perform endpoint
independent mapping and filtering.
Brunner Expires October 18, 2008 [Page 10]
Internet-Draft IKE-ME April 2008
7) IP_P1:4500 -> IP_P2:4500
HDR, N(ME_CONNECTID), N(ME_ENDPOINT),
N(ME_CONNECTAUTH) --> !! NOT REACHABLE
IP_P1:4500 -> IP_N2:1025
\--> IP_N1:1202 -> IP_N2:1025
HDR, N(ME_CONNECTID), N(ME_ENDPOINT),
N(ME_CONNECTAUTH) -->
IP_P2:4500 -> IP_N1:1202
\--> IP_N2:1025 -> IP_N1:1202
<-- HDR
Peer 2 does the same in the opposite direction. If at least one
connectivity check is successful, the initiating peer proceeds with a
normal IKE_SA_INIT request using the endpoints from the successful
check.
3. Mediation Connection
This section describes the protocol between peers and the mediation
server.
3.1. Initial IKE Exchanges
To establish a mediation connection with a mediation server an
implementation MUST include a ME_MEDIATION notification in the
IKE_SA_INIT exchange. The initiator MUST stop the initiation if the
responder does not include a ME_MEDIATION notification in its
response.
The format of the ME_MEDIATION notification is described in
Section 7.
If the transport address used to communicate with the mediation
server is also to be used as Host endpoint (see Section 3.3.2.2), the
peer MUST now float to port 4500 even if no NAT is detected between
the peer and the mediation server. Because connectivity checks are
sent with non-ESP marker in front of the IKE header it would be
confusing for implementations to receive such packets on port 500.
As no CHILD_SAs are established on mediation connections, the
IKE_AUTH exchange differs from [RFC4306]. The payloads SAi2 and TSi,
and SAr2 and TSr MUST be omitted from request and response,
respectively. If any of these payloads are found included in the
request, an implementation MUST respond with a NO_ADDITIONAL_SAS
notification without any other payloads, and then delete the IKE_SA.
Brunner Expires October 18, 2008 [Page 11]
Internet-Draft IKE-ME April 2008
All other payloads of the IKE_AUTH exchange remain as defined in
[RFC4306].
A peer MUST NOT have more than one connection to a specific mediation
server at the same time. Thus, a mediation server MUST delete an
existing IKE_SA with a peer upon receipt of a valid IKE_AUTH request
of the same peer.
An implementation that supports MOBIKE [RFC4555] SHALL include the
MOBIKE_SUPPORTED notification in the IKE_AUTH exchange.
Optionally, a peer MAY obtain a server reflexive endpoint from the
mediation server, as described in Section 3.3.2.2.
3.2. CREATE_CHILD_SA Exchange
The absence of CHILD_SAs on mediation connections also affects the
allowed usages of the CREATE_CHILD_SA exchange. Exchanges of this
type SHALL only be used to rekey the IKE_SA. An implementation MUST
respond to CREATE_CHILD_SA requests that demand the creation of a
CHILD_SA with a NO_ADDITIONAL_SAS notification, without any other
payloads.
3.3. Obtaining Endpoints
A peer obtains endpoints before requesting a mediated connection or
before responding to such a request. There are four types of
endpoints defined in this document - host, peer reflexive, server
reflexive, and relayed endpoints. Since every peer decides on its
own which endpoints it wants to share with other peers, the methods
to obtain these endpoints can vary widely.
3.3.1. Host Endpoints
Host endpoints are obtained by binding ports to an IP address on a
peer's host. A peer could use the same endpoint it uses to
communicate with the mediation server, but it could also use a
different port. If a peer is multihomed, it SHOULD obtain endpoints
for every available IP address.
3.3.2. Server Reflexive and Relayed Endpoints
Server reflexive and relayed endpoints can be obtained from various
sources. One possibility is to use STUN
([I-D.ietf-behave-rfc3489bis]) and its Binding Discovery and Relay
Usages ([I-D.ietf-behave-turn]). This specification does not
restrict implementations on the methods used to obtain such
endpoints. But a peer SHOULD obtain server reflexive and MAY obtain
Brunner Expires October 18, 2008 [Page 12]
Internet-Draft IKE-ME April 2008
relayed endpoints for each host endpoint, to increase the probability
of a successful connection.
Use of relays is expensive, and when using this protocol, relays will
only be utilized when both peers are behind NATs that perform address
and port dependent mapping. Consequently, some deployments might
consider this use case marginal and decide not to use relays.
3.3.2.1. Considerations Concerning TURN
An implementation that opts for STUN's Relay Usage
([I-D.ietf-behave-turn]) as source for relayed endpoints has to
consider several implications that result from that decision. For
instance, as long as no active destination is set for such an
endpoint, any IKE or ESP traffic that will be transferred through
that endpoint will be encapsulated in Data Indication messages.
Aside from the overhead of this additional layer of encapsulation,
this also means that the implementation has to be able to process
such traffic. This may be significantly easier for IKE traffic,
since IKE traffic is often processed in user space, whereas ESP
traffic is usually handled in kernel space, where the introduction of
an additional layer of encapsulation might be more difficult to
implement. Therefore, it is RECOMMENDED that an owner of such a
relayed endpoint sets an active destination as soon as it becomes
apparent that the endpoint is being used to establish the mediated
connection. Thus, it depends on the selected pair and the associated
endpoints. If the initiator owns the relayed endpoint of the
selected endpoint pair, it sets the active destination to the remote
endpoint of that pair, just before sending the IKE_SA_INIT request to
initiate the mediated connection. Because the responder does not
know which pair finally gets selected by the initiator, it waits
until it gets the IKE_SA_INIT request and just before sending the
IKE_SA_INIT response sets the active destination to the endpoint
provided in the REMOTE-ADDRESS attribute of the Data Indication
message. In the extremely rare case of the selected pair consisting
of two relayed endpoints, the procedure is the same, with both peers
taking appropriate measures. This could happen, for instance, if
both peers are behind a NAT and neither did provide server reflexive
endpoints.
3.3.2.2. Obtaining Server Reflexive Endpoints from Mediation Servers
A peer MAY obtain a server reflexive endpoint from the mediation
server. To do so, it includes a ME_ENDPOINT Notify payload either in
the IKE_AUTH request or at a later stage in a separate INFORMATIONAL
exchange.
The priority, family, and port fields of this payload are set to
Brunner Expires October 18, 2008 [Page 13]
Internet-Draft IKE-ME April 2008
zero, the address field is zero length, and the type field is set to
SERVER_REFLEXIVE. Upon receiving such a payload, the mediation
server includes in its answer a ME_ENDPOINT notification of the same
type filling in the family, address and port of the endpoint it
received the request from.
The mediation server MUST ignore the ME_ENDPOINT Notify payload if
the type is not SERVER_REFLEXIVE [anchor11].
If MOBIKE [RFC4555] is in use on the mediation connection, detection
of changes in NAT mappings SHOULD be activated (as specified in
[RFC4555], Section 3.8). A peer that previously obtained a server
reflexive endpoint from the mediation server SHOULD refresh that
endpoint, whenever MOBIKE indicates that the NAT mapping has changed.
3.3.3. Peer Reflexive Endpoints
Peer reflexive endpoints are different from the previous endpoint
types. Endpoints of this type are never obtained before a connection
attempt, but dynamically learned during the connectivity checks. The
process of how and when these endpoints MAY be learned is explained
in Section 5.
3.3.4. The Base of Local Endpoints
All local endpoints have a Base. This is the transport address used
to send the actual messages for an endpoint. Since it is not
possible to send messages directly from a server reflexive endpoint,
the base of such an endpoint is the host endpoint from which the
server reflexive endpoint was obtained. If the peer is not behind a
NAT, the base of a server reflexive endpoint will equal that
endpoint, which is then redundant and will be eliminated. The base
of host endpoints is the endpoint itself. The same is true for
relayed endpoints, since these are like remote host endpoints. Peer
reflexive endpoints also have a base; it is the base of the local
endpoint of the pair from whose connectivity check the peer reflexive
endpoint was learned.
3.3.5. Prioritizing Endpoints
Each obtained endpoint is assigned a unique priority that MUST be a
positive integer between 0 and 2**32 - 1. A peer SHOULD compute this
priority using the formula in Section 3.3.5.1 and choose its
parameters using the guidelines in Section 3.3.6. Using a different
formula will most likely break the coordination in the connectivity
checks, causing the protocol to take longer to converge.
Brunner Expires October 18, 2008 [Page 14]
Internet-Draft IKE-ME April 2008
3.3.5.1. Recommended Formula
The priority is based on a preference for each type of endpoint
(host, peer reflexive, server reflexive and relayed) and a preference
for each of a peer's local IP addresses, in case it is multihomed.
These two preferences are combined to compute the priority for an
endpoint using the following formula (which is derived from the
formula defined in [I-D.ietf-mmusic-ice], Section 4.1.2):
priority = (2**16)*(type preference) +
IP address preference
The type preference MUST be an integer from 0 to 255 inclusive and
represents the preference for the type of the endpoint. 255 is the
highest preference, and 0 is the lowest. Setting the value to 0
means that endpoints of this type will only be used as a last resort.
The type preference MUST be identical for all endpoints of the same
type and MUST be different for endpoints of different types. The
type preference for peer reflexive endpoints MUST be higher than that
of server reflexive endpoints. This is because it is easier for an
attacker to foist a bad server reflexive endpoint on a peer, than it
is to do the same with peer reflexive endpoints.
The IP address preference MUST be an integer from 0 to 65535
inclusive. It represents a preference for the particular IP address
from which the endpoint was obtained in case a peer is multihomed.
65535 represents the highest preference and 0 the lowest. When there
is only a single IP address, this value SHOULD be set to 65535. If a
peer is dual-stacked the IP address preference SHOULD be equal to the
precedence value for IP addresses as described in [RFC3484].
3.3.6. Guidelines for Choosing Type and IP Address Preferences
The RECOMMENDED values for the type preference are 255 for host
endpoints, 128 for peer reflexive endpoints, 64 for server reflexive
endpoints, and 0 for relayed endpoints.
One criteria for the selection of the IP address preference values is
IP address family. This protocol works with both IPv4 and IPv6. It
also allows dual-stack hosts to prefer connections over IPv6, but to
fall back to IPv4. Other criteria MAY be established as a matter of
local optimization.
Brunner Expires October 18, 2008 [Page 15]
Internet-Draft IKE-ME April 2008
3.3.7. Eliminating Redundant Endpoints
After obtaining the endpoints, the peer eliminates redundant ones.
An endpoint is redundant if its transport address equals that of
another endpoint and its base equals the base of that other endpoint.
Two endpoints that share the same transport address but have
different bases are not considered redundant. The peer SHOULD
eliminate the redundant candidate with the lower priority.
3.4. Initiating a Connection
To initiate a direct connection with another peer and to exchange
endpoints, a new exchange type (ME_CONNECT) is defined. The
communication between initiating peer and responding peer passes
through the mediation server and therefore consists of multiple
exchanges. Request and response between the peers are each composed
of two distinct exchanges between the mediation server and the peers.
This results in the following message flow:
Peer 1 Mediation Server Peer 2
-------- ------------------ --------
/ ME_CONNECT request ->
Re- <- ME_CONNECT response
quest ME_CONNECT request ->
\ <- ME_CONNECT response
/ <- ME_CONNECT request
Re- ME_CONNECT response ->
sponse <- ME_CONNECT request
\ ME_CONNECT response ->
Figure 2: ME_CONNECT Exchanges
3.4.1. ME_CONNECT Exchange
The first payload included in a ME_CONNECT request is an IDp payload
containing the ID of the other peer. All other payloads are
notifications.
The first two notifications are ME_CONNECTID and ME_CONNECTKEY.
ME_CONNECTID contains a randomly chosen value that is used to
identify the current connection setup. This identifier is provided
by the initiator and is sent back by the other peer in the reply in
order to be able to distinguish concurrent ME_CONNECT exchanges
initiated by both sides. Each peer also provides a randomly chosen
key contained in a ME_CONNECTKEY Notify payload that is used to
Brunner Expires October 18, 2008 [Page 16]
Internet-Draft IKE-ME April 2008
authenticate the connectivity checks.
If the requested peer is currently not online, that is, not connected
to the mediation server, the mediation server MUST include a
ME_CONNECT_FAILED error notification in its response. To prevent an
initiator from constantly having to poll the other peer's online
status, it MAY include a ME_CALLBACK notification in its request.
This instructs the mediation server to notify the initiator as soon
as the requested peer gets online.
To transmit the previously obtained endpoints, notification payloads
of type ME_ENDPOINT are used. A ME_CONNECT request MUST include at
least one such payload. Mediation servers MUST reply with a
ME_CONNECT_FAILED if a request contains no endpoints.
Figure 3 shows a schematic overview of the ME_CONNECT exchange that
is used to initiate a connection. Figure 4 shows the exchange used
to indicate a failure.
Initiator Responder
----------- -----------
HDR, SK { IDp, [N(ME_RESPONSE)], N(ME_CONNECTID),
N(ME_CONNECTKEY), [N(ME_CALLBACK)],
N(ME_ENDPOINT)+ } -->
<-- HDR, SK { [N(ME_CONNECT_FAILED)] }
Figure 3: ME_CONNECT Exchange: Initiation
Initiator Responder
----------- -----------
HDR, SK { IDp, N(ME_CONNECT_FAILED) } -->
<-- HDR, SK {}
Figure 4: ME_CONNECT Exchange: Failure
On every ME_CONNECT request the mediation server checks whether the
requested peer is connected to it. If this is the case, the
mediation server forwards the data included in the request to the
requested peer by initiating another ME_CONNECT exchange, thereby
Brunner Expires October 18, 2008 [Page 17]
Internet-Draft IKE-ME April 2008
replacing the IDp payload with the ID of the initiator. If the
requested peer is not available the mediation server responds
immediately with a ME_CONNECT_FAILED notification. If the initiator
included a ME_CALLBACK notification in its request, the mediation
server registers the requested ID. Once the requested peer connects,
the mediation server notifies all waiting peers by initiating a
ME_CONNECT exchange containing the peer ID of the requested peer and
a ME_CALLBACK Notify payload, as shown in Figure 5. Afterwards, the
mediation server removes the ID from the list of requested peers.
Initiator Responder
----------- -----------
HDR, SK { IDp, N(ME_CALLBACK) } -->
<-- HDR, SK {}
Figure 5: ME_CONNECT Exchange: Callback
3.4.2. Receiving a ME_CONNECT Request
Upon receipt of a ME_CONNECT request from the mediation server, a
peer has to obtain endpoints itself. Actually the peer could have
done that earlier, even before connecting to the mediation server,
keeping the endpoints alive while waiting for incoming requests. The
peer then assembles a ME_CONNECT request which contains its own
endpoints, the ID of the other peer, and a randomly generated value
for the ME_CONNECTKEY payload. It also includes the ME_CONNECTID
payload from the request and a ME_RESPONSE Notify payload to mark
this exchange as a response. This message is then sent to the
mediation server which should confirm it with an empty response. If
the response contains a ME_CONNECT_FAILED notification, the other
peer is not connected to the mediation server anymore. In this case
the peer stops handling the request, otherwise, it proceeds with
connectivity checks, as described beginning with Section 4.
In case a peer is unable to handle the request for a mediated
connection - this could be due to missing configuration, local policy
or other failures - it immediately responds with a ME_CONNECT_FAILED
in the response to the ME_CONNECT request it received from the
mediation server. If it later faces a condition that prevents it
from responding to the request, it SHOULD initiate a ME_CONNECT
exchange containing only an IDp and a ME_CONNECT_FAILED Notify
payload. This notification is then forwarded to the initiating peer
to inform it of this situation.
Brunner Expires October 18, 2008 [Page 18]
Internet-Draft IKE-ME April 2008
3.4.3. Receiving a ME_CONNECT Response
The initiator eventually gets a ME_CONNECT request from the mediation
server containing the response from the other peer. It correlates
the response with the previously sent request using the ID contained
in the ME_CONNECTID payload. It extracts the endpoints and key
provided by the responder and proceeds with connectivity checks, as
described beginning with Section 4.
3.4.4. Timeout for the Overall Transaction
Since the whole transaction is split in four separate exchanges (see
Figure 2) a timeout for the overall transaction is required. This
timeout allows the initiator to act appropriately in case any of the
three exchanges, in which it is not actively involved, fails. The
nature of appropriate means is not defined by this specification, a
peer might just restart the process, cancel it and log a message, or
might take more sophisticated measures (like contacting an
alternative mediation server). The timer controlling this timeout
SHOULD be started right after the initial ME_CONNECT exchange
finished successfully.
Since [RFC4306] does not exactly specify how retransmissions for
IKEv2 messages have to be effected and does not define the time frame
within which dead peers have to be detected, it becomes impossible to
specify an exact timeout value. Therefore this document only
specifies that an overall timeout value MUST be configurable to allow
it to be adapted to specific conditions. As a recommendation the
timeout value SHOULD approximately amount to at least three times the
maximum time it takes the initiating peer to conclude that the
retransmission of an IKEv2 message has finally failed.
4. Building Endpoint Pairs
After receiving endpoints with a ME_CONNECT exchange, a peer builds a
list of endpoint pairs. This is done by pairing each local endpoint
with each remote endpoint (endpoints get only paired if they share
the same IP address family). Then for each pair a priority is
computed. The resulting list is then sorted in decreasing order of
priorities. The formula used to compute this priority is as follows
(it is basically the same formula as defined in
[I-D.ietf-mmusic-ice], Section 5.7.2):
priority = (2**32) * MIN(pI, pR) +
2 * MAX(pI, pR) + (pI > pR ? 1 : 0)
Brunner Expires October 18, 2008 [Page 19]
Internet-Draft IKE-ME April 2008
where pI and pR denote the priorities of the initiator and the
responder, respectively. MIN and MAX are functions that result in
either the minimum or the maximum value of their parameters,
respectively. The last term of the formula evaluates to 1 if pI is
greater than pR or to 0 otherwise.
A peer cannot send messages directly from a reflexive endpoint, but
only from its base. Since a peer generated pairs with both host
endpoints and server reflexive endpoints as local endpoints, it's
likely that there are duplicate entries in the list of pairs.
Therefore, the peer MUST prune the list. This is done by removing a
pair if the base of its local endpoint and the remote endpoint are
identical to those of a pair higher up on the list.
After sorting and pruning the list, the pairs are numbered serially.
This number serves as a message ID in connectivity checks. The
result is a sequentially numbered, ordered list of endpoint pairs,
called the checklist.
Each pair in the checklist has a specific state assigned to it that
changes during the connectivity checks. Initially all pairs are in
state Waiting. The possible states are as follows:
Waiting: No check has been performed yet for this pair. As soon
as it becomes the highest priority Waiting pair on the checklist,
a check can be performed.
In-Progress: A check has been sent for this pair, but the
transaction is still in progress.
Succeeded: A check for this pair produced a successful result.
Failed: A check for this pair was done and it failed.
An implementation SHOULD limit the number of endpoints it accepts in
a ME_CONNECT exchange as well as the number of pairs in a single
checklist. This specification does not define what the limits are
but the limits MUST be configurable, so that users can adjust the
limits if a specific situation demands it. If more endpoints are
received than the configured upper limit, the implementation SHOULD
discard them according to their priority. The same procedure is
RECOMMENDED for supernumerary pairs.
5. Connectivity Checks
Connectivity checks are done using unprotected INFORMATIONAL
exchanges. The peers process the checklist sequentially and send a
request from the local endpoint to the remote endpoint of each pair.
Brunner Expires October 18, 2008 [Page 20]
Internet-Draft IKE-ME April 2008
In addition to the checklist each peer maintains a FIFO queue, called
the triggered check queue, which contains pairs for which checks are
to be sent at the next available opportunity. A periodically firing
timer T controls the generation of the checks. Whenever timer T
fires, a peer first checks whether there are any elements in the
triggered check queue. If so, it removes the first pair from it and
initiates a connectivity check for that pair. Otherwise the peer
sends a check for the topmost pair in the checklist which is in state
Waiting. If no such pair exists the peer does nothing in this time
slot. This process is illustrated in Figure 6. Once a check has
been sent the state of the pair is set to In-Progress.
+---------------------+ /---------------\
/----->| idle |<-----| send check |
| +---------------------+ \---------------/
| | timer fires ^
| v |
| +----------------------+ |
| |triggered check queue:| ok |
| | get first item |--------------+
| +----------------------+ |
| | none |
| v |
| +---------------------+ |
| none |checklist: get first | ok |
\------|pair in state Waiting|--------------/
+---------------------+
Figure 6: Sending Connectivity Checks
There is no RECOMMENDED setting for timer T specified in this
document. But timer T MUST be configurable so that a user may change
the setting to adjust to specific environments. There is a second
timer called retransmission timer R which is started for each
connectivity check request after it has been initially sent.
Whenever timer R fires the request is retransmitted. This not done
indefinitely, though. After a set number of retransmissions the
connectivity check times out and the state of the pair is set to
Failed. As with timer T, this specification does not restrict
implementors on how to design these retransmissions. However, it is
RECOMMENDED that a user may be able to configure how often and how
long retransmissions are sent in order to improve the connectivity in
specific situations.
Brunner Expires October 18, 2008 [Page 21]
Internet-Draft IKE-ME April 2008
5.1. Forming Connectivity Checks
Specially crafted unprotected INFORMATIONAL exchanges act as
connectivity checks. The INFORMATIONAL request is formed as follows.
The SPI fields in the IKE header are set to zero. The message ID is
set to the ID of the corresponding entry in the checklist. Three
payloads follow the header. The first one is a ME_CONNECTID
notification containing the value provided by the initiator that
allows the recipient to locate the correct checklist. The next
payload is a ME_ENDPOINT Notify payload that has all fields but the
priority and the type set to zero. The priority field is set equal
to the priority that would be assigned based on the formula in
Section 3.3.5.1 to a peer reflexive endpoint. Hence, the type field
is set to PEER_REFLEXIVE. To authenticate the message a
ME_CONNECTAUTH notification is built and added, containing an SHA-1
hash of several parts of the message and the value of the appropriate
ME_CONNECTKEY (see Section 5.1.1 for details). Request and response
of a connectivity check are always authenticated with the same key,
that of the responder. Thus a connectivity check from peer L to peer
R (and its response) is authenticated with the key provided by R.
Likewise, a connectivity check from R to L (and its response) is
authenticated with the key provided by L.
To simplify things, the IKE messages used to do connectivity checks
are always sent with a non-ESP marker in front of the IKE header, as
defined in [RFC3948], even if the port numbers used are not 4500.
Figure 7 provides a schematic diagram of a connectivity check.
Initiator Responder
----------- -----------
HDR, N(ME_CONNECTID), N(ME_ENDPOINT),
N(ME_CONNECTAUTH) -->
<-- HDR, N(ME_CONNECTID), N(ME_ENDPOINT)
N(ME_CONNECTAUTH)
Figure 7: Connectivity Checks
5.1.1. ME_CONNECTAUTH
The formula used to compute the value of the ME_CONNECTAUTH Notify
payload is:
Brunner Expires October 18, 2008 [Page 22]
Internet-Draft IKE-ME April 2008
auth = Hash(MID | ME_CONNECTID | ME_ENDPOINT | ME_CONNECTKEY)
where MID denotes the message ID in the IKE Header in network byte
order and | indicates concatenation. Of each included Notify payload
only the notification data is considered. The hash function used is
SHA-1.
5.2. Responding to Connectivity Checks
After receiving a connectivity check request, a peer uses the value
of the ME_CONNECTID payload to locate the correct checklist and the
appropriate key. It verifies that the message is genuine, by
computing the hash as the sender did and comparing the result with
the content of the ME_CONNECTAUTH Notify payload. If either the
checklist is not found or the verification fails, the peer MUST
ignore the connectivity check request. Otherwise, it proceeds as
follows. Refer to Figure 8 for an illustration of this process.
1. It checks whether the source address and port of the message are
already included in the list of remote endpoints. If this is not
the case, this represents a new peer reflexive endpoint. The
priority of this endpoint is set to the priority noted in the
ME_ENDPOINT payload of the request and it is then added to the
list of remote endpoints.
2. A new pair is constructed setting the local endpoint to the one
on which the request was received, and the remote endpoint to the
one where the request came from (this may be the peer reflexive
endpoint just learned). The priority of this pair is computed as
usual.
3. If this pair is already in the checklist, further processing
depends on the state of that pair.
* If the pair is in waiting state, a check for it is enqueued
into the triggered check queue.
* If the state is In-Progress, retransmissions for the pending
request will be cancelled, but the peer will wait the duration
of the retransmission timeout for a response. If there is no
answer the peer MUST schedule a new connectivity check for
that pair, by enqueuing a check in the triggered check queue.
The state of the pair is then changed to Waiting.
* If the state of the pair is Failed, it is changed to Waiting
and the peer MUST enqueue a new connectivity check for that
pair in the triggered check queue.
Brunner Expires October 18, 2008 [Page 23]
Internet-Draft IKE-ME April 2008
* If the state is already Succeeded, nothing is done.
If the pair had not yet been included in the checklist, it is now
inserted based on its priority. The ID is set to the number of
pairs in the checklist plus one. The state is set to Waiting and
a connectivity check is enqueued in the triggered check queue.
4. A response is then sent back. It includes the same ME_CONNECTID
as the request, the ME_ENDPOINT is filled with the source
endpoint from which the request was received - for relayed
endpoints that are obtained using STUN, the source address is
included in the REMOTE-ADDRESS attribute, if it was encapsulated
in a Data Indication message, or it is the current active
destination for the STUN relay session, otherwise - and the
ME_CONNECTAUTH is built as in the request, using the appropriate
key.
Brunner Expires October 18, 2008 [Page 24]
Internet-Draft IKE-ME April 2008
+-------------------+
| request received |
| and verified |
+-------------------+
|
v
+---------------+ +-------------------+
| add to | no | source in list of |
|remote endoints|<----| remote endpoints? |
+---------------+ +-------------------+
| | yes
| v
| +------------------+
\------------->| create pair and |
| compute priority |
+------------------+
|
v
+---------------+ +------------------+
| add pair to | no | pair is already |
| checklist |<-----| in checklist? |
+---------------+ +------------------+
| | yes
| v
| Waiting /------------------\ Succeeded
+--------------| pair state |--------------\
| \------------------/ |
| / \ |
| Failed | | In-Progress |
| v v |
| +------------+ +------------+ |
| |change state| failed | wait for | ok |
+-----| to Waiting |<---------| response |-----+
| +------------+ +------------+ |
v |
+---------------+ |
|queue triggered| |
| check | |
+---------------+ |
| +------------------+ |
\------------->| send response |<-------------/
+------------------+
Figure 8: Responding to Connectivity Checks
Brunner Expires October 18, 2008 [Page 25]
Internet-Draft IKE-ME April 2008
5.3. Processing Connectivity Checks
This section describes how responses to connectivity checks are
processed. On receipt of a connectivity check response a peer
correlates it to the corresponding pair using, first, the
ME_CONNECTID to find the correct checklist and then the message ID to
identify the pair. It MUST verify the authenticity of the check
using the key provided by the other peer.
5.3.1. Failure Cases
If the peer either cannot find the checklist or cannot find the
corresponding pair or if the verification of the check fails, it MUST
ignore the check response.
Implementations MAY support receipt of ICMP errors for connectivity
checks. If a connectivity check generates an ICMP error, a peer sets
the state of the corresponding pair to Failed.
If a connectivity check times out, the peer also sets the state of
the corresponding pair to Failed.
The peer MUST check that the source address and port of the response
equals the remote endpoint of the pair, and the destination address
and port of the response equals the base of the local endpoint of the
pair. If either of these comparisons fails the state of the pair is
set to Failed.
5.3.2. Success Cases
A connectivity check is considered a success, if the following are
true:
o The source address and port of the response equal the remote
endpoint of the pair.
o The destination address and port of the response match the base of
the local endpoint of the pair.
After verifying that the check is successful, the peer checks the
mapped endpoint that is returned in the ME_ENDPOINT Notify payload.
If the endpoint does not match any of the local endpoints that the
peer knows about, the mapped endpoint represents a new peer reflexive
endpoint. The base of this endpoint is set equal to the base of the
local endpoint of the pair the check was sent for. The priority is
set equal to the value noted in the payload. This endpoint is then
added to the list of local endpoints and a new pair is built as
follows.
Brunner Expires October 18, 2008 [Page 26]
Internet-Draft IKE-ME April 2008
A new pair is constructed whose local endpoint equals the endpoint
from the ME_ENDPOINT Notify payload as described in the preceding
paragraph, and whose remote endpoint equals the destination address
to which the request was sent. This pair is inserted into a second
list called valid list, since it has been validated by a connectivity
check. The valid pair may equal the pair that generated the check,
may equal a different pair in the checklist, or may be a pair not
currently in the checklist.
If the pair is not on the checklist, the priority is computed as
usual. If the local endpoint is peer reflexive, its priority is
equal to the priority field of the ME_ENDPOINT payload. The priority
of the remote endpoint is looked up in the list of remote endpoints.
The state of the pair that generated the check is then set to
Succeeded.
5.3.3. Stopping the Checks and Selecting the Endpoints
Once one or more connectivity checks have completed successfully,
valid pairs are generated and added to the valid list. The
initiating peer lets the checks continue until some stopping criteria
is met and then selects one pair from the valid list based on an
evaluation criteria. The criteria for stopping the checks and for
evaluating the valid pairs is entirely a matter of local
optimization.
The responding peer does not stop the checks for a checklist until it
receives an IKE_SA_INIT request that includes a ME_CONNECTID Notify
payload containing the respective connect ID.
6. Mediated Connection
6.1. Initiating the Mediated Connection
After the initiating peer has selected a valid pair, it uses these
endpoints to initiate an IKE_SA_INIT exchange with the other peer.
Like the connectivity checks, the IKE traffic on mediated connections
is sent with the non-ESP Marker prepended to the IKE header, as
defined in [RFC3948]. Whether UDP encapsulation of ESP traffic is
enabled on the mediated connection, is decided as usual, using NAT
detection as defined in [RFC4306], Section 2.23.
In addition to all the default payloads in the IKE_SA_INIT exchange
the initiating peer also includes a ME_CONNECTID Notify payload
containing the appropriate connect ID.
Brunner Expires October 18, 2008 [Page 27]
Internet-Draft IKE-ME April 2008
7. Payload Formats
7.1. Identification Payload - Peer Identity
This payload, denoted IDp in this document, is used to exchange the
identities of mediated peers. It is identical to the Identification
Payloads defined in [RFC4306], Section 3.5.
The payload type for this Identification Payload (IDp) is
TBD_BY_IANA.
7.2. Notify Messages - Error Types
7.2.1. ME_CONNECT_FAILED Notify Payload
This notification is used to signal that the attempt to mediate a
connection with a peer has failed. It is used in the ME_CONNECT
exchange request or response.
The Notify Message Type for ME_CONNECT_FAILED is TBD-BY-IANA. The
Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.
7.3. Notify Messages - Status Types
7.3.1. ME_MEDIATION Notify Payload
This notification is included in the IKE_SA_INIT exchange of a
mediation connection to indicate that both parties support this
specification and want to establish a mediation connection.
The Notify Message Type for ME_MEDIATION is TBD-BY-IANA. The
Protocol ID and SPI Size fields are set to zero. The notification
data field MUST be left empty (zero-length) when sending, and its
contents (if any) MUST be ignored when this notification is received.
This allows the field to be used by future versions of this protocol.
7.3.2. ME_ENDPOINT Notify Payloads
This notification is used to exchange endpoints.
The Notify Message Type for ME_ENDPOINT is TBD-BY-IANA. The Protocol
ID and SPI Size fields are set to zero. The data associated with
these Notify types starts with a four-octet long number denoting the
endpoint's priority, followed by the eight bit long address family,
and an eight bit long number indicating the type of the endpoint.
The data further consists of a two-octet port number, which is
finally followed by either a four-octet IPv4 address or a 16-octet
Brunner Expires October 18, 2008 [Page 28]
Internet-Draft IKE-ME April 2008
IPv6 address.
The following figure illustrates the format of the notification data
of the ME_ENDPOINT payload:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! priority !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! family ! type ! port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IP address (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The address family can take on the following values:
Name Value
------------------------------ -----
RESERVED 0
IPv4 1
IPv6 2
The following endpoint types are defined:
Name Value
------------------------------ -----
RESERVED 0
HOST 1
PEER_REFLEXIVE 2
SERVER_REFLEXIVE 3
RELAYED 4
This payload is also used to request endpoints from a mediation
server and in connectivity checks. Refer to Section 3.3 and
Section 5 for details.
7.3.3. ME_CALLBACK Notify Payload
This notification allows a peer to instruct the mediation server to
send out a notification once a specific peer connects to it, if it
was not available when the peer initially sent the ME_CONNECT. The
Brunner Expires October 18, 2008 [Page 29]
Internet-Draft IKE-ME April 2008
mediation server also includes a Notify payload of this type in the
requested callback.
The Notify Message Type for ME_CONNECTID is TBD-BY-IANA. The
Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.
7.3.4. ME_CONNECTID Notify Payload
This notification is used to exchange an identification number that
uniquely identifies a direct connection attempt. The initiator
provides this identifier in the ME_CONNECT exchange. It is then
later used in the connectivity checks as well as in the IKE_SA_INIT
request of the mediated connection. The randomly generated
identifier MUST have a length of 4 to 16 octets.
The Notify Message Type for ME_CONNECTID is TBD-BY-IANA. The
Protocol ID and SPI Size fields are set to zero. The data associated
with this Notify type consists of random data of variable length.
7.3.5. ME_CONNECTKEY Notify Payload
This notification contains a symmetric key used in the MAC that
authenticates the connectivity checks. The randomly generated key
MUST be at least 16 octets long, but MAY have a length of up to 32
octets.
The Notify Message Type for ME_CONNECTKEY is TBD-BY-IANA. The
Protocol ID and SPI Size fields are set to zero. The data associated
with this Notify type consists of random data of variable length.
7.3.6. ME_CONNECTAUTH Notify Payload
This notification contains the message authentication code (MAC) in a
connectivity check.
The Notify Message Type for ME_CONNECTAUTH is TBD-BY-IANA. The
Protocol ID and SPI Size fields are set to zero. The data associated
with this Notify type consists of a 20-octet SHA-1 digest.
7.3.7. ME_RESPONSE Notify Payload
This notification is used in ME_CONNECT exchanges to mark an exchange
as a response. Since ME_CONNECT exchanges usually contain the same
payloads, this Notify payload is required to distinguish between
exchanges that serve as requests and exchanges that serve as
responses. This is particularly important in the case of two peers
trying to initiate a connection to each other at the same time.
Brunner Expires October 18, 2008 [Page 30]
Internet-Draft IKE-ME April 2008
The Notify Message Type for ME_RESPONSE is TBD-BY-IANA. The Protocol
ID and SPI Size fields are set to zero. There is no data associated
with this Notify type.
8. Security Considerations
8.1. Trusting the Mediation Servers
The peers must at least partially trust the mediation servers they
use. Because the information that is passed to other peers is not
encrypted in an end-to-end fashion the mediation server can observe
all the exchanged endpoints. This could lead to the unwanted
disclosure of private IP addresses and address ranges. Of course
each peer can decide which endpoints it wants to share with other
peers and hence with the mediation server.
9. IANA Considerations
This document does not create any new namespaces to be maintained by
IANA, but it requires new values in namespaces that have been defined
in the IKEv2 base specification [RFC4306].
This document defines a new IKEv2 exchange whose value is to be
allocated from the "IKEv2 Exchange Types" namespace:
Exchange Type Value
------------------------------ -----
ME_CONNECT TBD-BY-IANA (38..239)
These exchange is described in Section 3.4.1.
This document defines one new IKEv2 payload whose value is to be
allocated from the "IKEv2 Payload Types" namespace:
Payload Type Notation Value
------------------------------ -------- -----
Identification - Peer IDp TBD-BY-IANA (49..127)
This payload is described in Section 7.
This document defines several new IKEv2 notifications whose values
are to be allocated from the "IKEv2 Notify Message Types" namespace:
Brunner Expires October 18, 2008 [Page 31]
Internet-Draft IKE-ME April 2008
Notify Messages - Error Types Value
------------------------------ -----
ME_CONNECT_FAILED TBD-BY-IANA (42..8191)
Notify Messages - Status Types Value
------------------------------ -----
ME_MEDIATION TBD-BY-IANA (16406..40959)
ME_ENDPOINT TBD-BY-IANA (16406..40959)
ME_CALLBACK TBD-BY-IANA (16406..40959)
ME_CONNECTID TBD-BY-IANA (16406..40959)
ME_CONNECTKEY TBD-BY-IANA (16406..40959)
ME_CONNECTAUTH TBD-BY-IANA (16406..40959)
ME_RESPONSE TBD-BY-IANA (16406..40959)
These notification payloads are described in Section 7.
10. IAB Considerations
TODO?
11. Acknowledgements
The author would like to thank Martin Willi for his work on the
introductory sections, and both him and Andreas Steffen for their
comments and suggestions. A special thanks goes to Daniel
Roethlisberger who worked with the author on an early revision of
this specification.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.
[RFC3948] Huttunen, A., Swander, B., Volpe, V.,
DiBurro, L., and M. Stenberg, "UDP
Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange
(IKEv2) Protocol", RFC 4306,
December 2005.
Brunner Expires October 18, 2008 [Page 32]
Internet-Draft IKE-ME April 2008
12.2. Informative References
[I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., Matthews, P.,
and D. Wing, "Session Traversal
Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work
in progress), February 2008.
[I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P.
Matthews, "Traversal Using Relays
around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT
(STUN)", draft-ietf-behave-turn-07
(work in progress), February 2008.
[I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive
Connectivity Establishment (ICE): A
Protocol for Network Address
Translator (NAT) Traversal for Offer/
Answer Protocols",
draft-ietf-mmusic-ice-19 (work in
progress), October 2007.
[RFC3484] Draves, R., "Default Address Selection
for Internet Protocol version 6
(IPv6)", RFC 3484, February 2003.
[RFC4555] Eronen, P., "IKEv2 Mobility and
Multihoming Protocol (MOBIKE)",
RFC 4555, June 2006.
Editorial Comments
[anchor11] this allows later revisions of this specification to
define a relay usage
Appendix A. Open Issues
A.1. Is the second ME_CONNECTKEY required?
The key provided by the responding peer is not really required. It's
just that the MACs of the connectivity check requests from both peers
would look the same, if only one key was used. On the other hand
using just one key, would allow us to drop the ME_RESPONSE Notify
payload from the ME_CONNECT response. Because the response from the
other peer would not contain a ME_CONNECTKEY Notify it were clearly
distinguishable from a ME_CONNECT request (see Appendix B.2).
Brunner Expires October 18, 2008 [Page 33]
Internet-Draft IKE-ME April 2008
A.2. Different NAT, Same Subnet
One problem arises when two hosts behind different NATs are attached
to the same subnet. Is this just a configuration problem that we
need or need not to document, or is it a main issue that we should
provide a solution for (Virtual IP?).
A.3. Relaying Provided by the Mediation Server
As we provide the possibility to request a server reflexive endpoint
from the mediation server, should we also provide relayed endpoints?
A.4. Compatibility/Synergy with MOBIKE
What happens in the following situations: Moving behind a NAT.
Moving out of a NAT. External IP changes (NAT/no NAT). Multihomed
host (active link goes down). If both peers still are connected to
the mediation server, is there a possibility to update the endpoints?
If a peer notices an address change with MOBIKE, should it update the
endpoints? Should it send updated endpoints to the other peer? If
the mediation server notices that our endpoint changed, does it send
us a notice (other than through MOBIKE)?
Appendix B. Design Decisions
B.1. Two exchanges between mediation server and second peer
This document proposes the initiation of a connection to be composed
of four exchanges: from one peer to the mediation server, from the
mediation server to the other peer, and vice-versa. The two
exchanges between the other peer and the mediation server could
theoretically be combined in one exchange. This would be problematic
in situations where the second peer first has to obtain endpoints
before being able to answer the request. As this will take some
time, the mediation server would most likely have retransmitted the
request due to a timeout. And, if the peer wants to acquire a server
reflexive endpoint from the mediation server a window size higher
than one is required.
B.2. Why the ME_RESPONSE Notify payload is needed
It might seem that the ME_RESPONSE is rather superfluous. The
ME_CONNECTID alone seems to be enough to distinguish requests from
responses. A peer just has to maintain a list of issued ids and then
simply compares the ME_CONNECTID of received ME_CONNECT messages with
the items in this list. If an item matches, the received message is
a response, otherwise, it is a request. Since the ME_CONNECTID is
randomly chosen by the initiator, the ids contained in requests from
Brunner Expires October 18, 2008 [Page 34]
Internet-Draft IKE-ME April 2008
two different peers should never match. So, this should even work if
two peers concurrently initiate a mediation with each other.
But there is a problem: What happens if a peer looses its state (e.g.
due to a crash/restart) right after initiating a mediation, but
immediately reconnects to the mediation server? Now, the
ME_CONNECTID included in the answer from the other peer to the
previously sent request is not included in the list of issued ids
anymore. The answer thus looks exactly like a request for a new
mediation. To avoid such a misunderstanding, peers have to be able
to clearly distinguish requests from responses. Therefore, a
ME_RESPONSE Notify payload is included in mediation responses.
Appendix C. Changelog
C.1. Changes from -.3 to -00
o Lots of clarifications and refinements. Major work on the
introductory sections.
C.2. Changes from -.2 to -.3
o Refined some details after implementing the protocol.
C.3. Changes from -.1 to -.2
o Complete redesign to an ICE-like solution.
C.4. Changes from -.0 to -.1
o P2P_CONNECT for both sides
o "Endpoint..." terms expanded.
Author's Address
Tobias Brunner
University of Applied Sciences, Rapperswil
Oberseestrasse 10
Rapperswil, SG 8640
Switzerland
EMail: tobias.brunner@hsr.ch
URI: http://ita.hsr.ch
Brunner Expires October 18, 2008 [Page 35]
Internet-Draft IKE-ME April 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Brunner Expires October 18, 2008 [Page 36]