[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Configuration payload for IKEv2
Attached is a draft which is intended to be merged with the IKEv2 draft.
There is no intent for this draft to continue on its own. It contains a
payload and description of how an IPsec Remote Access Client (IRAC) may use
that payload to get configuration information (internal IP, subnets, etc.)
from an IPsec Remote Access Server (IRAS).
The payload in this draft is very similar to the IKEv1 modecfg draft, this
draft states the differences between the two.
Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in
November, 2002, the IPsec WG decided to add remote access capabilities
(legacy authentication and remote client configuration) to IKEv2. At an
informal design team meeting after the WG meeting, the VPN vendors attending
decided that the best options to propose to the WG were to add capabilities
similar to XAUTH and MODE-CFG."
Please send all comments regarding this draft to ipsec@lists.tislabs.com
Thanks,
Darren
INTERNET-DRAFT Darren Dukes
Expires July 2003
Document: <draft-dukes-ikev2-config-payload-00.txt> Cisco Systems
December 2002
Configuration payload
<draft-dukes-ikev2-config-payload-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This document proposes changes to IKEv2 [IKEv2] to allow
configuration data to be securely distributed to IPsec Remote Access
Clients (IRACs) by IPsec Remote Access Servers (IRASs). It is
assumed this draft will be merged with the IKEv2 draft [IKEv2] and
refers to sections in that draft, preceded by "****”. This draft,
on its own, is not intended to progress to any RFC status.
Comments regarding this draft should be sent to ddukes@cisco.com or
ipsec@lists.tislabs.com
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 [2].
Dukes 1
IKEv2 Configuration Payload December 2002
Table of Contents
1. Introduction...................................................3
1.1. Changes from draft-dukes-ike-mode-cfg-02.txt.................3
1.2. Reader Prerequisites.........................................3
2. IKE_SA_AUTH Exchange changes...................................3
2. Informational (Phase 2) Exchanges..............................4
3. Configuration Payload..........................................4
3.1. Configuration Attributes.....................................6
4. Notify Message Types...........................................8
5. Implementation Notes...........................................8
5.1. Requesting an Internal Address...............................8
5.2. Requesting the Peer's Version................................9
6. Enterprise Management Considerations..........................10
7. Security Considerations.......................................10
8. References....................................................10
9. Acknowledgments...............................................11
10. Author's Addresses...........................................11
Full Copyright Statement.........................................12
Dukes 2
IKEv2 Configuration Payload December 2002
1. Introduction
In remote access scenarios it is desirable and often necessary for
an IRAS to provide configuration data, such as an internal IP
address, to an IRAC before Child-SAs are created. This document
describes requirements on TSi and TSr, and an additional
Configuration Payload in message 3 and 4 (IKE_SA_AUTH) of IKE-SA
creation in order to provide configuration data necessary for the
creation of Child-SAs. The Configuration Payload MAY also be used
within an Informational Exchange protected by an IKE-SA to request
or set configuration data from or to an IKE peer.
1.1. Changes from draft-dukes-ike-mode-cfg-02.txt
This document is similar to draft-dukes-ike-mode-cfg-02.txt for
IKEv1 [IKE], but is not intended to interoperate directly with
implementations of that draft.
Some differences for IKEv2
1 - No transaction exchange, use the Informational exchange and the
IKE_SA_AUTH exchange.
2 - The payload was called Attribute payload in the IKEv1 modecfg,
it is called Configuration payload in IKEv2.
3 - No Identifier in the Configuration Payload since this was a
major point of confusion in the IKEv1 modecfg draft, with no known
use other than XAUTH.
4 - Configuration payloads are always secured via the IKE-SA.
1.2. Reader Prerequisites
It is assumed that the reader is familiar with Proposal for the
Internet Key Exchange (IKEv2) Protocol [IKEv2]
2. IKE_SA_AUTH Exchange changes
**** [Below are changes to section 3.1 of [IKEv2], Message 3 and 4 are
modified to include the Configuration Payload and additional
description of CP and TS requirements are added]
HDR, SAi1, KEi, Ni, Nr,
SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, [CP], SAi2, TSi, TSr} -->
The optional CP (Configuration Payload) MAY be sent by the initiator
to request configuration data. If CP is used to request an internal
IP address (as is often the case when the initiator is an IRAC) the
initiator may not know what to place in the TSi payload, in this
case she MUST include at least one Traffic Selector in TSi with a
suitable range of ports, and addresses. As an example, if the
initiator did not have a selector trigger SA creation (as may be the
case when an IRAC starts up) she may include the selector (0.0.0.0-
Dukes 3
IKEv2 Configuration Payload December 2002
255.255.255.255) all ports and protocols. At least one suitable
selector MUST be included in TSr. Continuing with this example, the
initiator may not have any knowledge of the addresses secured by the
responder so she MAY include the selector (0.0.0.0-255.255.255.255)
all ports and protocols, requiring the responder to choose a
narrower selector if necessary.
<-- HDR, SK {IDr, [CERT,] AUTH,
[CP], SAr2, TSi, TSr}
If CP was present in message 3 there MUST be a corresponding CP in
message 4. When the responder sends a CP containing an internal IP
address in message 4, he MUST limit the traffic selector(s) in TSi
to contain only the address, or addresses, in the CP. The responder
MAY choose to limit TSr as described in section 4.9 Negotiating
Traffic Selectors of [IKEv2].
2. Informational (Phase 2) Exchanges
**** [This is an amendment to [IKEv2] section 3.3, paragraph 5 and the
exchange description at the end of that section]
Messages in an Informational Exchange may contain zero or one
Configuration Payloads. If there is a Configuration Payload in a
request there MUST be a corresponding Configuration Payload in the
response.
The Informational Exchange is defined as:
Initiator Responder
----------- -----------
HDR, SK {N, ..., D, ..., CP, ...} -->
<-- HDR, SK {N, ..., D, ..., CP, ...}
3. Configuration Payload
**** [This should be added to [IKEv2] section 5.?]
A Configuration payload, denoted CP in this document, is used to
exchange configuration information between IKE peers. Typically the
peers would be an IRAC and IRAS. A Configuration Payload MAY appear
in an Informational exchange, or an IKE_SA_AUTH exchange, and MUST
NOT be in any other exchanges.
Configuration payloads are of type CFG_REQUEST/CFG_REPLY or
CFG_SET/CFG_ACK (see CFG Type in the payload description below)
o "CFG_REQUEST/CFG_REPLY" allows an IRAC to request information from
an IRAS. If an attribute in the CFG_REQUEST Configuration Payload
is not zero length it is taken as a suggestion for that attribute.
The CFG_REPLY Configuration Payload MAY return that attribute, or a
new one. It MAY also add new attributes and not include some
requested ones.
Dukes 4
IKEv2 Configuration Payload December 2002
A CFG_REPLY MUST be sent when a CFG_REQUEST is received, even if it
is empty, or missing attributes from the CFG_REQUEST. This merely
means that the requested attributes were not available or unknown.
Initiator Responder
--------------- --------------
HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)}
o "CFG_SET/CFG_ACK" allows an IRAS to push configuration data to an
IRAC. In this case the CFG_SET Configuration Payload contains
attributes the initiator wants its peer to alter. The responder
MUST return a Configuration Payload and it MUST contain the zero
length attributes that the responder accepted. Those attributes
that it did not accept MUST NOT be in the CFG_ACK Configuration
Payload.
Initiator Responder
--------------- --------------
HDR, SK{CP(CFG_SET)} -->
<-- HDR, SK{CP(CFG_ACK)}
The Configuration Payload is defined as follows:
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CFG Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Configuration Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes.
Types Value
================ ===========
RESERVED 0
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4
values 5-127 are reserved to IANA. Values 128-255 are for private
use among mutually consenting parties.
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored.
Dukes 5
IKEv2 Configuration Payload December 2002
o Configuration Attribute (variable length) - These are type length
values specific to the Configuration Payload and are defined below.
There may be zero or more Configuration Attributes in this payload.
The payload type for the Configuration Payload is **TBD** (**TBD**).
3.1. Configuration Attributes
**** [ This section would be a subsection 5.?.1]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored.
o Attribute Type (7 bits) - A unique identifier for each of the
Configuration Attribute Types, the following are currently defined:
MUST
Attribute Type Value Support Length
======================= ===== ======= ==================
RESERVED 0
INTERNAL_IP4_ADDRESS 1 YES 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 NO 0 or 4 octets
INTERNAL_IP4_NBNS 4 NO 0 or 4 octets
INTERNAL_ADDRESS_EXPIRY 5 YES 0 or 4 octets
INTERNAL_IP4_DHCP 6 NO 0 or 4 octets
APPLICATION_VERSION 7 YES 0 or more
INTERNAL_IP6_ADDRESS 8 YES 0 or 16 octets
INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets
INTERNAL_IP6_DNS 10 NO 0 or 16 octets
INTERNAL_IP6_NBNS 11 NO 0 or 16 octets
INTERNAL_IP6_DHCP 12 NO 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 YES 0 or multiples of 2
INTERNAL_IP6_SUBNET 15 YES 0 or 17 octets
values 16-16383 are reserved to IANA. Values 16384-32767 are for
private use among mutually consenting parties.
Dukes 6
IKEv2 Configuration Payload December 2002
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or private
address and MAY be a private address on the Internet. Multiple
internal addresses MAY be requested by requesting multiple
internal address attributes. The responder MAY only send up to
the number of addresses requested.
The requested address is valid until the expiry time defined with
the INTERNAL_ADDRESS EXPIRY attribute or there are no IKE-SAs
between the peers.
o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal
network's netmask. Only one netmask is allowed in the request and
reply messages (e.g. 255.255.255.0) and it MUST be used only with
an INTERNAL_ADDRESS attribute.
o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a
DNS server within the network. Multiple DNS servers MAY be
requested. The responder MAY respond with zero or more DNS server
attributes.
o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a
NetBios Name Server (WINS) within the network. Multiple NBNS
servers MAY be requested. The responder MAY respond with zero or
more NBNS server attributes.
o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that
the host can use the internal IP address. The host MUST renew the
IP address before this expiry time. Only one of these attributes
MAY be present in the reply.
o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to
send any internal DHCP requests to the address contained within
the attribute. Multiple DHCP servers MAY be requested. The
responder MAY respond with zero or more DHCP server attributes.
o APPLICATION_VERSION - The version or application information of
the IPSec host. This is a string of printable ASCII characters
that is NOT null terminated.
o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields; the
first being an IP address and the second being a netmask.
Multiple sub-networks MAY be requested. The responder MAY respond
with zero or more sub-network attributes.
o SUPPORTED_ATTRIBUTES - When used within a Request, this
attribute must be zero length and specifies a query to the
responder to reply back with all of the attributes that it
supports. The response contains an attribute that contains a set
of attribute identifiers each in 2 octets. The length divided by
2 (bytes) would state the number of supported attributes contained
in the response.
Dukes 7
IKEv2 Configuration Payload December 2002
o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields; the
first being a 16 octet IPv6 address the second being a one octet
prefix-mask as defined in [ADDRIPV6]. Multiple sub-networks MAY
be requested. The responder MAY respond with zero or more sub-
network attributes.
Note that no recommendations are made in this document how an
implementation actually figures out what information to send in a
reply. i.e. we do not recommend any specific method of an IRAS
determining which DNS server should be returned to a requesting
IRAC.
o Length (2 octets) - Length in octets of Value.
o Value (0 or more octets) - The variable length value of this
Configuration Attribute.
4. Notify Message Types
**** [ This section is an amendment to 5.10.1 of [IKEv2] ]
INTERNAL-ADDRESS-FAILURE 36
Indicates an error assigning an internal address (i.e.,
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the
processing of a Configuration Payload by a Responder. If this
error is generated within an IKE_SA_AUTH exchange no Child-SA
will be created.
5. Implementation Notes
****[ This section and its subsections should be placed in an appendix
to [IKEv2] ]
The following descriptions detail how to perform specific functions
using the configuration payload. Other functions are possible and
thus this list is not a complete list of all of the possibilities.
While other functions are possible, the functions listed below MUST
be performed as detailed in this document to preserve
interoperability among different vendor's implementations.
5.1. Requesting an Internal Address
This function provides address allocation to an IRAC trying to
tunnel into a network protected by an IRAS. Since the IKE_SA_AUTH
exchange creates an IKE-SA and a Child-SA the IRAC MUST request the
internal address, and optionally other information concerning the
internal network, in the IKE_SA_AUTH exchange. The may IRAS procure
Dukes 8
IKEv2 Configuration Payload December 2002
an internal address for the IRAC from any number of sources such as
a DHCP/BOOTP server or its own address pool.
Initiator Responder
----------------------------- -------------------------------
HDR, SAi1, KEi, Ni, Nr,
SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2, TSi, TSr}
CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
(either IPv4 or IPv6) but MAY contain any number of additional
attributes the initiator wants returned in the response.
For example, message from Initiator to Responder:
CP(CFG_REQUEST)=
INTERNAL_ADDRESS(0.0.0.0)
INTERNAL_NETMASK(0.0.0.0)
INTERNAL_DNS(0.0.0.0)
TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
TSr = (0, 0-65536,0.0.0.0-255.255.255.255)
NOTE: Traffic Selectors are a (protocol, port range, address range)
message from Responder to Initiator:
CP(CFG_REPLY)=
INTERNAL_ADDRESS(192.168.219.202)
INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(192.168.219.0/255.255.255.0)
TSi = (0, 0-65536,192.168.219.202-192.168.219.202)
TSr = (0, 0-65536,192.168.219.0-192.168.219.255)
All returned values will be implementation dependent. As can be
seen in the above example, the IRAS MAY also send other attributes
that were not included in CP(CFG_REQUEST) and MAY ignore the non-
mandatory attributes that it does not support.
5.2. Requesting the Peer's Version
An IKE peer wishing to inquire about the other peer's version
information MUST use the method below. This is an example of a
configuration request within an Informational Exchange, after the
IKE-SA and first Child-SA have been created.
Initiator Responder
----------------------------- --------------------------
HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)}
Dukes 9
IKEv2 Configuration Payload December 2002
CP(CFG_REQUEST)=
APPLICATION_VERSION("")
CP(CFG_REPLY)
APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")
6. Enterprise Management Considerations
****[ Something similar to this section could be placed in an appendix
to [IKEv2] as well]
The method defined in this document SHOULD NOT be used for wide
scale management. Its main intent is to provide a bootstrap
mechanism to exchange information within IPSec from IRAS to IRAC.
While it MAY be useful to use such a method to exchange information
between some Security Gateways (SGW) or small networks, existing
management protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or
LDAP [LDAP] should be considered for enterprise management as well
as subsequent information exchanges.
7. Security Considerations
This draft defines a payload for the Informational Exchange and MUST
be protected by an IKE-SA.
8. References
[1] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[IKE] D. Harkins, D. Carrel, "The Internet Key Exchange
(IKE)", RFC240
[IKEv2] Charlie Kaufman, "Internet Key Exchange(IKEv2) Protocol”
draft-ietf-ipsec-ikev2-03.txt
[DHCP] R. Droms, "Dynamic Host Configuration Protocol",
RFC2131
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138
[LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory
Access Protocol (v3)", RFC2251
[ESP] S. Kent, "IP Encapsulating Security Payload (ESP)",
RFC2406
Dukes 10
IKEv2 Configuration Payload December 2002
[ADDRIPV6] Hinden, R., "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
. Acknowledgments
The editor would like to thank Stephane Beaulieu, Dan Harkins,
Derrell Piper, and Paul Hauffman.
0. Author's Addresses
Darren Dukes
Cisco Systems Co.
2000 Innovation Drive
Kanata, ON, Canada
Phone: 1-613-254-3679
Email: ddukes@cisco.com
ukes 11
IKEv2 Configuration Payload December 2002
ull Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
This Internet Draft expires July 2003
ukes 12