Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service
draft-ietf-v6ops-cpe-simple-security-10

Abstract

This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 27, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
    1.1.  Special Language
2.  Overview
    2.1.  Basic Sanitation
    2.2.  Internet Layer Protocols
    2.3.  Transport Layer Protocols
3.  Detailed Recommendations
    3.1.  Stateless Filters
    3.2.  Connection-free Filters
        3.2.1.  Internet Control and Management
        3.2.2.  Upper-layer Transport Protocols
        3.2.3.  UDP Filters
        3.2.4.  6to4 Tunnels
        3.2.5.  IPsec and Internet Key Exchange (IKE)
    3.3.  Connection-oriented Filters
        3.3.1.  TCP Filters
        3.3.2.  SCTP Filters
        3.3.3.  DCCP Filters
        3.3.4.  Level 3 Multihoming Shim Protocol for IPv6 (SHIM6)
    3.4.  Passive Listeners
    3.5.  Management Applications
4.  Summary of Recommendations
5.  Contributors
6.  IANA Considerations
7.  Security Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Change Log
    A.1.  draft-ietf-v6ops-cpe-simple-security-00 to draft-ietf-v6ops-cpe-simple-security-01
    A.2.  draft-ietf-v6ops-cpe-simple-security-01 to draft-ietf-v6ops-cpe-simple-security-02
    A.3.  draft-ietf-v6ops-cpe-simple-security-02 to draft-ietf-v6ops-cpe-simple-security-03
    A.4.  draft-ietf-v6ops-cpe-simple-security-03 to draft-ietf-v6ops-cpe-simple-security-04
    A.5.  draft-ietf-v6ops-cpe-simple-security-04 to draft-ietf-v6ops-cpe-simple-security-05
    A.6.  draft-ietf-v6ops-cpe-simple-security-05 to draft-ietf-v6ops-cpe-simple-security-06
    A.7.  draft-ietf-v6ops-cpe-simple-security-06 to draft-ietf-v6ops-cpe-simple-security-07
    A.8.  draft-ietf-v6ops-cpe-simple-security-07 to draft-ietf-v6ops-cpe-simple-security-08
    A.9.  draft-ietf-v6ops-cpe-simple-security-08 to draft-ietf-v6ops-cpe-simple-security-09
    A.10.  draft-ietf-v6ops-cpe-simple-security-09 to draft-ietf-v6ops-cpe-simple-security-10
§  Author's Address

1.  Introduction

Some IPv6 gateway devices that enable delivery of Internet services in residential and small office settings are augmented with 'simple security' capabilities as described in the Informational document "Local Network Protected for IPv6" [RFC4864] (Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, “Local Network Protection for IPv6,” May 2007.).

The principle goal of these capabilities is to improve security of the IPv6 Internet without increasing the perceived complexity for users who just want to accomplish useful work. However, there is a constructive tension between the desires of users for transparent 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 discarded by residential gateways in an attempt to make home networks and the Internet more secure. However, some packets sent by legitimate applications may also be discarded in the process, affecting reliability and ease of use for these applications.

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 below only for precision. Particular attention is drawn to recommendation REC-41, which calls for an easy way for a user to set a gateway to a transparent mode.

1.1.  Special Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

The key word "DEFAULT" in this document is to be interpreted as the configuration of a device, as applied by its vendor, prior to the operator changing it for the first time.

2.  Overview

For the purposes of this document, residential Internet gateways are assumed to be fairly simple devices with a limited subset of the full range of possible features. They function as default routers [RFC4294] (Loughney, J., “IPv6 Node Requirements,” April 2006.) for a single local-area network segment, e.g. an ethernet, a Wi-Fi network, a bridge between two or more such segments. They have a single interface by which they connect to the public Internet, and they can obtain service by any combination of sub-IP mechanisms, including tunnels and transition mechanisms. In referring to their security capabilities, it is reasonable to distinguish between the "interior" network, i.e. the local-area network, and the "exterior" network, i.e. the public Internet. This document is concerned with the behavior of packet filters that police the flow of traffic between the interior and exterior networks of residential Internet gateways.

The operational goals of security capabilities in Internet gateways are described with more detail in "Local Network Protection for IPv6" [RFC4864] (Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, “Local Network Protection for IPv6,” May 2007.), but they can be summarized as follows.

• Check all traffic to and from the public Internet for basic sanity, e.g. anti-spoofing and "martian" [RFC4949] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.) filters.
• Allow tracking of application usage by source and destination transport addresses.
• Provide a barrier against untrusted external influences on the interior network by requiring filter state to be activated by traffic originating at interior network nodes.
• Allow manually configured exceptions to the stateful filtering rules according to network administration policy.
• Isolate local network DHCP and DNS proxy resolver services from the public Internet.

Prior to the widespread availability of IPv6 Internet service, homes and small offices often used private IPv4 network address realms [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) with Network Address Translation (NAT) functions deployed to present all the hosts on the interior network as a single host to the Internet service provider. The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service. "Local Network Protection for IPv6" [RFC4864] (Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, “Local Network Protection for IPv6,” May 2007.) recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place.

Conventional stateful packet filters activate new states as a side effect of forwarding outbound flow initiations from interior network nodes. This requires applications to have advance knowledge of the addresses of exterior nodes with which they expect to communicate. Several proposals are currently under consideration for allowing applications to solicit inbound traffic from exterior nodes without advance knowledge of their addresses. While consensus within the Internet engineering community has emerged that such protocols are necessary to implement in residential IPv6 gateways, the best current practice has not yet been established.

2.1.  Basic Sanitation

In addition to the functions required of all Internet routers [RFC4294] (Loughney, J., “IPv6 Node Requirements,” April 2006.), residential gateways are expected to have basic stateless filters for prohibiting certains kinds of traffic with invalid headers, e.g. "martian" packets, spoofs, routing header type code zero, etc. (See Section 3.1 (Stateless Filters) for details.)

Conversely, simple Internet gateways are not expected to prohibit the development of new applications. In particular, packets with end-to-end network security and routing extension headers for mobility are expected to pass Internet gateways freely.

Finally, Internet gateways that route multicast traffic are expected to implement appropriate filters for multicast to limit the scope of multicast groups that span the demarcation between residential networks and service provider networks.

