Network Working Group CY Lee Internet Draft Expiration Date: September 2002 March, 2002 Customer Equipment Auto-configuration Status of this Memo 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 draft describes the protocols required to automatically configure a Customer Equipment (CE) to support a VPN service offered by the provider (aka as Provider Provisioned CE-based VPN). 1. Motivation To offer provider provisioned CE-based VPNs, a provider has to configure the CEs (either at customer premises or a priori). In CE-based VPNs, if a client site of a VPN is removed, other CE(s) belonging to the VPN must be reconfigured. It is desirable to be able to perform this reconfiguration remotely or automatically. PP CE-based VPNs which do not require the provider to manually perform configuration on the CEs at the customer premises reduces the cost of service deployment. [Note: Typically in PP CE-based VPN, the CEs are owned by the provider.] 2. Overview A CE shall be automatically configured with an IP address to allow it to communicate with the provider's network and be provisioned with the services offered to the customer. Both the automatic configuration of IP address on the CE and provisioning of services on the CE should be authenticated to prevent malicious users from tampering with CE configuration. Figure 1 below is based on Figure 1 from [CE-VPN] and shows the reference model for auto-configuration of CEs for PP CE-based VPN. Customer | Provider's network | Customer Site | | site | +-----------+ | | |DHCP_Server| | | +-----------+ | | | | edge edge | | router router | Customer ---CE1 ----PE1------- Backbone -----PE2-----CE2---- Customer X's network | | X's network | | | | Figure 1: Reference model for auto-configuration of CEs 3. Auto-configuration of IP address of CE A CE may use DHCP to automatically obtain and configure its IP address. The CE shall obtain an IP address from a DHCP server using the procedures defined in [DHCP]. The DHCP server and CE shall be configured with a shared key a priori. The CE and the DHCP server shall use the Delayed Authentication protocol defined in [DHCP-AUTH] (instead of Configuration Token). A CE should authenticate a DHCP server to ensure the DHCP server is the provider's DHCP server and not a rogue server. A DHCP server should authenticate the CE to ensure the CE is a legitimate DHCP client. No changes to [DHCP] and [DHCP-AUTH] are required during the auto-configuration of IP address of CE as described above. 4. Auto-configuration of VPN service parameters Once a CE has been automatically configure with an IP address the CE is able to communicate with the network. Two different approaches are described here to configure the CE to provide VPN service: i) The CE may automatically configure itself (VPN tunnels to other sites) using VPN information obtained from the network, via for e.g. the DHCP server. ii) The CE may be remotely configured (automatically or otherwise) by the network, for e.g.by a VPN Manager/Server in the provider's network. The CE is provided with the address of the VPN Manager/Server during DHCP auto-configuration, and shall be able to contact the VPN Manager/Server to initiate VPN service auto-configuration. 4.1 VPN service parameters The parameters that can be auto-configured at a CE device to automatically setup IPSec tunnels include: i) the list of remote CE IP address(es) ii) the transform sets defining the security protocols and algorithms that shall be used by two CEs for encryption and authentication The (pre-shared or CE's private) key for IPSec must be pre-configured on the CE. Other VPN service related configuration which do not change as sites are removed or added to a VPN may also be configured a priori. The intent here is to standardize a minimal set of VPN service parameters that should be auto-configured. Hence, this draft shall focus on the auto-configuration of tunnel(s) to remote CE(s). If necessary, the transform sets and other service parameters shall be defined to be auto-configured in future. It is assumed for now, the transform sets configured on a CE shall be applicable to all the IPSec tunnel(s) to other CEs of the same VPN. 5. Auto-configuration of VPN service - using DHCP only Once the CE has obtained an IP address, the CE shall send DHCPINFORM directly to the DHCP server to solicit for other configuration information. The DHCP server shall respond with a DHCPACK and the following VPN related DHCP option(s). If a VPN site is removed or added (or the CEs must be updated with new VPN configuration information), the DHCP server may send DHCP FORCERENEW to the CEs belonging to the VPN. The CEs shall send DHCPINFORM as described in the previous paragraph to obtain new VPN site information. This section lists the new DHCP option(s) required. 5.1 Peer CE DHCP Option The Peer CE option specifies a list of Peer CE(s) which the client may connect to. The CE should setup a tunnel to every Peer CE listed. The code for this option is to be assigned by IANA. The minimum length for this option is 4 octets, and the length MUST always be a multiple of 4. Code Len CE Address 1 CE Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- 6. Auto-configuration of VPN service - using a VPN Server The CE is provided with the address of the VPN Server during DHCP IP address auto-configuration, and shall be able then to contact the VPN server. VPN configuration parameters may be solicited from a VPN server or sent to a CE using a transport protocol such as https or BEEP. The use of an appropriate transport protocol is to be determined. This approach is suitable if there are a large number of configurations to be performed on CEs and a richer management support is required on CEs. The CE must be pre-configured with the CE's private key and digital certificate and the provider's Certificate Authority. 6.1 Default VPN Server DHCP Option The new DHCP option required is the VPN Server option. The VPN Server option specifies a list of servers available to the client. VPN Server should be listed in order of preference. The code for this option is TBD. The minimum length for this option is 4 octets, and the length MUST always be a multiple of 4. Code Len Address 1 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- 6.2 VPN configuration parameters The VPN configuration parameters are XML based. The tag specifies a list of tunnels, (local CE interface, remote CE interface) pairs. s1.s2.s3.s4 d1.d2.d3.d4 sa.sb.sc.sd da.db.dc.dd ..... 7. Security Considerations The addition of DHCP option(s) for VPN auto-configuration does not affect the security of DHCP. The security issues of DHCP are described in [DHCP-AUTH] and as it pertains to the auto-configuration of CEs, the security issues are described in this draft. If an unauthorised CE configure its own IP address, the CE may not be permitted to use any services unless the CE has been authenticated for the particular service. For e.g. a device or the default filter at the ingress to the network can be configured to discard all traffic except DHCP messages from the client (port 67) unless the client has been authenticated for services as described in Section 5. In addition all DHCP messages on port 68 from the client should be discarded (a network user should not be sending DHCP messages from a DHCP server into the provider's network). This measure which is applicable to Section 5, does not prevent a malicious user from launching a DoS attack on DHCP servers in the provider's network. [Note: If Layer 2 authentication is available, (e.g. 802.1x), it may be used to provide authenticated access to the Layer 2 network. In this case, unauthorised users are not allowed to send traffic]. To reduce DoS attacks, the DHCP server may choose to remember which client DHCP message failed to pass validation after a specified number of failures and may log the authentication failure. Subsequent messages from that client may be discarded. If these measures are necessary, the text in DHCP-AUTH would need to be modified accordingly. 8. Authors' Information Cheng-Yin Lee Email: Cheng-Yin.Lee@alcatel.com 9. References [DHCP] Dynamic Host Configuration Protocol, http://www.ietf.org/rfc/rfc2131.txt [DHCP-AUTH] Authentication for DHCP Messages, ftp://ftp.isi.edu/in-notes/rfc3118.txt [CE-VPN] A Framework for Provider Provisioned CE-based Virtual Private Networks http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-ce-based-01.txt [DSL_autoconf] Technical Report TR-044, "Auto-Configuration for Basic Internet (IP-based) Services", DSL Forum, November 2001 [HTTP-BCP] http://www.ietf.org/rfc/rfc3205.txt?number=3205 [PPVPN-REQ] http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-requirements-03.txt