draft-ietf-v6ops-cpe-simple-security-00.txt   draft-ietf-v6ops-cpe-simple-security-01.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Best Current June 6, 2007 Intended status: Best Current December 21, 2007
Practice Practice
Expires: December 8, 2007 Expires: June 23, 2008
Recommended Simple Security Capabilities in Customer Premises Equipment Recommended Simple Security Capabilities in Customer Premises Equipment
for Providing Residential IPv6 Internet Service for Providing Residential IPv6 Internet Service
draft-ietf-v6ops-cpe-simple-security-00 draft-ietf-v6ops-cpe-simple-security-01
Status of this Memo Status of this Memo
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 8, 2007. This Internet-Draft will expire on June 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document makes specific recommendations to the makers of devices This document makes specific recommendations to the makers of devices
that provide "simple security" capabilities at the perimeter of that provide "simple security" capabilities at the perimeter of
local-area IPv6 networks in Internet-enabled homes and small offices. local-area IPv6 networks in Internet-enabled homes and small offices.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5 2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 7 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8
3.2.1. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Teredo-specific Filters . . . . . . . . . . . . . . . 9 3.2.2. Teredo-specific Filters . . . . . . . . . . . . . . . 9
3.2.3. IPsec and Internet Key Exchange (IKE) . . . . . . . . 9 3.2.3. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10
3.2.4. Other Virtual Private Network Protocols . . . . . . . 10 3.2.4. Other Virtual Private Network Protocols . . . . . . . 10
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 10 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 10
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 14
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 14 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 14
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 14 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 14
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. draft-ietf-v6ops-cpe-simple-security-00 to
Intellectual Property and Copyright Statements . . . . . . . . . . 18 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
In "Local Network Protection for IPv6" [IPv6-NAP], IETF recommends In "Local Network Protection for IPv6" [RFC4864], IETF recommends
'simple security' capabilities for gateway devices that enable 'simple security' capabilities for gateway devices that enable
delivery of Internet services in residential and small office delivery of Internet services in residential and small office
settings. The principle goal of these capabilties is to improve settings. The principle goal of these capabilties is to improve
security of the IPv6 Internet without increasing the perceived security of the IPv6 Internet without increasing the perceived
complexity for users who just want to accomplish useful work. complexity for users who just want to accomplish useful work.
There is, at best, a constructive tension between the desires of There is, at best, a constructive tension between the desires of
users for transparent end-to-end connectivity on the one hand, and users for transparent end-to-end connectivity on the one hand, and
the need for local-area network administrators to detect and prevent the need for local-area network administrators to detect and prevent
intrusion by unauthorized public Internet users on the other. The intrusion by unauthorized public Internet users on the other. The
skipping to change at page 4, line 12 skipping to change at page 4, line 12
including tunnels and transition mechanisms. In referring to their including tunnels and transition mechanisms. In referring to their
security capabilities, it is reasonable to distinguish between the security capabilities, it is reasonable to distinguish between the
"interior" network, i.e. the local-area network, and the "exterior" "interior" network, i.e. the local-area network, and the "exterior"
network, i.e. the public Internet. This document is concerned with network, i.e. the public Internet. This document is concerned with
the behavior of packet filters that police the flow of traffic the behavior of packet filters that police the flow of traffic
between the interior and exterior networks of residential Internet between the interior and exterior networks of residential Internet
gateways. gateways.
The operational goals of security capabilities in Internet gateways The operational goals of security capabilities in Internet gateways
are described with more detail in "Local Network Protection for IPv6" are described with more detail in "Local Network Protection for IPv6"
[IPv6-NAP], but they can be summarized as follows. [RFC4864], but they can be summarized as follows.
o Check all traffic to and from the public Internet for basic o Check all traffic to and from the public Internet for basic
sanity, e.g. anti-spoofing and "martian" filters. sanity, e.g. anti-spoofing and "martian" filters.
o Allow tracking of application usage by source and destination o Allow tracking of application usage by source and destination
transport addresses. transport addresses.
o Provide a barrier against untrusted external influences on the o Provide a barrier against untrusted external influences on the
interior network by requiring filter state to be activated by interior network by requiring filter state to be activated by
traffic originating at interior network nodes. traffic originating at interior network nodes.
o Allow manually configured exceptions to the stateful filtering o Allow manually configured exceptions to the stateful filtering
rules according to network administration policy. rules according to network administration policy.
o Isolate local network DHCP and DNS proxy resolver services from
the public Internet.
Prior to the widespread availability of IPv6 Internet service, homes Prior to the widespread availability of IPv6 Internet service, homes
and small offices often used private IPv4 network address realms and small offices often used private IPv4 network address realms
[RFC1918] with Network Address Translation (NAT) functions deployed [RFC1918] with Network Address Translation (NAT) functions deployed
to present all the hosts on the interior network as a single host to to present all the hosts on the interior network as a single host to
the Internet service provider. The stateful packet filtering the Internet service provider. The stateful packet filtering
behavior of NAT set user expectations that persist today with behavior of NAT set user expectations that persist today with
residential IPv6 service. "Local Network Protection for IPv6" residential IPv6 service. "Local Network Protection for IPv6"
[IPv6-NAP] recommends applying stateful packet filtering at [RFC4864] recommends applying stateful packet filtering at
residential IPv6 gateways that conforms to the user expectations residential IPv6 gateways that conforms to the user expectations
already in place. already in place.
It should be noted that NAT for IPv6 is both strictly forbidden by It should be noted that NAT for IPv6 is both strictly forbidden by
the standards documents and strongly deprecated by Internet the standards documents and strongly deprecated by Internet
operators. Only the perceived security benefits associated with operators. Only the perceived security benefits associated with
stateful packet filtering, which NAT requires as a side effect, are stateful packet filtering, which NAT requires as a side effect, are
thought relevant in the IPv6 residential usage scenario. thought relevant in the IPv6 residential usage scenario.
As the latest revision of this document is being drafted, As the latest revision of this document is being drafted,
skipping to change at page 6, line 17 skipping to change at page 6, line 20
addition to the "automatic sunset" provision in section 5.5 of addition to the "automatic sunset" provision in section 5.5 of
[RFC4380] because it's all too common that nested IPv4/NAT gateways [RFC4380] because it's all too common that nested IPv4/NAT gateways
are deployed unintentionally in residential settings and without are deployed unintentionally in residential settings and without
consideration for Internet architectural implications.) consideration for Internet architectural implications.)
2.3. Transport Layer Protocols 2.3. Transport Layer Protocols
IPv6 simple security functions are principally concerned with the IPv6 simple security functions are principally concerned with the
stateful filtering of transport layers like User Datagram Protocol stateful filtering of transport layers like User Datagram Protocol
(UDP) [RFC0768], Transport Control Protocol (TCP) [RFC0793], the (UDP) [RFC0768], Transport Control Protocol (TCP) [RFC0793], the
Stream Control Transmission Protocol (SCTP) [RFC2960], the Datagram Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram
Congestion Control Protocol (DCCP) [RFC4340], and potentially any Congestion Control Protocol (DCCP) [RFC4340], and potentially any
standards-track transport protocols to be defined in the future. standards-track transport protocols to be defined in the future.
The general operating principle is that transport layer traffic is The general operating principle is that transport layer traffic is
only permitted into the interior network of a residential IPv6 only permitted into the interior network of a residential IPv6
gateway when it has been solicited explicitly by interior nodes. All gateway when it has been solicited explicitly by interior nodes. All
other traffic is expected to be discarded or rejected with an ICMPv6 other traffic is expected to be discarded or rejected with an ICMPv6
error message to indicate the traffic is administratively prohibited. error message to indicate the traffic is administratively prohibited.
3. Detailed Recommendations 3. Detailed Recommendations
skipping to change at page 7, line 13 skipping to change at page 7, line 13
association, e.g. a TCP connection, et cetera. association, e.g. a TCP connection, et cetera.
3.1. Stateless Filters 3.1. Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses, state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers. prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to guard against spoofing and Other stateless filters are recommended to guard against spoofing, to
to enforce multicast scope boundaries. enforce multicast scope boundaries, and to isolate certain local
network services from the public Internet.
R1: Packets bearing in their outer IPv6 headers multicast source R1: Packets bearing in their outer IPv6 headers multicast source
addresses MUST NOT be forwarded or transmitted on any interface. addresses MUST NOT be forwarded or transmitted on any interface.
R2: Packets bearing in their outer IPv6 headers multicast destination R2: Packets bearing in their outer IPv6 headers multicast destination
addresses of equal or narrower scope that the configured scope addresses of equal or narrower scope that the configured scope
boundary level of the gateway MUST NOT be forwarded in any direction. boundary level of the gateway MUST NOT be forwarded in any direction.
The DEFAULT scope boundary level SHOULD be organization-local scope. The DEFAULT scope boundary level SHOULD be organization-local scope.
R3: Packets bearing deprecated extension headers prior to their first R3: Packets bearing deprecated extension headers prior to their first
skipping to change at page 7, line 43 skipping to change at page 7, line 44
R4: Inbound packets MUST NOT be forwarded if the source address in R4: Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for use their outer IPv6 header has a global unicast prefix assigned for use
by globally reachable nodes on the interior network. by globally reachable nodes on the interior network.
R5: Packets MAY be discarded if the source and/or destination address R5: Packets MAY be discarded if the source and/or destination address
in the outer IPv6 header is a unique local address. By DEFAULT, in the outer IPv6 header is a unique local address. By DEFAULT,
gateways SHOULD NOT forward packets across unique local address scope gateways SHOULD NOT forward packets across unique local address scope
boundaries. boundaries.
R6: By DEFAULT, inbound non-recursive DNS queries received on
exterior interfaces MUST NOT be processed by any integrated DNS proxy
resolving server.
R7: Inbound DHCP discovery packets received on exterior interfaces
MUST NOT be processed by any integrated DHCP server.
3.2. Connection-free Filters 3.2. Connection-free Filters
Some Internet applications use connection-free transport protocols Some Internet applications use connection-free transport protocols
with no release semantics, e.g. UDP. These protocols pose a special with no release semantics, e.g. UDP. These protocols pose a special
difficulty for stateful packet filters because most of the difficulty for stateful packet filters because most of the
application state is not carried at the transport level. State application state is not carried at the transport level. State
records are created when communication is initiated and abandoned records are created when communication is initiated and abandoned
when no further communication is detected after some period of time. when no further communication is detected after some period of time.
3.2.1. UDP Filters 3.2.1. UDP Filters
skipping to change at page 8, line 23 skipping to change at page 8, line 32
An interior endpoint initiates a UDP exchange through a stateful An interior endpoint initiates a UDP exchange through a stateful
packet filter by sending a packet to an exterior address. The filter packet filter by sending a packet to an exterior address. The filter
allocates (or reuses) a filter state record for the duration of the allocates (or reuses) a filter state record for the duration of the
exchange. The state record defines the interior and exterior IP exchange. The state record defines the interior and exterior IP
addresses and ports used between all packets in the exchange. addresses and ports used between all packets in the exchange.
State records for UDP exchanges remain active while they are in use State records for UDP exchanges remain active while they are in use
and only abandoned after an idle period of some time. and only abandoned after an idle period of some time.
R7: A state record for a UDP exchange where both interior and R8: A state record for a UDP exchange where both interior and
exterior ports are outside the well-known port range (ports 0-1023) exterior ports are outside the well-known port range (ports 0-1023)
MUST NOT expire in less than two minutes of idle time. The value of MUST NOT expire in less than two minutes of idle time. The value of
the UDP state record idle timer MAY be configurable. The DEFAULT is the UDP state record idle timer MAY be configurable. The DEFAULT is
five minutes. five minutes.
R8: A state record for a UDP exchange where one or both of the R9: A state record for a UDP exchange where one or both of the
interior and exterior ports are in the well-known port range (ports interior and exterior ports are in the well-known port range (ports
0-1023) MAY expire after a period of idle time shorter than two 0-1023) MAY expire after a period of idle time shorter than two
minutes to facilitate the operation of the IANA-registered service minutes to facilitate the operation of the IANA-registered service
assigned to the port in question. assigned to the port in question.
As [RFC4787] notes, outbound refresh is necessary for allowing the As [RFC4787] notes, outbound refresh is necessary for allowing the
interior endpoint to keep the state record alive. Inbound refresh interior endpoint to keep the state record alive. Inbound refresh
may be useful for applications with no outbound UDP traffic. may be useful for applications with no outbound UDP traffic.
However, allowing inbound refresh can allow an attacker in the However, allowing inbound refresh can allow an attacker in the
exterior or a misbehaviing application to keep a state record alive exterior or a misbehaviing application to keep a state record alive
indefinitely. This could be a security risk. Also, if the process indefinitely. This could be a security risk. Also, if the process
is repeated with different ports, over time, it could use up all the is repeated with different ports, over time, it could use up all the
state record memory and resources in the filter. state record memory and resources in the filter.
R9: A state record for a UDP exchange MUST be refreshed when a packet R10: A state record for a UDP exchange MUST be refreshed when a
is forwarded from the interior to the exterior, and it MAY be packet is forwarded from the interior to the exterior, and it MAY be
refreshed when a packet is forwarded in the reverse direction. refreshed when a packet is forwarded in the reverse direction.
As described in section 5.5 of [RFC4787], the connection-free As described in section 5.5 of [RFC4787], the connection-free
semantics of UDP pose a difficulty for packet filters in trying to semantics of UDP pose a difficulty for packet filters in trying to
recognize which packets comprise an application flow and which are recognize which packets comprise an application flow and which are
unsolicited. Various strategies have been used in IPv4/NAT gateways unsolicited. Various strategies have been used in IPv4/NAT gateways
with differing effects. with differing effects.
R10: If application transparency is most important, then a stateful R11: If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior for packet filter SHOULD have "Endpoint independent filter" behavior for
UDP. If a more stringent filtering behavior is most important, then UDP. If a more stringent filtering behavior is most important, then
a filter SHOULD have "Address dependent filtering" behavior. The a filter SHOULD have "Address dependent filtering" behavior. The
filtering behavior MAY be an option configurable by the network filtering behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering behavior administrator, and it MAY be independent of the filtering behavior
for TCP and other protocols. for TCP and other protocols.
Applications mechanisms may depend on the reception of ICMP error Applications mechanisms may depend on the reception of ICMP error
messages triggered by the transmission of UDP messages. One such messages triggered by the transmission of UDP messages. One such
mechanism is path MTU discovery. mechanism is path MTU discovery.
R11: If a gateway forwards a UDP exchange, it MUST also forward ICMP R12: If a gateway forwards a UDP exchange, it MUST also forward ICMP
Destination Unreachable messages containing UDP headers that match Destination Unreachable messages containing UDP headers that match
the exchange state record. the exchange state record.
R12: Receipt of any sort of ICMP message MUST NOT terminate the state R13: Receipt of any sort of ICMP message MUST NOT terminate the state
record for a UDP exchange. record for a UDP exchange.
3.2.2. Teredo-specific Filters 3.2.2. Teredo-specific Filters
Transitional residential IPv6 gateways that also feature integrated Transitional residential IPv6 gateways that also feature integrated
IPv4/NAT gateways require special filtering for Teredo tunnels. IPv4/NAT gateways require special filtering for Teredo tunnels.
R13: Where an IPv6 prefix is advertised on an interior interface R14: Where an IPv6 prefix is advertised on an interior interface
alongside an IPv4 private address [RFC1918] and IPv4 Internet service alongside an IPv4 private address [RFC1918] and IPv4 Internet service
is provided with NAT [RFC4787], the Teredo qualification procedure is provided with NAT [RFC4787], the Teredo qualification procedure
(see section 5.2.1 and 5.2.2 of [RFC4380]) for clients in the (see section 5.2.1 and 5.2.2 of [RFC4380]) for clients in the
interior MUST be prohibited by the IPv4/NAT stateful filter. This interior MUST be prohibited by the IPv4/NAT stateful filter. This
SHOULD be done by blocking outbound UDP initiations to port 3544, the SHOULD be done by blocking outbound UDP initiations to port 3544, the
port reserved by IANA for Teredo servers. This MAY be done by port reserved by IANA for Teredo servers. This MAY be done by
discarding Teredo packets identified by the heuristic defined in discarding Teredo packets identified by the heuristic defined in
"Teredo Security Concerns Beyond What Is In RFC 4380" [HOAGLAND]. "Teredo Security Concerns Beyond What Is In RFC 4380" [HOAGLAND].
[ EDITOR'S NOTE: In the event [HOAGLAND] does not advance to [ EDITOR'S NOTE: In the event [HOAGLAND] does not advance to
publication as an RFC, then that heuristic will be reproduced here. ] publication as an RFC, then that heuristic will be reproduced here. ]
3.2.3. IPsec and Internet Key Exchange (IKE) 3.2.3. IPsec and Internet Key Exchange (IKE)
Internet protocol security (IPsec) offers greater flexibility and Internet protocol security (IPsec) offers greater flexibility and
better overall security than the simple security of stateful packet better overall security than the simple security of stateful packet
filtering at network perimeters. Therefore, residential IPv6 filtering at network perimeters. Therefore, residential IPv6
gateways need not prohibit IPsec traffic flows. gateways need not prohibit IPsec traffic flows.
R14: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R15: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
with destination extension headers of type "Authenticated Header with destination extension headers of type "Authenticated Header
(AH)" [RFC4302] in their outer IP extension header chain. (AH)" [RFC4302] in their outer IP extension header chain.
R15: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R16: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
with an upper layer protocol of type "Encapsulating Security Payload with an upper layer protocol of type "Encapsulating Security Payload
(ESP)" [RFC4303] in their outer IP extension header chain. (ESP)" [RFC4303] in their outer IP extension header chain.
R16: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R17: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of any UDP packets, to and from legitimate node the forwarding of any UDP packets, to and from legitimate node
addresses, with a destination port of 500, i.e. the port reserved by addresses, with a destination port of 500, i.e. the port reserved by
IANA for the Internet Key Exchange Protocol [RFC4306]. IANA for the Internet Key Exchange Protocol [RFC4306].
3.2.4. Other Virtual Private Network Protocols 3.2.4. Other Virtual Private Network Protocols
Residential IPv6 gateways are not expected to prohibit the use of Residential IPv6 gateways are not expected to prohibit the use of
virtual private networks in residential usage scenarios. virtual private networks in residential usage scenarios.
R17: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R18: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding, to and from legitimate node addresses, with upper the forwarding, to and from legitimate node addresses, with upper
layer protocol of type IP version 6, and SHOULD NOT prohibit the layer protocol of type IP version 6, and SHOULD NOT prohibit the
forwarding of other tunneled networking protocols commonly used for forwarding of other tunneled networking protocols commonly used for
virtual private networking, e.g. IP version 4, Generic Routing virtual private networking, e.g. IP version 4, Generic Routing
Encapsulation, etcetera. Encapsulation, etcetera.
3.3. Connection-oriented Filters 3.3. Connection-oriented Filters
Most Internet applications use connection-oriented transport Most Internet applications use connection-oriented transport
protocols with orderly release semantics. These protocols include protocols with orderly release semantics. These protocols include
the Transport Control Protocol (TCP) [RFC0793], the Stream Control the Transport Control Protocol (TCP) [RFC0793], the Stream Control
Transmission Protocol (SCTP) [RFC2960], the Datagram Congestion Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion
Control Protocol (DCCP) [RFC4340], and potentially any future IETF Control Protocol (DCCP) [RFC4340], and potentially any future IETF
standards-track transport protocols that use such semantics. standards-track transport protocols that use such semantics.
Stateful packet filters track the state of individual transport Stateful packet filters track the state of individual transport
connections and prohibit the forwarding of packets that do not match connections and prohibit the forwarding of packets that do not match
the state of an active connection and do not conform to a rule for the state of an active connection and do not conform to a rule for
the automatic creation of such state. the automatic creation of such state.
3.3.1. TCP Filters 3.3.1. TCP Filters
An interior endpoint initiates a TCP connection through a stateful An interior endpoint initiates a TCP connection through a stateful
skipping to change at page 11, line 13 skipping to change at page 11, line 27
cross in the network. Upon receiving the other end's SYN packet, cross in the network. Upon receiving the other end's SYN packet,
each end responds with a SYN-ACK packet, which also cross in the each end responds with a SYN-ACK packet, which also cross in the
network. The connection is established at each endpoint once the network. The connection is established at each endpoint once the
SYN-ACK packets are received. SYN-ACK packets are received.
In order to provide stateful packet filtering service for TCP, it is In order to provide stateful packet filtering service for TCP, it is
necessary for a filter to receive, process and forward all packets necessary for a filter to receive, process and forward all packets
for a connection that conform to valid transitions of the TCP state for a connection that conform to valid transitions of the TCP state
machine (Fig. 6, [RFC0793]). machine (Fig. 6, [RFC0793]).
R17: All valid sequences of TCP packets (defined in [RFC0793]) MUST R19: All valid sequences of TCP packets (defined in [RFC0793]) MUST
be forwarded for outbound connections and explicitly permitted be forwarded for outbound connections and explicitly permitted
inbound connections. In particular, both the normal TCP 3-way inbound connections. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes of handshake mode of operation and the simultaneous-open modes of
operation MUST be supported. operation MUST be supported.
A stateful filter can allow an existing mapping to be reused by an A stateful filter can allow an existing mapping to be reused by an
externally initiated connection if its security policy permits. externally initiated connection if its security policy permits.
Several different policies are possible as described in "Network Several different policies are possible as described in "Network
Address Translation (NAT) Behavioral Requirements for Unicast UDP Address Translation (NAT) Behavioral Requirements for Unicast UDP
[RFC4787] and extended in "NAT Behaviorial Requirements for TCP" [RFC4787] and extended in "NAT Behaviorial Requirements for TCP"
[BEHAVE-TCP]. [BEHAVE-TCP].
R18: If application transparency is most important, then a stateful R20: If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior for packet filter SHOULD have "Endpoint independent filter" behavior for
TCP. If a more stringent filtering behavior is most important, then TCP. If a more stringent filtering behavior is most important, then
a filter SHOULD have "Address dependent filtering" behavior. The a filter SHOULD have "Address dependent filtering" behavior. The
filtering behavior MAY be an option configurable by the network filtering behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering behavior administrator, and it MAY be independent of the filtering behavior
for UDP and other protocols. for UDP and other protocols.
If an inbound SYN packet is filtered, either because a corresponding If an inbound SYN packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error silently, or to signal an error to the sender. Signaling an error
through ICMP messages allows the sender to detect that the SYN did through ICMP messages allows the sender to detect that the SYN did
not reach the intended destination. Discarding the packet, on the not reach the intended destination. Discarding the packet, on the
other hand, allows applications to perform simultaneous-open more other hand, allows applications to perform simultaneous-open more
reliably. A more detailed discussion of this issue can be found in reliably. A more detailed discussion of this issue can be found in
[BEHAVE-TCP], but the basic outcome of it is that filters need to [BEHAVE-TCP], but the basic outcome of it is that filters need to
wait on signaling errors until simultaneous-open will not be wait on signaling errors until simultaneous-open will not be
impaired. impaired.
R19: A gateway MUST NOT signal an error for an unsolicited inbound R21: A gateway MUST NOT signal an error for an unsolicited inbound
SYN packet for at least 6 seconds after the packet is received. If SYN packet for at least 6 seconds after the packet is received. If
during this interval the gateway receives and forwards an outbound during this interval the gateway receives and forwards an outbound
SYN for the connection, then the gateway MUST discard the original SYN for the connection, then the gateway MUST discard the original
unsolicited inbound SYN packet without signaling an error. unsolicited inbound SYN packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN-- error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of network unless sending any response violates the security policy of network
administrator. administrator.
A TCP filter maintains state associated with in-progrss and A TCP filter maintains state associated with in-progrss and
skipping to change at page 12, line 50 skipping to change at page 13, line 15
The "established connection idle-timeout" for a stateful packet The "established connection idle-timeout" for a stateful packet
filter is defined as the minimum time a TCP connection in the filter is defined as the minimum time a TCP connection in the
established phase must remain idle before the filter considers the established phase must remain idle before the filter considers the
associated state record a candidate for collection. The "transitory associated state record a candidate for collection. The "transitory
connection idle-timeout" for a filter is defined as the minimum time connection idle-timeout" for a filter is defined as the minimum time
a TCP connection in the partially-open or closing phases must remain a TCP connection in the partially-open or closing phases must remain
idle before the filter considers the associated state record a idle before the filter considers the associated state record a
candidate for collection. TCP connections in the TIME_WAIT state are candidate for collection. TCP connections in the TIME_WAIT state are
not affected by the "transitory connection idle-timeout" parameter. not affected by the "transitory connection idle-timeout" parameter.
R20: If a gateway cannot determine whether the endpoints of a TCP R22: If a gateway cannot determine whether the endpoints of a TCP
connection are active, then it MAY abandon the state record if it has connection are active, then it MAY abandon the state record if it has
been idle for some time. In such cases, the value of the been idle for some time. In such cases, the value of the
"established connection idle-timeout" MUST NOT be less than two hours "established connection idle-timeout" MUST NOT be less than two hours
four minutes. The value of the "transitory connection idle-timeout" four minutes. The value of the "transitory connection idle-timeout"
MUST NOT be less than four minutes. The value of the idle-timeouts MUST NOT be less than four minutes. The value of the idle-timeouts
MAY be configurable by the network administrator. MAY be configurable by the network administrator.
Behavior for handing RST packets, or connections in the TIME_WAIT Behavior for handing RST packets, or connections in the TIME_WAIT
state is left unspecified. A gateway MAY hold state for a connection state is left unspecified. A gateway MAY hold state for a connection
in TIME_WAIT state to accommodate retransmissions of the last ACK. in TIME_WAIT state to accommodate retransmissions of the last ACK.
skipping to change at page 13, line 39 skipping to change at page 13, line 52
example due to a timeout expiring, the filter MAY send a TCP RST example due to a timeout expiring, the filter MAY send a TCP RST
packet to each endpoint on behalf of the other. Sending a RST packet to each endpoint on behalf of the other. Sending a RST
notification allows endpoint applications to recover more quickly, notification allows endpoint applications to recover more quickly,
however, notifying endpoints might not always be possible if, for however, notifying endpoints might not always be possible if, for
example, state records are lost due to power interruption. example, state records are lost due to power interruption.
Several TCP mechanisms depend on the reception of ICMP error messages Several TCP mechanisms depend on the reception of ICMP error messages
triggered by the transmission of TCP segments. One such mechanism is triggered by the transmission of TCP segments. One such mechanism is
path MTU discovery, which is required for correct operation of TCP. path MTU discovery, which is required for correct operation of TCP.
R21: If a gateway forwards a TCP connection, it MUST also forward R23: If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that ICMP Destination Unreachable messages containing TCP headers that
match the connection state record. match the connection state record.
R22: Receipt of any sort of ICMP message MUST NOT terminate the state R24: Receipt of any sort of ICMP message MUST NOT terminate the state
record for a TCP connection. record for a TCP connection.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
[ Insert verbiage here. ] [ Insert verbiage here. ]
3.3.3. DCCP Filters 3.3.3. DCCP Filters
[ Insert verbiage here. ] [ Insert verbiage here. ]
skipping to change at page 14, line 25 skipping to change at page 14, line 34
One proposal that has been offered as an Internet Draft is the One proposal that has been offered as an Internet Draft is the
Application Listener Discovery Protocol [IPv6-ALD]. It remains to be Application Listener Discovery Protocol [IPv6-ALD]. It remains to be
seen whether the Internet Gateway Device profile of the Universal seen whether the Internet Gateway Device profile of the Universal
Plug And Play protocol will be extended for IPv6. Other proposals of Plug And Play protocol will be extended for IPv6. Other proposals of
note include the Middlebox Communication Protocol [RFC3989] and the note include the Middlebox Communication Protocol [RFC3989] and the
Next Steps in Signaling framework [RFC4080]. No consensus has yet Next Steps in Signaling framework [RFC4080]. No consensus has yet
emerged in the Internet engineering community as to which proposal is emerged in the Internet engineering community as to which proposal is
most appropriate for residential IPv6 usage scenarios. most appropriate for residential IPv6 usage scenarios.
R23: Gateways MUST implement a protocol to permit applications to R25: Gateways MUST implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses of solicit inbound traffic without advance knowledge of the addresses of
exterior nodes with which they expect to communicate. This protocol exterior nodes with which they expect to communicate. This protocol
MUST have a specification that meets the requirements of [RFC3978], MUST have a specification that meets the requirements of [RFC3978],
[RFC3979] and [RFC4748]. [RFC3979] and [RFC4748].
4. Summary of Recommendations 4. Summary of Recommendations
This section collects all of the recommendations made in this This section collects all of the recommendations made in this
document into a convenient list. document into a convenient list.
skipping to change at page 14, line 39 skipping to change at page 15, line 4
[RFC3979] and [RFC4748]. [RFC3979] and [RFC4748].
4. Summary of Recommendations 4. Summary of Recommendations
This section collects all of the recommendations made in this This section collects all of the recommendations made in this
document into a convenient list. document into a convenient list.
[ EDITOR'S NOTE: This section is left intentionally incomplete while [ EDITOR'S NOTE: This section is left intentionally incomplete while
discussion on the V6CPE Design Team mailing list establishes a discussion on the V6CPE Design Team mailing list establishes a
consensus about what to present at IETF 68 in Chicago. ] consensus about what to present at IETF 68 in Chicago. ]
R1-Rn: Insert summary of recommendations R1-Rn here. R1-Rn: Insert summary of recommendations R1-Rn here.
5. Contributors 5. Contributors
[ Insert list of contributors here. ] Comments and criticisms during the development of this document were
received from the following IETF participants: Jun-ichiro itojun
Hagino, Kurt Erik Lindqvist and Fred Baker.
[ Insert list of additional contributors here. ]
Much of the text describing the detailed requirements for TCP and UDP Much of the text describing the detailed requirements for TCP and UDP
filtering is derived or transposed from [BEHAVE-TCP] and [RFC4787], filtering is derived or transposed from [BEHAVE-TCP] and [RFC4787],
and some form of attribution here may therefore be appopriate. and some form of attribution here may therefore be appopriate.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
skipping to change at page 15, line 22 skipping to change at page 15, line 35
See RFC 3552 [RFC3552] for a guide. See RFC 3552 [RFC3552] for a guide.
[ EDITOR'S NOTE: Yes, I'm sure there are security considerations, but [ EDITOR'S NOTE: Yes, I'm sure there are security considerations, but
I'm currently at a loss for words to describe them. This section I'm currently at a loss for words to describe them. This section
needs careful wordsmithing prior to the next revision. ] needs careful wordsmithing prior to the next revision. ]
8. References 8. References
8.1. Normative References 8.1. Normative References
[BEHAVE-TCP]
Guha, S., Biswas, K., Sivakumar, S., Ford, B., and P.
Srisuresh, "NAT Behavioral Requirements for TCP",
April 2007,
<http://tools.ietf.org/html/draft-ietf-behave-tcp>.
[HOAGLAND]
Hoagland, J., "Teredo Security Concerns Beyond What Is In
RFC 4380", May 2007, <http://tools.ietf.org/html/
draft-hoagland-v6ops-teredoconcerns>.
[IPv6-NAP]
Van de Velde, G., Hain, T., Droms, R., and B. Carpenter,
"Local Network Protection for IPv6", January 2007,
<http://tools.ietf.org/html/draft-ietf-v6ops-nap>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005. RFC 3978, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005. Technology", BCP 79, RFC 3979, March 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
skipping to change at page 16, line 37 skipping to change at page 16, line 32
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF
Trust", BCP 78, RFC 4748, October 2006. Trust", BCP 78, RFC 4748, October 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
8.2. Informative References 8.2. Informative References
[BEHAVE-TCP]
Guha, S., Biswas, K., Sivakumar, S., Ford, B., and P.
Srisuresh, "NAT Behavioral Requirements for TCP",
April 2007,
<http://tools.ietf.org/html/draft-ietf-behave-tcp>.
[HOAGLAND]
Hoagland, J., "Teredo Security Concerns Beyond What Is In
RFC 4380", May 2007, <http://tools.ietf.org/html/
draft-hoagland-v6ops-teredosecconcerns>.
[IPv6-ALD] [IPv6-ALD]
Woodyatt, j., "Application Listener Discovery (ALD) for Woodyatt, j., "Application Listener Discovery (ALD) for
IPv6", May 2007, IPv6", May 2007,
<http://tools.ietf.org/html/draft-woodyatt-ald>. <http://tools.ietf.org/html/draft-woodyatt-ald>.
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port [NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
Mapping Protocol (NAT-PMP)", November 2001, Mapping Protocol (NAT-PMP)", November 2001,
<http://tools.ietf.org/html/draft-cheshire-nat-pmp>. <http://tools.ietf.org/html/draft-cheshire-nat-pmp>.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
skipping to change at page 17, line 25 skipping to change at page 17, line 34
Communications (MIDCOM) Protocol Semantics", RFC 3989, Communications (MIDCOM) Protocol Semantics", RFC 3989,
February 2005. February 2005.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005. RFC 4080, June 2005.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006. April 2006.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway UPnP Forum, "Universal Plug and Play Internet Gateway
Device Standardized Gateway Device Protocol", Device Standardized Gateway Device Protocol",
September 2006, September 2006,
<http://www.upnp.org/standardizeddcps/igd.asp>. <http://www.upnp.org/standardizeddcps/igd.asp>.
Appendix A. Additional Stuff Appendix A. Change Log
This becomes an Appendix. A.1. draft-ietf-v6ops-cpe-simple-security-00 to
draft-ietf-v6ops-cpe-simple-security-01
o Added requirements for sequestering DHCP and DNS proxy resolver
services to the local network.
o Fixed numbering of recommendations.
o Local Network Protection is now [RFC4864].
o SCTP is now [RFC4960].
o Moved some references to informative.
o Corrected the reference for [HOAGLAND].
Author's Address Author's Address
james woodyatt (editor) james woodyatt (editor)
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
US US
Email: jhw@apple.com Email: jhw@apple.com
 End of changes. 44 change blocks. 
63 lines changed or deleted 90 lines changed or added

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