2.2.  Internet Layer Protocols

As virtual private networking tunnels are regarded as an unacceptably wide attack surface, this document recommends the DEFAULT operating mode for residential IPv6 simple security is to treat IP-in-IP and GRE tunneling protocols as opaque transport layers, i.e. inbound tunnel initiations are denied and outbound tunnel initiations are accepted. IPsec transport and tunnel modes are explicitly secured by definition, so this document recommends the DEFAULT operating mode permit IPsec and Internet Key Exchange (IKE) flows to pass without filtering.

2.3.  Transport Layer Protocols

IPv6 simple security functions are principally concerned with the stateful filtering of Internet Control and Management Protocol (ICMP) (Bonica, R., Gan, D., Tappan, D., and C. Pignataro, “Extended ICMP to Support Multi-Part Messages,” April 2007.) [RFC4884] and transport layers like User Datagram Protocol (UDP) (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768] (and Lightweight User Datagram Protocol (UDP-Lite) (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) [RFC3828]), Transport Control Protocol (TCP) (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793], the Stream Control Transmission Protocol (SCTP) (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) [RFC4960], the Datagram Congestion Control Protocol (DCCP) (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.) [RFC4340], and potentially any standards-track transport protocols to be defined in the future.

The general operating principle is that transport layer traffic is not forwarded into the interior network of a residential IPv6 gateway unless it has been solicited explicitly by interior transport endpoints, e.g. by matching the reverse path for previously forwarded outbound traffic, or by matching manually configured exceptions set by the network administrator. All other traffic is expected to be discarded or rejected with an ICMPv6 error message to indicate the traffic is administratively prohibited.

3.  Detailed Recommendations

This section describes the specific recommendations made by this document in full detail. They are summarized into a convenient list in Section 4 (Summary of Recommendations).

Some recommended filters are to be applied to all traffic that passes through residential Internet gateways regardless of the direction they are to be forwarded. Other recommended filters are intended to be sensitive to the "direction" of traffic flows. Applied to bidirectional transport flows, "direction" has a specific meaning in this document.

Packets are said to be "outbound" if they originate from interior nodes to be forwarded to the Internet, and "inbound" if they originate from exterior nodes to be forwarded to any node or nodes on the interior prefix.

Flows, as opposed to packets, are said to be "outbound" if the originator of the initial packet in any given transport association is an interior node and one or more of the participants are at exterior addresses. Flows are said to be "inbound" if the originator of the initial packet is an exterior node and one or more of the participants are nodes on the interior network.

3.1.  Stateless Filters

Certain kinds of IPv6 packets MUST NOT be forwarded in either direction by residential Internet gateways regardless of network state. These include packets with multicast source addresses, packets to destinations with certain non-routable and/or reserved prefixes and packets with deprecated extension headers.

Other stateless filters are recommended to implement ingress filtering (see [RFC2827] (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.) and [RFC3704] (Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” March 2004.)), to enforce multicast scope boundaries, and to isolate certain local network services from the public Internet.

REC-1: Packets which bear in their outer IPv6 headers multicast source addresses MUST NOT be forwarded or transmitted on any interface.

REC-2: Packets which bear in their outer IPv6 headers multicast destination addresses of equal or narrower scope (see IPv6 Scoped Address Architecture (Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, “IPv6 Scoped Address Architecture,” March 2005.) [RFC4007]) than the configured scope boundary level of the gateway MUST NOT be forwarded in any direction. The DEFAULT scope boundary level SHOULD be organization-local scope, and it SHOULD be configurable by the network admininistrator.

REC-3: Packets bearing source and/or destination addresses forbidden to appear in the outer headers of packets transmitted over the public Internet MUST NOT be forwarded. In particular, site-local addresses are deprecated by [RFC3879] (Huitema, C. and B. Carpenter, “Deprecating Site Local Addresses,” September 2004.), and [RFC5156] (Blanchet, M., “Special-Use IPv6 Addresses,” April 2008.) explicitly forbids the use of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and ORCHID prefixes.

REC-4: Packets bearing deprecated extension headers prior to their first upper-layer-protocol header SHOULD NOT be forwarded or transmitted on any interface. In particular, all packets with routing extension header type 0 [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) preceding the first upper-layer-protocol header MUST NOT be forwarded. (See [RFC5095] (Abley, J., Savola, P., and G. Neville-Neil, “Deprecation of Type 0 Routing Headers in IPv6,” December 2007.) for additional background.)

REC-5: Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix configured for use by globally reachable nodes on the interior network.

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 by globally reachable nodes on the interior network.

REC-7: By DEFAULT, packets with unique local source and/or destination addresses [RFC4193] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.) SHOULD NOT be forwarded to or from the exterior network.

REC-8: By DEFAULT, inbound non-recursive DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS proxy resolving server.

REC-9: Inbound DHCP discovery packets received on exterior interfaces MUST NOT be processed by any integrated DHCP server.

3.2.  Connection-free Filters

Some Internet applications use connection-free transport protocols with no release semantics, e.g. UDP. These protocols pose a special difficulty for stateful packet filters because most of the application state is not carried at the transport level. State records are created when communication is initiated and abandoned when no further communication is detected after some period of time.

3.2.1.  Internet Control and Management

Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890] (Davies, E. and J. Mohacsi, “Recommendations for Filtering ICMPv6 Messages in Firewalls,” May 2007.) and apply generally to residential gateways as to any class of router. No additional recommendations are made here, but it's important to note that Destination Unreachable and Packet Too Big errors corresponding to filtering states for all upper-layer transport protocols are important to the proper function of the Internet.

3.2.2.  Upper-layer Transport Protocols

Residential IPv6 gateways are not expected to prohibit the use of applications to be developed using future upper-layer transport protocols. In particular, transport protocols not otherwise discussed in subsequent sections of this document are expected to be treated consistently, i.e. as having connection-free semantics and no special requirements to inspect the transport headers.

In general, upper-layer transport filter state records are expected to be created when an interior endpoint sends a packet to an exterior address. The filter allocates (or reuses) a record for the duration of communications, with an idle timer to delete the state record when no further communications are detected.

