draft-ietf-v6ops-cpe-simple-security-10.txt   draft-ietf-v6ops-cpe-simple-security-11.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Informational March 26, 2010 Intended status: Informational April 24, 2010
Expires: September 27, 2010 Expires: October 26, 2010
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-10 draft-ietf-v6ops-cpe-simple-security-11
Abstract Abstract
This document makes specific recommendations to the makers of devices This document identifies a set of recommendations for the makers of
that provide "simple security" capabilities at the perimeter of devices describing how to provide for "simple security" capabilities
local-area IPv6 networks in Internet-enabled homes and small offices. at the perimeter of local-area IPv6 networks in Internet-enabled
homes and small offices.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on October 26, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 4 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Use of Normative Keywords . . . . . . . . . . . . . . . . 3
2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 6 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 7 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 9 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8
3.2.1. Internet Control and Management . . . . . . . . . . . 9 3.2.1. Internet Control and Management . . . . . . . . . . . 8
3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 9 3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8
3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 9
3.2.4. 6to4 Tunnels . . . . . . . . . . . . . . . . . . . . . 11 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10
3.2.5. IPsec and Internet Key Exchange (IKE) . . . . . . . . 11 3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 11
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 15
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 18
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 21 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 21
3.5. Management Applications . . . . . . . . . . . . . . . . . 22 3.5. Management Applications . . . . . . . . . . . . . . . . . 22
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 22
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32
A.1. draft-ietf-v6ops-cpe-simple-security-00 to A.1. draft-ietf-v6ops-cpe-simple-security-10 to
draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 33 draft-ietf-v6ops-cpe-simple-security-11 . . . . . . . . . 32
A.2. draft-ietf-v6ops-cpe-simple-security-01 to Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 33
A.3. draft-ietf-v6ops-cpe-simple-security-02 to
draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 33
A.4. draft-ietf-v6ops-cpe-simple-security-03 to
draft-ietf-v6ops-cpe-simple-security-04 . . . . . . . . . 34
A.5. draft-ietf-v6ops-cpe-simple-security-04 to
draft-ietf-v6ops-cpe-simple-security-05 . . . . . . . . . 34
A.6. draft-ietf-v6ops-cpe-simple-security-05 to
draft-ietf-v6ops-cpe-simple-security-06 . . . . . . . . . 35
A.7. draft-ietf-v6ops-cpe-simple-security-06 to
draft-ietf-v6ops-cpe-simple-security-07 . . . . . . . . . 36
A.8. draft-ietf-v6ops-cpe-simple-security-07 to
draft-ietf-v6ops-cpe-simple-security-08 . . . . . . . . . 36
A.9. draft-ietf-v6ops-cpe-simple-security-08 to
draft-ietf-v6ops-cpe-simple-security-09 . . . . . . . . . 36
A.10. draft-ietf-v6ops-cpe-simple-security-09 to
draft-ietf-v6ops-cpe-simple-security-10 . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Some IPv6 gateway devices that enable delivery of Internet services Some IPv6 gateway devices that enable delivery of Internet services
in residential and small office settings are augmented with 'simple in residential and small office settings may be augmented with
security' capabilities as described in the Informational document 'simple security' capabilities as described in "Local Network
"Local Network Protected for IPv6" [RFC4864]. Protection for IPv6" [RFC4864]. In general, these capabilities cause
packets to be discarded in an attempt to make local networks and the
The principle goal of these capabilities is to improve security of Internet more secure. However, it is worth noting that some packets
the IPv6 Internet without increasing the perceived complexity for sent by legitimate applications may also be discarded in this
users who just want to accomplish useful work. However, there is a process, affecting reliability and ease of use for these
constructive tension between the desires of users for transparent applications.
end-to-end connectivity on the one hand, and the need for local-area
network administrators to detect and prevent intrusion by
unauthorized public Internet users on the other. The specific
recommendations in this document are intended to promote optimal
local-area network security while retaining full end-to-end
transparency for users, and to highlight reasonable limitations on
transparency where security considerations are deemed important.
Residential and small office network administrators are expected to
have no expertise in Internet engineering whatsoever. Configuration
interfaces for simple security in router/gateway appliances marketed
toward them should be easy to understand and even easier to ignore.
In particular, extra care should be taken in designing the baseline
operating modes of unconfigured devices, since the security functions
of most devices will never be changed from their factory set default.
The mechanisms described in this document cause packets to be There is a constructive tension between the desires of users for
discarded by residential gateways in an attempt to make home networks transparent end-to-end connectivity on the one hand, and the need for
and the Internet more secure. However, some packets sent by local-area network administrators to detect and prevent intrusion by
legitimate applications may also be discarded in the process, unauthorized public Internet users on the other. This document is
affecting reliability and ease of use for these applications. intended to highlight reasonable limitations on end-to-end
transparency where security considerations are deemed important to
promote local and Internet security.
Note well: this document is not a standard and conformance with it is The reader is cautioned always to remember that the typical
not required in order to claim conformance with IETF standards for residential or small office network administrator has no expertise
IPv6. It uses the normative keywords defined below only for whatsoever in Internet engineering. Configuration interfaces for
precision. Particular attention is drawn to recommendation REC-41, router/gateway appliances marketed toward them should be easy to
which calls for an easy way for a user to set a gateway to a understand and even easier to ignore. In particular, extra care
transparent mode. should be used in the design of baseline operating modes for
unconfigured devices, since most devices will never be changed from
their factory configurations.
1.1. Special Language 1.1. Special Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
The key word "DEFAULT" in this document is to be interpreted as the Additionally, the key word "DEFAULT" is to be interpreted in this
configuration of a device, as applied by its vendor, prior to the document as pertaining to a configuration as applied by a vendor,
operator changing it for the first time. prior to the administrator changing it for its initial activation.
1.2. Use of Normative Keywords
NOTE WELL: This document is not a standard, and conformance with it
is not required in order to claim conformance with IETF standards for
IPv6. It uses the normative keywords defined in the previous section
only for precision.
Particular attention is drawn to recommendation REC-43, which calls
for an easy way to set a gateway to a transparent mode of operation.
2. Overview 2. Overview
For the purposes of this document, residential Internet gateways are For the purposes of this document, residential Internet gateways are
assumed to be fairly simple devices with a limited subset of the full assumed to be fairly simple devices with a limited subset of the full
range of possible features. They function as default routers range of possible features. They function as default routers
[RFC4294] for a single local-area network segment, e.g. an ethernet, [RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi
a Wi-Fi network, a bridge between two or more such segments. They network, a bridge between two or more such segments. They have only
have a single interface by which they connect to the public Internet, one interface by which they can access the Internet service at any
and they can obtain service by any combination of sub-IP mechanisms, one time, using any of several possible sub-IP mechanisms including
including tunnels and transition mechanisms. In referring to their tunnels and transition mechanisms.
security capabilities, it is reasonable to distinguish between the
"interior" network, i.e. the local-area network, and the "exterior" In referring to the security capabilities of residential gateways, it
network, i.e. the public Internet. This document is concerned with is reasonable to distinguish between their "interior" network, i.e.
the behavior of packet filters that police the flow of traffic the local-area network, and their "exterior" networks, e.g. the
between the interior and exterior networks of residential Internet public Internet and the networks of Internet service providers. This
gateways. document is concerned only with the behavior of IP packet filters
that police the flow of traffic between the interior IPv6 network and
the exterior IPv6 networks of residential Internet 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"
[RFC4864], 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" [RFC4949] filters. sanity, e.g. anti-spoofing and "martian" [RFC4949] filters.
o Allow tracking of application usage by source and destination o Allow tracking of applications 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 administrative policy.
o Isolate local network DHCP and DNS proxy resolver services from o Isolate local network DHCPv6 and DNS resolver services from the
the public Internet. 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"
[RFC4864] 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.
Conventional stateful packet filters activate new states as a side Conventional stateful packet filters activate new states as a side
effect of forwarding outbound flow initiations from interior network effect of forwarding outbound flow initiations from interior network
nodes. This requires applications to have advance knowledge of the nodes. This requires applications to have advance knowledge of the
addresses of exterior nodes with which they expect to communicate. addresses of exterior nodes with which they expect to communicate.
Several proposals are currently under consideration for allowing Several proposals are currently under consideration for allowing
applications to solicit inbound traffic from exterior nodes without applications to solicit inbound traffic from exterior nodes without
advance knowledge of their addresses. While consensus within the advance knowledge of their addresses. While consensus within the
Internet engineering community has emerged that such protocols are Internet engineering community has emerged that such protocols are
necessary to implement in residential IPv6 gateways, the best current necessary to implement in residential IPv6 residential gateways, the
practice has not yet been established. best current practice has not yet been established.
2.1. Basic Sanitation 2.1. Basic Sanitation
In addition to the functions required of all Internet routers In addition to the functions required of all Internet routers
[RFC4294], residential gateways are expected to have basic stateless [RFC4294], residential gateways are expected to have basic stateless
filters for prohibiting certains kinds of traffic with invalid filters for prohibiting certain kinds of traffic with invalid
headers, e.g. "martian" packets, spoofs, routing header type code headers, e.g. "martian" packets, spoofs, routing header type code
zero, etc. (See Section 3.1 for details.) zero, etc. (See Section 3.1 for more details.)
Conversely, simple Internet gateways are not expected to prohibit the Conversely, simple Internet gateways are not expected to prohibit the
development of new applications. In particular, packets with end-to- development of new applications. In particular, packets with end-to-
end network security and routing extension headers for mobility are end network security and routing extension headers for mobility are
expected to pass Internet gateways freely. expected to pass Internet gateways freely.
Finally, Internet gateways that route multicast traffic are expected Finally, Internet gateways that route multicast traffic are expected
to implement appropriate filters for multicast to limit the scope of to implement appropriate filters for multicast traffic to limit the
multicast groups that span the demarcation between residential scope of multicast groups that span the demarcation between
networks and service provider networks. residential networks and service provider networks.
2.2. Internet Layer Protocols 2.2. Internet Layer Protocols
As virtual private networking tunnels are regarded as an unacceptably As virtual private networking tunnels are regarded as an unacceptably
wide attack surface, this document recommends the DEFAULT operating wide attack surface, this document recommends the DEFAULT operating
mode for residential IPv6 simple security is to treat IP-in-IP and mode for residential IPv6 simple security is to treat Generic Packet
GRE tunneling protocols as opaque transport layers, i.e. inbound Tunneling [RFC2473] and similar protocols as opaque transport layers,
tunnel initiations are denied and outbound tunnel initiations are i.e. inbound tunnel initiations are denied and outbound tunnel
accepted. IPsec transport and tunnel modes are explicitly secured by initiations are accepted.
IPsec transport and tunnel modes are explicitly secured by
definition, so this document recommends the DEFAULT operating mode definition, so this document recommends the DEFAULT operating mode
permit IPsec and Internet Key Exchange (IKE) flows to pass without permit IPsec. To facilitate the use of IPsec in support of IPv6
filtering. Mobility, Internet Key Exchange (IKE) protocol [RFC4306] and "Host
Identity Protocol (HIP)" [RFC5201] should also be permitted in the
DEFAULT operating mode.
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 Internet Control and Management Protocol (ICMP) stateful filtering of Internet Control Message Protocol (ICMPv6)
[RFC4443] and transport layers like User Datagram Protocol (UDP)
[RFC4884] and transport layers like User Datagram Protocol (UDP) [RFC0768], Lightweight User Datagram Protocol (UDP-Lite) [RFC3828],
[RFC0768] (and Lightweight User Datagram Protocol (UDP-Lite) Transport Control Protocol (TCP) [RFC0793], the Stream Control
[RFC3828]), Transport Control Protocol (TCP) [RFC0793], the Stream Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion
Control Transmission Protocol (SCTP) [RFC4960], the Datagram Control Protocol (DCCP) [RFC4340], and potentially any standards-
Congestion Control Protocol (DCCP) [RFC4340], and potentially any 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
not forwarded into the interior network of a residential IPv6 gateway not forwarded into the interior network of a residential IPv6 gateway
unless it has been solicited explicitly by interior transport unless it has been solicited explicitly by interior transport
endpoints, e.g. by matching the reverse path for previously forwarded endpoints, e.g. by matching the reverse path for previously forwarded
outbound traffic, or by matching manually configured exceptions set outbound traffic, or by matching configured exceptions set by the
by the network administrator. All other traffic is expected to be network administrator. All other traffic is expected to be discarded
discarded or rejected with an ICMPv6 error message to indicate the or rejected with an ICMPv6 error message to indicate the traffic is
traffic is administratively prohibited. administratively prohibited.
3. Detailed Recommendations 3. Detailed Recommendations
This section describes the specific recommendations made by this This section describes the specific recommendations made by this
document in full detail. They are summarized into a convenient list document in full detail. Section 4 is a summary.
in Section 4.
Some recommended filters are to be applied to all traffic that passes Some recommended filters are to be applied to all traffic that passes
through residential Internet gateways regardless of the direction through residential Internet gateways regardless of the direction
they are to be forwarded. Other recommended filters are intended to they are to be forwarded. Other recommended filters are intended to
be sensitive to the "direction" of traffic flows. Applied to be sensitive to the "direction" of traffic flows. Applied to
bidirectional transport flows, "direction" has a specific meaning in bidirectional transport flows, "direction" has a specific meaning in
this document. this document.
Packets are said to be "outbound" if they originate from interior Packets are said to be "outbound" if they originate at nodes located
nodes to be forwarded to the Internet, and "inbound" if they in the interior network for exterior destinations, and "inbound" if
originate from exterior nodes to be forwarded to any node or nodes on they arrive from exterior sources with interior destinations.
the interior prefix.
Flows, as opposed to packets, are said to be "outbound" if the Flows are said to be "outbound" if the originator of the initial
originator of the initial packet in any given transport association packet in any given transport association is an interior node and one
is an interior node and one or more of the participants are at or more of the participants are located in the exterior. Flows are
exterior addresses. Flows are said to be "inbound" if the originator said to be "inbound" if the originator of the initial packet is an
of the initial packet is an exterior node and one or more of the exterior node and one or more of the participants are nodes on the
participants are nodes on the interior network. interior network.
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 implement ingress Other stateless filters are recommended to implement ingress
skipping to change at page 8, line 20 skipping to change at page 7, line 22
REC-1: Packets which bear in their outer IPv6 headers multicast REC-1: Packets which bear in their outer IPv6 headers multicast
source addresses MUST NOT be forwarded or transmitted on any source addresses MUST NOT be forwarded or transmitted on any
interface. interface.
REC-2: Packets which bear in their outer IPv6 headers multicast REC-2: Packets which bear in their outer IPv6 headers multicast
destination addresses of equal or narrower scope (see IPv6 Scoped destination addresses of equal or narrower scope (see IPv6 Scoped
Address Architecture [RFC4007]) than the configured scope boundary Address Architecture [RFC4007]) than the configured scope boundary
level of the gateway MUST NOT be forwarded in any direction. The level of the gateway MUST NOT be forwarded in any direction. The
DEFAULT scope boundary level SHOULD be organization-local scope, and DEFAULT scope boundary level SHOULD be organization-local scope, and
it SHOULD be configurable by the network admininistrator. it SHOULD be configurable by the network administrator.
REC-3: Packets bearing source and/or destination addresses forbidden REC-3: Packets bearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over the public to appear in the outer headers of packets transmitted over the public
Internet MUST NOT be forwarded. In particular, site-local addresses Internet MUST NOT be forwarded. In particular, site-local addresses
are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use
of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and
ORCHID prefixes. ORCHID prefixes.
REC-4: Packets bearing deprecated extension headers prior to their REC-4: Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be forwarded or first upper-layer-protocol header SHOULD NOT be forwarded or
transmitted on any interface. In particular, all packets with transmitted on any interface. In particular, all packets with
routing extension header type 0 [RFC2460] preceding the first upper- routing extension header type 0 [RFC2460] preceding the first upper-
layer-protocol header MUST NOT be forwarded. (See [RFC5095] for layer-protocol header MUST NOT be forwarded. See [RFC5095] for
additional background.) additional background.
REC-5: Outbound packets MUST NOT be forwarded if the source address REC-5: Outbound packets MUST NOT be forwarded if the source address
in their outer IPv6 header does not have a unicast prefix configured in their outer IPv6 header does not have a unicast prefix configured
for use by globally reachable nodes on the interior network. for use by globally reachable nodes on the interior network.
REC-6: Inbound packets MUST NOT be forwarded if the source address in REC-6: 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.
REC-7: By DEFAULT, packets with unique local source and/or REC-7: By DEFAULT, packets with unique local source and/or
destination addresses [RFC4193] SHOULD NOT be forwarded to or from destination addresses [RFC4193] SHOULD NOT be forwarded to or from
the exterior network. the exterior network.
REC-8: By DEFAULT, inbound non-recursive DNS queries received on REC-8: By DEFAULT, inbound non-recursive DNS queries received on
exterior interfaces MUST NOT be processed by any integrated DNS proxy exterior interfaces MUST NOT be processed by any integrated DNS
resolving server. resolving server.
REC-9: Inbound DHCP discovery packets received on exterior interfaces REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
MUST NOT be processed by any integrated DHCP server. exterior interfaces MUST NOT be processed by any integrated DHCPv6
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. Internet Control and Management 3.2.1. Internet Control and Management
Recommendations for filtering ICMPv6 messages in firewall devices are Recommendations for filtering ICMPv6 messages in firewall devices are
described separately in [RFC4890] and apply generally to residential described separately in [RFC4890] and apply to residential gateways
gateways as to any class of router. No additional recommendations with the additional recommendation that incoming "Destination
are made here, but it's important to note that Destination Unreachable" and "Packet Too Big" error messages that don't match any
Unreachable and Packet Too Big errors corresponding to filtering filtering state should be dropped.
states for all upper-layer transport protocols are important to the
proper function of the Internet. REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
Unreachable" and "Packet Too Big messages" containing IP headers that
do not match generic upper-layer transport state 3-tuples.
3.2.2. Upper-layer Transport Protocols 3.2.2. Upper-layer Transport Protocols
Residential IPv6 gateways are not expected to prohibit the use of Residential IPv6 gateways are not expected to prohibit the use of
applications to be developed using future upper-layer transport applications to be developed using future upper-layer transport
protocols. In particular, transport protocols not otherwise protocols. In particular, transport protocols not otherwise
discussed in subsequent sections of this document are expected to be discussed in subsequent sections of this document are expected to be
treated consistently, i.e. as having connection-free semantics and no treated consistently, i.e. as having connection-free semantics and no
special requirements to inspect the transport headers. special requirements to inspect the transport headers.
In general, upper-layer transport filter state records are expected In general, upper-layer transport filter state records are expected
to be created when an interior endpoint sends a packet to an exterior to be created when an interior endpoint sends a packet to an exterior
address. The filter allocates (or reuses) a record for the duration address. The filter allocates (or reuses) a record for the duration
of communications, with an idle timer to delete the state record when of communications, with an idle timer to delete the state record when
no further communications are detected. no further communications are detected.
REC-10: Filter state records for generic upper-layer transport REC-11: Filter state records for generic upper-layer transport
protocols MUST BE indexable by a 3-tuple comprising the interior node protocols MUST be indexable by a 3-tuple comprising the interior node
address, the exterior node address and the upper-layer transport address, the exterior node address and the upper-layer transport
protocol identifier. protocol identifier.
REC-11: Filter state records for generic upper-layer transport REC-12: Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer not protocols MUST NOT be deleted or recycled until an idle timer not
less than two minutes has expired without having forwarded a packet less than two minutes has expired without having forwarded a packet
matching the state in some configurable amount of time. By DEFAULT, matching the state in some configurable amount of time. By DEFAULT,
the idle timer for such state records is five minutes. the idle timer for such state records is five minutes.
REC-12: IPv6 gateways MUST forward ICMP Destination Unreachable and
Packet Too Big messages containing IP headers that match generic
upper-layer transport state 3-tuples.
3.2.3. UDP Filters 3.2.3. UDP Filters
"Network Address Translation (NAT) Behavioral Requirements for "Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP" [RFC4787] defines the terminology and best current Unicast UDP" [RFC4787] defines the terminology and best current
practice for stateful filtering of UDP applications in IPv4 with NAT, practice for stateful filtering of UDP applications in IPv4 with NAT,
which serves as the model for behavioral requirements for simple UDP which serves as the model for behavioral requirements for simple UDP
security in IPv6 gateways, notwithstanding the requirements related security in IPv6 gateways, notwithstanding the requirements related
specifically to network address translation. specifically to network address translation.
An interior endpoint initiates a UDP exchange through a stateful An interior endpoint initiates a UDP flow through a stateful packet
packet filter by sending a packet to an exterior address. The filter 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 flow. 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 flow.
State records for UDP exchanges remain active while they are in use State records for UDP flows remain active while they are in use and
and only abandoned after an idle period of some time. only abandoned after an idle period of some time.
REC-13: A state record for a UDP exchange where both interior and REC-13: A state record for a UDP flow where both source and
exterior ports are outside the well-known port range (ports 0-1023) destination ports are outside the well-known port range (ports
MUST NOT expire in less than two minutes of idle time. The value of 0-1023) MUST NOT expire in less than two minutes of idle time. The
the UDP state record idle timer MAY be configurable. The DEFAULT is value of the UDP state record idle timer MAY be configurable. The
five minutes. DEFAULT is five minutes.
REC-14: A state record for a UDP exchange where one or both of the REC-14: A state record for a UDP flow where one or both of the source
interior and exterior ports are in the well-known port range (ports and destination ports are in the well-known port range (ports 0-1023)
0-1023) MAY expire after a period of idle time shorter than two MAY expire after a period of idle time shorter than two minutes to
minutes to facilitate the operation of the IANA-registered service facilitate the operation of the IANA-registered service assigned to
assigned to the port in question. 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 misbehaving application to keep a state record alive exterior or a misbehaving 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.
REC-15: A state record for a UDP exchange MUST be refreshed when a REC-15: A state record for a UDP flow MUST be refreshed when a packet
packet is forwarded from the interior to the exterior, and it MAY be 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.
REC-16: If application transparency is most important, then a REC-16: If application transparency is most important, then a
stateful packet filter SHOULD have "Endpoint independent filter" stateful packet filter SHOULD have "Endpoint independent filter"
behavior for UDP. If a more stringent filtering behavior is most behavior for UDP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "Address dependent filtering" important, then a filter SHOULD have "Address dependent filtering"
behavior. The filtering behavior MAY be an option configurable by behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the filtering the network administrator, and it MAY be independent of the filtering
behavior for TCP and other protocols. Filtering behavior SHOULD by behavior for TCP and other protocols. Filtering behavior SHOULD by
endpoint independent by DEFAULT in gateways intended for provisioning endpoint independent by DEFAULT in gateways intended for provisioning
without service-provider management. without service-provider management.
Applications mechanisms may depend on the reception of ICMP error Applications mechanisms may depend on the reception of ICMPv6 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.
REC-17: If a gateway forwards a UDP exchange, it MUST also forward REC-17: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
ICMP Destination Unreachable and Packet Too Big messages containing "Destination Unreachable" and "Packet Too Big messages" containing
UDP headers that match the exchange state record. UDP headers that match the flow state record.
REC-18: Receipt of any sort of ICMP message MUST NOT terminate the
state record for a UDP exchange.
REC-19: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same
way as UDP exchanges, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore UDP
packets MUST NOT match UDP-Lite state records, and vice versa.
3.2.4. 6to4 Tunnels REC-18: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP flow.
Typical dual-stack IPv4/IPv6 residential gateways use private IPv4 REC-19: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
address ranges and network address/port translation on a single IPv4 UDP flows, except that the upper-layer transport protocol identifier
address assigned by the service provider. The use of private for UDP-Lite is not the same as UDP, and therefore UDP packets MUST
addresses prevents interior hosts from using 6to4 [RFC3068] tunnels. NOT match UDP-Lite state records, and vice versa.
3.2.5. IPsec and Internet Key Exchange (IKE) 3.2.4. IPsec and Internet Key Exchange (IKE)
Internet protocol security (IPsec) offers greater flexibility and The Internet protocol security suite (IPsec) offers greater
better overall security than the simple security of stateful packet flexibility and better overall security than the simple security of
filtering at network perimeters. Therefore, residential IPv6 stateful packet filtering at network perimeters. Therefore,
gateways need not prohibit IPsec traffic flows. residential IPv6 gateways need not prohibit IPsec traffic flows.
REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with destination extension headers of type "Authenticated addresses, with destination extension headers of type "Authenticated
Header (AH)" [RFC4302] in their outer IP extension header chain. Header (AH)" [RFC4302] in their outer IP extension header chain.
REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with an upper layer protocol of type "Encapsulating addresses, with an upper layer protocol of type "Encapsulating
Security Payload (ESP)" [RFC4303] in their outer IP extension header Security Payload (ESP)" [RFC4303] in their outer IP extension header
chain. chain.
Internet Key Exchange (IKE) is a secure mechanism for exchanging
cryptographic material. Residential IPv6 gateways are expected to
facilitate the use of IPsec security policies by allowing inbound IKE
flows.
REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of any UDP packets, to and from legitimate prohibit the forwarding of any UDP packets, to and from legitimate
node addresses, with a destination port of 500, i.e. the port node addresses, with a destination port of 500, i.e. the port
reserved by IANA for the Internet Key Exchange Protocol [RFC4306]. reserved by IANA for the Internet Key Exchange (IKE) protocol
[RFC4306].
REC-23: In all operating modes, IPv6 gateways SHOULD use filter state REC-23: In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] that are records for Encapsulating Security Payload (ESP) [RFC4303] that are
indexable by a 3-tuple comprising the interior node address, the indexable by a 3-tuple comprising the interior node address, the
exterior node address and the ESP protocol identifier. In exterior node address and the ESP protocol identifier. In
particular, the IPv4/NAT method of indexing state records also by particular, the IPv4/NAT method of indexing state records also by
security parameters index (SPI) SHOULD NOT be used. Likewise, any security parameters index (SPI) SHOULD NOT be used. Likewise, any
mechanism that depends on detection of Internet Key Exchange (IKE) mechanism that depends on detection of Internet Key Exchange (IKE)
[RFC4306] initiations SHOULD NOT be used. [RFC4306] initiations SHOULD NOT be used.
"Host Identity Protocol (HIP)" is a secure mechanism for establishing
host identity and secure communications between authenticated hosts.
Residential IPv6 gateways need not prohibit inbound HIP flows.
REC-24: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node
addresses, with destination extension headers of type "Host Identity
Protocol (HIP)" [RFC5201] in their outer IP extension header chain.
3.2.5. Mobility Support in IPv6
Mobility support in IPv6 [RFC3775] relies on the use of an
encapsulation mechanism in flows between mobile nodes and their
correspondent nodes, involving the use of the type 2 IPv6 routing
header and the Home Address destination header option. In contrast
to mobility support in IPv4, mobility is a standard feature of IPv6,
and no security benefit is generally to be gained by denying
communications with either interior or exterior mobile nodes.
REC-25: The state records for flows initiated by outbound packets
that bear a Home Address destination option [RFC3775] are
distinguished by the addition of the home address of the flow as well
as the interior Care-of address. IPv6 gateways MUST NOT prohibit the
forwarding of any inbound packets bearing type 2 routing headers,
which otherwise match a flow state record, and where A) the
destination matches the home address of the flow, and B) the Home
Address field in the routing header matches the interior Care-of
address of the flow.
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 TCP, SCTP, DCCP, and potentially any future IETF standards-track
Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion transport protocols that use such semantics. Stateful packet filters
Control Protocol (DCCP) [RFC4340], and potentially any future IETF track the state of individual transport flows and prohibit the
standards-track transport protocols that use such semantics. forwarding of packets that do not match the state of an active flow
Stateful packet filters track the state of individual transport and do not conform to a rule for the automatic creation of such
connections and prohibit the forwarding of packets that do not match state.
the state of an active connection and do not conform to a rule for
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 flow through a stateful packet
packet filter by sending a SYN packet. The filter allocates (or filter by sending a SYN packet. The filter allocates (or reuses) a
reuses) a filter state record for the connection. The state record filter state record for the flow. The state record defines the
defines the interior and exterior IP addresses and ports used for interior and exterior IP addresses and ports used for forwarding all
forwarding all packets for that connection. packets for that flow.
Some peer-to-peer applications use an alternate method of connection Some peer-to-peer applications use an alternate method of connection
initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse
stateful filters. In the simultaneous-open mode of operation, both stateful filters. In the simultaneous-open mode of operation, both
peers send SYN packets for the same TCP connection. The SYN packets peers send SYN packets for the same TCP flow. The SYN packets cross
cross in the network. Upon receiving the other end's SYN packet, in the network. Upon receiving the other end's SYN packet, each end
each end responds with a SYN-ACK packet, which also cross in the responds with a SYN-ACK packet, which also cross in the network. The
network. The connection is established at each endpoint once the connection is established at each endpoint once the SYN-ACK packets
SYN-ACK packets are received. are received.
To provide stateful packet filtering service for TCP, it is necessary To provide stateful packet filtering service for TCP, it is necessary
for a filter to receive, process and forward all packets for a for a filter to receive, process and forward all packets for a flow
connection that conform to valid transitions of the TCP state machine that conform to valid transitions of the TCP state machine (Fig. 6,
(Fig. 6, [RFC0793]). [RFC0793]).
REC-24: All valid sequences of TCP packets (defined in [RFC0793]) REC-26: All valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound connections and explicitly permitted MUST be forwarded for outbound flows and explicitly permitted inbound
inbound connections. In particular, both the normal TCP 3-way flows. In particular, both the normal TCP 3-way handshake mode of
handshake mode of operation and the simultaneous-open modes of operation and the simultaneous-open modes of operation MUST be
operation MUST be supported. supported.
It is possible to reconstruct enough of the state of a TCP connection It is possible to reconstruct enough of the state of a TCP flow to
to allow forwarding between an interior and exterior node even when allow forwarding between an interior and exterior node even when the
the filter starts operating after TCP enters the established state. filter starts operating after TCP enters the established state. In
In this case, because the filter has not seen the TCP window-scale this case, because the filter has not seen the TCP window-scale
option, it is not possible for the filter to enforce the TCP window option, it is not possible for the filter to enforce the TCP window
invariant by dropping out-of-window segments. invariant by dropping out-of-window segments.
REC-25: The TCP window invariant MUST NOT be enforced on connections REC-27: The TCP window invariant MUST NOT be enforced on flows for
for which the filter did not detect whether the window-scale option which the filter did not detect whether the window-scale option (see
(see [RFC1323]) was sent in the 3-way handshake or simultaneous open. [RFC1323]) was sent in the 3-way handshake or simultaneous open.
A stateful filter can allow an existing state record to be reused by A stateful filter can allow an existing state record to be reused by
an externally initiated connection if its security policy permits. an externally initiated flow if its security policy permits. Several
Several different policies are possible as described in "Network different policies are possible as described in [RFC4787] and
Address Translation (NAT) Behavioral Requirements for Unicast UDP extended in [RFC5382].
[RFC4787] and extended in "NAT Behavioral Requirements for TCP"
[RFC5382].
REC-26: If application transparency is most important, then a REC-28: If application transparency is most important, then a
stateful packet filter SHOULD have "Endpoint independent filter" stateful packet filter SHOULD have "Endpoint independent filter"
behavior for TCP. If a more stringent filtering behavior is most behavior for TCP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "Address dependent filtering" important, then a filter SHOULD have "Address dependent filtering"
behavior. The filtering behavior MAY be an option configurable by behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the filtering the network administrator, and it MAY be independent of the filtering
behavior for UDP and other protocols. Filtering behavior SHOULD by behavior for UDP and other protocols. Filtering behavior SHOULD by
endpoint independent by DEFAULT in gateways intended for provisioning endpoint independent by DEFAULT in gateways intended for provisioning
without service-provider management. without service-provider management.
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 ICMPv6 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
[RFC5382], but the basic outcome of it is that filters need to wait [RFC5382], but the basic outcome of it is that filters need to wait
on signaling errors until simultaneous-open will not be impaired. on signaling errors until simultaneous-open will not be impaired.
REC-27: By DEFAULT, a gateway MUST respond with an ICMP Destination REC-29: By DEFAULT, a gateway MUST respond with an ICMPv6
Unreachable error (administratively prohibited) to any unsolicited "Destination Unreachable" error code 1 (administratively prohibited)
inbound SYN packet after waiting at least 6 seconds without first to any unsolicited inbound SYN packet after waiting at least 6
forwarding the associated outbound SYN or SYN/ACK from the interior seconds without first forwarding the associated outbound SYN or SYN/
peer. ACK from the interior peer.
A TCP filter maintains state associated with in-progress and A TCP filter maintains state associated with in-progress connections
established connections. Because of this, a filter is susceptible to and established flows. Because of this, a filter is susceptible to a
a resource-exhaustion attack whereby an attacker (or virus) on the resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long needs to abandon unused state records after a sufficiently long
period of idleness. period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by abandon preferentially flow state records for crashed endpoints,
closed TCP connections and partially-open connections. A gateway can followed by closed flows and partially-open flows. A gateway can
check if an endpoint for a session has crashed by sending a TCP keep- check if an endpoint for a session has crashed by sending a TCP keep-
alive packet on behalf of the other endpoint and receiving a TCP RST alive packet on behalf of the other endpoint and receiving a TCP RST
packet in response. If the gateway connot determine whether the packet in response. If the gateway cannot determine whether the
endpoint is active, then the associated state record needs to be endpoint is active, then the associated state record needs to be
retained until the TCP connection has been idle for some time. Note: retained until the TCP flow has been idle for some time. Note: an
an established TCP connection can stay idle (but live) indefinitely; established TCP flow can stay idle (but live) indefinitely; hence,
hence, there is no fixed value for an idle-timeout that accommodates there is no fixed value for an idle-timeout that accommodates all
all applications. However, a large idle-timeout motivated by applications. However, a large idle-timeout motivated by
recommendations in [RFC1122] and [RFC4294] can reduce the chances of recommendations in [RFC1122] and [RFC4294] can reduce the chances of
abandoning a live connection. abandoning a live flow.
TCP connections can stay in the established phase indefinitely TCP flows can stay in the established phase indefinitely without
without exchanging packets. Some end-hosts can be configured to send exchanging packets. Some end-hosts can be configured to send keep-
keep-alive packets on such idle connections; by default, such packets alive packets on such idle flows; by default, such packets are sent
are sent every two hours, if enabled [RFC1122]. Consequently, a every two hours, if enabled [RFC1122]. Consequently, a filter that
filter that waits for slightly over two hours can detect idle waits for slightly over two hours can detect idle flows with keep-
connections with keep-alive packets being sent at the default rate. alive packets being sent at the default rate. TCP flows in the
TCP connections in the partially-open or closing phases, on the other partially-open or closing phases, on the other hand, can stay idle
hand, can stay idle for at most four minutes while waiting for in- for at most four minutes while waiting for in-flight packets to be
flight packets to be delivered [RFC1122]. delivered [RFC1122].
The "established connection idle-timeout" for a stateful packet The "established flow idle-timeout" for a stateful packet filter is
filter is defined as the minimum time a TCP connection in the defined as the minimum time a TCP flow in the established phase must
established phase must remain idle before the filter considers the remain idle before the filter considers the associated state record a
associated state record a candidate for collection. The "transitory candidate for collection. The "transitory flow idle-timeout" for a
connection idle-timeout" for a filter is defined as the minimum time filter is defined as the minimum time a TCP flow in the partially-
a TCP connection in the partially-open or closing phases must remain open or closing phases must remain idle before the filter considers
idle before the filter considers the associated state record a the associated state record a candidate for collection. TCP flows in
candidate for collection. TCP connections in the TIME_WAIT state are the TIME_WAIT state are not affected by the "transitory flow idle-
not affected by the "transitory connection idle-timeout" parameter. timeout" parameter.
REC-28: If a gateway cannot determine whether the endpoints of a TCP REC-30: If a gateway cannot determine whether the endpoints of a TCP
connection are active, then it MAY abandon the state record if it has flow are active, then it MAY abandon the state record if it has been
been idle for some time. In such cases, the value of the idle for some time. In such cases, the value of the "established
"established connection idle-timeout" MUST NOT be less than two hours flow idle-timeout" MUST NOT be less than two hours four minutes, as
four minutes, as discussed in [RFC5382]. The value of the discussed in [RFC5382]. The value of the "transitory flow idle-
"transitory connection idle-timeout" MUST NOT be less than four timeout" MUST NOT be less than four minutes. The value of the idle-
minutes. The value of the idle-timeouts MAY be configurable by the timeouts MAY be configurable by the network administrator.
network administrator.
Behavior for handing RST packets, or connections in the TIME_WAIT Behavior for handing RST packets, or TCP flows in the TIME_WAIT state
state is left unspecified. A gateway MAY hold state for a connection is left unspecified. A gateway MAY hold state for a flow in
in TIME_WAIT state to accommodate retransmissions of the last ACK. TIME_WAIT state to accommodate retransmissions of the last ACK.
However, since the TIME_WAIT state is commonly encountered by However, since the TIME_WAIT state is commonly encountered by
interior endpoints properly closing the TCP connection, holding state interior endpoints properly closing the TCP flow, holding state for a
for a closed connection can limit the throughput of connections closed flow can limit the throughput of flows through a gateway with
through a gateway with limited resources. [RFC1337] discusses limited resources. [RFC1337] discusses hazards associated with
hazards associated with TIME_WAIT assassination. TIME_WAIT assassination.
The handling of non-SYN packets for which there is no active state The handling of non-SYN packets for which there is no active state
record is left unspecified. Such packets can be received if the record is left unspecified. Such packets can be received if the
gateway abandons a live connection, or abandons a connection in the gateway abandons a live flow, or abandons a flow in the TIME_WAIT
TIME_WAIT state before the four minute TIME_WAIT period expires. The state before the four minute TIME_WAIT period expires. The decision
decision either to discard or to respond with an ICMP Destination either to discard or to respond with an ICMPv6 "Destination
Unreachable error, code 1 (administratively prohibited) is left up to Unreachable" error code 1 (administratively prohibited) is left up to
the implementation. the implementation.
Behavior for notifying endpoints when abandoning live connections is Behavior for notifying endpoints when abandoning live flows is left
left unspecified. When a gateway abandons a live connection, for unspecified. When a gateway abandons a live flow, for example due to
example due to a timeout expiring, the filter MAY send a TCP RST a timeout expiring, the filter MAY send a TCP RST packet to each
packet to each endpoint on behalf of the other. Sending a RST endpoint on behalf of the other. Sending a RST notification allows
notification allows endpoint applications to recover more quickly, endpoint applications to recover more quickly, however, notifying
however, notifying endpoints might not always be possible if, for endpoints might not always be possible if, for example, state records
example, state records are lost due to power interruption. 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 ICMPv6 error
triggered by the transmission of TCP segments. One such mechanism is messages triggered by the transmission of TCP segments. One such
path MTU discovery, which is required for correct operation of TCP. mechanism is path MTU discovery, which is required for correct
operation of TCP.
REC-29: If a gateway forwards a TCP connection, it MUST also forward REC-31: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
ICMP Destination Unreachable and Packet Too Big messages containing "Destination Unreachable" and "Packet Too Big" messages containing
TCP headers that match the connection state record. TCP headers that match the flow state record.
REC-30: Receipt of any sort of ICMP message MUST NOT terminate the REC-32: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP connection. state record for a TCP flow.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
Because Stream Control Transmission Protocol (SCTP) [RFC4960] Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows
connections can be terminated at multiple network addresses, IPv6 can be terminated at multiple network addresses, IPv6 simple security
simple security functions cannot achieve full transparency for SCTP functions cannot achieve full transparency for SCTP applications. In
applications. In multipath traversal scenarios, full transparency multipath traversal scenarios, full transparency requires
requires coordination between all the packet filter processes in the coordination between all the packet filter processes in the various
various paths between the endpoint network addresses. Such paths between the endpoint network addresses. Such coordination is
coordination is not "simple" and it is, therefore, beyond the scope not "simple" and it is, therefore, beyond the scope of this
of this recommendation. recommendation.
However, some SCTP applications are capable of tolerating the However, some SCTP applications are capable of tolerating the
inherent unipath restriction of IPv6 simple security, even in inherent unipath restriction of IPv6 simple security, even in
multipath traversal scenarios. They expect similar connection- multipath traversal scenarios. They expect similar connection-
oriented filtering behaviors as for TCP, but at the level of SCTP oriented filtering behaviors as for TCP, but at the level of SCTP
associations, not stream connections. This section describes associations, not stream connections. This section describes
specific recommendations for SCTP filtering for such traversal specific recommendations for SCTP filtering for such traversal
scenarios. scenarios.
An interior endpoint initiates SCTP associations through a stateful An interior endpoint initiates SCTP associations through a stateful
skipping to change at page 16, line 51 skipping to change at page 16, line 27
of the peers in simultaneous-open mode of operation will send an of the peers in simultaneous-open mode of operation will send an
ERROR or ABORT chunk along with the INIT-ACK chunk. The association ERROR or ABORT chunk along with the INIT-ACK chunk. The association
is established at each endpoint once an INIT-ACK chunks is received is established at each endpoint once an INIT-ACK chunks is received
at one end without an ERROR or ABORT chunk. at one end without an ERROR or ABORT chunk.
To provide stateful packet filtering service for SCTP, it is To provide stateful packet filtering service for SCTP, 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 an association that conform to valid transitions of the SCTP for an association that conform to valid transitions of the SCTP
state machine (Fig. 3, [RFC4960]). state machine (Fig. 3, [RFC4960]).
REC-31: All valid sequences of SCTP packets (defined in [RFC4960]) REC-33: All valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly permitted MUST be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP inbound associations. In particular, both the normal SCTP
association establishment and simultaneous-open modes of operation association establishment and simultaneous-open modes of operation
MUST be supported. MUST be supported.
If an inbound INIT packet is filtered, either because a corresponding If an inbound INIT 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 INIT through ICMPv6 messages allows the sender to detect that the INIT
packet did not reach the intended destination. Discarding the packet did not reach the intended destination. Discarding the
packet, on the other hand, allows applications to perform packet, on the other hand, allows applications to perform
simultaneous-open more reliably. Delays in signaling errors can simultaneous-open more reliably. Delays in signaling errors can
prevent the impairment of simultaneous-open mode of operation. prevent the impairment of simultaneous-open mode of operation.
REC-32: By DEFAULT, a gateway MUST respond with an ICMP Destination REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6
Unreachable error (administratively prohibited) to any unsolicited "Destination Unreachable" error code 1 (administratively prohibited),
inbound INIT packet after waiting at least 6 seconds without first to any unsolicited inbound INIT packet after waiting at least 6
forwarding the associated outbound INIT from the interior peer. seconds without first forwarding the associated outbound INIT from
the interior peer.
An SCTP filter maintains state associated with in-progress and An SCTP filter maintains state associated with in-progress and
established associations. Because of this, a filter is susceptible established associations. Because of this, a filter is susceptible
to a resource-exhaustion attack whereby an attacker (or virus) on the to a resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long needs to abandon unused state records after a sufficiently long
period of idleness. period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to A common method used for TCP filters in IPv4/NAT gateways is to
skipping to change at page 18, line 18 skipping to change at page 17, line 43
The "established association idle-timeout" for a stateful packet The "established association idle-timeout" for a stateful packet
filter is defined as the minimum time an SCTP association in the filter is defined as the minimum time an SCTP association in the
established phase must remain idle before the filter considers the established phase must remain idle before the filter considers the
corresponding state record a candidate for collection. The corresponding state record a candidate for collection. The
"transitory association idle-timeout" for a filter is defined as the "transitory association idle-timeout" for a filter is defined as the
minimum time an SCTP association in the partially-open or closing minimum time an SCTP association in the partially-open or closing
phases must remain idle before the filter considers the corresponding phases must remain idle before the filter considers the corresponding
state record a candidate for collection. state record a candidate for collection.
REC-33: If a gateway cannot determine whether the endpoints of an REC-35: If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state record if SCTP association are active, then it MAY abandon the state record if
it has been idle for some time. In such cases, the value of the it has been idle for some time. In such cases, the value of the
"established association idle-timeout" MUST NOT be less than two "established association idle-timeout" MUST NOT be less than two
hours four minutes. The value of the "transitory association idle- hours four minutes. The value of the "transitory association idle-
timeout" MUST NOT be less than four minutes. The value of the idle- timeout" MUST NOT be less than four minutes. The value of the idle-
timeouts MAY be configurable by the network administrator. timeouts MAY be configurable by the network administrator.
Behavior for handling ERROR and ABORT packets is left unspecified. A Behavior for handling ERROR and ABORT packets is left unspecified. A
gateway MAY hold state for an association after its closing phases gateway MAY hold state for an association after its closing phases
have completed to accommodate retransmissions of its final SHUTDOWN have completed to accommodate retransmissions of its final SHUTDOWN
ACK packets. However, holding state for a closed association can ACK packets. However, holding state for a closed association can
limit the throughput of associations traversing a gateway with limit the throughput of associations traversing a gateway with
limited resources. The discussion in [RFC1337] regarding the hazards limited resources. The discussion in [RFC1337] regarding the hazards
of TIME_WAIT assassination are relevant. of TIME_WAIT assassination are relevant.
The handling of inbound non-INIT packets for which there is no active The handling of inbound non-INIT packets for which there is no active
state record is left unspecified. Such packets can be received if state record is left unspecified. Such packets can be received if
the gateway abandons a live connection, or abandons an association in the gateway abandons a live flow, or abandons an association in the
the closing states before the transitory association idle-timeout closing states before the transitory association idle-timeout
expires. The decision either to discard or to respond with an ICMP expires. The decision either to discard or to respond with an ICMPv6
Destination Unreachable error, code 1 (administratively prohibited) "Destination Unreachable" error code 1 (administratively prohibited)
is left to the implementation. is left to the implementation.
Behavior for notifying endpoints when abandoning live associations is Behavior for notifying endpoints when abandoning live associations is
left unspecified. When a gateway abandons a live association, for left unspecified. When a gateway abandons a live association, for
example due to a timeout expiring, the filter MAY send an ABORT example due to a timeout expiring, the filter MAY send an ABORT
packet to each endpoint on behalf of the other. Sending an ABORT packet to each endpoint on behalf of the other. Sending an ABORT
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 SCTP mechanisms depend on the reception of ICMP error Several SCTP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of SCTP packets. messages triggered by the transmission of SCTP packets.
REC-34: If a gateway forwards an SCTP association, it MUST also REC-36: If a gateway forwards an SCTP association, it MUST also
forward ICMP Destination Unreachable and Packet Too Big messages forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
containing SCTP headers that match the association state record. messages containing SCTP headers that match the association state
record.
REC-35: Receipt of any sort of ICMP message MUST NOT terminate the REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for an SCTP association. state record for an SCTP association.
3.3.3. DCCP Filters 3.3.3. DCCP Filters
The connection semantics described in Datagram Congestion Control The connection semantics described in Datagram Congestion Control
Protocol (DCCP) [RFC4340] are very similar to those of TCP. An Protocol (DCCP) [RFC4340] are very similar to those of TCP. An
interior endpoint initiates a DCCP connection through a stateful interior endpoint initiates a DCCP flow through a stateful packet
packet filter by sending a DCCP-Request packet. Simultaneous open is filter by sending a DCCP-Request packet. Simultaneous open is not
not defined for DCCP. defined for DCCP.
In order to provide stateful packet filtering service for DCCP, it is In order to provide stateful packet filtering service for DCCP, 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 DCCP state for a flow that conform to valid transitions of the DCCP state
machine (Section 8, [RFC4340]). machine (Section 8, [RFC4340]).
REC-36: All valid sequences of DCCP packets (defined in [RFC4340]) REC-38: All valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all connections to exterior servers and those MUST be forwarded for all flows to exterior servers and those flows
connections to interior servers with explicitly permitted service to interior servers with explicitly permitted service codes.
codes.
It is possible to reconstruct enough of the state of a DCCP It is possible to reconstruct enough of the state of a DCCP flow to
connection to allow forwarding between an interior and exterior node allow forwarding between an interior and exterior node even when the
even when the filter starts operating after DCCP enters the OPEN filter starts operating after DCCP enters the OPEN state. Also, a
state. Also, a filter can allow an existing state record to be filter can allow an existing state record to be reused by an
reused by an externally initiated connection if its security policy externally initiated flow if its security policy permits. As with
permits. As with TCP, several different policies are possible, with TCP, several different policies are possible, with a good discussion
a good discussion of the issue involved presented in Network Address of the issue involved presented in [RFC4787] and extended in
Translation (NAT) Behavioral Requirements for Unicast UDP [RFC4787] [RFC5382].
and extended in NAT Behavioral Requirements for TCP [RFC5382].
If an inbound DCCP-Request packet is filtered, either because a If an inbound DCCP-Request packet is filtered, either because a
corresponding state record does not already exist for it or because corresponding state record does not already exist for it or because
of the filter's normal behavior of refusing connections not of the filter's normal behavior of refusing flows not explicitly
explicitly permitted, then a filter has two basic choices: to discard permitted, then a filter has two basic choices: to discard the packet
the packet silently, or to signal an error to the sender. Signaling silently, or to signal an error to the sender. Signaling an error
an error through ICMP messages allows the sender to detect that the through ICMPv6 messages allows the sender to detect that the DCCP-
DCCP-Request did not reach the intended destination. Discarding the Request did not reach the intended destination. Discarding the
packet, on the other hand, only delays the failure to connect and packet, on the other hand, only delays the failure to connect and
provides no measurable security. provides no measurable security.
A DCCP filter maintains state associated with in-progress and A DCCP filter maintains state associated with in-progress connections
established connections. Because of this, a filter is susceptible to and established flows. Because of this, a filter is susceptible to a
a resource-exhaustion attack whereby an attacker (or virus) on the resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To prevent such an attack, a filter needs to creating state records. To prevent such an attack, a filter needs to
abandon unused state records after a sufficiently long period of abandon unused state records after a sufficiently long period of
idleness. idleness.
A common method used for TCP filters in IPv4/NAT gateways is to A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by abandon preferentially sessions for crashed endpoints, followed by
closed TCP connections and partially-open connections. No such closed TCP flows and partially-open flows. No such method exists for
method exists for DCCP, and connections can stay in the OPEN phase DCCP, and flows can stay in the OPEN phase indefinitely without
indefinitely without exchanging packets. Hence, there is no fixed exchanging packets. Hence, there is no fixed value for an idle-
value for an idle-timeout that accommodates all applications. timeout that accommodates all applications. However, a large idle-
However, a large idle-timeout motivated by [RFC4294] can reduce the timeout motivated by [RFC4294] can reduce the chances of abandoning a
chances of abandoning a live connection. live flow.
DCCP connections in the partially-open or closing phases can stay DCCP flows in the partially-open or closing phases can stay idle for
idle for at most eight minutes while waiting for in-flight packets to at most eight minutes while waiting for in-flight packets to be
be delivered. delivered.
The "open connection idle-timeout" for a stateful packet filter is The "open flow idle-timeout" for a stateful packet filter is defined
defined as the minimum time a DCCP connection in the open state must as the minimum time a DCCP flow in the open state must remain idle
remain idle before the filter considers the associated state record a before the filter considers the associated state record a candidate
candidate for collection. The "transitory connection idle-timeout" for collection. The "transitory flow idle-timeout" for a filter is
for a filter is defined as the minimum time a DCCP connection in the defined as the minimum time a DCCP flow in the partially-open or
partially-open or closing phases must remain idle before the filter closing phases must remain idle before the filter considers the
considers the associated state record a candidate for collection. associated state record a candidate for collection. DCCP flows in
DCCP connections in the TIMEWAIT state are not affected by the the TIMEWAIT state are not affected by the "transitory flow idle-
"transitory connection idle-timeout" parameter. timeout" parameter.
REC-37: A gateway MAY abandon a DCCP state record if it has been idle REC-39: A gateway MAY abandon a DCCP state record if it has been idle
for some time. In such cases, the value of the "established for some time. In such cases, the value of the "established flow
connection idle-timeout" MUST NOT be less than two hours four idle-timeout" MUST NOT be less than two hours four minutes. The
minutes. The value of the "transitory connection idle-timeout" MUST value of the "transitory flow idle-timeout" MUST NOT be less than
NOT be less than eight minutes. The value of the idle-timeouts MAY eight minutes. The value of the idle-timeouts MAY be configurable by
be configurable by the network administrator. the network administrator.
Behavior for handing DCCP-Reset packets, or connections in the Behavior for handing DCCP-Reset packets, or flows in the TIMEWAIT
TIMEWAIT state is left unspecified. A gateway MAY hold state for a state is left unspecified. A gateway MAY hold state for a flow in
connection in TIMEWAIT state to accommodate retransmissions of the TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset.
last DCCP-Reset. However, since the TIMEWAIT state is commonly However, since the TIMEWAIT state is commonly encountered by interior
encountered by interior endpoints properly closing the DCCP endpoints properly closing the DCCP flow, holding state for a closed
connection, holding state for a closed connection can limit the flow can limit the throughput of flows through a gateway with limited
throughput of connections through a gateway with limited resources. resources. [RFC1337] discusses hazards associated with TIME_WAIT
[RFC1337] discusses hazards associated with TIME_WAIT assassination assassination in TCP, and similar hazards exists for DCCP.
in TCP, and similar hazards exists for DCCP.
The handling of non-SYN packets for which there is no active state The handling of non-SYN packets for which there is no active state
record is left unspecified. Such packets can be received if the record is left unspecified. Such packets can be received if the
gateway abandons a live connection, or abandons a connection in the gateway abandons a live flow, or abandons a flow in the TIMEWAIT
TIMEWAIT state before the four minute 2MSL period expires. The state before the four minute 2MSL period expires. The decision
decision either to discard or to respond with an ICMP Destination either to discard or to respond with an ICMPv6 "Destination
Unreachable error, code 1 (administratively prohibited) is left up to Unreachable" error code 1 (administratively prohibited) is left up to
the implementation. the implementation.
Behavior for notifying endpoints when abandoning live connections is Behavior for notifying endpoints when abandoning live flows is left
left unspecified. When a gateway abandons a live connection, for unspecified. When a gateway abandons a live flow, for example due to
example due to a timeout expiring, the filter MAY send a DCCP-Reset a timeout expiring, the filter MAY send a DCCP-Reset packet to each
packet to each endpoint on behalf of the other. Sending a DCCP-Reset endpoint on behalf of the other. Sending a DCCP-Reset notification
notification allows endpoint applications to recover more quickly, allows endpoint applications to recover more quickly, however,
however, notifying endpoints might not always be possible if, for notifying endpoints might not always be possible if, for example,
example, state records are lost due to power interruption. state records are lost due to power interruption.
Several DCCP mechanisms depend on the reception of ICMP error Several DCCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of DCCP packets. One such messages triggered by the transmission of DCCP packets. One such
mechanism is path MTU discovery, which is required for correct mechanism is path MTU discovery, which is required for correct
operation. operation.
REC-38: If a gateway forwards a DCCP connection, it MUST also forward REC-40: If an Internet gateway forwards a DCCP flow, it MUST also
ICMP Destination Unreachable and Packet Too Big messages containing forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
DCCP headers that match the connection state record. messages containing DCCP headers that match the flow state record.
REC-39: Receipt of any sort of ICMP message MUST NOT terminate the REC-41: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a DCCP connection. state record for a DCCP flow.
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6)
IPv6 simple security is applicable to residential networks with only IPv6 simple security is applicable to residential networks with only
one default router, i.e. a single residential gateway to exactly one one Internet service provider at a time. The use of Level 3
Internet service provider. The use of Level 3 Multihoming Shim Multihoming Shim Protocol for IPv6 (SHIM6) [RFC5533] as a site multi-
Protocol for IPv6 (SHIM6) [RFC5533] as a site multi-homing solution homing solution is not generally compatible with IPv6 simple
is not generally compatible with IPv6 simple security. security. No special recommendations with regard to SHIM6 are made
in this document.
Residential gateways that are capable of site multi-homing
simultaneously on more than one exterior network link SHOULD
reference addresses in SHIM6 headers when comparing and creating
filter state corresponding to interior endpoint hosts.
3.4. Passive Listeners 3.4. Passive Listeners
Some applications expect to solicit traffic from exterior nodes Some applications expect to solicit traffic from exterior nodes
without any advance knowledge of the exterior address. This without advance knowledge of the exterior addresses of their peers.
requirement is met by IPv4/NAT gateways typically by the use of This requirement is met by IPv4/NAT gateways typically by the use of
either [I-D.cheshire-nat-pmp] or [UPnP-IGD]. On IPv4/NAT networks either [I-D.cheshire-nat-pmp] or [UPnP-IGD]. On IPv4/NAT networks
connected by gateways without such services, applications must use connected by gateways without such services, applications must use
techniques like Session Traversal Utilities for NAT (STUN) [RFC5389] techniques like Session Traversal Utilities for NAT (STUN) [RFC5389]
to obtain and maintain connectivity, despite the translation and to obtain and maintain connectivity, despite the translation and
filtering effects of NAT. filtering effects of NAT.
While NAT for IPv6 is unlikely to be used in most residential While NAT for IPv6 is unlikely to be used in most residential
gateways, the filtering effect of the simple security functions gateways, the filtering effect of the simple security functions
recommended by this document are derived from those in widespread use recommended by this document are derived from those in widespread use
on the IPv4 Internet, and a similar barrier to communication at on the IPv4 Internet, and a similar barrier to communication at
passive listeners is a natural outcome of its deployment. To avoid passive listeners is a natural outcome of its deployment. To avoid
the need for IPv6 applications to use techniques like STUN for the need for IPv6 applications to use techniques like STUN for
opening and maintaining dynamic filter state, something similar to opening and maintaining dynamic filter state, something similar to
NAT-PMP and UPnP-IGD but without actually supporting NAT needs to be NAT-PMP and UPnP-IGD but without actually supporting NAT could be
deployed. Alas, no consensus has yet emerged in the Internet deployed. Alas, no consensus has yet emerged in the Internet
engineering community as to what is most appropriate for residential engineering community as to what is most appropriate for residential
IPv6 usage scenarios. IPv6 usage scenarios.
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 [I-D.woodyatt-ald]. It Application Listener Discovery Protocol [I-D.woodyatt-ald]. It
remains to be seen whether the Internet Gateway Device profile of the remains to be seen whether the Internet Gateway Device profile of the
Universal Plug And Play protocol will be extended for IPv6. Other Universal Plug And Play protocol will be extended for IPv6. Other
proposals of note include the Middlebox Communication Protocol proposals of note include the Middlebox Communication Protocol
[RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until [RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until
a consensus emerges around a specific method, the following a consensus emerges around a specific method, the following
recommendations are the best guidance available. recommendations are the best guidance available.
REC-40: Gateways SHOULD implement a protocol to permit applications REC-42: Internet gateways with IPv6 simple security capabilities
to solicit inbound traffic without advance knowledge of the addresses SHOULD implement a protocol to permit applications to solicit inbound
of exterior nodes with which they expect to communicate. traffic without advance knowledge of the addresses of exterior nodes
with which they expect to communicate.
REC-41: Gateways MUST provide an easily selected configuration option REC-43: Internet gateways with IPv6 simple security capabilities MUST
that permits a "transparent mode" of operation that forwards all provide an easily selected configuration option that permits a
unsolicited flows regardless of forwarding direction, i.e. to disable "transparent mode" of operation that forwards all unsolicited flows
the IPv6 simple security capabilities of the gateway. regardless of forwarding direction, i.e. to disable the IPv6 simple
security capabilities of the gateway.
In general, "transparent mode" will enable more flexibility and In general, "transparent mode" will enable more flexibility and
reliability for applications which require devices to be contacted reliability for applications which require devices to be contacted
inside the home directly, particularly in absence of a protocol as inside the home directly, particularly in absence of a protocol as
described in REC-40. Operating in transparent mode may come at the described in REC-42. Operating in transparent mode may come at the
expense of security if there are IPv6 nodes in the home that do not expense of security if there are IPv6 nodes in the home that do not
have their own host-based firewall capability and require a firewall have their own host-based firewall capability and require a firewall
in the gateway in order not to be compromised. in the gateway in order not to be compromised.
3.5. Management Applications 3.5. Management Applications
Subscriber managed residential gateways are unlikely ever to be Subscriber managed residential gateways are unlikely ever to be
completely zero-configuration, but their administrators will very completely zero-configuration, but their administrators will very
often possess no particular expertise in Internet engineering. In often possess no particular expertise in Internet engineering. In
general, the specification of management interfaces for residential general, the specification of management interfaces for residential
gateways is out of scope for this document, but security of gateways is out of scope for this document, but security of
subscriber managed gateways merit special attention here. subscriber managed gateways merit special attention here.
REC-42: By DEFAULT, subscriber managed residential gateways MUST NOT REC-44: By DEFAULT, subscriber managed residential gateways MUST NOT
offer management application services to the exterior network. offer management application services to the exterior network.
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.
REC-1 Packets bearing in their outer IPv6 headers multicast source REC-1 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.
REC-2 Packets which bear in their outer IPv6 headers multicast REC-2 Packets which bear in their outer IPv6 headers multicast
destination addresses of equal or narrower scope (see IPv6 Scoped destination addresses of equal or narrower scope (see IPv6
Address Architecture [RFC4007]) than the configured scope boundary Scoped Address Architecture [RFC4007]) than the configured
level of the gateway MUST NOT be forwarded in any direction. The scope boundary level of the gateway MUST NOT be forwarded in
DEFAULT scope boundary level SHOULD be organization-local scope, any direction. The DEFAULT scope boundary level SHOULD be
and it SHOULD be configurable by the network admininistrator. organization-local scope, and it SHOULD be configurable by
the network administrator.
REC-3 Packets bearing source and/or destination addresses forbidden REC-3 Packets bearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over the to appear in the outer headers of packets transmitted over
public Internet MUST NOT be forwarded. In particular, site-local the public Internet MUST NOT be forwarded. In particular,
addresses are deprecated by [RFC3879], and [RFC5156] explicitly site-local addresses are deprecated by [RFC3879], and
forbids the use of addresses with IPv4-Mapped, IPv4-Compatible, [RFC5156] explicitly forbids the use of addresses with IPv4-
Documentation and ORCHID prefixes. Mapped, IPv4-Compatible, Documentation and ORCHID prefixes.
REC-4 Packets bearing deprecated extension headers prior to their REC-4 Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be forwarded or first upper-layer-protocol header SHOULD NOT be forwarded or
transmitted on any interface. In particular, all packets with transmitted on any interface. In particular, all packets
routing extension header type 0 [RFC2460] preceding the first with routing extension header type 0 [RFC2460] preceding the
upper-layer-protocol header MUST NOT be forwarded. (See [RFC5095] first upper-layer-protocol header MUST NOT be forwarded.
for additional background.) (See [RFC5095] for additional background.)
REC-5 Outbound packets MUST NOT be forwarded if the source address REC-5 Outbound packets MUST NOT be forwarded if the source address
in their outer IPv6 header does not have a unicast prefix assigned in their outer IPv6 header does not have a unicast prefix
for use by globally reachable nodes on the interior network. assigned for use by globally reachable nodes on the interior
network.
REC-6 Inbound packets MUST NOT be forwarded if the source address in REC-6 Inbound packets MUST NOT be forwarded if the source address
their outer IPv6 header has a global unicast prefix assigned for in their outer IPv6 header has a global unicast prefix
use by globally reachable nodes on the interior network. assigned for use by globally reachable nodes on the interior
network.
REC-7 By DEFAULT, packets with unique local source and/or REC-7 By DEFAULT, packets with unique local source and/or
destination addresses [RFC4193] SHOULD NOT be forwarded to or from destination addresses [RFC4193] SHOULD NOT be forwarded to or
the exterior network. from the exterior network.
REC-8 By DEFAULT, inbound non-recursive DNS queries received on REC-8 By DEFAULT, inbound non-recursive DNS queries received on
exterior interfaces MUST NOT be processed by any integrated DNS exterior interfaces MUST NOT be processed by any integrated
proxy resolving server. DNS resolving server.
REC-9 Inbound DHCP discovery packets received on exterior interfaces REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on
MUST NOT be processed by any integrated DHCP server. exterior interfaces MUST NOT be processed by any integrated
DHCPv6 server.
REC-10 Filter state records for generic upper-layer transport REC-10 IPv6 gateways MUST forward ICMPv6 "Destination Unreachable"
protocols MUST BE indexable by a 3-tuple comprising the interior and "Packet Too Big" messages containing IP headers that
node address, the exterior node address and the upper-layer match generic upper-layer transport state 3-tuples.
transport protocol identifier.
REC-11 Filter state records for generic upper-layer transport REC-11 Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer not protocols MUST be indexable by a 3-tuple comprising the
less than two minutes has expired without having forwarded a interior node address, the exterior node address and the
packet matching the state in some configurable amount of time. By upper-layer transport protocol identifier.
DEFAULT, the idle timer for such state records is five minutes.
REC-12 IPv6 gateways MUST forward ICMP Destination Unreachable and REC-12 Filter state records for generic upper-layer transport
Packet Too Big messages containing IP headers that match generic protocols MUST NOT be deleted or recycled until an idle timer
upper-layer transport state 3-tuples. not less than two minutes has expired without having
forwarded a packet matching the state in some configurable
amount of time. By DEFAULT, the idle timer for such state
records is five minutes.
REC-13 A state record for a UDP exchange where both interior and REC-13 A state record for a UDP flow where both source and
exterior ports are outside the well-known port range (ports destination ports are outside the well-known port range
0-1023) MUST NOT expire in less than two minutes of idle time. (ports 0-1023) MUST NOT expire in less than two minutes of
The value of the UDP state record idle timer MAY be configurable. idle time. The value of the UDP state record idle timer MAY
The DEFAULT is five minutes. be configurable. The DEFAULT is five minutes.
REC-14 A state record for a UDP exchange where one or both of the REC-14 A state record for a UDP flow where one or both of the source
interior and exterior ports are in the well-known port range and destination ports are in the well-known port range (ports
(ports 0-1023) MAY expire after a period of idle time shorter than 0-1023) MAY expire after a period of idle time shorter than
two minutes to facilitate the operation of the IANA-registered two minutes to facilitate the operation of the IANA-
service assigned to the port in question. registered service assigned to the port in question.
REC-15 A state record for a UDP exchange MUST be refreshed when a REC-15 A state record for a UDP flow MUST be refreshed when a packet
packet is forwarded from the interior to the exterior, and it MAY is forwarded from the interior to the exterior, and it MAY be
be refreshed when a packet is forwarded in the reverse direction. refreshed when a packet is forwarded in the reverse
direction.
REC-16 If application transparency is most important, then a REC-16 If application transparency is most important, then a
stateful packet filter SHOULD have "Endpoint independent filter" stateful packet filter SHOULD have "Endpoint independent
behavior for UDP. If a more stringent filtering behavior is most filter" behavior for UDP. If a more stringent filtering
important, then a filter SHOULD have "Address dependent filtering" behavior is most important, then a filter SHOULD have
behavior. The filtering behavior MAY be an option configurable by "Address dependent filtering" behavior. The filtering
the network administrator, and it MAY be independent of the behavior MAY be an option configurable by the network
filtering behavior for TCP and other protocols. Filtering administrator, and it MAY be independent of the filtering
behavior SHOULD by endpoint independent by DEFAULT in gateways behavior for TCP and other protocols. Filtering behavior
intended for provisioning without service-provider management. SHOULD by endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider
management.
REC-17 If a gateway forwards a UDP exchange, it MUST also forward REC-17 If a gateway forwards a UDP flow, it MUST also forward ICMPv6
ICMP Destination Unreachable and Packet Too Big messages "Destination Unreachable" and "Packet Too Big" messages
containing UDP headers that match the exchange state record. containing UDP headers that match the flow state record.
REC-18 Receipt of any sort of ICMP message MUST NOT terminate the REC-18 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP exchange. state record for a UDP flow.
REC-19 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same REC-19 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
way as UDP exchanges, except that the upper-layer transport UDP flows, except that the upper-layer transport protocol
protocol identifier for UDP-Lite is not the same as UDP, and identifier for UDP-Lite is not the same as UDP, and therefore
therefore UDP packets MUST NOT match UDP-Lite state records, and UDP packets MUST NOT match UDP-Lite state records, and vice
vice versa. versa.
REC-20 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-20 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate
addresses, with destination extension headers of type node addresses, with destination extension headers of type
"Authenticated Header (AH)" [RFC4302] in their outer IP extension "Authenticated Header (AH)" [RFC4302] in their outer IP
header chain. extension header chain.
REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate
addresses, with an upper layer protocol of type "Encapsulating node addresses, with an upper layer protocol of type
Security Payload (ESP)" [RFC4303] in their outer IP extension "Encapsulating Security Payload (ESP)" [RFC4303] in their
header chain. outer IP extension header chain.
REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of any UDP packets, to and from legitimate prohibit the forwarding of any UDP packets, to and from
node addresses, with a destination port of 500, i.e. the port legitimate node addresses, with a destination port of 500,
reserved by IANA for the Internet Key Exchange Protocol [RFC4306]. i.e. the port reserved by IANA for the Internet Key Exchange
Protocol [RFC4306].
REC-23 In all operating modes, IPv6 gateways SHOULD use filter state REC-23 In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] that records for Encapsulating Security Payload (ESP) [RFC4303]
are indexable by a 3-tuple comprising the interior node address, that are indexable by a 3-tuple comprising the interior node
the exterior node address and the ESP protocol identifier. In address, the exterior node address and the ESP protocol
particular, the IPv4/NAT method of indexing state records also by identifier. In particular, the IPv4/NAT method of indexing
security parameters index (SPI) SHOULD NOT be used. Likewise, any state records also by security parameters index (SPI) SHOULD
mechanism that depends on detection of Internet Key Exchange (IKE) NOT be used. Likewise, any mechanism that depends on
[RFC4306] initiations SHOULD NOT be used. detection of Internet Key Exchange (IKE) [RFC4306]
initiations SHOULD NOT be used.
REC-24 All valid sequences of TCP packets (defined in [RFC0793]) REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT
MUST be forwarded for outbound connections and explicitly prohibit the forwarding of packets, to and from legitimate
permitted inbound connections. In particular, both the normal TCP node addresses, with destination extension headers of type
3-way handshake mode of operation and the simultaneous-open modes "Host Identity Protocol (HIP)" [RFC5201] in their outer IP
of operation MUST be supported. extension header chain.
REC-25 The TCP window invariant MUST NOT be enforced on connections REC-25 The state records for flows initiated by outbound packets
for which the filter did not detect whether the window-scale that bear a Home Address destination option [RFC3775] are
option (see [RFC1323]) was sent in the 3-way handshake or distinguished by the addition of the home address of the flow
simultaneous open. as well as the interior Care-of address. IPv6 gateways MUST
NOT prohibit the forwarding of any inbound packets bearing
type 2 routing headers, which otherwise match a flow state
record, and where A) the destination matches the home address
of the flow, and B) the Home Address field in the routing
header matches the interior Care-of address of the flow.
REC-26 If application transparency is most important, then a REC-26 All valid sequences of TCP packets (defined in [RFC0793])
stateful packet filter SHOULD have "Endpoint independent filter" MUST be forwarded for outbound flows and explicitly permitted
behavior for TCP. If a more stringent filtering behavior is most inbound flows. In particular, both the normal TCP 3-way
important, then a filter SHOULD have "Address dependent filtering" handshake mode of operation and the simultaneous-open modes
behavior. The filtering behavior MAY be an option configurable by of operation MUST be supported.
the network administrator, and it MAY be independent of the
filtering behavior for UDP and other protocols. Filtering
behavior SHOULD by endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider management.
REC-27 By DEFAULT, a gateway MUST respond with an ICMP Destination REC-27 The TCP window invariant MUST NOT be enforced on flows for
Unreachable error (administratively prohibited) to any unsolicited which the filter did not detect whether the window-scale
inbound SYN packet after waiting at least 6 seconds without first option (see [RFC1323]) was sent in the 3-way handshake or
forwarding the associated outbound SYN or SYN/ACK from the simultaneous open.
interior peer.
REC-28 If a gateway cannot determine whether the endpoints of a TCP REC-28 If application transparency is most important, then a
connection are active, then it MAY abandon the state record if it stateful packet filter SHOULD have "Endpoint independent
has been idle for some time. In such cases, the value of the filter" behavior for TCP. If a more stringent filtering
"established connection idle-timeout" MUST NOT be less than two behavior is most important, then a filter SHOULD have
hours four minutes, as discussed in [RFC5382]. The value of the "Address dependent filtering" behavior. The filtering
"transitory connection idle-timeout" MUST NOT be less than four behavior MAY be an option configurable by the network
minutes. The value of the idle-timeouts MAY be configurable by administrator, and it MAY be independent of the filtering
the network administrator. behavior for UDP and other protocols. Filtering behavior
SHOULD by endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider
management.
REC-29 If a gateway forwards a TCP connection, it MUST also forward REC-29 By DEFAULT, a gateway MUST respond with an ICMPv6
ICMP Destination Unreachable and Packet Too Big messages "Destination Unreachable" error code 1 (administratively
containing TCP headers that match the connection state record. prohibited) to any unsolicited inbound SYN packet after
waiting at least 6 seconds without first forwarding the
associated outbound SYN or SYN/ACK from the interior peer.
REC-30 Receipt of any sort of ICMP message MUST NOT terminate the REC-30 If a gateway cannot determine whether the endpoints of a TCP
state record for a TCP connection. flow are active, then it MAY abandon the state record if it
has been idle for some time. In such cases, the value of the
"established flow idle-timeout" MUST NOT be less than two
hours four minutes, as discussed in [RFC5382]. The value of
the "transitory flow idle-timeout" MUST NOT be less than four
minutes. The value of the idle-timeouts MAY be configurable
by the network administrator.
REC-31 All valid sequences of SCTP packets (defined in [RFC4960]) REC-31 If a gateway forwards a TCP flow, it MUST also forward ICMPv6
MUST be forwarded for outbound associations and explicitly "Destination Unreachable" and "Packet Too Big" messages
permitted inbound associations. In particular, both the normal containing TCP headers that match the flow state record.
SCTP association establishment and simultaneous-open modes of
operation MUST be supported.
REC-32 By DEFAULT, a gateway MUST respond with an ICMP Destination REC-32 Receipt of any sort of ICMPv6 message MUST NOT terminate the
Unreachable error (administratively prohibited) to any unsolicited state record for a TCP flow.
inbound INIT packet after waiting at least 6 seconds without first
forwarding the associated outbound INIT from the interior peer.
REC-33 If a gateway cannot determine whether the endpoints of an REC-33 All valid sequences of SCTP packets (defined in [RFC4960])
SCTP association are active, then it MAY abandon the state record MUST be forwarded for outbound associations and explicitly
if it has been idle for some time. In such cases, the value of permitted inbound associations. In particular, both the
the "established association idle-timeout" MUST NOT be less than normal SCTP association establishment and simultaneous-open
two hours four minutes. The value of the "transitory association modes of operation MUST be supported.
idle-timeout" MUST NOT be less than four minutes. The value of
the idle-timeouts MAY be configurable by the network
administrator.
REC-34 If a gateway forwards an SCTP association, it MUST also REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6
forward ICMP Destination Unreachable and Packet Too Big messages "Destination Unreachable" error code 1 (administratively
containing SCTP headers that match the association state record. prohibited) to any unsolicited inbound INIT packet after
waiting at least 6 seconds without first forwarding the
associated outbound INIT from the interior peer.
REC-35 Receipt of any sort of ICMP message MUST NOT terminate the REC-35 If a gateway cannot determine whether the endpoints of an
state record for an SCTP association. SCTP association are active, then it MAY abandon the state
record if it has been idle for some time. In such cases, the
value of the "established association idle-timeout" MUST NOT
be less than two hours four minutes. The value of the
"transitory association idle-timeout" MUST NOT be less than
four minutes. The value of the idle-timeouts MAY be
configurable by the network administrator.
REC-36 All valid sequences of DCCP packets (defined in [RFC4340]) REC-36 If a gateway forwards an SCTP association, it MUST also
MUST be forwarded for all connections to exterior servers and forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
those connections to interior servers with explicitly permitted messages containing SCTP headers that match the association
service codes. state record.
REC-37 A gateway MAY abandon a DCCP state record if it has been idle REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the
for some time. In such cases, the value of the "established state record for an SCTP association.
connection idle-timeout" MUST NOT be less than two hours four
minutes. The value of the "transitory connection idle-timeout"
MUST NOT be less than eight minutes. The value of the idle-
timeouts MAY be configurable by the network administrator.
REC-38 If a gateway forwards a DCCP connection, it MUST also forward REC-38 All valid sequences of DCCP packets (defined in [RFC4340])
ICMP Destination Unreachable and Packet Too Big messages MUST be forwarded for all flows to exterior servers and those
containing DCCP headers that match the connection state record. flows to interior servers with explicitly permitted service
codes.
REC-39 Receipt of any sort of ICMP message MUST NOT terminate the REC-39 A gateway MAY abandon a DCCP state record if it has been idle
state record for a DCCP connection. for some time. In such cases, the value of the "established
flow idle-timeout" MUST NOT be less than two hours four
minutes. The value of the "transitory flow idle-timeout"
MUST NOT be less than eight minutes. The value of the idle-
timeouts MAY be configurable by the network administrator.
REC-40 Gateways SHOULD implement a protocol to permit applications REC-40 If a gateway forwards a DCCP flow, it MUST also forward
to solicit inbound traffic without advance knowledge of the ICMPv6 "Destination Unreachable" and "Packet Too Big"
addresses of exterior nodes with which they expect to communicate. messages containing DCCP headers that match the flow state
record.
REC-41 Gateways MUST provide an easily selected configuration option REC-41 Receipt of any sort of ICMPv6 message MUST NOT terminate the
that permits a "transparent mode" of operation that forwards all state record for a DCCP flow.
unsolicited flows regardless of forwarding direction, i.e. to
disable the IPv6 simple security capabilities of the gateway.
REC-42 By DEFAULT, subscriber managed residential gateways MUST NOT REC-42 Gateways SHOULD implement a protocol to permit applications
offer management application services to the exterior network. to solicit inbound traffic without advance knowledge of the
addresses of exterior nodes with which they expect to
communicate.
REC-43 Gateways MUST provide an easily selected configuration option
that permits a "transparent mode" of operation that forwards
all unsolicited flows regardless of forwarding direction,
i.e. to disable the IPv6 simple security capabilities of the
gateway.
REC-44 By DEFAULT, subscriber managed residential gateways MUST NOT
offer management application services to the exterior
network.
5. Contributors 5. Contributors
Comments and criticisms during the development of this document were Comments and criticisms during the development of this document were
received from the following IETF participants: received from the following IETF participants:
Fred Baker +----------------------------+----------------------+
| Fred Baker | Norbert Bollow |
Norbert Bollow | Cameron Byrne | Brian Carpenter |
| Remi Despres | Fabrice Fontaine |
Cameron Byrne | Jun-ichiro "itojun" Hagino | Thomas Herbst |
| Christian Huitema | Joel Jaeggli |
Brian Carpenter | Cullen Jennings | Suresh Krishnan |
| Erik Kline | Kurt Erik Lindqvist |
Remi Despres | Boucadair Mohamed | Keith Moore |
| Robert Moskowitz | Teemu Savolainen |
Fabrice Fontaine | Hemant Singh | Yaron Sheffer |
| Mark Townsley | Iljitsch van Beijnum |
Jun-ichiro "itojun" Hagino | Dan Wing | |
+----------------------------+----------------------+
Thomas Herbst
Christian Huitema
Joel Jaeggli
Cullen Jennings
Suresh Krishnan
Erik Kline
Kurt Erik Lindqvist
Keith Moore
Robert Moskowitz
Teemu Savolainen
Hemant Singh
Yaron Sheffer
Iljitsch van Beijnum
Dan Wing
The editor thanks them all for their contributions. The editor thanks them all for their contributions.
It must be noted that a substantial portion of the text describing It must be noted that a substantial portion of the text describing
the detailed requirements for TCP and UDP filtering is derived or the detailed requirements for TCP and UDP filtering is derived or
transposed from [RFC4787] and [RFC5382]. The editors of those transposed from [RFC4787] and [RFC5382]. The editors of those
documents, Francois Audet and Saikat Guha, deserve substantial credit documents, Francois Audet and Saikat Guha, deserve substantial credit
for the form of the present document, as well. for the form of the present document, as well.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 29, line 22 skipping to change at page 29, line 7
The IPv6 stateful filtering behavior described in this document is The IPv6 stateful filtering behavior described in this document is
intended to be similar in function to the filtering behavior of intended to be similar in function to the filtering behavior of
commonly use IPv4/NAT gateways, which have been widely sold as a commonly use IPv4/NAT gateways, which have been widely sold as a
security tool for residential and small-office/home-office networks. security tool for residential and small-office/home-office networks.
As noted in the security considerations section of [RFC2993], the As noted in the security considerations section of [RFC2993], the
true impact of these tools may be a reduction in security. It may be true impact of these tools may be a reduction in security. It may be
generally assumed that the impacts discussed in that document related generally assumed that the impacts discussed in that document related
to filtering (and not translation) are to be expected with the simple to filtering (and not translation) are to be expected with the simple
IPv6 security mechanisms described here. IPv6 security mechanisms described here.
In particular, it's worth noting that stateful filters create the In particular, it is worth noting that stateful filters create the
illusion of a security barrier, but without the managed intent of a illusion of a security barrier, but without the managed intent of a
firewall. Appropriate security mechanisms implemented in the end firewall. Appropriate security mechanisms implemented in the end
nodes, in conjunction with the [RFC4864] local network protection nodes, in conjunction with the [RFC4864] local network protection
methods, function without reliance on network layer hacks and methods, function without reliance on network layer hacks and
transport filters that may change over time. Also, defined security transport filters that may change over time. Also, defined security
barriers assume that threats originate in the exterior, which may barriers assume that threats originate in the exterior, which may
lead to practices that result in applications being fully exposed to lead to practices that result in applications being fully exposed to
interior attack and which therefore make breaches much easier. interior attack and which therefore make breaches much easier.
The security functions described in this document may be considered The security functions described in this document may be considered
skipping to change at page 30, line 25 skipping to change at page 30, line 9
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[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)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 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.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
April 2008. April 2008.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
8.2. Informative References 8.2. Informative References
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008. draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.woodyatt-ald] [I-D.woodyatt-ald]
Woodyatt, J., "Application Listener Discovery (ALD) for Woodyatt, J., "Application Listener Discovery (ALD) for
IPv6", draft-woodyatt-ald-03 (work in progress), IPv6", draft-woodyatt-ald-03 (work in progress),
July 2008. July 2008.
skipping to change at page 31, line 50 skipping to change at page 31, line 39
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992. RFC 1337, May 1992.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[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.
skipping to change at page 33, line 4 skipping to change at page 32, line 39
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[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. Change Log Appendix A. Change Log
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
draft-hoagland-v6ops-teredosecconcerns.
A.2. draft-ietf-v6ops-cpe-simple-security-01 to A.1. draft-ietf-v6ops-cpe-simple-security-10 to
draft-ietf-v6ops-cpe-simple-security-02 draft-ietf-v6ops-cpe-simple-security-11
o Inserted REC-20, i.e. do not enforce TCP window invariant unless
the TCP window-scale is known for the state.
o Filled out Section 4.
o Added reference to [RFC1323].
o Updated the reference for draft-hoagland-v6ops-teredosecconcerns.
o Expanded list of contributers and commenters.
o Mention that UDP-Lite should be handled just like UDP.
o Added section for generic upper layer transport protocols.
o Expanded on recommendations for IPsec ESP filtering.
o Expanded overview of recommendations with discussion about IP
mobility and IPsec interactions.
o Added a security considerations section.
A.3. draft-ietf-v6ops-cpe-simple-security-02 to
draft-ietf-v6ops-cpe-simple-security-03
o Fixed some spelling errors.
o Replace "prevent such attacks" with "defend against such attacks"
everywhere.
o Replace "mapping" with "state record" in the TCP filters section.
o Added recommendations for SCTP and DCCP.
A.4. draft-ietf-v6ops-cpe-simple-security-03 to
draft-ietf-v6ops-cpe-simple-security-04
o Removed references to draft-hoagland-v6ops-teredosecconcerns.
o Updated reference to [RFC5382].
o Add reference to RFC 4879. (Removed in -08).
o Use SYSTEM resources for referencing Internet Drafts.
o Updated IPR boilerplate.
A.5. draft-ietf-v6ops-cpe-simple-security-04 to
draft-ietf-v6ops-cpe-simple-security-05
o Changed category from BCP to Informational.
o Change text in section 3 to read "activate new states as a side
effect of forwarding outbound flow initiations" to improve
clarity.
o Qualified an informative insertion by inserting the phrase "on
such networks" appropriately and relaxed the MUST to a SHOULD in
the text about impeding Teredo.
o Changed MUST to SHOULD in REC-18 about impeding Teredo.
o Replace "that" with "than" in REC-2.
o Removed an unnecessary and incorrect paragraph about IPv6/NAT from
the overview.
o Changed the first MUST NOT to a SHOULD NOT in REC-3.
o Renumbered the recommendations in section 3.1 to increase
monotonically and match the same recommendations in the summary.
o Rewrote REC-6, REC-27 and REC-32 for clarity.
o Added normative reference to [RFC4193].
o Removed REC-8 from the summary, which did not appear in section
3.1, and was redundant with REC-27.
o Added a reference to [RFC5382] in REC-28.
o Inserted REC-32 into the summary, which had been skipped.
o Removed "alongside an IPv4 private address" and inserted "globally
routed" before the first use of the word "prefix" in REC-18.
o Qualify an assertion with "some" in the informative section about
TCP filters.
o Updated obsolete references to RFC 3989 and RFC 4748.
A.6. draft-ietf-v6ops-cpe-simple-security-05 to
draft-ietf-v6ops-cpe-simple-security-06
o Corrected some typographical spelling errors.
o Added more names to the contributors section and attempted to
provide better attribution for the editors of previous RFCs.
o Add normative reference to [RFC5095].
o Editorial improvement to Section 2.3.
o Added DEFAULT recommendation for REC-14 and REC-26 to use
Endpoint-independent filtering in gateways intended for
provisioning without service-provider management.
o Added informative reference to [RFC4949].
o Added normative references for ICMP6 [RFC4884] and [RFC4890].
o Added normative references to [RFC3879] and [RFC5156] and inserted
new REC-3 to forbid forwarding packets for addresses forbidden on
the public Internet.
o Removed erroneous recommendation about SCTP INIT from summary
list, which had already been removed from the detailed section in
an earlier revision.
o Added a section describing the irrelevance of 6to4 and an
informative reference to [RFC3068].
o Added normative reference to [RFC4291], and word-smithed REC-2 to
add a brief discussion about multicast scope boundaries.
o Added a section and an information reference for SHIM6 explaining
why it's incompatible with IPv6 simple security.
A.7. draft-ietf-v6ops-cpe-simple-security-06 to
draft-ietf-v6ops-cpe-simple-security-07
o Improve the language describing directionality of traffic flows.
o Explicitly recommend a less restrictive configuration option.
o Don't use Latin-1 characters not present in 7-bit ASCII.
A.8. draft-ietf-v6ops-cpe-simple-security-07 to
draft-ietf-v6ops-cpe-simple-security-08
o Use REC- instead of R for prefixing recommendations.
o Remove second sentence of REC-41, dropping the somewhat squirrely
language about documentation standards.
o Remove section 3.2.7 Other Virtual Private Network Protocols,
including REC-24.
o Improve section 3.4, Passive Listeners, with a reference to
[RFC5389] and further explanation of motivation for
recommendations.
o Correct order of recommendations in summary section.
o Update reference to [RFC5533].
A.9. draft-ietf-v6ops-cpe-simple-security-08 to
draft-ietf-v6ops-cpe-simple-security-09
o Add references to [RFC2827] and [RFC3704] for uRPF spoofing.
o Add REC-42 to discourage use of the WAN interface for management.
o Updated contributors.
A.10. draft-ietf-v6ops-cpe-simple-security-09 to o Wordsmithing on the abstract.
draft-ietf-v6ops-cpe-simple-security-10
o Cite [RFC4007] in REC-2. o Use the word "flow" throughout, as introduced in Section 3,
instead of using "exchange" for UDP and "connection" for TCP, SCTP
and DCCP.
o Insert REC-12 to complete consistency of recommendations with o Added HIP [RFC5201] to the set of secure transports.
those in [RFC4890] and renumber subsequent recommendations.
o Completely remove recommendation to block Teredo. o Added citation of DHCP6 [RFC3315].
o Soften the language recommending implementation of simple o Added citation of Mobility Support in IPv6 (MIPv6) [RFC3775] along
security. Insert explicit note about intent of the document to with a new section and a recommendation for filtering behavior.
inform and not to prescribe.
o Editorial revision in section 2.2 to match the removal of section o Removed all references to 6to4 [RFC3068].
3.2.7 in the -08 revision.
o Editorial improvements to promote the phrase "transparent mode" to o Removed all the earlier Change Log sections.
describe the alternative operating mode recommended in REC-41.
o Fix some minor spelling and grammar errors. o Made a boatload of little editorial changes recommended by
Boucadair Mohamed.
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. 175 change blocks. 
865 lines changed or deleted 696 lines changed or added

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