draft-iab-ip-config-08.txt   draft-iab-ip-config-09.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
INTERNET-DRAFT D. Thaler INTERNET-DRAFT D. Thaler
Category: Informational Loa Andersson Category: Informational Loa Andersson
Expires: April 5, 2009 Stuart Cheshire Expires: June 5, 2009 Stuart Cheshire
4 October 2008 Internet Architecture Board 9 December 2008 Internet Architecture Board
Principles of Internet Host Configuration Principles of Internet Host Configuration
draft-iab-ip-config-08.txt draft-iab-ip-config-09.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 33 skipping to change at page 1, line 33
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 April 5, 2009. This Internet-Draft will expire on June 5, 2009.
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.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Terminology ........................................ 3 1.1 Terminology ........................................ 3
1.2 Internet Host Configuration ........................ 4 1.2 Internet Host Configuration ........................ 4
2. Principles ............................................... 6 2. Principles ............................................... 6
2.1 Minimize Configuration ............................. 6 2.1 Minimize Configuration ............................. 7
2.2 Less is More ....................................... 7 2.2 Less is More ....................................... 7
2.3 Minimize Diversity ................................. 8 2.3 Minimize Diversity ................................. 8
2.4 Lower Layer Independence ........................... 9 2.4 Lower Layer Independence ........................... 9
2.5 Configuration is Not Access Control ................ 11 2.5 Configuration is Not Access Control ................ 11
3. Additional Discussion .................................... 11 3. Additional Discussion .................................... 11
3.1 Reliance on General Purpose Mechanisms ............. 11 3.1 Reliance on General Purpose Mechanisms ............. 11
3.2 Relationship between IP Configuration and 3.2 Relationship between IP Configuration and
Service Discovery .................................. 12 Service Discovery .................................. 12
4. Security Considerations .................................. 15 3.3 Discovering Names vs. Addresses .................... 14
4.1 Configuration Authentication ....................... 16 3.4 Dual Stack Issues .................................. 15
5. IANA Considerations ...................................... 17 3.5 Relationship between Per-Interface and
6. References ............................................... 17 Per-Host Configuration ............................. 16
6.1 Informative References ............................. 17 4. Security Considerations .................................. 17
Acknowledgments .............................................. 22 4.1 Configuration Authentication ....................... 18
Appendix A - IAB Members ..................................... 22 5. IANA Considerations ...................................... 19
Authors' Addresses ........................................... 22 6. References ............................................... 19
Full Copyright Statement ..................................... 23 6.1 Informative References ............................. 19
Intellectual Property ........................................ 23 Acknowledgments .............................................. 23
Appendix A - IAB Members ..................................... 23
Authors' Addresses ........................................... 24
Full Copyright Statement ..................................... 25
Intellectual Property ........................................ 25
1. Introduction 1. Introduction
This document describes principles of Internet host [STD3] This document describes principles of Internet host [STD3]
configuration. It covers issues relating to configuration of configuration. It covers issues relating to configuration of
Internet layer parameters, as well as parameters affecting higher Internet layer parameters, as well as parameters affecting higher
layer protocols. 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:
o What protocol layers and general approaches are most appropriate o What protocol layers and general approaches are most appropriate
for configuration of various parameters. for configuration of various parameters.
o The relationship between parameter configuration and service o The relationship between parameter configuration and
discovery. service discovery.
o The relationship between network access authentication and host o The relationship between per-interface and per-host
configuration. configuration.
o The relationship between network access authentication and
host configuration.
o The desirability of avoiding parameter configuration or o The desirability of avoiding parameter configuration or
supporting self-configuration. supporting self-configuration.
o The role of link-layer protocols and tunneling protocols o The role of link-layer protocols and tunneling protocols
in Internet host configuration. in Internet host configuration.
The role of the link-layer and tunneling protocols is particularly The role of the link-layer and tunneling protocols is particularly
important, since it can affect the properties of a link as seen by important, since it can affect the properties of a link as seen by
higher layers (for example, whether privacy extensions specified in higher layers (for example, whether privacy extensions specified in
"Privacy Extensions for Stateless Address Autoconfiguration in IPv6" "Privacy Extensions for Stateless Address Autoconfiguration in IPv6"
skipping to change at page 4, line 10 skipping to change at page 4, line 13
to any interfaces on the specified link. to any interfaces on the specified link.
mobility agent mobility agent
Either a home agent or a foreign agent. Either a home agent or a foreign agent.
1.2. Internet Host Configuration 1.2. Internet Host Configuration
1.2.1. Internet Layer Configuration 1.2.1. Internet Layer Configuration
Internet layer configuration is defined as the configuration required Internet layer configuration is defined as the configuration required
to support the operation of the Internet layer. This includes IP to support the operation of the Internet layer. This includes
configuration of per-interface and per-host parameters, including IP
address(es), subnet prefix(es), default gateway(s), mobility address(es), subnet prefix(es), default gateway(s), mobility
agent(s), boot service configuration and other parameters: agent(s), boot service configuration and other parameters:
IP address(es) IP address(es)
Internet Protocol (IP) address configuration includes both Internet Protocol (IP) address configuration includes both
configuration of link-scope addresses as well as global configuration of link-scope addresses as well as global
addresses. Configuration of IP addresses is a vital step, addresses. Configuration of IP addresses is a vital step,
since practically all of IP networking relies on the since practically all of IP networking relies on the
assumption that hosts have IP address(es) associated with assumption that hosts have IP address(es) associated with
(each of) their active network interface(s). Used as the (each of) their active network interface(s). Used as the
source address of an IP packet, these IP addresses source address of an IP packet, these IP addresses
indicate the sender of the packet; used as the destination indicate the sender of the packet; used as the destination
address of a unicast IP packet, these IP addresses address of a unicast IP packet, these IP addresses
indicate the intended receiver. indicate the intended receiver.
The only common example of IP-based protocols operating The only common example of IP-based protocols operating
without an IP address involves address configuration, such without an IP address involves address configuration, such
as the use of DHCPv4 [RFC2131] to obtain an address. In as the use of DHCPv4 [RFC2131] to obtain an address. In
this case, by definition, DHCPv4 is operating before the this case, by definition, DHCPv4 is operating before the
client has an IPv4 address, so the DHCP protocol designers host has an IPv4 address, so the DHCP protocol designers
had the choice of either using IP without an IP address, had the choice of either using IP without an IP address,
or not using IP at all. The benefits of making IPv4 self- or not using IP at all. The benefits of making IPv4 self-
reliant, configuring itself using its own IPv4 packets, reliant, configuring itself using its own IPv4 packets,
instead of depending on some other protocol, outweighed instead of depending on some other protocol, outweighed
the drawbacks of having to use IP in this constrained the drawbacks of having to use IP in this constrained
mode. Use of IP for purposes other than address mode. Use of IP for purposes other than address
configuration can safely assume that the host will have configuration can safely assume that the host will have
one or more IP addresses, which may be self-configured one or more IP addresses, which may be self-configured
link-local addresses, or other addresses configured via link-local addresses, or other addresses configured via
DHCP or other means. DHCP or other means.
Subnet prefix(es) Subnet prefix(es)
Once a subnet prefix is configured, hosts with an IP Once a subnet prefix is configured on an interface, hosts
address can exchange unicast IP packets directly with on- with an IP address can exchange unicast IP packets
link hosts within the same subnet prefix. directly with on-link hosts within the same subnet prefix.
Default gateway(s) Default gateway(s)
Once a default gateway is configured, hosts with an IP Once a default gateway is configured on an interface,
address can send unicast IP packets to that gateway for hosts with an IP address can send unicast IP packets to
forwarding to off-link hosts. that gateway for forwarding to off-link hosts.
Mobility agent(s) Mobility agent(s)
While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775]
include their own mechanisms for locating home agents, it include their own mechanisms for locating home agents, it
is also possible for mobile nodes to utilize dynamic home is also possible for mobile nodes to utilize dynamic home
agent configuration. agent configuration.
Boot service configuration Boot service configuration
Boot service configuration is defined as the configuration Boot service configuration is defined as the configuration
necessary for a host to obtain and perhaps also to verify necessary for a host to obtain and perhaps also to verify
skipping to change at page 5, line 25 skipping to change at page 5, line 27
less hosts looking to obtain a boot image via mechanisms less hosts looking to obtain a boot image via mechanisms
such as the Trivial File Transfer Protocol (TFTP) such as the Trivial File Transfer Protocol (TFTP)
[RFC1350], Network File System (NFS) [RFC3530] and [RFC1350], Network File System (NFS) [RFC3530] and
Internet Small Computer Systems Interface (iSCSI) Internet Small Computer Systems Interface (iSCSI)
[RFC3720][RFC4173]. It also may be useful in situations [RFC3720][RFC4173]. It also may be useful in situations
where it is necessary to update the boot image of a host where it is necessary to update the boot image of a host
that supports a disk, such as in the Preboot eXecution that supports a disk, such as in the Preboot eXecution
Environment (PXE) [PXE][RFC4578]. While strictly speaking Environment (PXE) [PXE][RFC4578]. While strictly speaking
boot services operate above the Internet layer, where boot boot services operate above the Internet layer, where boot
service is used to obtain the Internet layer code, it may service is used to obtain the Internet layer code, it may
be considered part of Internet layer configuration. be considered part of Internet layer configuration. While
boot service parameters may be provided on a per-interface
basis, loading and verification of a boot image affects
behavior of the host as a whole.
Other IP parameters Other IP parameters
Internet layer parameter configuration also includes Internet layer parameter configuration also includes
configuration of per-host parameters (e.g. hostname) and configuration of per-host parameters (e.g. hostname) and
per-interface parameters (e.g. IP Time-To-Live (TTL) to per-interface parameters (e.g. IP Time-To-Live (TTL) to
use in outgoing packets, enabling/disabling of IP use in outgoing packets, enabling/disabling of IP
forwarding and source routing, and Maximum Transmission forwarding and source routing, and Maximum Transmission
Unit (MTU)). Unit (MTU)).
1.2.2. Higher Layer Configuration 1.2.2. Higher Layer Configuration
skipping to change at page 6, line 14 skipping to change at page 6, line 20
Multicast Name Resolution (LLMNR) [RFC4795] and multicast Multicast Name Resolution (LLMNR) [RFC4795] and multicast
DNS (mDNS) [mDNS]) typically do not require configuration. DNS (mDNS) [mDNS]) typically do not require configuration.
Once the host has completed name service configuration, it Once the host has completed name service configuration, it
is capable of resolving names using name resolution is capable of resolving names using name resolution
protocols that require configuration. This not only protocols that require configuration. This not only
allows the host to communicate with off-link hosts whose allows the host to communicate with off-link hosts whose
IP address is not known, but to the extent that name IP address is not known, but to the extent that name
services requiring configuration are utilized for service services requiring configuration are utilized for service
discovery, this also enables the host to discover services discovery, this also enables the host to discover services
available on the network or elsewhere. available on the network or elsewhere. While name service
parameters can be provided on a per-interface basis, their
configuration will typically affect behavior of the host
as a whole.
Time Service Configuration Time Service Configuration
Time service configuration includes configuration of Time service configuration includes configuration of
servers for protocols such as the Simple Network Time servers for protocols such as the Simple Network Time
Protocol (SNTP) and the Network Time Protocol (NTP). Protocol (SNTP) and the Network Time Protocol (NTP).
Since accurate determination of the time may be important Since accurate determination of the time may be important
to operation of the applications running on the host to operation of the applications running on the host
(including security services), configuration of time (including security services), configuration of time
servers may be a prerequisite for higher layer operation. servers may be a prerequisite for higher layer operation.
However, it is typically not a requirement for Internet However, it is typically not a requirement for Internet
layer configuration. layer configuration. While time service parameters can be
provided on a per-interface basis, their configuration
will typically affect behavior of the host as a whole.
Other service configuration Other service configuration
This can include discovery of additional servers and This can include discovery of additional servers and
devices, such as printers, Session Initiation Protocol devices, such as printers, Session Initiation Protocol
(SIP) proxies, etc. (SIP) proxies, etc. This configuration will typically
apply to the entire host.
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. "Architectural Anything that can be configured can be misconfigured. "Architectural
Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid
skipping to change at page 11, line 41 skipping to change at page 12, line 8
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.
Taking into account the availability of existing general-purpose Taking into account the availability of existing general-purpose
configuration mechanisms, we see little need for development of configuration mechanisms, we see little need for development of
additional general-purpose configuration mechanisms. additional general-purpose configuration mechanisms.
When defining a new host parameter, protocol designers should first When defining a new host parameter, protocol designers should first
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.2.1), 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 per-host 2. Whether the need is to configure a set of interchangeable
servers or to select a server satisfying a particular set
of criteria. See Section 3.2.
3. Whether IP address(es) should configured or name(s).
See Section 3.3.
4. If IP address(es) are configured, whether IPv4 and
IPv6 addresses should be configured simultaneously or
separately. See Section 3.4.
5. Whether the parameter is a per-interface or a per-host
parameter. For example, configuration protocols parameter. For example, configuration protocols
such as DHCP 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.
6. How per-interface configuration affects host-wide behavior.
For example, whether the host should select a subset
of the per-interface configurations, or whether the
configurations are to merged, and if so, how this is
done. See Section 3.5.
3.2. Relationship between IP Configuration and Service Discovery 3.2. Relationship between IP Configuration and 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] or DNS-Based Service Location Protocol Version 2 (SLPv2) [RFC2608] or DNS-Based
Service Discovery (DNS-SD) [DNS-SD]. Service Discovery (DNS-SD) [DNS-SD].
In Internet host configuration mechanisms such as DHCP, if multiple In Internet host configuration mechanisms such as DHCP, if multiple
server instances are provided, they are considered interchangeable. server instances are provided, they are considered interchangeable.
skipping to change at page 14, line 15 skipping to change at page 14, line 47
"IPv6 Host configuration of DNS Server Information Approaches" "IPv6 Host configuration of DNS Server Information Approaches"
[RFC4339] Section 3.3 discusses the use of well-known anycast [RFC4339] Section 3.3 discusses the use of well-known anycast
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 one or more well-known this approach would require allocation of one or more well-known
anycast addresses for each service. Configuration of more than one anycast addresses for each service. Configuration of more than one
anycast address is desirable to allow the client to fail over faster anycast address is desirable to allow the client to fail over faster
than would be possible from routing protocol convergence. than would be possible from routing protocol convergence.
3.2.2. Discovering Names vs. Addresses 3.3. 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 names, each of which may resolve to a list of addresses. discover names, each of which may resolve to a list of addresses.
It is typically more efficient to obtain the list of addresses It is typically more efficient to obtain the list of addresses
directly, since this avoids the extra name resolution steps and directly, since this avoids the extra name resolution steps and
accompanying latency. On the other hand, where servers are mobile, accompanying latency. On the other hand, where servers are mobile,
the name to address binding may change, requiring a fresh set of the name to address binding may change, requiring a fresh set of
addresses to be obtained. Where the configuration mechanism does not addresses to be obtained. Where the configuration mechanism does not
skipping to change at page 14, line 41 skipping to change at page 15, line 25
protocols), a fresh address can be obtained by re-initiating protocols), a fresh address can be obtained by re-initiating
parameter configuration. parameter configuration.
In providing the IP addresses for a set of servers, it is desirable In providing 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.
3.2.3. Dual Stack Issues 3.4. Dual Stack Issues
One use for learning a list of interchangeable server addresses is One use for learning a list of interchangeable server addresses is
for fault tolerance, in case one or more of the servers are for fault tolerance, in case one or more of the servers are
unresponsive. Hosts will typically try the addresses in turn, only unresponsive. Hosts will typically try the addresses in turn, only
attempting to use the second and subsequent addresses in the list if attempting to use the second and subsequent addresses in the list if
the first one fails to respond quickly enough. In such cases, having the first one fails to respond quickly enough. In such cases, having
the list sorted in order of expected likelihood of success will help the list sorted in order of expected likelihood of success will help
clients get results faster. For hosts that support both IPv4 and clients get results faster. For hosts that support both IPv4 and
IPv6, it is desirable to obtain both IPv4 and IPv6 server addresses IPv6, it is desirable to obtain both IPv4 and IPv6 server addresses
within a single list. Obtaining IPv4 and IPv6 addresses in separate within a single list. Obtaining IPv4 and IPv6 addresses in separate
skipping to change at page 15, line 33 skipping to change at page 16, line 17
IPv6 addresses. Note that the same issue can arise with any IPv6 addresses. Note that the same issue can arise with any
mechanism (e.g. DHCP, DNS, etc.) for obtaining server IP addresses. mechanism (e.g. DHCP, DNS, etc.) for obtaining server IP addresses.
Configuring a combined list of both IPv4 and IPv6 addresses gives the Configuring a combined list of both IPv4 and IPv6 addresses gives the
configuration mechanism control over the ordering of addresses, as configuration mechanism control over the ordering of addresses, as
compared with configuring a name and allowing the host resolver to compared with configuring a name and allowing the host resolver to
determine the address list ordering. See "DHCP Dual-Stack Issues" determine the address list ordering. See "DHCP Dual-Stack Issues"
[RFC4477] for more discussion of dual-stack issues in the context of [RFC4477] for more discussion of dual-stack issues in the context of
DHCP. DHCP.
3.5. Relationship between Per-Interface and Per-Host Configuration
Parameters that are configured or acquired on a per-interface basis
can affect behavior of the host as a whole. Where only a single
configuration can be applied to a host, the host may need to
prioritize the per-interface configuration information in some way
(e.g. most trusted to least trusted). If the host needs to merge
per-interface configuration to produce a host-wide configuration, it
may need to take the union of the per-host configuration parameters
and order them in some way (e.g. highest speed interface to lowest
speed interface). Which procedure is to be applied and how this is
accomplished may vary depending on the parameter being configured.
Examples include:
Boot service configuration
While boot service configuration can be provided on
multiple interfaces, a given host may be limited in the
number of boot loads that it can handle simultaneously.
For example, a host not supporting virtualization may only
be capable of handling a single boot load at a time, or a
host capable of supporting N virtual machines may only be
capable of handling up to N simultaneous boot loads. As a
result, a host may need to select which boot load(s) it
will act on, out of those configured on a per-interface
basis. This requires that the host prioritize them (e.g.
most trusted to least trusted).
Name service configuration
While name service configuration is provided on a per-
interface basis, name resolution configuration typically
will affect behavior of the host as a whole. For example,
given the configuration of DNS server addresses and
searchlist parameters on each interface, the host
determines what sequence of name service queries is to be
sent on which interfaces, as well as how the answers are
prioritized (e.g. first answered returned, most trusted
answer preferred, etc.).
Since the algorithms used to determine per-host behavior based on
per-interface configuration can affect interoperability, it is
important for these algorithms to be understood by implementers. We
therefore recommend that documents defining per-interface mechanisms
for acquiring per-host configuration (e.g. DHCP or IPv6 Router
Advertisement options) include guidance on how to deal with multiple
interfaces. This may include discussions of the following items:
1. Merging. How are per-interface configurations combined to
produce a per-host configuration? Is a single configuration
selected, or is the union of the configurations taken?
2. Prioritization. Are the per-interface configurations
prioritized as part of the merge process? If so, what are
some of the considerations to be taken into account in
prioritization?
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 such as those
exist with various classes of parameters, as discussed in Section described in "New trojan in mass DNS hijack" [DNSTrojan]. A number
2.6, "IPv6 Neighbor Discovery (ND) Trust Models and Threats" of issues exist with various classes of parameters, as discussed in
Section 2.6, "IPv6 Neighbor Discovery (ND) Trust Models and Threats"
[RFC3756] Section 4.2.7, "Authentication for DHCP Messages" [RFC3118] [RFC3756] Section 4.2.7, "Authentication for DHCP Messages" [RFC3118]
Section 1.1, and "Dynamic Host Configuration Protocol for IPv6 Section 1.1, and "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" [RFC3315] Section 23. Given the potential vulnerabilities (DHCPv6)" [RFC3315] Section 23. Given the potential vulnerabilities,
resulting from implementation of these options, it is currently hosts often restrict support for DHCP options to the minimum set
common for hosts to restrict support for DHCP options to the minimum required to provide basic TCP/IP configuration.
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 Approaches to boot configuration security are described in
"Bootstrapping Clients using the Internet Small Computer System "Bootstrapping Clients using the Internet Small Computer System
Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution
Environment (PXE) Specification" [PXE]. Environment (PXE) Specification" [PXE].
skipping to change at page 16, line 33 skipping to change at page 18, line 28
Architecture for the Internet Protocol" [RFC4301], or Transport Layer Architecture for the Internet Protocol" [RFC4301], or Transport Layer
Security (TLS) [RFC5246]. As a result, configuration security is Security (TLS) [RFC5246]. As a result, configuration security is
typically implemented within the configuration protocols themselves. 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 Where configuration packets are only expected to originate on
Access Server (NAS) acts as a DHCP relay or server, protection can be particular links or from particular hosts, filtering can help control
provided against rogue DHCP servers, provided that the NAS filters configuration spoofing. For example, in situations where
incoming DHCP packets from unauthorized sources. However, explicit configuration packets only originate on a wired link, an Access Point
dependencies on lower layer security mechanisms are limited by the can filter incoming configuration packets on wireless links, such as
"lower layer independence" principle (see Section 2.4). IPv6 Router Advertisement packets (ICMP Type 134), DHCPv4 packets
sent to the client port (68), and DHCPv6 packets sent to the client
port (546). On the wired link, a Network Access Server (NAS) acting
as a DHCP relay can only permit incoming DHCP packets sent to the
client port originating from DHCP server addresses. To prevent
spoofing, communication between the DHCP Relay and Server can be
authenticated and integrity protected using a mechanism such as
IPsec.
Internet layer secure configuration mechanisms include SEcure Internet layer secure configuration mechanisms include SEcure
Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address
autoconfiguration [RFC4862], or DHCP authentication for stateful autoconfiguration [RFC4862], or DHCP authentication for stateful
address configuration. DHCPv4 [RFC2131] initially did not include address configuration. DHCPv4 [RFC2131] initially did not include
support for security; this was added in "Authentication for DHCP support for security; this was added in "Authentication for DHCP
Messages" [RFC3118]. DHCPv6 [RFC3315] included security support. Messages" [RFC3118]. DHCPv6 [RFC3315] included security support.
However, DHCP authentication is not widely implemented for either However, DHCP authentication is not widely implemented for either
DHCPv4 or DHCPv6. DHCPv4 or DHCPv6.
skipping to change at page 17, line 37 skipping to change at page 19, line 38
6. References 6. References
6.1. Informative References 6.1. Informative References
[3GPP-24.008] [3GPP-24.008]
3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
specification; Core network protocols; Stage 3 (Release 5)", specification; Core network protocols; Stage 3 (Release 5)",
June 2003. June 2003.
[DNSTrojan]
Goodin, D., "New trojan in mass DNS hijack", The Register,
December 5, 2008, http://www.theregister.co.uk/2008/12/05/
new_dnschanger_hijacks/
[IEN116] J. Postel, "Internet Name Server", IEN 116, August 1979, [IEN116] J. Postel, "Internet Name Server", IEN 116, August 1979,
http://www.ietf.org/rfc/ien/ien116.txt http://www.ietf.org/rfc/ien/ien116.txt
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "Local and Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004. Control", IEEE Standard 802.1X-2004, December 2004.
[DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery",
Internet-Draft (work in progress), draft-cheshire-dnsext-dns- Internet-Draft (work in progress), draft-cheshire-dnsext-dns-
skipping to change at page 22, line 8 skipping to change at page 23, line 22
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[STD3] Braden, R., "Requirements for Internet Hosts -- Communication [STD3] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, and "Requirements for Internet Hosts Layers", STD 3, RFC 1122, and "Requirements for Internet Hosts
-- Application and Support", STD 3, RFC 1123, October 1989. -- Application and Support", STD 3, RFC 1123, October 1989.
Acknowledgments Acknowledgments
Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola, Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola,
James Kempf and Alfred Hoenes provided valuable input on this James Kempf, Ted Hardie and Alfred Hoenes provided valuable input on
document. this document.
Appendix A - IAB Members at the time of this writing Appendix A - IAB Members at the time of this writing
Loa Andersson Loa Andersson
Gonzalo Camarillo Gonzalo Camarillo
Stuart Cheshire Stuart Cheshire
Russ Housley
Olaf Kolkman Olaf Kolkman
Gregory Lebovitz Gregory Lebovitz
Barry Leiba Barry Leiba
Kurtis Lindqvist Kurtis Lindqvist
Andrew Malis Andrew Malis
Danny McPherson Danny McPherson
David Oran David Oran
Dave Thaler Dave Thaler
Lixia Zhang Lixia Zhang
skipping to change at page 22, line 45 skipping to change at page 24, line 24
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
Loa Andersson Loa Andersson
Acreo AB Acreo AB
EMail: loa@pi.se EMail: loa@pi.nu
Stuart Cheshire Stuart Cheshire
Apple Computer, Inc. Apple Computer, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
EMail: chesire [at] apple [dot] com EMail: chesire [at] apple [dot] com
Full Copyright Statement Full Copyright Statement
 End of changes. 29 change blocks. 
50 lines changed or deleted 152 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/