REC-10: Filter state records for generic upper-layer transport protocols MUST BE indexable by a 3-tuple comprising the interior node address, the exterior node address and the upper-layer transport protocol identifier.

REC-11: Filter state records for generic upper-layer transport protocols MUST NOT be deleted or recycled until an idle timer 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-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

"Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) [RFC4787] defines the terminology and best current practice for stateful filtering of UDP applications in IPv4 with NAT, which serves as the model for behavioral requirements for simple UDP security in IPv6 gateways, notwithstanding the requirements related specifically to network address translation.

An interior endpoint initiates a UDP exchange through a stateful packet filter by sending a packet to an exterior address. The filter allocates (or reuses) a filter state record for the duration of the exchange. The state record defines the interior and exterior IP addresses and ports used between all packets in the exchange.

State records for UDP exchanges remain active while they are in use and only abandoned after an idle period of some time.

REC-13: A state record for a UDP exchange where both interior and exterior ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.

REC-14: A state record for a UDP exchange where one or both of the interior and exterior ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes to facilitate the operation of the IANA-registered service assigned to the port in question.

As [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) notes, outbound refresh is necessary for allowing the interior endpoint to keep the state record alive. Inbound refresh may be useful for applications with no outbound UDP traffic. However, allowing inbound refresh can allow an attacker in the exterior or a misbehaving application to keep a state record alive indefinitely. This could be a security risk. Also, if the process is repeated with different ports, over time, it could use up all the state record memory and resources in the filter.

REC-15: A state record for a UDP exchange MUST be refreshed when a packet is forwarded from the interior to the exterior, and it MAY be refreshed when a packet is forwarded in the reverse direction.

As described in section 5.5 of [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.), the connection-free semantics of UDP pose a difficulty for packet filters in trying to recognize which packets comprise an application flow and which are unsolicited. Various strategies have been used in IPv4/NAT gateways with differing effects.

REC-16: If application transparency is most important, then a stateful packet filter SHOULD have "Endpoint independent filter" behavior for UDP. If a more stringent filtering behavior is most important, then a filter SHOULD have "Address dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior SHOULD by endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.

Applications mechanisms may depend on the reception of ICMP error messages triggered by the transmission of UDP messages. One such mechanism is path MTU discovery.

REC-17: If a gateway forwards a UDP exchange, it MUST also forward ICMP Destination Unreachable and Packet Too Big messages containing UDP headers that match the exchange 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] (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) 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

Typical dual-stack IPv4/IPv6 residential gateways use private IPv4 address ranges and network address/port translation on a single IPv4 address assigned by the service provider. The use of private addresses prevents interior hosts from using 6to4 (Huitema, C., “An Anycast Prefix for 6to4 Relay Routers,” June 2001.) [RFC3068] tunnels.

3.2.5.  IPsec and Internet Key Exchange (IKE)

Internet protocol security (IPsec) offers greater flexibility and better overall security than the simple security of stateful packet filtering at network perimeters. Therefore, residential IPv6 gateways need not prohibit IPsec traffic flows.

REC-20: 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 "Authenticated Header (AH)" (Kent, S., “IP Authentication Header,” December 2005.) [RFC4302] in their outer IP extension header chain.

REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper layer protocol of type "Encapsulating Security Payload (ESP)" (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) [RFC4303] in their outer IP extension header chain.

REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of any UDP packets, to and from legitimate node addresses, with a destination port of 500, i.e. the port reserved by IANA for the Internet Key Exchange Protocol (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) [RFC4306].

REC-23: In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) [RFC4303] that are indexable by a 3-tuple comprising the interior node address, the exterior node address and the ESP protocol identifier. In particular, the IPv4/NAT method of indexing state records also by security parameters index (SPI) SHOULD NOT be used. Likewise, any mechanism that depends on detection of Internet Key Exchange (IKE) (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) [RFC4306] initiations SHOULD NOT be used.

3.3.  Connection-oriented Filters

Most Internet applications use connection-oriented transport protocols with orderly release semantics. These protocols include the Transport Control Protocol (TCP) [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.), the Stream Control Transmission Protocol (SCTP) [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.), the Datagram Congestion Control Protocol (DCCP) [RFC4340] (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.), and potentially any future IETF standards-track transport protocols that use such semantics. Stateful packet filters track the state of individual transport connections and prohibit the forwarding of packets that do not match the state of an active connection and do not conform to a rule for the automatic creation of such state.

3.3.1.  TCP Filters

An interior endpoint initiates a TCP connection through a stateful packet filter by sending a SYN packet. The filter allocates (or reuses) a filter state record for the connection. The state record defines the interior and exterior IP addresses and ports used for forwarding all packets for that connection.

Some peer-to-peer applications use an alternate method of connection initiation termed simultaneous-open (Fig. 8, [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.)) to traverse stateful filters. In the simultaneous-open mode of operation, both peers send SYN packets for the same TCP connection. The SYN packets cross in the network. Upon receiving the other end's SYN packet, each end responds with a SYN-ACK packet, which also cross in the network. The connection is established at each endpoint once the SYN-ACK packets are received.

To provide stateful packet filtering service for TCP, it is necessary for a filter to receive, process and forward all packets for a connection that conform to valid transitions of the TCP state machine (Fig. 6, [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.)).

REC-24: All valid sequences of TCP packets (defined in [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.)) MUST be forwarded for outbound connections and explicitly permitted inbound connections. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open modes of operation MUST be supported.

It is possible to reconstruct enough of the state of a TCP connection to allow forwarding between an interior and exterior node even when the filter starts operating after TCP enters the established state. In 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 invariant by dropping out-of-window segments.

REC-25: The TCP window invariant MUST NOT be enforced on connections for which the filter did not detect whether the window-scale option (see [RFC1323] (Jacobson, V., Braden, B., and D. Borman, “TCP Extensions for High Performance,” May 1992.)) was sent in the 3-way handshake or simultaneous open.

A stateful filter can allow an existing state record to be reused by an externally initiated connection if its security policy permits. Several different policies are possible as described in "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) [RFC4787] and extended in "NAT Behavioral Requirements for TCP" (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.) [RFC5382].

