draft-iab-ip-config-02.txt   draft-iab-ip-config-03.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
INTERNET-DRAFT D. Thaler INTERNET-DRAFT D. Thaler
Category: Informational Microsoft Corporation Category: Informational Microsoft Corporation
Expires: September 15, 2008 Loa Andersson Expires: September 20, 2008 Loa Andersson
15 March 2008 Acreo AB 20 March 2008 Acreo AB
Internet Architecture Board Internet Architecture Board
Principles of Internet Host Configuration Principles of Internet Host Configuration
draft-iab-ip-config-02.txt draft-iab-ip-config-03.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 15, 2008. This Internet-Draft will expire on September 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes principles of Internet host configuration. This document describes principles of Internet host configuration.
It covers issues relating to configuration of Internet layer It covers issues relating to configuration of Internet layer
parameters, as well as parameters affecting higher layer protocols. parameters, as well as parameters affecting higher layer protocols.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1 Terminology ........................................ 3 1.1 Terminology ........................................ 3
2. Principles ............................................... 6 2. Principles ............................................... 6
2.1 Minimize Configuration ............................. 6 2.1 Minimize Configuration ............................. 6
2.2 Less is More ....................................... 6 2.2 Less is More ....................................... 6
2.3 Diversity is Not a Benefit ......................... 7 2.3 Diversity is Not a Benefit ......................... 7
2.4 Lower Layer Independence ........................... 8 2.4 Lower Layer Independence ........................... 8
2.5 Configuration is Not Access Control ................ 9 2.5 Configuration is Not Access Control ................ 9
3. Additional Discussion .................................... 10 3. Additional Discussion .................................... 10
3.1 General Purpose Mechanisms ......................... 10 3.1 General Purpose Mechanisms ......................... 10
3.2 Service Discovery .................................. 10 3.2 Service Discovery .................................. 10
4. Security Considerations .................................. 12 4. Security Considerations .................................. 13
4.1 Configuration Authentication ....................... 13 4.1 Configuration Authentication ....................... 13
5. IANA Considerations ...................................... 14 5. IANA Considerations ...................................... 14
6. References ............................................... 14 6. References ............................................... 14
6.1 Informative References ............................. 14 6.1 Informative References ............................. 14
Acknowledgments .............................................. 16 Acknowledgments .............................................. 17
Appendix A - IAB Members ..................................... 17 Appendix A - IAB Members ..................................... 17
Authors' Addresses ........................................... 17 Authors' Addresses ........................................... 18
Full Copyright Statement ..................................... 18 Full Copyright Statement ..................................... 18
Intellectual Property ........................................ 18 Intellectual Property ........................................ 19
1. Introduction 1. Introduction
This document describes principles of Internet host configuration. This document describes principles of Internet host configuration.
It covers issues relating to configuration of Internet layer It covers issues relating to configuration of Internet layer
parameters, as well as parameters affecting higher layer protocols. parameters, as well as parameters affecting higher layer protocols.
In recent years, a number of architectural questions have arisen, for In recent years, a number of architectural questions have arisen, for
which we provide guidance to protocol developers: which we provide guidance to protocol developers:
skipping to change at page 6, line 12 skipping to change at page 6, line 12
such as printers, Session Initiation Protocol (SIP) proxies, such as printers, Session Initiation Protocol (SIP) proxies,
etc. etc.
2. Principles 2. Principles
This section describes basic principles of Internet host This section describes basic principles of Internet host
configuration. configuration.
2.1. Minimize Configuration 2.1. Minimize Configuration
Anything that can be configured can be misconfigured. RFC 1958 Anything that can be configured can be misconfigured. "Architectural
[RFC1958] Section 3.8 states: "Avoid options and parameters whenever Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid
possible. Any options and parameters should be configured or options and parameters whenever possible. Any options and parameters
negotiated dynamically rather than manually." should be configured or negotiated dynamically rather than manually."
That is, to minimize the possibility of configuration errors, That is, to minimize the possibility of configuration errors,
parameters should be automatically computed (or at least have parameters should be automatically computed (or at least have
reasonable defaults) whenever possible. For example, the reasonable defaults) whenever possible. For example, the
Transmission Control Protocol (TCP) [RFC793] does not require Transmission Control Protocol (TCP) [RFC793] does not require
configuration of the Maximum Segment Size, but is able to compute an configuration of the Maximum Segment Size, but is able to compute an
appropriate value. appropriate value.
Some protocols support self-configuration mechanisms, such as Some protocols support self-configuration mechanisms, such as
capability negotiation or discovery of other hosts that implement the capability negotiation or discovery of other hosts that implement the
skipping to change at page 6, line 48 skipping to change at page 6, line 48
span a wide range of devices, from embedded devices operating with span a wide range of devices, from embedded devices operating with
minimal footprint to supercomputers. Since the resources (e.g. minimal footprint to supercomputers. Since the resources (e.g.
memory and code size) available for host configuration may be very memory and code size) available for host configuration may be very
small, it is desirable for a host to be able to configure itself in small, it is desirable for a host to be able to configure itself in
as simple a manner as possible. as simple a manner as possible.
One interesting example is IP support in pre-boot execution One interesting example is IP support in pre-boot execution
environments. Since by definition boot configuration is required in environments. Since by definition boot configuration is required in
hosts that have not yet fully booted, it is often necessary for pre- hosts that have not yet fully booted, it is often necessary for pre-
boot code to be executed from Read Only Memory (ROM), with minimal boot code to be executed from Read Only Memory (ROM), with minimal
available memory. In PXE, prior to obtaining a boot image, the host available memory. In the Pre-boot Execution Environment (PXE), prior
is typically only able to communicate using IP and the User Datagram to obtaining a boot image, the host is typically only able to
Protocol (UDP). This is one reason why Internet layer configuration communicate using IP and the User Datagram Protocol (UDP). This is
mechanisms typically depend only on IP and UDP. After obtaining the one reason why Internet layer configuration mechanisms typically
boot image, the host will have the full facilities of TCP/IP depend only on IP and UDP. After obtaining the boot image, the host
available to it, including support for reliable transport protocols, will have the full facilities of TCP/IP available to it, including
IPsec, etc. support for reliable transport protocols, IPsec, etc.
In order to reduce complexity, it is desirable for Internet layer In order to reduce complexity, it is desirable for Internet layer
configuration mechanisms to avoid dependencies on higher layers. configuration mechanisms to avoid dependencies on higher layers.
Since embedded hosts may wish to minimize the code included within a Since embedded hosts may wish to minimize the code included within a
boot ROM, availability of higher layer facilities cannot be boot ROM, availability of higher layer facilities cannot be
guaranteed during Internet layer configuration. In fact, it cannot guaranteed during Internet layer configuration. In fact, it cannot
even be guaranteed that all Internet layer facilities will be even be guaranteed that all Internet layer facilities will be
available. For example, IP fragmentation and reassembly may not work available. For example, IP fragmentation and reassembly may not work
reliably until a host has obtained an IP address. reliably until a host has obtained an IP address.
2.3. Diversity is Not a Benefit 2.3. Diversity is Not a Benefit
The number of host configuration mechanisms should be minimized. The number of host configuration mechanisms should be minimized.
Diversity in Internet host configuration mechanisms presents several Diversity in Internet host configuration mechanisms presents several
problems: problems:
Interoperability Interoperability As configuration diversity increases, it becomes
As configuration diversity increases, it becomes likely that a likely that a host will not support the
host will not support the configuration mechanism(s) available configuration mechanism(s) available on the network
on the network to which it has attached, creating to which it has attached, creating interoperability
interoperability problems. problems.
Footprint In order to interoperate, hosts need to implement all Footprint In order to interoperate, hosts need to implement
configuration mechanisms used on the link layers they support. all configuration mechanisms used on the link layers
This increases the required footprint, a burden for embedded they support. This increases the required
devices. footprint, a burden for embedded devices.
Redundancy Redundancy To support diversity in host configuration
To support diversity in host configuration mechanisms, mechanisms, operators would need to support multiple
operators would need to support multiple configuration configuration services to ensure that hosts
services to ensure that hosts connecting to their networks connecting to their networks could configure
could configure themselves. This represents an additional themselves. This represents an additional expense
expense for little benefit. for little benefit.
Latency As configuration diversity increases, hosts supporting Latency As configuration diversity increases, hosts
multiple configuration mechanisms may spend increasing effort supporting multiple configuration mechanisms may
to determine which mechanism(s) are supported. This adds to spend increasing effort to determine which
mechanism(s) are supported. This adds to
configuration latency. configuration latency.
Conflicts Whenever multiple mechanisms are available, it is possible Conflicts Whenever multiple mechanisms are available, it is
that multiple configuration(s) will be returned. To handle possible that multiple configuration(s) will be
this, hosts would need to merge potentially conflicting returned. To handle this, hosts would need to merge
configurations. This would require conflict resolution logic, potentially conflicting configurations. This would
such as ranking of potential configuration sources, increasing require conflict resolution logic, such as ranking
of potential configuration sources, increasing
implementation complexity. implementation complexity.
Additional traffic Additional traffic To limit configuration latency, hosts may
To limit configuration latency, hosts may simultaneously simultaneously attempt to obtain configuration by
attempt to obtain configuration by multiple mechanisms. This multiple mechanisms. This can result in increasing
can result in increasing on-the-wire traffic, both from use of on-the-wire traffic, both from use of multiple
multiple mechanisms as well as from retransmissions within mechanisms as well as from retransmissions within
configuration mechanisms not implemented on the network. configuration mechanisms not implemented on the
network.
Security Support for multiple configuration mechanisms increases the Security Support for multiple configuration mechanisms
attack surface of the host. increases the potential for security vulnerabilities
in one of the mechanisms.
2.4. Lower Layer Independence 2.4. Lower Layer Independence
RFC 1958 [RFC1958] states, "Modularity is good. If you can keep RFC 1958 [RFC1958] states, "Modularity is good. If you can keep
things separate, do so." things separate, do so."
It is becoming increasingly common for hosts to support multiple It is becoming increasingly common for hosts to support multiple
network access mechanisms, including dialup, wireless and wired local network access mechanisms, including dialup, wireless and wired local
area networks, wireless metropolitan and wide area networks, etc. As area networks, wireless metropolitan and wide area networks, etc. As
a result, it is desirable for hosts to be able to configure a result, it is desirable for hosts to be able to configure
skipping to change at page 8, line 50 skipping to change at page 9, line 5
link-layer protocol independent. link-layer protocol independent.
While there are examples of IP address assignment within the link While there are examples of IP address assignment within the link
layer (such as in the Point-to-Point Protocol (PPP) IPv4CP layer (such as in the Point-to-Point Protocol (PPP) IPv4CP
[RFC1332]), the disadvantages of this approach have now become [RFC1332]), the disadvantages of this approach have now become
apparent. The main disadvantages include the extra complexity of apparent. The main disadvantages include the extra complexity of
implementing different mechanisms on different link layers, and the implementing different mechanisms on different link layers, and the
difficulty in adding new parameters which would require defining a difficulty in adding new parameters which would require defining a
mechanism in each link layer protocol. mechanism in each link layer protocol.
For example, PPP IPv4CP and Internet Protocol Control Protocol (IPCP) For example, PPP IPv4CP and "Internet Protocol Control Protocol
extensions for name service configuration [RFC1877] were developed at (IPCP) Extensions for Name Service Configuration" [RFC1877] were
a time when the Dynamic Host Configuration Protocol (DHCP) [RFC2131] developed at a time when the Dynamic Host Configuration Protocol
had not yet been widely implemented on access devices or in service (DHCP) [RFC2131] had not yet been widely implemented on access
provider networks. However, in IPv6 where link layer independent devices or in service provider networks. However, in IPv6 where link
mechanisms such as stateless address configuration [RFC4862] and layer independent mechanisms such as "IPv6 Stateless Address
DHCPv6 [RFC3736] are available, PPP IPv6CP [RFC5072] instead simply Autoconfiguration" [RFC4862] and DHCPv6 [RFC3736] are available, PPP
configures an Interface-Identifier which is similar to a MAC address. IPv6CP [RFC5072] instead simply configures an Interface-Identifier
This enables PPP IPv6CP to avoid having to duplicate DHCPv6 which is similar to a MAC address. This enables PPP IPv6CP to avoid
functionality. having to duplicate DHCPv6 functionality.
In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306] In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306]
utilizes the same approach as PPP IPv4CP by defining a Configuration utilizes the same approach as PPP IPv4CP by defining a Configuration
Payload for Internet host configuration for both IPv4 and IPv6. As Payload for Internet host configuration for both IPv4 and IPv6. As
pointed out in [RFC3456], leveraging DHCP has advantages in terms of pointed out in "Dynamic Host Configuration Protocol (DHCPv4)
address management integration, address pool management, Configuration of IPsec Tunnel Mode" [RFC3456], leveraging DHCP has
reconfiguration and fail-over. On the other hand, the IKEv2 approach advantages in terms of address management integration, address pool
reduces the number of exchanges. management, reconfiguration and fail-over. On the other hand, the
IKEv2 approach reduces the number of exchanges.
Extensions to link layer protocols for the purpose of Internet, Extensions to link layer protocols for the purpose of Internet,
transport or application layer configuration (including server transport or application layer configuration (including server
configuration) should be avoided. Such extensions can negatively configuration) should be avoided. Such extensions can negatively
affect the properties of a link as seen by higher layers. For affect the properties of a link as seen by higher layers. For
example, if a link layer protocol (or tunneling protocol) configures example, if a link layer protocol (or tunneling protocol) configures
individual IPv6 addresses and precludes using any other addresses, individual IPv6 addresses and precludes using any other addresses,
then applications that desire "Privacy Extensions for Stateless then applications that desire "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6" [RFC4941] may not function well. Address Autoconfiguration in IPv6" [RFC4941] may not function well.
Similar issues may arise for other types of addresses, such as Similar issues may arise for other types of addresses, such as
skipping to change at page 9, line 41 skipping to change at page 9, line 46
Avoiding lower layer dependencies is desirable even where the lower Avoiding lower layer dependencies is desirable even where the lower
layer is link independent. For example, while the Extensible layer is link independent. For example, while the Extensible
Authentication Protocol (EAP) [RFC3748] may be run over any link Authentication Protocol (EAP) [RFC3748] may be run over any link
satisfying the requirements of [RFC3748] Section 3.1, many link satisfying the requirements of [RFC3748] Section 3.1, many link
layers do not support EAP and therefore Internet layer configuration layers do not support EAP and therefore Internet layer configuration
mechanisms with EAP dependencies would not be usable on all links mechanisms with EAP dependencies would not be usable on all links
that support IP. that support IP.
2.5. Configuration is Not Access Control 2.5. Configuration is Not Access Control
Network access authentication is a distinct problem from Internet Network access authentication and authorizaton is a distinct problem
host configuration. Network access authentication is best handled from Internet host configuration. Therefore network access
independently of the configuration mechanisms in use for the Internet authentication and authorization is best handled independently of the
and higher layers. Internet and higher layer configuration mechanisms.
For example, attempting to control access by requiring authentication Having an Internet (or higher) layer protocol authenticate clients is
in order to obtain configuration parameters (such as an IP address)
has little value if the user can manually configure the host. Having
an Internet (or higher) layer protocol authenticate clients is
appropriate to prevent resource exhaustion of a scarce resource on appropriate to prevent resource exhaustion of a scarce resource on
the server, but not for preventing rogue hosts from obtaining access the server (such as IP addresses or prefixes), but not for preventing
to a link. Note that client authentication is not required for hosts from obtaining access to a link. If the user can manually
Stateless DHCPv6 [RFC3736] since it does not result in allocation of configure the host, requiring authentication in order to obtain
any limited resources on the server. configuration parameters (such as an IP address) has little value.
Note that client authentication is not required for Stateless DHCPv6
[RFC3736] since it does not result in allocation of any limited
resources on the server.
3. Additional Discussion 3. Additional Discussion
3.1. General Purpose Mechanisms 3.1. General Purpose Mechanisms
Protocols should either be self-configuring (especially where fate Protocols should either be self-configuring (especially where fate
sharing is important), or use general-purpose configuration sharing is important), or use general-purpose configuration
mechanisms (such as DHCP or a service discovery protocol, as noted in mechanisms (such as DHCP or a service discovery protocol, as noted in
Section 3.2). The choice should be made taking into account the Section 3.2). The choice should be made taking into account the
architectural principles discussed in Section 2. architectural principles discussed in Section 2.
skipping to change at page 10, line 36 skipping to change at page 10, line 40
consider whether configuration is indeed necessary (see Section 2.1). consider whether configuration is indeed necessary (see Section 2.1).
If configuration is necessary, in addition to considering fate If configuration is necessary, in addition to considering fate
sharing (see Section 3.3), protocol designers should consider: sharing (see Section 3.3), protocol designers should consider:
1. The organizational implications for administrators. For 1. The organizational implications for administrators. For
example, routers and servers are often administered by example, routers and servers are often administered by
different sets of individuals, so that configuring a router different sets of individuals, so that configuring a router
with server parameters may require cross-group collaboration. with server parameters may require cross-group collaboration.
2. Whether the parameter is a per-interface or a global 2. Whether the parameter is a per-interface or a global
parameter. For example, most standard general purpose parameter. For example, configuration protocols
configuration protocols run on a per-interface basis and hence such as DHCP run on a per-interface basis and hence
are more appropriate for per-interface parameters. are more appropriate for per-interface parameters.
3.2. Service Discovery 3.2. Service Discovery
Higher-layer configuration often includes configuring server Higher-layer configuration often includes configuring server
addresses. The question arises as to how this differs from "service addresses. The question arises as to how this differs from "service
discovery" as provided by Service Discovery protocols such as the discovery" as provided by Service Discovery protocols such as the
Service Location Protocol Version 2 (SLPv2) [RFC2608]. Service Location Protocol Version 2 (SLPv2) [RFC2608] or Domain Name
Service Service Discovery (DNS-SD) [DNS-SD].
In general-purpose configuration mechanisms such as DHCP, server In Internet host configuration mechanisms such as DHCP, server
instances are considered equivalent. In service discovery protocols, instances are considered equivalent. In service discovery protocols,
on the other hand, a host desires to find a server satisfying a on the other hand, a host desires to find a server satisfying a
particular set of criteria, which may vary by request. particular set of criteria, which may vary by request.
Service discovery protocols such as SLPv2 can support discovery of Service discovery protocols can support discovery of servers on the
servers on the Internet [RFC3832], not just those within the local Internet, not just those within the local administrative domain. For
administrative domain. General-purpose configuration mechanisms such example, see "Remote Service Discovery in the Service Location
as DHCP, on the other hand, typically assume the server(s) in the Protocol (SLP) via DNS SRV" [RFC3832] and [DNS-SD]. Internet host
local administrative domain contain the authoritative set of configuration mechanisms such as DHCP, on the other hand, typically
information. assume the server(s) in the local administrative domain contain the
authoritative set of information.
For the service discovery problem (i.e., where the criteria varies on For the service discovery problem (i.e., where the criteria varies on
a per-request basis, even from the same host), protocols should a per-request basis, even from the same host), protocols should
either be self-discovering (if fate sharing is critical), or use either be self-discovering (if fate sharing is critical), or use
general purpose service discovery mechanisms. general purpose service discovery mechanisms.
In order to avoid a dependency on multicast routing, it is necessary In order to avoid a dependency on multicast routing, it is necessary
for a host to either restrict discovery to services on the local link for a host to either restrict discovery to services on the local link
or to discover the location of a Directory Agent (DA). Therefore the or to discover the location of a Directory Agent (DA). Since the DA
use of service discovery protocols beyond the local link is typically may not be available on the local link, service discovery beyond the
dependent on a parameter configuration mechanism. As a result, local link is typically dependent on a parameter configuration
service discovery protocols are typically not appropriate for use in mechanism. As a result, service discovery protocols can typically
obtaining basic Internet layer configuration, although they can be not be relied upon for obtaining basic Internet layer configuration.
used to obtain higher-layer configuration for parameters that don't However, they can be used to obtain higher-layer configuration
meet the assumptions above made by general-purpose configuration parameters.
mechanisms.
3.2.1. Fate Sharing 3.2.1. Fate Sharing
If a server (or set of servers) is needed to get a set of If a server (or set of servers) is needed to get a set of
configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is
preserved if the servers are ones without which the parameters could preserved if the servers are ones without which the parameters could
not be used, even if they were obtained via other means. The not be used, even if they were obtained via other means. The
possibility of incorrect information being configured is minimized if possibility of incorrect information being configured is minimized if
there is only one machine which is authoritative for the information there is only one machine which is authoritative for the information
(i.e., there is no need to keep multiple authoritative servers in (i.e., there is no need to keep multiple authoritative servers in
skipping to change at page 12, line 30 skipping to change at page 12, line 35
addresses for discovery of DNS servers. The use of anycast addresses addresses for discovery of DNS servers. The use of anycast addresses
enables fate sharing, even where the anycast address is provided by enables fate sharing, even where the anycast address is provided by
an unrelated server. However, in order to be universally useful, an unrelated server. However, in order to be universally useful,
this approach would require allocation of a well-known anycast this approach would require allocation of a well-known anycast
address for each service. address for each service.
3.2.2. Discovering Names vs. Addresses 3.2.2. Discovering Names vs. Addresses
In discovering servers other than name resolution servers, it is In discovering servers other than name resolution servers, it is
possible to either discover the IP addresses of the server(s), or to possible to either discover the IP addresses of the server(s), or to
discover a name that resolves to a list of addresses. discover names, each of which may resolve to a list of addresses.
It is typically more secure and efficient to obtain the list of It is typically more efficient to obtain the list of addresses
addresses directly, since this avoids the extra name resolution step directly, since this avoids the extra name resolution steps and
and the accompanying latency, security and fate sharing issues. accompanying latency. However, where servers are mobile, the name to
address binding may change, so that the initially discovered
addresses can become stale. In such a situation, if the discovery
mechanism supports fate sharing then a fresh set of addresses can be
obtained by re-initiating discovery. If there is no fate sharing
(e.g. the server address has been provided via DNS, but the server
has renumbered), but the server to address binding is dynamically
updated, then obtaining a list of names will be more robust.
In obtaining the IP addresses for a set of servers, it is desirable In obtaining the IP addresses for a set of servers, it is desirable
to distinguish which IP addresses belong to which servers. If a to distinguish which IP addresses belong to which servers. If a
server IP address is unreachable, this enables the host to try the IP server IP address is unreachable, this enables the host to try the IP
address of another server, rather than another IP address of the same address of another server, rather than another IP address of the same
server, in case the server is down. This can be enabled by server, in case the server is down. This can be enabled by
distinguishing which addresses belong to the same server. distinguishing which addresses belong to the same server.
4. Security Considerations 4. Security Considerations
Secure IP configuration presents a number of challenges. In addition Secure IP configuration presents a number of challenges. In addition
to denial-of-service and man-in-the-middle attacks, attacks on to denial-of-service and man-in-the-middle attacks, attacks on
configuration mechanisms may target particular parameters. For configuration mechanisms may target particular parameters. For
example, attackers may target DNS server configuration in order to example, attackers may target DNS server configuration in order to
support subsequent phishing or pharming attacks. A number of issues support subsequent phishing or pharming attacks. A number of issues
exist with various classes of parameters, as discussed in Section exist with various classes of parameters, as discussed in Section
2.6, [RFC3756] Section 4.2.7, [RFC3118] Section 1.1, and [RFC3315] 2.6, "IPv6 Neighbor Discovery (ND) Trust Models and Threats"
Section 23. Given the potential vulnerabilities resulting from [RFC3756] Section 4.2.7, "Authentication for DHCP Messages" [RFC3118]
implementation of these options, it is currently common for hosts to Section 1.1, and "Dynamic Host Configuration Protocol for IPv6
restrict support for DHCP options to the minimum set required to (DHCPv6)" [RFC3315] Section 23. Given the potential vulnerabilities
provide basic TCP/IP configuration. resulting from implementation of these options, it is currently
common for hosts to restrict support for DHCP options to the minimum
set required to provide basic TCP/IP configuration.
Since boot configuration determines the boot image to be run by the Since boot configuration determines the boot image to be run by the
host, a successful attack on boot configuration could result in an host, a successful attack on boot configuration could result in an
attacker gaining complete control over a host. As a result, it is attacker gaining complete control over a host. As a result, it is
particularly important that boot configuration be secured. particularly important that boot configuration be secured.
Approaches to boot configuration security are described in
"Bootstrapping Clients using the Internet Small Computer System
Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution
Environment (PXE) Specification" [PXE].
4.1. Configuration Authentication 4.1. Configuration Authentication
The techniques available for securing Internet layer configuration The techniques available for securing Internet layer configuration
are limited, since transmission layer security protocols such as are limited, since transmission layer security protocols such as
IPsec [RFC4301] or TLS [RFC4346] cannot be used until an IP address IPsec [RFC4301] or Transport Layer Security (TLS) [RFC4346] cannot be
has been configured. As a result, configuration security is used until an IP address has been configured. As a result,
typically implemented within the configuration protocols themselves. configuration security is typically implemented within the
configuration protocols themselves.
PPP [RFC1661] does not support secure negotiation within IPv4CP PPP [RFC1661] does not support secure negotiation within IPv4CP
[RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to
the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] the link to subvert the negotiation. In contrast, IKEv2 [RFC4306]
provides encryption, integrity and replay protection for provides encryption, integrity and replay protection for
configuration exchanges. configuration exchanges.
In situations where link layer security is provided, and the Network In situations where link layer security is provided, and the Network
Access Server (NAS) acts as a DHCP relay or server, protection can be Access Server (NAS) acts as a DHCP relay or server, protection can be
provided against rogue DHCP servers, provided that the NAS filters provided against rogue DHCP servers, provided that the NAS filters
skipping to change at page 14, line 8 skipping to change at page 14, line 27
even if a host does not support DHCPv6 authentication, higher-layer even if a host does not support DHCPv6 authentication, higher-layer
configuration via Stateless DHCPv6 [RFC3736] can still be secured configuration via Stateless DHCPv6 [RFC3736] can still be secured
with IPsec. with IPsec.
Possible exceptions can exist where security facilities are not Possible exceptions can exist where security facilities are not
available until later in the boot process. It may be difficult to available until later in the boot process. It may be difficult to
secure boot configuration even once the Internet layer has been secure boot configuration even once the Internet layer has been
configured, if security functionality is not available until after configured, if security functionality is not available until after
boot configuration has been completed. For example, it is possible boot configuration has been completed. For example, it is possible
that Kerberos, IPsec or TLS will not be available until later in the that Kerberos, IPsec or TLS will not be available until later in the
boot process. boot process; see [RFC4173] for discussion.
Where public key cryptography is used to authenticate and integrity Where public key cryptography is used to authenticate and integrity
protect configuration, hosts need to be configured with trust anchors protect configuration, hosts need to be configured with trust anchors
in order to validate received configuration messages. For a node in order to validate received configuration messages. For a node
that visits multiple administrative domains, acquiring the required that visits multiple administrative domains, acquiring the required
trust anchors may be difficult. This is left as an area for future trust anchors may be difficult. This is left as an area for future
work. work.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. References 6. References
6.1. Informative References 6.1. Informative References
[DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery",
Internet-Draft (work in progress), draft-cheshire-dnsext-dns-
sd-04.txt, August 2006.
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005.
http://files.multicastdns.org/draft-cheshire-dnsext- http://files.multicastdns.org/draft-cheshire-dnsext-
multicastdns.txt multicastdns.txt
[PXE] Henry, M. and M. Johnston, "Preboot Execution Environment [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment
(PXE) Specification", September 1999, (PXE) Specification", September 1999,
http://www.pix.net/software/pxeboot/archive/pxespec.pdf http://www.pix.net/software/pxeboot/archive/pxespec.pdf
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
 End of changes. 33 change blocks. 
107 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/