One document matched: draft-dupont-ikev2-addrmgmt-03.txt
Differences from draft-dupont-ikev2-addrmgmt-02.txt
Internet Engineering Task Force Francis Dupont
INTERNET DRAFT ENST Bretagne
Expires in December 2003 June 2003
Address Management for IKE version 2
<draft-dupont-ikev2-addrmgmt-03.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. 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.
Distribution of this memo is unlimited.
Abstract
The current IKEv2 proposal [1] lacks an address management
feature. As it is compatible with the NAT traversal capability,
this document specifies a complete address management with support
for multi-homing and mobility.
1. Introduction
In this document, the addresses used to transport IKE messages are
named the "peer addresses" (term introduced by [2]). These peer
addresses should no more be directly or indirectly included in
identities ([3] and [4]) as it is commonly done for IKEv1.
draft-dupont-ikev2-addrmgmt-03.txt [Page 1]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
The current IKEv2 draft [1] often makes the assumption that an
address identifies a node when nodes behind a NAT can share the
same address and a node can use many different addresses. This
must be fixed.
This document describes the goals of an address management for
IKEv2, including the requirements for multi-homing and mobility
support, and finishes by a concrete proposal.
In this document, open questions are introduced by the word NOTE.
2. Goals
The goals of the address management proposed in the document can be
divided in some general goals and in requirements for the three
mechanisms which can change the peer addresses.
2.1 General goals
2.1.1 Simplicity, Performance and Security
The address management should be as simple as possible, i.e., it
should introduce minimal changes to the current IKEv2 draft [1]
and each changes should be justified.
The performance is an important criterion. For instance, rekeying
can update the peer addresses of an IKE SA or of an IPsec SA pair,
but rekeying is too expensive and a specific solution is needed.
As a security protocol, IKEv2 should get a high security
level. Unfortunately we already showed that the NAT traversal
feature comes with a security issue (the transient pseudo-NAT
attack [5]). Such problems introduced by the peer address
flexibility must be described in this document and at least be
mitigated by options in configurations. For instance, the NAT
traversal feature should never be enabled when one knows that
there can not be a NAT as in today IPv6.
2.1.4 Extensions of the IKEv2 draft
The first things to fix in the current IKEv2 draft [1] are for
the NAT traversal mechanisms but we exclude them from the scope
of this document. We assume that the NAT detection is performed
in the first exchange, i.e., NAT_DETECTION notifications are
mandatory when IKE doesn't run over UDP port 500.
The second missing thing in the current IKEv2 draft [1] is about
some misusage of the peer addresses:
- At the reception of a message, the lookup of the corresponding
IKE SA MUST be done using only the SPIs, never using the peer
addresses.
draft-dupont-ikev2-addrmgmt-03.txt [Page 2]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
- An INITIAL-CONTACT notification deletes old IKE SAs associated
to the peer Identity, not to the peer address. Current wording
is a bit misleading.
- The revised identity proposal [3] should be integrated in the
IKEv2 specifications. According to IAB recommendations [4],
addresses should not be used as or associated to identities.
Note that the last point stresses the issue of the lack of
protection of peer addresses.
The last thing to fix in the current IKEv2 draft [1] is the
support of the proxy case: the setup of transport mode IPsec SAs
on the behalf of another party.
2.2 Multi-homing requirements
In this document, the support of multi-homing is the support of
nodes with several global addresses. Some of the addresses can be
"better" than others, or "better" for some destinations. Some can,
from time to time, be unavailable.
The main requirement for the support of multi-homing is the
management of a set of peer addresses for each peer. The set can
be partially ordered or some subset can be loosely associated with
some destinations (i.e., some subset of the other peer address
set).
For the communication between multi-addressed hosts, the support
of the proxy case can be useful because it provides an easy way to
setup transport mode IPsec SAs with different addresses from one
IKE SA. In such cases the other party is in fact the same host,
this dramatically simplifies the authorization issue.
2.3 Mobility requirements
In the context of Mobile IPv6 ([7] and for the special case of
Home Agents [8]), the interaction of Mobility and IPsec was
analyzed in another document [9]. This document assumes an IPv6
context as Mobile IPv6 is the most powerful mobility proposal
available today.
An IPv6 mobile node is another type of multi-addressed node with:
- a care-of address in a prefix of the visited link.
The care-of address is used to route packets.
- the home address in a prefix of the home link.
The home address is used to identify the mobile node.
The care-of address is transient and usually the mobile node can
not provide a proof that it is the node using it. So it must be
trusted and a return routability check (i.e., an enforced answer
from this address) should be used if it is not.
draft-dupont-ikev2-addrmgmt-03.txt [Page 3]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
With a common correspondent, the mobility is transparent and
there is no reason to use another address than the home address.
With the home agent, there are three main cases (c.f. [8]):
- The mobility signaling which is mandatory protected and
raises a specific issue in its initial phase: the IKE SA
must be setup using the care-of address as the peer address
but this IKE SA is used to build an IPsec SA pair with
the home address as traffic selector. This IPsec SA will
protect the home registration which will make the home
address available. This can be considered as a special
proxy case.
- Other genuine communications between the home agent and
the mobile node can be covered by the proxy case support
too. Note this is the only case at the exception of signaling
where mobility behaves in a different way than a mobile IPsec
VPN (so we proposed to relax the corresponding rule in a
future version of [7] and [8]).
- The traffic relayed by the home agent through a tunnel with the
mobile node can be partially or fully protected by IPsec SA
pair(s). Encapsulation should be performed only once, including
for degenerated (but not for free) encapsulation like the home
address option or the mobility routing header.
In all cases of interaction with the home agent, the mobile node
peer address should be a care-of address. When the mobile node
moves, another care-of address is used and some SAs, including the
IKE SA, must be updated to use the new address.
Usually the previous peer address is no more usable. In order to
avoid a trivial denial of services, a strong sequencing of updates
is required with a way to cancel possible pending updates when
fast multiple handoff happen.
The IPsec pair which protects the mobility signaling uses the home
address as its traffic selector for the mobile node. It must not
be updated at each handoff. The update mechanism must provide a
fine grain (i.e., per SA) update.
3. Proposal
The proposal for an address management in IKEv2 is spawn from the
NAT traversal mechanisms, mainly with a new peer address update
payload. But there are some points that have to be kept as they
are in the current IKEv2 draft [1].
draft-dupont-ikev2-addrmgmt-03.txt [Page 4]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
3.1 Kept points from draft 06
The peer addresses are used to transport messages. The reply to
a request MUST be sent to the source of the request from the
destination request, i.e., addresses and ports are reversed
between the request and its reply. There is no exception to this
rule.
For tunnel mode IPsec SAs, the endpoint addresses are the peer
addresses. We don't propose an alternate way to specify them.
The same requirement applies to transport mode IPsec SAs at the
exception of the proxy case.
3.2 Small points
In retransmission of requests or responses, copies of messages do
not include peer addresses. So a peer MAY retransmit a message
from or to a different address. Proposition: clarify that
messages are "IKE messages".
The peer addresses are IKE SA parameters and are specified by
the IKE_SA_INIT exchange. Note that when NAT traversal is not
active, they are implicitly protected by the mandatory
NAT_DETECTION notifications.
All the text below implies only to the case where NAT traversal
is not active.
In the proxy case, the initiator is acting as a client negotiator
on the behalf of another party. The address of this other party is
sent in the initiator traffic selector and will become the address
of this end of the transport mode IPsec SA pair. A proper
authorization in the local policy of the responder is
REQUIRED, the defaults SHOULD be:
- using another address of the peer address set is permitted
- other cases are denied.
3.3 Peer address notifications
The peer address notifications are copied from the current
NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP
notifications. They includes the peer source or destination
address and the source or destination port and MUST be
in an encrypted payload.
All messages after the first exchange involving peer addresses
which are not the current IKE SA addresses MUST include at least
one peer address notification for each peer, i.e., at least one
for the source and at least one for the destination.
Such messages belong to IKE_AUTH or CREATE_CHILD_SA exchanges,
or carry the peer address update payload defined below.
draft-dupont-ikev2-addrmgmt-03.txt [Page 5]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
They provide a cryptographically proof of no alteration en-route
of the peer addresses and, when multiple peer address
notifications for the same peer are included, they encode its
whole peer address set. To allow the reduction of the peer
address set to one address, an address MAY be repeated.
If multiple peer address notifications for the same peer are
included in a message, the first one MUST be the used peer
address.
In order to associate some possible peer source addresses to
possible peer destination addresses, the source and destination
peer addresses notifications MAY be mixed (i.e., not in the common
order source(s) first, destination(s) after). For instance S1, S2,
D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction
with D1, S3 with D2 or D3.
In case of a mismatch of a peer address with the corresponding
peer address notifications, there is a dangling update or an
attack. If the possibly compromised message is a new request, its
content MUST be ignored and a warning notification sent, but the
message counter MUST be incremented in order to accept next
requests. If it is a retransmitted request, the cached reply MUST
be sent. If it is a reply, the corresponding request MUST be
retransmitted.
If the peer has moved between two retransmissions of a request, it
can interleave an explicit address update of at least the IKE SA.
When the peer address notifications are not supported, the
capability to use different peer addresses, and only this,
is lost.
3.4 Explicit peer address update payload
A new payload has to be defined for an explicit peer address
update mechanism. We propose to copy it from the delete payload,
see Annex C.
The new peer address update payload has strong sequencing
requirements. IKEv2 messages have a protected sequence number so
the only sequencing issues are the window of processing and
pending exchanges. Any messages with a peer address update payload
MUST be processed in order.
When the receiver of an update request has to check the validity
of the new peer address, it MAY use a return routability check
sending an informational request at the new address and waiting
for an answer. As informational exchanges are protected no more is
needed.
draft-dupont-ikev2-addrmgmt-03.txt [Page 6]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
Example of a return routability check:
I --- address update request --> R
I <-- informational RR request - R
I --- informational RR reply --> R
now the responder knows the initiator should be where it
claimed to be.
I <--- address update reply ---- R
As for the delete payload, the peer address update payload
specifies the SPIs of the IPsec and IKE SAs it applies to. But a
simple way to specify all SAs (i.e., the IKE SA and all the
tunnel mode IPsec SAs it negotiated) is needed.
4. Security Considerations
Great care was used to avoid to introduce security threats.
The NAT traversal feature comes with a security flaw (the transient
pseudo-NAT attack [5]) which can not be easily avoid. IMHO the NAT
traversal feature should be enabled only when the presence of NATs
is likely/possible.
When the NAT traversal feature is disabled, the other peer address
can not be changed en-route by an attacker but the proofs the peer
is really at its address are:
- the trust in the peer
- the proof that the peer can receive messages sent to its address
The second (a.k.a. the return routability check) works only with at
least three messages, i.e., for the initial exchange (with the
address stability requirement) and for the explicit optional
checks. IMHO these checks SHOULD be required by default.
5. Acknowledgments
The need for an address management for IKEv2 was explained at the
ipsec session of the Yokohama IETF meeting. It seems most people
agree but do not propose concrete solutions.
The rare people in the Mobility world with IPsec interests, or in
the IPsec world with Mobility interest, should receive all thanks
because without them we (me and all the future co-authors) have
given up for a long time.
Tero Kivinen helped to improve the NAT traversal part of this
proposal. Tero and Jari Arkko proposed another form of peer
address update based on the IKE SA addresses.
draft-dupont-ikev2-addrmgmt-03.txt [Page 7]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
6. Changes from previous versions
6.1 Changes from the previous version
Remove the address stability stuff.
Permit by default only the proxy case on the behalf of the same
node.
Remove the clarification request for INITIAL_CONTACT.
Make the peer addresses IKE SA parameters specified by the
IKE_SA_INIT exchange.
Exceptions for the "All flag" are all transport mode IPsec SAs,
not proxy case SAs only.
6.2 Previous changes
The explicit peer address update mechanism is a new payload
(and it followed the update of the deletion payload).
The NAT traversal part was dropped and the "merge" style given up.
Secret peer addresses are supported.
The implicit mechanism comes back but is restricted to NAT traversal.
Annexes are added for a more accurate proposal.
7. Normative References
None?
8. Informative References
[1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol",
draft-ietf-ipsec-ikev2-08.txt, May 2003.
[2] B. Korver, E. Rescorla, "The Internet IP Security PKI
Profile of ISAKMP and PKIX",
draft-ietf-ipsec-pki-profile-02.txt, February 2003.
[3] P. Hoffman, "Adding revised identities to IKEv2",
http://www.vpnc.org/ietf-ipsec/,
Message-Id: <p05200f06b9edf48ac57b@[165.227.249.18]>,
November 2002.
[4] M. Kaat, "Overview of 1999 IAB Network Layer Workshop",
RFC 2956, October 2000.
draft-dupont-ikev2-addrmgmt-03.txt [Page 8]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
[5] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks
or how NATs are even more evil than you believed",
draft-dupont-transient-pseudonat-01.txt, December 2002.
[6] Jayant Shukla, "RE: peer address protection and NAT Traversal",
http://www.vpnc.org/ietf-ipsec/,
Message-ID: <000201c2bb27$e7021ff0$5803a8c0@trlhpc1>,
January 2003.
[7] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-23.txt, May 2003.
[8] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
draft-ietf-mobileip-mipv6-ha-ipsec-05.txt, May 2003.
[9] F. Dupont, W. Haddad, "How to make IPsec more mobile IPv6
friendly", draft-dupont-ipsec-mipv6-03.txt, March 2003.
[10] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API,
Version 2", RFC 2367, July 1998.
9. Author's Address
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
FRANCE
Fax: +33 2 99 12 70 30
EMail: Francis.Dupont@enst-bretagne.fr
Annex A. Proxy Case Usage Scenario.
+-+-+-+-+-+-+
! !
!Negotiator !
!Endpoint !<.....\ IKE
! ! \............................\
+-+-+-+-+-+-+ !
V
+-+-+-+-+-+ +-+-+-+-+-+
! ! ! !
!Protected! IPsec Transport !Protected!
!Endpoint !<-------------------------------->!Endpoint !
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
draft-dupont-ikev2-addrmgmt-03.txt [Page 9]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
In this scenario, both protected endpoints of the IP connection
implement IPsec both the first one does not support IKE. The
negotiator endpoint needs only to implement IKE. Address
management is not supported for the IPsec SAs between the two
protected endpoints because the negotiator endpoint has no
control over the address of the protected endpoint it establishes
on the behalf of. For instance, NAT traversal is not supported.
In the environments addressed by this document, the protected
endpoint is the same than the negotiator but another address
is used. As this other address is in the peer address set, there
is no authorization issue.
Annex B. Peer Address Notification Format.
The following diagram illustrates the content of the Peer Address
Notification:
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Address Family ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The notification header is for IKE SA (Protocol-ID 0, SPI Size 0
and no SPI. The Address Family is from IANA Address Family Numbers
(IPv4 is 1 and IPv6 2). The proposed names are PEER-ADDRESS-SOURCE
and PEER-ADDRESS-DESTINATION, with 248XX.
Annex C. Peer Address Update Payload Format.
The next figure 17 shows the format of the Peer Address Update
Payload. It is possible to send multiple SPIs in a Peer Address
Update payload, however, each SPI MUST be for the same
protocol. Mixing of Protocol Identifiers MUST NOT be performed in a
the Peer Address Update payload. It is permitted, however, to
include multiple Peer Address Update payloads in a single
INFORMATIONAL Exchange where each Peer Address Update payload lists
SPIs for a different protocol.
Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but
no SPIs. Update of a CHILD_SA, such as ESP or AH, will contain the
Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the
SPI the sending endpoint would expect in inbound ESP or AH packets.
draft-dupont-ikev2-addrmgmt-03.txt [Page 10]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
The following diagram illustrates the content of the Peer Address
Update Notification:
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A| Protocol-ID ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o All (1 bit) - MUST be set to one when all SAs (the IKE SA and
all tunnel mode outgoing IPsec SAs negotiated by it) are
updated. In this case the update is for the IKE-SA (Protocol-ID
0, SPI size 0, no SPI and number of SPIs 0). MUST be set to zero
when an individual SA is updated.
o Protocol_Id (7 bits) - Must be zero for an IKE_SA, 1 for
ESP, or 2 for AH.
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. Zero for IKE (SPI is in message header)
or four for AH and ESP.
o # of SPIs (2 octets) - The number of SPIs contained in the Peer
Address Update Notification. The size of each SPI is defined by
the SPI Size field.
o Security Parameter Index(es) (variable length) - Identifies the
specific security association(s) to delete. The lengths of these
fields are determined by the SPI Size and # of SPIs fields.
ESP and AH SAs always exist in pairs, with one SA in each direction.
When an SA is updated for a peer address, both members of the pair
MUST be updated. When SAs are nested, as when data (and IP headers
if in tunnel mode) are encapsulated first with IPcomp, then with
ESP, and finally with AH between the same pair of endpoints, all of
the SAs MUST be updated together. Each endpoint MUST update the SAs
it receives on and allow the other endpoint to update the other SA
in each pair.
To update a peer address of an SA, an Informational Exchange with
one or more peer address update payloads is sent listing the SPIs
(as they would be placed in the headers of inbound packets) of the
SAs to be updated. The recipient MUST update the designated SAs.
Normally, the reply in the Informational Exchange will contain peer
address update payloads for the paired SAs going in the other
direction. Note there is no special case for update collision.
The proposed name is the Update (U) payload.
draft-dupont-ikev2-addrmgmt-03.txt [Page 11]
INTERNET-DRAFT Address Management for IKEv2 Jun 2003
Annex D. PF_KEY version 2 SADB_X_ADDUPD
This annex describes an extension to PF_KEYv2 [10] which provides
a way to ask a peer address update of an IPsec SA and all its
siblings (i.e., an update with the All flag set to one).
The format of the message is:
<base, SA(*), address(SD), new_address(SD)>
and is sent the registered socket listeners by or via the kernel.
No answer is needed because if it fails it will be done again.
New values are needed for SADB_X_ADDUPD and for
SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST
which should have the same layout than SADB_EXT_ADDRESS_*,
i.e., sadb_address structure.
NOTE: IKE itself needs a PF_KEYv2 extension for individual
updating of an IPsec SA.
draft-dupont-ikev2-addrmgmt-03.txt [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-22 15:19:09 |