REC-26: If application transparency is most important, then a stateful packet filter SHOULD have "Endpoint independent filter" behavior for TCP. If a more stringent filtering behavior is most important, then a filter SHOULD have "Address dependent filtering" behavior. The filtering behavior MAY be an option configurable by 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.

If an inbound SYN packet is filtered, either because a corresponding state record does not exist or because of the filter's normal behavior, a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMP messages allows the sender to detect that the SYN did not reach the intended destination. Discarding the packet, on the other hand, allows applications to perform simultaneous-open more reliably. A more detailed discussion of this issue can be found in [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.), but the basic outcome of it is that filters need to wait on signaling errors until simultaneous-open will not be impaired.

REC-27: By DEFAULT, a gateway MUST respond with an ICMP Destination Unreachable error (administratively 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.

A TCP filter maintains state associated with in-progress and established connections. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To defend against such attacks, a filter needs to abandon unused state records after a sufficiently long period of idleness.

A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially sessions for crashed endpoints, followed by closed TCP connections and partially-open connections. A gateway can 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 packet in response. If the gateway connot determine whether the endpoint is active, then the associated state record needs to be retained until the TCP connection has been idle for some time. Note: an established TCP connection can stay idle (but live) indefinitely; hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) and [RFC4294] (Loughney, J., “IPv6 Node Requirements,” April 2006.) can reduce the chances of abandoning a live connection.

TCP connections can stay in the established phase indefinitely without exchanging packets. Some end-hosts can be configured to send keep-alive packets on such idle connections; by default, such packets are sent every two hours, if enabled [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). Consequently, a filter that waits for slightly over two hours can detect idle connections with keep-alive packets being sent at the default rate. TCP connections in the partially-open or closing phases, on the other hand, can stay idle for at most four minutes while waiting for in-flight packets to be delivered [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.).

The "established connection idle-timeout" for a stateful packet filter is defined as the minimum time a TCP connection in the established phase must remain idle before the filter considers the associated state record a candidate for collection. The "transitory connection idle-timeout" for a filter is defined as the minimum time a TCP connection in the partially-open or closing phases must remain idle before the filter considers the associated state record a candidate for collection. TCP connections in the TIME_WAIT state are not affected by the "transitory connection idle-timeout" parameter.

REC-28: If a gateway cannot determine whether the endpoints of a TCP connection are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than two hours four minutes, as discussed in [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.). The value of the "transitory connection idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.

Behavior for handing RST packets, or connections in the TIME_WAIT state is left unspecified. A gateway MAY hold state for a connection in TIME_WAIT state to accommodate retransmissions of the last ACK. However, since the TIME_WAIT state is commonly encountered by interior endpoints properly closing the TCP connection, holding state for a closed connection can limit the throughput of connections through a gateway with limited resources. [RFC1337] (Braden, B., “TIME-WAIT Assassination Hazards in TCP,” May 1992.) discusses hazards associated with TIME_WAIT assassination.

The handling of non-SYN packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live connection, or abandons a connection in the TIME_WAIT state before the four minute TIME_WAIT period expires. The decision either to discard or to respond with an ICMP Destination Unreachable error, code 1 (administratively prohibited) is left up to the implementation.

Behavior for notifying endpoints when abandoning live connections is left unspecified. When a gateway abandons a live connection, for example due to a timeout expiring, the filter MAY send a TCP RST packet to each endpoint on behalf of the other. Sending a RST notification allows endpoint applications to recover more quickly, however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.

Several TCP mechanisms depend on the reception of ICMP error messages triggered by the transmission of TCP segments. One such 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 ICMP Destination Unreachable and Packet Too Big messages containing TCP headers that match the connection state record.

REC-30: Receipt of any sort of ICMP message MUST NOT terminate the state record for a TCP connection.

3.3.2.  SCTP Filters

Because Stream Control Transmission Protocol (SCTP) (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) [RFC4960] connections can be terminated at multiple network addresses, IPv6 simple security functions cannot achieve full transparency for SCTP applications. In multipath traversal scenarios, full transparency requires coordination between all the packet filter processes in the various paths between the endpoint network addresses. Such coordination is not "simple" and it is, therefore, beyond the scope of this recommendation.

However, some SCTP applications are capable of tolerating the inherent unipath restriction of IPv6 simple security, even in multipath traversal scenarios. They expect similar connection-oriented filtering behaviors as for TCP, but at the level of SCTP associations, not stream connections. This section describes specific recommendations for SCTP filtering for such traversal scenarios.

An interior endpoint initiates SCTP associations through a stateful packet filter by sending a packet comprising a single INIT chunk. The filter allocates (or reuses) a filter state record for the association. The state record defines the interior and exterior IP addresses and the observed verification tag used for forwarding packets in that association.

Peer-to-peer applications use an alternate method of association initiation termed simultaneous-open to traverse stateful filters. In the simultaneous-open mode of operation, both peers send INIT chunks at the same time to establish an association. Upon receiving the other end's INIT chunk, each end responds with an INIT-ACK packet, which is expected to traverse the same path in reverse. Because only one SCTP association may exist between any two network addresses, one of the peers in simultaneous-open mode of operation will send an ERROR or ABORT chunk along with the INIT-ACK chunk. The association is established at each endpoint once an INIT-ACK chunks is received at one end without an ERROR or ABORT chunk.

To provide stateful packet filtering service for SCTP, it is necessary for a filter to receive, process and forward all packets for an association that conform to valid transitions of the SCTP state machine (Fig. 3, [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.)).

REC-31: All valid sequences of SCTP packets (defined in [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.)) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and simultaneous-open modes of operation MUST be supported.

If an inbound INIT packet is filtered, either because a corresponding state record does not exist or because of the filter's normal behavior, a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMP messages allows the sender to detect that the INIT packet did not reach the intended destination. Discarding the packet, on the other hand, allows applications to perform simultaneous-open more reliably. Delays in signaling errors can prevent the impairment of simultaneous-open mode of operation.

REC-32: By DEFAULT, a gateway MUST respond with an ICMP Destination Unreachable error (administratively prohibited) to any unsolicited inbound INIT packet after waiting at least 6 seconds without first forwarding the associated outbound INIT from the interior peer.

