[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DHCP over IKE draft 2/3
IP Security Protocol Working Group (IPSEC) T. Kivinen
INTERNET-DRAFT 2 April 2003
draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.txt
Expires: 2 October 2003
Using DHCP server/client backend for DHCP over IKE
Status of This Memo
This document is a submission to the IETF IP Security Protocol
(IPSEC) Working Group. Comments are solicited and should be
addressed to the working group mailing list (ipsec@lists.tislabs.com)
or to the editor.
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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 describes method of using dynamic host configuration pro-
tocol (DHCP) as a backend for the internet key exchange (IKE) version 2
host configuration protocol.
T. Kivinen [page 1]
INTERNET-DRAFT 2 April 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Using existing DHCP client . . . . . . . . . . . . . . . . . . . 2
3. Using existing DHCP server . . . . . . . . . . . . . . . . . . . 2
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . . 4
7. Non-Normative References . . . . . . . . . . . . . . . . . . . . 5
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The IKEv2 [IKEV2] offers way to put DHCP [RFC2131] packets inside the
IKE packet exchange to do the host configuration for the remote access
clients. This protocol describes how to use existing DHCP client and/or
server with IKEv2 host configuration protocol.
2. Using existing DHCP client
The host configuration protocol in IKEv2 is defined so that it can be
easily be used with currently existing DHCP client. All packets normally
sent by the DHCP client are simply intercepted and put inside the DHCP
payload. If this is during the initial IKE SA creation phase, the the
DHCP payloads are sent inside the IKE_AUTH packets. If the DHCP packet
is intercepted when the IKE SA is already ready, then the DHCP payloads
are sent as informational exchange. Informational exchanges MUST NOT be
used before the IKE SA creation is finished.
The reason for the interception and sending DHCP packets inside IKE is
that the IPsec SAs created between the client and security gateway might
not allow DHCP traffic, and also because replies to the DHCP packets
might come as broadcast in some cases (DHCPNAK), and to get those
working we MUST use DHCP relay processing in the security gateway end.
Also the actual configuration backend on the other end might not be DHCP
server, but for example RADIUS [RFC2865] server.
Note, that the reply to the information exchange having DHCP payload,
might not contain the reply to the actual DHCP request, i.e it might be
empty, and the reply might be sent as separate informational exchange
initiated by the security gateway when the reply packet is available or
during the next reply to IKE_AUTH if the IKE SA is not yet ready.
3. Using existing DHCP server
If the security gateway wants to use existing DHCP server(s) it MUST act
as a DHCP relay. When it receives DHCP payload from the client it MUST
set the giaddr field to contain one of its own IP addresses, and it
SHOULD add DHCP Relay Agent Information Option [RFC3046] (DHCP option
code 82) as last DHCP option just before end option. The Agent Circuit
ID Sub-option (sub-option code 1) is filled with the security gateways
T. Kivinen [page 2]
INTERNET-DRAFT 2 April 2003
IKE SPI value.
In some cases the security gateway might put this DHCP relay to its own
IP alias and use that address in the giaddr field. This is especially
useful if the security gateway already has DHCP server or DHCP relay
running.
Where the DHCP server does not support the Relay Agent Information
Option, stateless Relay Agent behavior will not be possible. In such
cases, implementations MAY devise a mapping between the xid, chaddr, and
IKE SA in order to route the DHCP server response to the appropriate IKE
SA. Note that this is particularly undesirable in large VPN servers
where the resulting state will be substantial.
After sending the request out (either to the configured DHCP server(s)
or to broadcast address), the security gateway should wait for
configurable time (default should be few seconds) and collect replies
received during that. The security gateway might reply immediately when
the first reply is received, or it might wait for the full time and send
all packets received during that time. It normally is not useful to wait
for multiple DHCPACK packets, as there should only be exactly one of
those. On the other hand when waiting for the DHCPOFFER packets in
environment where there are multiple DHCP servers available (load
balancing, high availability cases etc) it might be better to wait for
more than one DHCPOFFER packet.
When the security gateway gets DHCP replies back from the network it
should use the DHCP Relay Agent Information to associate the reply to
specific IKE SA. The security gateway MUST remove the DHCP Relay Agent
Information Option and set the giaddr to 0 before encoding the DHCP
packet inside the IKE DHCP payload.
If during the IKE SA creation phase the security gateway receives DHCP
replies during the time it does not have request to be replied (i.e it
has replied to last IKE request from the client, and the client has not
yet sent a next request), it MUST keep at least the last DHCP reply it
has received, and send it to the client when possible (i.e when the
client makes next IKE request). Security gateway cannot during the IKE
SA creation phase initiate exchanges to the client itself, it must wait
for the client to drive the exchange.
After the IKE SA is created then the security gateway can send replies
back to the client as separate informational exchanges.
When security gateway sees DHCPACK it must get the yiaddr from the
payload and configure that to be the clients IP address. This clients IP
address is used during the IKE_AUTH exchange to narrowing the TSi
selector down to only include clients IP address. Security gateway MUST
also make sure that if the same client IP address is given out to two
different entities (== clients IKE SA authenticated IKE identity are
different) the older one of those IPsec SAs is deleted.
I.e if DHCPACK is received to address which is already associated with
T. Kivinen [page 3]
INTERNET-DRAFT 2 April 2003
some other entity, then the old entities IPsec SAs are deleted.
The DHCP server should be sending the reply packets to the Relay
address, i.e to the security gateway, but in some cases the DHCP server
might also try to send the packet directly to the client's IP address
(DHCP renewing state, or replies to DHCPINFORMs). The security gateway
SHOULD try to intercept all DHCP packets going directly to clients IP
address and encapsulate them inside the DHCP payload in the IKE SA. This
is never needed for the IKE_AUTH state as the DHCP server will not try
to send packets directly to the client (the client is either in DHCP
init or DHCP init-reboot state, it cannot be in DHCP renewing state).
The reason for the interception is to make sure the DHCP requests gets
back to the client even if the IPsec SA created between client and
security gateway does not allow DHCP traffic in it, or the client might
not be actually using DHCP client to do the configuration. As any of
those packets going directly to the client cannot have effect to the
security gateway operations, there is no mandatory requirement for the
security gateway to intercept those packets.
Only packet that could affect the security gateway operations are the
DHCPACKs which have different IP address than given in previous case,
and those packets cannot be sent to the client directly.
If client never gets DHCPACK back (which might be sent by the DHCP
server directly to the client) when in DHCP renewing state, it moves to
DHCP rebinding state, which uses broadcasts, and the client will get
packets through.
The client MUST NOT use DHCPINFORM packets, but use normal DHCP address
allocation instead. The security gateway does need to support DHCPINFORM
processing.
4. Security Considerations
If real DHCP server is used, then the DHCP protocol between security
gateway and the DHCP server might be vulnerable to different kind of
attacks. If the DHCP server is inside the security gateway itself then
such attacks are not possible.
5. IANA Considerations
This document does not have any actions for IANA.
6. Normative References
[IKEV2]
Kaufman C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-
ipsec-ikev2-05.txt, February 2003
[RFC3046]
Patrick M., "DHCP Relay Agent Information Option", January 2001
T. Kivinen [page 4]
INTERNET-DRAFT 2 April 2003
[RFC2131]
Droms R., "Dynamic Host Configuration Protocol", March 1997
7. Non-Normative References
[RFC2865]
Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote
Authentication Dial In User Service (RADIUS)", June 2000.
[RFC1533]
Alexander S., and Droms R., "DHCP Options and BOOTP Vendor
Extensions", October 1993.
8. Authors' Addresses
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
FIN-00100 HELSINKI
Finland
E-mail: kivinen@ssh.fi
T. Kivinen [page 5]
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/