An SCTP filter maintains state associated with in-progress and established associations. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To defend against such attacks, a filter needs to abandon unused state records after a sufficiently long period of idleness.

A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially sessions for crashed endpoints, followed by closed associations and partially opened associations. A similar method is an option for SCTP filters in IPv6 gateways. A gateway can check if an endpoint for an association has crashed by sending HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the gateway cannot determine whether the endpoint is active, then the associated state records needs to be retained until the SCTP association has been idle for some time. Note: an established SCTP association can stay idle (but live) indefinitely, hence there is no fixed value of an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by [RFC4294] (Loughney, J., “IPv6 Node Requirements,” April 2006.) can reduce the chances of abandoning a live association.

SCTP associations can stay in the ESTABLISHED state indefinitely without exchanging packets. Some end-hosts can be configured to send HEARTBEAT chunks on such idle associations, but [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) does not specify (or even suggest) a default time interval. A filter that waits for slightly over two hours can detect idle associations with HEARTBEAT packets being sent at the same rate as most hosts use for TCP keep-alive, which is a reasonably similar system for this purpose. SCTP associations in the partially-open or closing states, on the other hand, can stay idle for at most four minutes while waiting for in-flight packets to be delivered (assuming the suggested SCTP protocol parameter values in Section 15 of [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.)).

The "established association idle-timeout" for a stateful packet filter is defined as the minimum time an SCTP association in the established phase must remain idle before the filter considers the corresponding state record a candidate for collection. The "transitory association idle-timeout" for a filter is defined as the minimum time an SCTP association in the partially-open or closing phases must remain idle before the filter considers the corresponding state record a candidate for collection.

REC-33: If a gateway cannot determine whether the endpoints of an 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.

Behavior for handling ERROR and ABORT packets is left unspecified. A gateway MAY hold state for an association after its closing phases have completed to accommodate retransmissions of its final SHUTDOWN ACK packets. However, holding state for a closed association can limit the throughput of associations traversing a gateway with limited resources. The discussion in [RFC1337] (Braden, B., “TIME-WAIT Assassination Hazards in TCP,” May 1992.) regarding the hazards of TIME_WAIT assassination are relevant.

The handling of inbound non-INIT packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live connection, or abandons an association in the closing states before the transitory association idle-timeout expires. The decision either to discard or to respond with an ICMP Destination Unreachable error, code 1 (administratively prohibited) is left to the implementation.

Behavior for notifying endpoints when abandoning live associations is left unspecified. When a gateway abandons a live association, for example due to a timeout expiring, the filter MAY send an ABORT packet to each endpoint on behalf of the other. Sending an ABORT notification allows endpoint applications to recover more quickly, however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.

Several SCTP mechanisms depend on the reception of ICMP error messages triggered by the transmission of SCTP packets.

REC-34: If a gateway forwards an SCTP association, it MUST also forward ICMP Destination Unreachable and Packet Too Big messages containing SCTP headers that match the association state record.

REC-35: Receipt of any sort of ICMP message MUST NOT terminate the state record for an SCTP association.

3.3.3.  DCCP Filters

The connection semantics described in Datagram Congestion Control Protocol (DCCP) (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.) [RFC4340] are very similar to those of TCP. An interior endpoint initiates a DCCP connection through a stateful packet filter by sending a DCCP-Request packet. Simultaneous open is not defined for DCCP.

In order to provide stateful packet filtering service for DCCP, it is necessary for a filter to receive, process and forward all packets for a connection that conform to valid transitions of the DCCP state machine (Section 8, [RFC4340] (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.)).

REC-36: All valid sequences of DCCP packets (defined in [RFC4340] (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.)) MUST be forwarded for all connections to exterior servers and those connections to interior servers with explicitly permitted service codes.

It is possible to reconstruct enough of the state of a DCCP connection to allow forwarding between an interior and exterior node even when the filter starts operating after DCCP enters the OPEN state. Also, a filter can allow an existing state record to be reused by an externally initiated connection if its security policy permits. As with TCP, several different policies are possible, with a good discussion of the issue involved presented in Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) [RFC4787] and extended in NAT Behavioral Requirements for TCP (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.) [RFC5382].

If an inbound DCCP-Request packet is filtered, either because a corresponding state record does not already exist for it or because of the filter's normal behavior of refusing connections not explicitly permitted, then a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMP messages allows the sender to detect that the DCCP-Request did not reach the intended destination. Discarding the packet, on the other hand, only delays the failure to connect and provides no measurable security.

A DCCP filter maintains state associated with in-progress and established connections. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To prevent such an attack, a filter needs to abandon unused state records after a sufficiently long period of idleness.

A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially sessions for crashed endpoints, followed by closed TCP connections and partially-open connections. No such method exists for DCCP, and connections can stay in the OPEN phase indefinitely without exchanging packets. Hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by [RFC4294] (Loughney, J., “IPv6 Node Requirements,” April 2006.) can reduce the chances of abandoning a live connection.

DCCP connections in the partially-open or closing phases can stay idle for at most eight minutes while waiting for in-flight packets to be delivered.

The "open connection idle-timeout" for a stateful packet filter is defined as the minimum time a DCCP connection in the open state must remain idle before the filter considers the associated state record a candidate for collection. The "transitory connection idle-timeout" for a filter is defined as the minimum time a DCCP connection in the partially-open or closing phases must remain idle before the filter considers the associated state record a candidate for collection. DCCP connections in the TIMEWAIT state are not affected by the "transitory connection idle-timeout" parameter.

REC-37: A gateway MAY abandon a DCCP state record if it has been idle for some time. In such cases, the value of the "established 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.

Behavior for handing DCCP-Reset packets, or connections in the TIMEWAIT state is left unspecified. A gateway MAY hold state for a connection in TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset. However, since the TIMEWAIT state is commonly encountered by interior endpoints properly closing the DCCP connection, holding state for a closed connection can limit the throughput of connections through a gateway with limited resources. [RFC1337] discusses hazards associated with TIME_WAIT assassination in TCP, and similar hazards exists for DCCP.

The handling of non-SYN packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live connection, or abandons a connection in the TIMEWAIT state before the four minute 2MSL period expires. The decision either to discard or to respond with an ICMP Destination Unreachable error, code 1 (administratively prohibited) is left up to the implementation.

Behavior for notifying endpoints when abandoning live connections is left unspecified. When a gateway abandons a live connection, for example due to a timeout expiring, the filter MAY send a DCCP-Reset packet to each endpoint on behalf of the other. Sending a DCCP-Reset notification allows endpoint applications to recover more quickly, however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.

Several DCCP mechanisms depend on the reception of ICMP error messages triggered by the transmission of DCCP packets. One such mechanism is path MTU discovery, which is required for correct operation.

REC-38: If a gateway forwards a DCCP connection, it MUST also forward ICMP Destination Unreachable and Packet Too Big messages containing DCCP headers that match the connection state record.

REC-39: Receipt of any sort of ICMP message MUST NOT terminate the state record for a DCCP connection.

3.3.4.  Level 3 Multihoming Shim Protocol for IPv6 (SHIM6)

IPv6 simple security is applicable to residential networks with only one default router, i.e. a single residential gateway to exactly one Internet service provider. The use of Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” June 2009.) [RFC5533] as a site multi-homing solution is not generally compatible with IPv6 simple security.

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

Some applications expect to solicit traffic from exterior nodes without any advance knowledge of the exterior address. This requirement is met by IPv4/NAT gateways typically by the use of either [I‑D.cheshire‑nat‑pmp] (Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” April 2008.) or [UPnP‑IGD] (UPnP Forum, “Universal Plug and Play Internet Gateway Device Standardized Gateway Device Protocol,” September 2006.). On IPv4/NAT networks connected by gateways without such services, applications must use techniques like Session Traversal Utilities for NAT (STUN) (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) [RFC5389] to obtain and maintain connectivity, despite the translation and filtering effects of NAT.

While NAT for IPv6 is unlikely to be used in most residential gateways, the filtering effect of the simple security functions recommended by this document are derived from those in widespread use on the IPv4 Internet, and a similar barrier to communication at passive listeners is a natural outcome of its deployment. To avoid the need for IPv6 applications to use techniques like STUN for opening and maintaining dynamic filter state, something similar to NAT-PMP and UPnP-IGD but without actually supporting NAT needs to be deployed. Alas, no consensus has yet emerged in the Internet engineering community as to what is most appropriate for residential IPv6 usage scenarios.

One proposal that has been offered as an Internet Draft is the Application Listener Discovery Protocol (Woodyatt, J., “Application Listener Discovery (ALD) for IPv6,” July 2008.) [I‑D.woodyatt‑ald]. It remains to be seen whether the Internet Gateway Device profile of the Universal Plug And Play protocol will be extended for IPv6. Other proposals of note include the Middlebox Communication Protocol (Stiemerling, M., Quittek, J., and T. Taylor, “Middlebox Communication (MIDCOM) Protocol Semantics,” March 2008.) [RFC5189] and the Next Steps in Signaling framework (Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, “Next Steps in Signaling (NSIS): Framework,” June 2005.) [RFC4080]. Until a consensus emerges around a specific method, the following recommendations are the best guidance available.

REC-40: Gateways SHOULD implement a protocol to permit applications to solicit inbound 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 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.

In general, "transparent mode" will enable more flexibility and reliability for applications which require devices to be contacted inside the home directly, particularly in absence of a protocol as described in REC-40. Operating in transparent mode may come at the 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 in the gateway in order not to be compromised.

3.5.  Management Applications

Subscriber managed residential gateways are unlikely ever to be completely zero-configuration, but their administrators will very often possess no particular expertise in Internet engineering. In general, the specification of management interfaces for residential gateways is out of scope for this document, but security of subscriber managed gateways merit special attention here.

REC-42: By DEFAULT, subscriber managed residential gateways MUST NOT offer management application services to the exterior network.

4.  Summary of Recommendations

This section collects all of the recommendations made in this document into a convenient list.

REC-1

Packets bearing in their outer IPv6 headers multicast source addresses MUST NOT be forwarded or transmitted on any interface.

REC-2

Packets which bear in their outer IPv6 headers multicast destination addresses of equal or narrower scope (see IPv6 Scoped Address Architecture (Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, “IPv6 Scoped Address Architecture,” March 2005.) [RFC4007]) than the configured scope boundary level of the gateway MUST NOT be forwarded in any direction. The DEFAULT scope boundary level SHOULD be organization-local scope, and it SHOULD be configurable by the network admininistrator.

REC-3

Packets bearing source and/or destination addresses forbidden to appear in the outer headers of packets transmitted over the public Internet MUST NOT be forwarded. In particular, site-local addresses are deprecated by [RFC3879] (Huitema, C. and B. Carpenter, “Deprecating Site Local Addresses,” September 2004.), and [RFC5156] (Blanchet, M., “Special-Use IPv6 Addresses,” April 2008.) explicitly forbids the use of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and ORCHID prefixes.

REC-4

Packets bearing deprecated extension headers prior to their first upper-layer-protocol header SHOULD NOT be forwarded or transmitted on any interface. In particular, all packets with routing extension header type 0 [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) preceding the first upper-layer-protocol header MUST NOT be forwarded. (See [RFC5095] (Abley, J., Savola, P., and G. Neville-Neil, “Deprecation of Type 0 Routing Headers in IPv6,” December 2007.) for additional background.)

REC-5

Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix assigned for use by globally reachable nodes on the interior network.

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 by globally reachable nodes on the interior network.

REC-7

By DEFAULT, packets with unique local source and/or destination addresses [RFC4193] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.) SHOULD NOT be forwarded to or from the exterior network.

REC-8

By DEFAULT, inbound non-recursive DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS proxy resolving server.

REC-9

Inbound DHCP discovery packets received on exterior interfaces MUST NOT be processed by any integrated DHCP server.

REC-10

Filter state records for generic upper-layer transport protocols MUST BE indexable by a 3-tuple comprising the interior node address, the exterior node address and the upper-layer transport protocol identifier.

REC-11

Filter state records for generic upper-layer transport protocols MUST NOT be deleted or recycled until an idle timer 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-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.

REC-13

A state record for a UDP exchange where both interior and exterior ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.

REC-14

A state record for a UDP exchange where one or both of the interior and exterior ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes to facilitate the operation of the IANA-registered service assigned to the port in question.

REC-15

A state record for a UDP exchange MUST be refreshed when a packet is forwarded from the interior to the exterior, and it MAY be refreshed when a packet is forwarded in the reverse direction.

REC-16

If application transparency is most important, then a stateful packet filter SHOULD have "Endpoint independent filter" behavior for UDP. If a more stringent filtering behavior is most important, then a filter SHOULD have "Address dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior 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 ICMP Destination Unreachable and Packet Too Big messages containing UDP headers that match the exchange 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] (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) 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.

REC-20

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 "Authenticated Header (AH)" (Kent, S., “IP Authentication Header,” December 2005.) [RFC4302] in their outer IP extension header chain.

REC-21

In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper layer protocol of type "Encapsulating Security Payload (ESP)" (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) [RFC4303] in their outer IP extension header chain.

REC-22

In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of any UDP packets, to and from legitimate node addresses, with a destination port of 500, i.e. the port reserved by IANA for the Internet Key Exchange Protocol (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) [RFC4306].

REC-23

In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) [RFC4303] that are indexable by a 3-tuple comprising the interior node address, the exterior node address and the ESP protocol identifier. In particular, the IPv4/NAT method of indexing state records also by security parameters index (SPI) SHOULD NOT be used. Likewise, any mechanism that depends on detection of Internet Key Exchange (IKE) (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) [RFC4306] initiations SHOULD NOT be used.

REC-24

All valid sequences of TCP packets (defined in [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.)) MUST be forwarded for outbound connections and explicitly permitted inbound connections. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open modes of operation MUST be supported.

REC-25

The TCP window invariant MUST NOT be enforced on connections for which the filter did not detect whether the window-scale option (see [RFC1323] (Jacobson, V., Braden, B., and D. Borman, “TCP Extensions for High Performance,” May 1992.)) was sent in the 3-way handshake or simultaneous open.

REC-26

If application transparency is most important, then a stateful packet filter SHOULD have "Endpoint independent filter" behavior for TCP. If a more stringent filtering behavior is most important, then a filter SHOULD have "Address dependent filtering" behavior. The filtering behavior MAY be an option configurable by 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 Unreachable error (administratively 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-28

If a gateway cannot determine whether the endpoints of a TCP connection are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than two hours four minutes, as discussed in [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.). The value of the "transitory connection idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.

REC-29

If a gateway forwards a TCP connection, it MUST also forward ICMP Destination Unreachable and Packet Too Big messages containing TCP headers that match the connection state record.

REC-30

Receipt of any sort of ICMP message MUST NOT terminate the state record for a TCP connection.

REC-31

All valid sequences of SCTP packets (defined in [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.)) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and simultaneous-open modes of operation MUST be supported.

REC-32

By DEFAULT, a gateway MUST respond with an ICMP Destination Unreachable error (administratively 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-33

If a gateway cannot determine whether the endpoints of an 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-34

If a gateway forwards an SCTP association, it MUST also forward ICMP Destination Unreachable and Packet Too Big messages containing SCTP headers that match the association state record.

REC-35

Receipt of any sort of ICMP message MUST NOT terminate the state record for an SCTP association.

REC-36

All valid sequences of DCCP packets (defined in [RFC4340] (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.)) MUST be forwarded for all connections to exterior servers and those connections to interior servers with explicitly permitted service codes.

REC-37

A gateway MAY abandon a DCCP state record if it has been idle for some time. In such cases, the value of the "established 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 ICMP Destination Unreachable and Packet Too Big messages containing DCCP headers that match the connection state record.

REC-39

Receipt of any sort of ICMP message MUST NOT terminate the state record for a DCCP connection.

REC-40

Gateways SHOULD implement a protocol to permit applications to solicit inbound 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 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-42

By DEFAULT, subscriber managed residential gateways MUST NOT offer management application services to the exterior network.

5.  Contributors

Comments and criticisms during the development of this document were received from the following IETF participants:

Fred Baker

Norbert Bollow

Cameron Byrne

Brian Carpenter

Remi Despres

Fabrice Fontaine

Jun-ichiro "itojun" Hagino

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.

It must be noted that a substantial portion of the text describing the detailed requirements for TCP and UDP filtering is derived or transposed from [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) and [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.). The editors of those documents, Francois Audet and Saikat Guha, deserve substantial credit for the form of the present document, as well.

6.  IANA Considerations

This memo includes no request to IANA.

7.  Security Considerations

The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly use IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks. As noted in the security considerations section of [RFC2993] (Hain, T., “Architectural Implications of NAT,” November 2000.), the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here.

In particular, it's worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end nodes, in conjunction with the [RFC4864] (Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, “Local Network Protection for IPv6,” May 2007.) local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier.

The security functions described in this document may be considered redundant in the event that all IPv6 hosts using a particular gateway have their own IPv6 host firewall capabilities enabled. At the time of this writing, the vast majority of commercially available operating systems with support for IPv6 include IPv6 host firewall capability.

Finally, residential gateways that implement simple security functions are a bastion between the interior and the exterior, and therefore are a target of denial of service attacks against the interior network itself by processes designed to consume the resources of the gateway, e.g. a ping or SYN flood. Gateways should employ the same sorts of protection techniques as application servers on the Internet.

IETF makes no statement, expressed or implied, as to whether using the capabilities described in this document ultimately improve security for any individual users or for the Internet community as a whole.

8.  References

8.1. Normative References

8.2. Informative References

Appendix A.  Change Log

A.1.  draft-ietf-v6ops-cpe-simple-security-00 to draft-ietf-v6ops-cpe-simple-security-01

• Added requirements for sequestering DHCP and DNS proxy resolver services to the local network.
• Fixed numbering of recommendations.
• Local Network Protection is now [RFC4864] (Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, “Local Network Protection for IPv6,” May 2007.).
• SCTP is now [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.).
• Moved some references to informative.
• Corrected the reference for draft-hoagland-v6ops-teredosecconcerns.

A.2.  draft-ietf-v6ops-cpe-simple-security-01 to draft-ietf-v6ops-cpe-simple-security-02

• Inserted REC-20, i.e. do not enforce TCP window invariant unless the TCP window-scale is known for the state.
• Filled out Section 4 (Summary of Recommendations).
• Added reference to [RFC1323] (Jacobson, V., Braden, B., and D. Borman, “TCP Extensions for High Performance,” May 1992.).
• Updated the reference for draft-hoagland-v6ops-teredosecconcerns.
• Expanded list of contributers and commenters.
• Mention that UDP-Lite should be handled just like UDP.
• Added section for generic upper layer transport protocols.
• Expanded on recommendations for IPsec ESP filtering.
• Expanded overview of recommendations with discussion about IP mobility and IPsec interactions.
• Added a security considerations section.

A.3.  draft-ietf-v6ops-cpe-simple-security-02 to draft-ietf-v6ops-cpe-simple-security-03

• Fixed some spelling errors.
• Replace "prevent such attacks" with "defend against such attacks" everywhere.
• Replace "mapping" with "state record" in the TCP filters section.
• Added recommendations for SCTP and DCCP.

A.4.  draft-ietf-v6ops-cpe-simple-security-03 to draft-ietf-v6ops-cpe-simple-security-04

• Removed references to draft-hoagland-v6ops-teredosecconcerns.
• Updated reference to [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.).
• Add reference to RFC 4879. (Removed in -08).
• Use SYSTEM resources for referencing Internet Drafts.
• Updated IPR boilerplate.

A.5.  draft-ietf-v6ops-cpe-simple-security-04 to draft-ietf-v6ops-cpe-simple-security-05

• Changed category from BCP to Informational.
• Change text in section 3 to read "activate new states as a side effect of forwarding outbound flow initiations" to improve clarity.
• 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.
• Changed MUST to SHOULD in REC-18 about impeding Teredo.
• Replace "that" with "than" in REC-2.
• Removed an unnecessary and incorrect paragraph about IPv6/NAT from the overview.
• Changed the first MUST NOT to a SHOULD NOT in REC-3.
• Renumbered the recommendations in section 3.1 to increase monotonically and match the same recommendations in the summary.
• Rewrote REC-6, REC-27 and REC-32 for clarity.
• Added normative reference to [RFC4193] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.).
• Removed REC-8 from the summary, which did not appear in section 3.1, and was redundant with REC-27.
• Added a reference to [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.) in REC-28.
• Inserted REC-32 into the summary, which had been skipped.
• Removed "alongside an IPv4 private address" and inserted "globally routed" before the first use of the word "prefix" in REC-18.
• Qualify an assertion with "some" in the informative section about TCP filters.
• 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

• Corrected some typographical spelling errors.
• Added more names to the contributors section and attempted to provide better attribution for the editors of previous RFCs.
• Add normative reference to [RFC5095] (Abley, J., Savola, P., and G. Neville-Neil, “Deprecation of Type 0 Routing Headers in IPv6,” December 2007.).
• Editorial improvement to Section 2.3 (Transport Layer Protocols).
• Added DEFAULT recommendation for REC-14 and REC-26 to use Endpoint-independent filtering in gateways intended for provisioning without service-provider management.
• Added informative reference to [RFC4949] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.).
• Added normative references for ICMP6 [RFC4884] (Bonica, R., Gan, D., Tappan, D., and C. Pignataro, “Extended ICMP to Support Multi-Part Messages,” April 2007.) and [RFC4890] (Davies, E. and J. Mohacsi, “Recommendations for Filtering ICMPv6 Messages in Firewalls,” May 2007.).
• Added normative references to [RFC3879] (Huitema, C. and B. Carpenter, “Deprecating Site Local Addresses,” September 2004.) and [RFC5156] (Blanchet, M., “Special-Use IPv6 Addresses,” April 2008.) and inserted new REC-3 to forbid forwarding packets for addresses forbidden on the public Internet.
• Removed erroneous recommendation about SCTP INIT from summary list, which had already been removed from the detailed section in an earlier revision.
• Added a section describing the irrelevance of 6to4 and an informative reference to [RFC3068] (Huitema, C., “An Anycast Prefix for 6to4 Relay Routers,” June 2001.).
• Added normative reference to [RFC4291] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.), and word-smithed REC-2 to add a brief discussion about multicast scope boundaries.
• 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

• Improve the language describing directionality of traffic flows.
• Explicitly recommend a less restrictive configuration option.
• 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

• Use REC- instead of R for prefixing recommendations.
• Remove second sentence of REC-41, dropping the somewhat squirrely language about documentation standards.
• Remove section 3.2.7 Other Virtual Private Network Protocols, including REC-24.
• Improve section 3.4, Passive Listeners, with a reference to [RFC5389] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) and further explanation of motivation for recommendations.
• Correct order of recommendations in summary section.
• Update reference to [RFC5533] (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” June 2009.).

A.9.  draft-ietf-v6ops-cpe-simple-security-08 to draft-ietf-v6ops-cpe-simple-security-09

• Add references to [RFC2827] (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.) and [RFC3704] (Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” March 2004.) for uRPF spoofing.
• Add REC-42 to discourage use of the WAN interface for management.
• Updated contributors.

A.10.  draft-ietf-v6ops-cpe-simple-security-09 to draft-ietf-v6ops-cpe-simple-security-10

• Cite [RFC4007] (Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, “IPv6 Scoped Address Architecture,” March 2005.) in REC-2.
• Insert REC-12 to complete consistency of recommendations with those in [RFC4890] (Davies, E. and J. Mohacsi, “Recommendations for Filtering ICMPv6 Messages in Firewalls,” May 2007.) and renumber subsequent recommendations.
• Completely remove recommendation to block Teredo.
• Soften the language recommending implementation of simple security. Insert explicit note about intent of the document to inform and not to prescribe.
• Editorial revision in section 2.2 to match the removal of section 3.2.7 in the -08 revision.
• Editorial improvements to promote the phrase "transparent mode" to describe the alternative operating mode recommended in REC-41.
• Fix some minor spelling and grammar errors.

Author's Address