RFC 6092
Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
RFC 6092: Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service 🎀
Okay, bestie, the title block first. 🧚 This is RFC 6092, written by J. Woodyatt, Ed. from Apple. It's an Informational doc, dated January 2011, with ISSN 2070-1721. The title block doesn't list any RFCs it obsoletes or updates, so nothing gets replaced or patched here. 💅
Abstract 🌸
This doc gives device makers a list of recommendations and explains how to add "simple security" at the edge of local IPv6 networks in Internet-connected homes and small offices. 🏡 It's giving protection without the drama. ✨
Status of This Memo 📜
This is not an Internet Standards Track spec. It's just published for information. 🦋
It's an IETF product, so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). BUT not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details. 🤓
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6092. 🔗
Copyright Notice ©
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the day it was published. Please read those carefully, bestie, because they explain your rights and restrictions for this doc. 📖
Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes. 💜
This doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from them, this doc may not be modified outside the IETF Standards Process, and derivative works may not be created outside it. The exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🫶
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Special Language ...........................................3
1.2. Use of Normative Keywords ..................................3
2. Overview ........................................................4
2.1. Basic Sanitation ...........................................5
2.2. Internet Layer Protocols ...................................5
2.3. Transport Layer Protocols ..................................6
3. Detailed Recommendations ........................................6
3.1. Stateless Filters ..........................................7
3.2. Connection-Free Filters ....................................8
3.2.1. Internet Control and Management .....................8
3.2.2. Upper-Layer Transport Protocols .....................8
3.2.3. UDP Filters ........................................10
3.2.4. IPsec and Internet Key Exchange (IKE) ..............11
3.2.5. Mobility Support in IPv6 ...........................12
3.3. Connection-Oriented Filters ...............................13
3.3.1. TCP Filters ........................................14
3.3.2. SCTP Filters .......................................17
3.3.3. DCCP Filters .......................................20
3.3.4. Level 3 Multihoming Shim Protocol for IPv6
(Shim6) ............................................23
3.4. Passive Listeners .........................................23
3.5. Management Applications ...................................24
4. Summary of Recommendations .....................................25
5. Contributors ...................................................31
6. Security Considerations ........................................32
7. References .....................................................33
7.1. Normative References ......................................33
7.2. Informative References ....................................351. Introduction ✨
Some IPv6 gateway devices that bring Internet service to homes and small offices may come with "simple security" features, as described in "Local Network Protection for IPv6" [RFC4864]. 🛡️ These features generally make packets get dropped, all in the name of keeping local networks and the Internet safer. BUT heads up: some packets from totally legit apps can get dropped too, and that can hurt reliability and ease of use for those apps. 😭
There's a real tension here, babe. Users want transparent end-to-end connectivity, and local-area network admins need to detect and stop intrusion by unauthorized people on the public Internet. 🥺 This doc highlights reasonable limits on end-to-end transparency for cases where security matters enough to protect both local and Internet security. 🔥
Also, the typical home or small-office network admin has zero expertise in Internet engineering. Like, none. 💀 Config interfaces for router and gateway appliances marketed to them should be easy to understand and even easier to ignore. Extra care should go into designing the baseline operating modes for unconfigured devices, because most devices never get changed from their factory settings. 🍓
1.1. Special Language 💬
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119]. 📚
There's also a key word "DEFAULT", which in this doc refers to a configuration as applied by a vendor, before the administrator changes 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.
Pay special attention to recommendation REC-49, which calls for an easy way to set a gateway to a transparent mode of operation. 👀✨
2. Overview 🦋
For this doc, residential Internet gateways are assumed to be pretty simple devices with a limited subset of the full feature set. 🎀 They work as default routers [RFC4294] for a single local-area network, like an Ethernet network, a Wi-Fi network, or a bridge between two or more of those segments. They have only one interface for accessing the Internet service at any one time, and they can use any of several possible sub-IP mechanisms, including tunnels and transition mechanisms. 🧩
When we talk about the security features of residential gateways, it makes sense to split things into the "interior" network (the local-area network) and the "exterior" networks (like the public Internet and the networks of Internet service providers). 🏠🌍 This doc only cares about how IP packet filters behave when they police traffic between the interior IPv6 network and the exterior IPv6 networks of residential Internet gateways. 🛂
The operational goals of security features in Internet gateways are described in more detail in "Local Network Protection for IPv6" [RFC4864], but the short version is this:
- Check all traffic to and from the public Internet for basic sanity. For example, filter out spoofs and misdirected ("Martian") packets [RFC4949]. 🧹
- Allow tracking of application usage by source and destination network addresses and ports. 📊
- Provide a barrier against untrusted external influences on the interior network, by requiring that filter state gets activated by traffic originating at interior network nodes. 🚧
- Allow manually configured exceptions to the stateful filtering rules, according to network administrative policy. 📝
- Isolate local network DHCPv6 and DNS resolver services from the public Internet. 🔒
Before IPv6 Internet service was widely available, homes and small offices often used private IPv4 network address realms [RFC1918] with Network Address Translation (NAT) functions deployed. NAT made all the hosts on the interior network look like a single host to the Internet service provider. 🎭 The stateful packet filtering behavior of NAT set user expectations that are still around with residential IPv6 service today. "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways in a way that matches 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. 🤔 That means applications need advance knowledge of the addresses of the exterior nodes they expect to talk to. Several proposals are under consideration for letting applications solicit inbound traffic from exterior nodes without knowing their addresses in advance. 🔮 The Internet engineering community has agreed that these protocols are necessary to implement in residential IPv6 gateways, but the best current practice hasn't been established yet. 🙈
2.1. Basic Sanitation 🧼
On top of the functions required of all IPv6 routers [RFC4294], residential gateways are expected to have basic stateless filters. These filters prohibit certain kinds of traffic with invalid headers, like "Martian" packets, spoofs, routing header type code zero, and so on. (See Section 3.1 for more details.) 🚫
On the flip side, simple Internet gateways are not expected to block the development of new applications. ✨ In particular, packets with end-to-end network security and routing extension headers for mobility are expected to pass through Internet gateways freely. 🦄
Finally, Internet gateways that route multicast traffic are expected to implement appropriate multicast filters. These limit the scope of multicast groups that span the line between residential networks and service provider networks. 🌸
2.2. Internet Layer Protocols ✨
okay so bestie, virtual private networking tunnels are giving unacceptably wide attack surface 😭, so this doc says the DEFAULT mode for residential IPv6 simple security should treat Generic Packet Tunneling [RFC2473] and friends as opaque transport layers 🧚. Translation: inbound tunnel initiations get denied, outbound ones are accepted. Main character energy for keeping the house safe 🏠🔒
IPsec transport and tunnel modes are explicitly secured by definition, so the DEFAULT operating mode should permit IPsec 💅. To help IPsec support IPv6 mobility, the Internet Key Exchange (IKE) protocol [RFC5996] and the Host Identity Protocol (HIP) [RFC5201] should also be permitted in the DEFAULT operating mode 🫶
2.3. Transport Layer Protocols 🦋
ngl this list is iconic 👑. IPv6 simple security is mostly about stateful filtering of ICMPv6 [RFC4443] and transport layers like UDP [RFC0768], UDP-Lite [RFC3828], TCP [RFC0793], SCTP [RFC4960], DCCP [RFC4340], and potentially any standards-track transport protocols defined in the future 🌈
The general vibe is that transport layer traffic is NOT forwarded into the interior network of a residential IPv6 gateway unless interior transport endpoints explicitly solicited it 🙈. That means matching the reverse path for previously forwarded outbound traffic, or matching exceptions the network administrator set up ✨. Everything else should be discarded or rejected with an ICMPv6 error message to say the traffic is administratively prohibited 💀
3. Detailed Recommendations 🍓
this section goes deep on the specific recs, and Section 4 is the summary, so no skipping 🫶
some filters apply to ALL traffic through residential Internet gateways no matter which direction it's going 🚦. Other filters are sensitive to the "direction" of traffic flows, and for bidirectional transport flows, "direction" has a very specific meaning here 🎀
Packets are "outbound" if they start at nodes in the interior network heading to exterior destinations, and "inbound" if they arrive from exterior sources going to interior destinations 🦋
Flows are "outbound" if the originator of the initial packet in a transport association is an interior node and one or more participants are in the exterior. Flows are "inbound" if the originator of the initial packet is an exterior node and one or more participants are interior nodes 💜
3.1. Stateless Filters 💅
certain kinds of IPv6 packets MUST NOT be forwarded in either direction by residential Internet gateways, regardless of network state. This includes packets with multicast source addresses, packets going to certain non-routable and/or reserved prefixes, and packets with deprecated extension headers 🚫
other stateless filters are recommended to do ingress filtering (see [RFC2827] and [RFC3704]), enforce multicast scope boundaries, and isolate certain local network services from the public Internet 🌸
REC-1: Packets bearing multicast source addresses in their outer IPv6 headers MUST NOT be forwarded or transmitted on any interface. 🙅♀️
REC-2: Packets bearing multicast destination addresses in their outer IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address Architecture" [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 administrator ⭐
REC-3: Packets bearing source and/or destination addresses forbidden to appear in the outer headers of packets sent over the public Internet MUST NOT be forwarded. In particular, site-local addresses are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible Addresses, Documentation Prefix, and Overlay Routable Cryptographic Hash IDentifiers (ORCHID) 🔥
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] preceding the first upper-layer-protocol header MUST NOT be forwarded. See [RFC5095] 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] SHOULD NOT be forwarded to or from the exterior network 🙈
REC-8: By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server 💅
REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server or relay agent 🫶
NOTE WELL: Nothing in this document relieves residential Internet gateways, when processing headers to identify valid sequences of upper-layer transport packets, from any of the requirements of the "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460], including any and all future updates and revisions. 📣
3.2. Connection-Free Filters 🦋
some Internet apps use connection-free transport protocols with no release semantics, e.g., UDP. These protocols are a special headache for stateful packet filters because most of the app state isn't carried at the transport level 😩. State records get created when communication starts and get 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] and apply to residential gateways, with the extra rec that incoming "Destination Unreachable" and "Packet Too Big" error messages that don't match any filtering state should be dropped 🧚
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 records. ✨
3.2.2. Upper-Layer Transport Protocols 💜
residential IPv6 gateways aren't expected to prohibit apps built on future upper-layer transport protocols. In particular, transport protocols not covered in later sections of this doc 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 that deletes the state record when no further communications are detected ⏳
One key aspect of how a packet filter behaves is how it evaluates the exterior address of an endpoint when applying a filtering rule. A gateway has "endpoint-independent filtering" behavior when the exterior address is NOT evaluated when matching a packet with a flow. A gateway has "address-dependent filtering" behavior when the exterior address of a packet is required to match the exterior address for its flow 🔥
REC-11: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for generic upper-layer transport protocols. 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 other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management 👑
REC-12: 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. ⏰
The Internet security community is never completely at rest 😭. New attack surfaces, and vulnerabilities in them, are typically discovered faster than they can be patched by normal equipment upgrade cycles. It's therefore important for vendors of residential gateway equipment to provide automatic software updates to patch vulnerabilities as they're discovered 🛡️
REC-13: Residential IPv6 gateways SHOULD provide a convenient means to update their firmware securely, for the installation of security patches and other manufacturer-recommended changes. 🔐
Vendors can expect users and operators to have differing viewpoints on maintaining patches, with some preferring automatic update and some preferring manual procedures. Those preferring automatic update may also prefer either downloading from a vendor site or from one managed by their network provider 🌈. To handle the disparity, vendors are advised to provide both manual and automatic options. In the automatic case, they would do well to facilitate pre-configuration of the download URL and a means of validating the software image, such as a certificate 💖
3.2.3. UDP Filters ✨
Okay, UDP is the connectionless one, so it gets its own whole section 💅. "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787] is the go-to doc for the terminology and best current practice for stateful filtering of UDP apps over IPv4 with NAT 🦋. It's the model for the behavioral requirements for simple UDP security in IPv6 gateways, even though the NAT-specific stuff doesn't carry over 🙈.
An interior endpoint starts a UDP flow through a stateful packet filter by sending a packet out to an exterior address 🌸. The filter then allocates (or reuses) a filter state record for the whole flow. That record defines the interior and exterior IP addresses and ports used by every packet in the flow ✨.
State records for UDP flows stay active while they're in use, and they only get dropped after some amount of idle time 🧚.
REC-14: A state record for a UDP flow where both source and destination 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-15: A state record for a UDP flow where one or both of the source and destination ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes, so the IANA-registered service assigned to that port can keep working 🎀.
As [RFC4787] points out, outbound refresh is needed so the interior endpoint can keep its state record alive 🫶. Inbound refresh may be useful for apps that don't send any outbound UDP traffic. BUT, allowing inbound refresh means an attacker on the exterior side, or a misbehaving app, could keep a state record alive forever 😭. That's a security risk, no cap. And if it keeps happening with different ports, over time it could eat up all the state record memory and resources in the filter 💀.
REC-16: A state record for a UDP flow 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 of [RFC4787], UDP is connection-free, which makes it hard for packet filters to figure out which packets belong to an application flow and which ones are unsolicited 👑. Different IPv4/NAT gateways have used different strategies here, with different effects 🌈.
REC-17: If application transparency is the most important thing, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for UDP. If stricter filtering is more important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option the network administrator can configure, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management ⭐.
Some app mechanisms depend on receiving ICMPv6 error messages that were triggered by UDP messages being sent 🍓. One example is path MTU discovery [RFC1981] 🦋.
REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing UDP headers that match the flow state record 💜.
REC-19: Receiving any sort of ICMPv6 message MUST NOT terminate the state record for a UDP flow 🙌.
REC-20: UDP-Lite flows [RFC3828] SHOULD be handled the same way as UDP flows, with one catch: the upper-layer transport protocol identifier for UDP-Lite is not the same as UDP's. So UDP packets MUST NOT match UDP-Lite state records, and vice versa 🎀✨.
3.2.4. IPsec and Internet Key Exchange (IKE) 🔐
IPsec is giving more flexibility and better overall security than the simple security you get from stateful packet filtering at network perimeters 💅. So residential IPv6 gateways don't need to prohibit IPsec traffic flows. Iconic behavior 👑.
REC-21: 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 "Authentication Header (AH)" [RFC4302] in their outer IP extension header chain 💖.
REC-22: 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)" [RFC4303] in their outer IP extension header chain 🌸.
REC-23: If a gateway forwards an ESP flow, it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record 🧚.
Internet Key Exchange (IKE) is the secure mechanism for doing mutual authentication, swapping cryptographic material, and setting up IPsec Security Associations between peers 🫶. Residential IPv6 gateways are expected to make IPsec security policies work by allowing inbound IKE flows 🎀.
REC-24: 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 (IKE) protocol [RFC5996] 🔥.
REC-25: In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) [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 also indexing state records by the security parameters index (SPI) SHOULD NOT be used. Likewise, any mechanism that depends on detecting Internet Key Exchange (IKE) [RFC5996] initiations SHOULD NOT be used 🙈💀.
The Host Identity Protocol (HIP) is a secure mechanism for establishing host identity and secure communication between authenticated hosts 🦋. Residential IPv6 gateways don't need to prohibit inbound HIP flows 💅.
REC-26: 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 an encapsulation mechanism in flows between mobile nodes and their correspondent nodes. It involves the Type 2 IPv6 Routing Header, the Home Address destination header option, and the Mobility extension header 🌈. Compared to mobility support in IPv4, mobility is a standard feature of IPv6, and there's generally no security benefit to be gained by denying communications with either interior or exterior mobile nodes 💜.
Not every usage scenario of mobility support in IPv6 is expected to play nicely with IPv6 simple security 😬. In particular, exterior mobile nodes are expected to be blocked from setting up bindings with interior correspondent nodes, by filtering out unsolicited inbound Mobility Header messages, unless they're covered by an IPsec security policy 🔐.
REC-27: The state records for flows started by outbound packets that bear a Home Address destination option [RFC3775] are distinguished by adding 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 address in the destination field of the IPv6 header matches the interior care-of address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the home address of the flow 🦋✨.
REC-28: Valid sequences of Mobility Header [RFC3775] packets MUST be forwarded for all outbound and explicitly permitted inbound Mobility Header flows 🍓.
REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward, in both directions, the IPv4 and IPv6 packets that are encapsulated in IPv6 associated with the tunnel between the home agent and the correspondent node 🌸.
REC-30: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing any headers that match the associated flow state records 🫶.
3.3. Connection-Oriented Filters 🤝
Most Internet apps use connection-oriented transport protocols with orderly release semantics 💅. That includes TCP, SCTP, DCCP, and any future IETF Standards-Track transport protocols that use the same kind of semantics 🌈. Stateful packet filters keep track of the state of each transport flow, and they block packets that don't match the state of an active flow and don't follow a rule for automatically creating that state 🚫💖.
3.3.1. TCP Filters ✨
Okay so, an interior endpoint starts a TCP flow through a stateful packet filter by sending a SYN packet 💖 The filter then allocates (or reuses) a filter state record for the flow. That record defines the interior and exterior IP addresses and ports used for forwarding all packets for that flow 🦋
Some peer-to-peer apps use a different way to start a connection, called "simultaneous-open" ([RFC0793], Figure 8), to get through stateful filters 🧚 In simultaneous-open, both peers send SYN packets for the same TCP flow. The SYN packets cross in the network. When each end gets the other end's SYN packet, it responds with a SYN-ACK packet, and those SYN-ACK packets also cross in the network. The connection is established at each endpoint once the SYN-ACK packets are received.
To do stateful packet filtering for TCP, a filter has to receive, process, and forward all packets for a flow that follow valid transitions of the TCP state machine ([RFC0793], Figure 6) 💅
REC-31: All valid sequences of TCP packets (defined in [RFC0793]) MUST be forwarded for outbound flows and explicitly permitted inbound flows. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open mode of operation MUST be supported.
It's possible to reconstruct enough of a TCP flow's state to allow forwarding between an interior and exterior node, even when the filter starts operating after TCP enters the established state. But since the filter never saw the TCP window-scale option, it can't enforce the TCP window invariant by dropping out-of-window segments 😭
REC-32: The TCP window invariant MUST NOT be enforced on flows for which the filter did not detect whether the window-scale option (see [RFC1323]) was sent in the 3-way handshake or simultaneous-open.
A stateful filter can let an existing state record be reused by an externally initiated flow if its security policy allows it. Several different policies are possible, as described in [RFC4787] and extended in [RFC5382] 🌸
REC-33: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" 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 be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
If an inbound SYN packet gets filtered, either because no matching state record exists or because of the filter's normal behavior, the filter has two basic choices: discard the packet silently, or signal an error to the sender. Signaling an error through ICMPv6 messages lets the sender detect that the SYN didn't reach its intended destination. Discarding the packet, on the other hand, lets applications do simultaneous-open more reliably. There's a more detailed discussion in [RFC5382], but the bottom line is that filters need to wait before signaling errors until simultaneous-open won't be impaired 🙈
REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination 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 keeps state for in-progress connections and established flows, so it's vulnerable to a resource-exhaustion attack, where an attacker (or virus) on the interior tries to make the filter run out of capacity for creating state records 💀 To defend against that, a filter needs to abandon unused state records after a sufficiently long period of idleness.
A common method for TCP filters in IPv4/NAT gateways is to preferentially abandon flow state records for crashed endpoints, then closed flows, then partially open flows. A gateway can check whether 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 can't determine whether the endpoint is active, the associated state record needs to be retained until the TCP flow has been idle for some time.
Note: An established TCP flow 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] and [RFC4294] can reduce the chances of abandoning a live flow.
TCP flows can stay in the established phase indefinitely without exchanging packets. Some end-hosts can be configured to send keep-alive packets on these idle flows; by default, such packets are sent every two hours, if enabled [RFC1122]. So a filter that waits for slightly over two hours can detect idle flows with keep-alive packets being sent at the default rate. TCP flows 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] ⏳
The "established flow idle-timeout" for a stateful packet filter is defined as the minimum time a TCP flow in the established phase must remain idle before the filter considers the associated state record a candidate for collection. The "transitory flow idle-timeout" for a filter is defined as the minimum time a TCP flow in the partially open or closing phases must remain idle before the filter considers the associated state record a candidate for collection. TCP flows in the TIME-WAIT state are not affected by the "transitory flow idle-timeout" parameter.
REC-35: If a gateway cannot determine whether the endpoints of a TCP 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.
Behavior for handling RST packets or TCP flows in the TIME-WAIT state is left unspecified. A gateway MAY hold state for a flow in the 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 flow, holding state for a closed flow can limit the throughput of flows through a gateway with limited resources. [RFC1337] 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 flow, or abandons a flow in the TIME-WAIT state before the four-minute TIME-WAIT period expires. The decision to either discard them or respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left up to the implementation.
Behavior for notifying endpoints when abandoning live flows is left unspecified. When a gateway abandons a live flow, 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 ICMPv6 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-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing TCP headers that match the flow state record.
REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a TCP flow.
3.3.2. SCTP Filters ✨
okay bestie, so SCTP [RFC4960] flows can be terminated at multiple network addresses 🌸, which means IPv6 simple security functions literally cannot be fully transparent for SCTP apps 😭. In multipath traversal scenarios, full transparency needs every packet filter process on all the different paths between the endpoint network addresses to coordinate. That coordination is not "simple" ngl, so it is, therefore, beyond the scope of this recommendation 💅.
however, some SCTP apps can totally tolerate the inherent unipath restriction of IPv6 simple security, even in multipath traversal scenarios 🦋. they expect connection-oriented filtering behaviors similar to TCP's, but at the level of SCTP associations, not stream connections. this section is all about specific recommendations for SCTP filtering in those traversal scenarios 🎀.
an interior endpoint starts an SCTP association through a stateful packet filter by sending a packet with a single INIT chunk 🧚. the filter allocates (or reuses) a filter state record for the association. that state record defines the interior and exterior IP addresses and the observed verification tag used for forwarding packets in that association.
some peer-to-peer SCTP apps use a different way to start an association, called "simultaneous-open", to get through stateful filters 👑. in simultaneous-open mode, both peers send INIT chunks at the same time to establish an association. when each end gets the other end's INIT chunk, it 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 will send an ERROR or ABORT chunk along with the INIT-ACK chunk. the association is established at each endpoint once an INIT-ACK chunk without an ERROR or ABORT chunk is received at one end 🫶.
to provide stateful packet filtering for SCTP, a filter has to receive, process, and forward all packets for an association that conform to valid transitions of the SCTP state machine ([RFC4960], Figure 3) 🔥.
REC-38: All valid sequences of SCTP packets (defined in [RFC4960]) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and the simultaneous-open mode of operation MUST be supported. 💖
if an inbound INIT packet gets filtered, either because a corresponding state record doesn't exist or because of the filter's normal behavior, the filter has two basic choices: discard the packet silently, or signal an error to the sender 🙈. signaling an error through ICMPv6 messages lets the sender detect that the INIT packet didn't reach the intended destination. discarding the packet, on the other hand, lets applications do simultaneous-open more reliably. delays in signaling errors can prevent the impairment of simultaneous-open mode 🍓.
REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination 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 keeps state for in-progress and established associations, so it's susceptible to a resource-exhaustion attack, where an attacker (or virus) on the interior tries to make the filter run out of room for creating state records 💀. to defend against that, a filter needs to abandon unused state records after a sufficiently long period of idleness 🛡️.
a common method 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 whether an endpoint for an association has crashed by sending HEARTBEAT chunks and looking for the HEARTBEAT ACK response. if the gateway can't determine whether the endpoint is active, the associated state record 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 recommendations in [RFC4294] 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 those idle associations, but [RFC4960] 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 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]) 🧚.
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-40: 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] about the hazards of TIME-WAIT assassination is relevant 🌈.
the handling of inbound non-INIT packets with no active state record is also left unspecified 🙃. those packets can show up if the gateway abandons a live flow, or abandons an association in the closing states before the transitory association idle-timeout expires. the decision to either discard them or respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left to the implementation 🍓.
behavior for notifying endpoints when abandoning live associations is also 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 lets endpoint applications 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 receiving ICMPv6 error messages triggered by the transmission of SCTP packets 🧠.
REC-41: If a gateway forwards an SCTP association, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing SCTP headers that match the association state record. 💜
REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for an SCTP association. 🫶
3.3.3. DCCP Filters ✨
okay so DCCP is giving TCP energy 🦋 its connection semantics are super similar to TCP's ([RFC4340]). an interior endpoint starts a DCCP flow through a stateful packet filter by sending a DCCP-Request packet. simultaneous-open is not defined for DCCP, so don't go looking for it 🙈
bestie, to do stateful packet filtering for DCCP, the filter has to receive, process, and forward every packet for a flow that follows the valid transitions of the DCCP state machine ([RFC4340], Section 8). that's the whole job 💅
REC-43: All valid sequences of DCCP packets (defined in [RFC4340]) MUST be forwarded for all flows to exterior servers, and for any flows to interior servers that have explicitly permitted service codes. 🔥
it's actually possible to rebuild enough of a DCCP flow's state to forward traffic between an interior and an exterior node, even if the filter only starts running after the flow has already hit the OPEN state 🌸 also, a filter can let an existing state record get reused by an externally initiated flow, if its security policy says that's cool. just like with TCP, there are a bunch of different policies you could pick, and [RFC4787] has a great discussion of the issue, which [RFC5382] extends 🧚
if an inbound DCCP-Request packet gets filtered, either because there's no matching state record or because the filter normally refuses flows that weren't explicitly permitted, the filter has two basic options: discard the packet silently, or signal an error back to the sender. signaling through ICMPv6 messages lets the sender figure out that its DCCP-Request never reached the intended destination. discarding it just delays the connection failure and gives you no measurable security, so it's kinda pointless 😭
a DCCP filter keeps state for connections that are in progress and for flows that are established. because of that, it's vulnerable to a resource-exhaustion attack, where an attacker (or a virus) on the interior tries to make the filter run out of room for creating state records. to stop that, a filter needs to abandon unused state records after a long enough stretch of idleness 💀
TCP filters in IPv4/NAT gateways commonly abandon sessions for crashed endpoints first, then closed TCP flows, then partially open flows. there's no equivalent method for DCCP, and flows can sit in the OPEN phase forever without exchanging any packets 😳 so there's no single idle-timeout value that works for every application. however, a large idle-timeout, motivated by the recommendations in [RFC4294], can lower the chances of abandoning a live flow ✨
DCCP flows in the partially open or closing phases can stay idle for at most eight minutes while they wait for in-flight packets to be delivered ⏳
here are the definitions you need:
- the "open flow idle-timeout" for a stateful packet filter is the minimum time a DCCP flow in the open state must stay idle before the filter considers its state record a candidate for collection.
- the "transitory flow idle-timeout" for a filter is the minimum time a DCCP flow in the partially open or closing phases must stay idle before the filter considers its state record a candidate for collection.
DCCP flows in the TIMEWAIT state are not affected by the "transitory flow idle-timeout" parameter. 🙌
REC-44: A gateway MAY abandon a DCCP state record if it has been idle for some time. In such cases, the value of the "open 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. 👑
how the filter handles DCCP-Reset packets or flows in the TIMEWAIT state is left unspecified. a gateway MAY hold state for a flow in the TIMEWAIT state so it can handle retransmissions of the last DCCP-Reset. but TIMEWAIT is commonly hit by interior endpoints that are properly closing a DCCP flow, so holding state for a closed flow can limit throughput through a gateway with limited resources 🫠 [RFC1337] talks about the hazards of TIME-WAIT assassination in TCP, and similar hazards exist for DCCP.
how to handle non-SYN packets that don't have an active state record is also left unspecified. those packets can show up if the gateway abandons a live flow, or abandons a flow in the TIMEWAIT state before the four-minute 2MSL period (two times the maximum segment lifetime [RFC4340]) is over. whether to discard them or respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is up to the implementation 🤷♀️
how to notify endpoints when a live flow gets abandoned is left unspecified too. when a gateway abandons a live flow, for example because a timeout expired, the filter MAY send a DCCP-Reset packet to each endpoint on behalf of the other. sending that DCCP-Reset notification helps endpoint applications recover faster, but notifying endpoints might not always be possible, for example if state records get wiped out by a power interruption 🔌
several DCCP mechanisms depend on receiving ICMPv6 error messages that were triggered by DCCP packets being sent. one of them is path MTU discovery, which is required for correct operation. 🛣️
REC-45: If an Internet gateway forwards a DCCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing DCCP headers that match the flow state record. 💖
REC-46: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a DCCP flow. 🧚
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (Shim6) 🌈
IPv6 simple security works fine for residential networks with only one Internet service provider at a time, but using the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] is necessary for talking to some multihomed exterior destinations 🌍 this document doesn't make any special recommendations for handling the Shim6 message format (protocol 140) beyond what's in Section 3.2.2. the content of the Shim6 payload extension header may be ignored. ✨
REC-47: Valid sequences of packets bearing Shim6 payload extension headers in their outer IP extension header chains MUST be forwarded for all outbound and explicitly permitted flows. The content of the Shim6 payload extension header MAY be ignored for the purpose of state tracking. 🫶
3.4. Passive Listeners 👂
some applications want to hear from exterior nodes without knowing the exterior addresses of their peers ahead of time 🦋 this gets handled on IPv4/NAT gateways, usually through either the NAT Port Mapping Protocol [NAT-PMP] or the Universal Plug and Play Internet Gateway Device [UPnP-IGD] standardized device control protocol. on IPv4/NAT networks connected by gateways that don't have either of those services, applications have to use techniques like Session Traversal Utilities for NAT (STUN) [RFC5389] to get and keep connectivity, despite the translation and filtering effects of NAT 😤
NAT for IPv6 is unlikely to show up in most residential gateways, but the simple security functions recommended by this document, and their filtering effects, come from comparable functions that are already widely used on the IPv4 Internet. a similar barrier to communication at passive listeners is a natural result of deploying NAT for IPv6. to keep IPv6 applications from needing techniques like STUN to open and maintain dynamic filter state, something similar to NAT-PMP and UPnP-IGD, but without actually supporting NAT, could be deployed. alas, the Internet engineering community hasn't agreed yet on what's best for residential IPv6 usage scenarios 🥲
one proposal that's been offered is the Application Listener Discovery Protocol [WOODYATT-ALD] document. we'll see whether the Internet Gateway Device profile of the Universal Plug and Play protocol gets extended for IPv6. other proposals worth noting are the Middlebox Communication Protocol [RFC5189] and the Next Steps in Signaling framework [RFC4080]. until the community agrees on one specific method, the following recommendations are the best guidance available 📝
REC-48: Internet gateways with IPv6 simple security capabilities 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-49: Internet gateways with IPv6 simple security capabilities 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., not to use the IPv6 simple security capabilities of the gateway. The transparent mode of operation MAY be the default configuration. 🌟
in general, "transparent mode" gives more flexibility and reliability to applications that need devices inside the home to be contacted directly, especially when there's no protocol like the one in REC-48. but operating in transparent mode may come at the expense of security if there are IPv6 nodes in the home that don't have their own host-based firewall and need a firewall in the gateway so they don't get compromised 🚨
3.5. Management Applications 🛠️
subscriber-managed residential gateways are unlikely ever to be completely zero-configuration, but their administrators very often won't have any particular Internet engineering expertise 🙃 in general, specifying management interfaces for residential gateways is out of scope for this document, but the security of subscriber-managed gateways deserves special attention here 🔐
REC-50: By DEFAULT, subscriber-managed residential gateways MUST NOT offer management application services to the exterior network. 🚫
4. Summary of Recommendations 📋
this section gathers every recommendation made in this document into one handy list 💅
REC-1 Packets bearing multicast source addresses in their outer
IPv6 headers MUST NOT be forwarded or transmitted on any
interface.
REC-2 Packets bearing multicast destination addresses in their
outer IPv6 headers of equal or narrower scope (see "IPv6
Scoped Address Architecture" [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 administrator.
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], and
[RFC5156] explicitly forbids the use of address blocks of
types IPv4-Mapped Addresses, IPv4-Compatible Addresses,
Documentation Prefix, and Overlay Routable Cryptographic Hash
IDentifiers (ORCHID).REC-4 okay bestie, packets with deprecated extension headers sitting in front of the first upper-layer-protocol header SHOULD NOT be forwarded or sent out on any interface 🙅♀️. Especially, any packet with routing extension header type 0 [RFC2460] before that first upper-layer header MUST NOT be forwarded 💀. See [RFC5095] for more background 📚.
REC-5 Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header doesn't have a unicast prefix set up for 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 globally reachable nodes on the interior network 👀.
REC-7 By DEFAULT, packets with unique local source and/or destination addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior network 🏠.
REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server 🔒.
REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server or relay agent 🙅.
REC-10 IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that don't match generic upper-layer transport state records 🌸.
REC-11 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for generic upper-layer transport protocols. 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 the network administrator can configure, and it MAY be independent of the filtering behavior for other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management 🎀.
REC-12 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-13 Residential IPv6 gateways SHOULD provide a convenient means to update their firmware securely, for installing security patches and other manufacturer-recommended changes 🛠️.
REC-14 A state record for a UDP flow where both source and destination 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-15 A state record for a UDP flow where one or both of the source and destination ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes, so the IANA-registered service assigned to that port keeps working smoothly 🧚.
REC-16 A state record for a UDP flow 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-17 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" 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 the network administrator can configure, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management 💜.
REC-18 If a gateway forwards a UDP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing UDP headers that match the flow state record 🫧.
REC-19 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a UDP flow. Not me, ICMPv6 getting to end a UDP flow 🙅♀️✨.
REC-20 UDP-Lite flows [RFC3828] SHOULD be handled the same way as UDP flows, except that the upper-layer transport protocol identifier for UDP-Lite is not the same as UDP. Therefore, UDP packets MUST NOT match UDP-Lite state records, and vice versa 🌈.
REC-21 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 "Authentication Header (AH)" [RFC4302] in their outer IP extension header chain 🔑.
REC-22 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)" [RFC4303] in their outer IP extension header chain 🔐.
REC-23 If a gateway forwards an ESP flow, it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record 🌷.
REC-24 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 (IKE) Protocol [RFC5996] 🗝️.
REC-25 In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) [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) [RFC5996] initiations SHOULD NOT be used 🧩.
REC-26 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 🪪.
REC-27 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 address in the destination field of the IPv6 header matches the interior care-of address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the home address of the flow 🏡✈️.
REC-28 Valid sequences of Mobility Header [RFC3775] packets MUST be forwarded for all outbound and explicitly permitted inbound Mobility Header flows 🦄.
REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward, in both directions, the IPv4 and IPv6 packets that are encapsulated in IPv6 associated with the tunnel between the home agent and the correspondent node 🚇.
REC-30 If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing any headers that match the associated flow state records 🎁.
REC-31 All valid sequences of TCP packets (defined in [RFC0793]) MUST be forwarded for outbound flows and explicitly permitted inbound flows. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open mode of operation MUST be supported 🤝💖.
REC-32 The TCP window invariant MUST NOT be enforced on flows for which the filter did not detect whether the window-scale option (see [RFC1323]) was sent in the 3-way handshake or simultaneous-open. Don't enforce it if you couldn't tell, bestie 🙈.
REC-33 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" 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 the network administrator can configure, and it MAY be independent of the filtering behavior for UDP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management 👑.
REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination 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-35 If a gateway cannot determine whether the endpoints of a TCP 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-36 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing TCP headers that match the flow state record 🍓.
REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a TCP flow. Same energy as REC-19, ICMPv6 is not allowed to end the TCP vibe either 🫶🔥.
REC-38 All valid sequences of SCTP packets (defined in [RFC4960]) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and the simultaneous-open mode of operation MUST be supported 🌟.
REC-39 By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination 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-40 Okay so, if a gateway can't tell whether the endpoints of an SCTP association are still active 💀, it MAY abandon the state record once it's been idle for a while. When it does, the established association idle-timeout MUST NOT be less than two hours four minutes, and the transitory association idle-timeout MUST NOT be less than four minutes. The idle-timeouts MAY be configurable by the network administrator 🎀
REC-41 If a gateway forwards an SCTP association, it MUST also forward ICMPv6 Destination Unreachable and Packet Too Big messages that contain SCTP headers matching the association state record 🦋
REC-42 Receiving any sort of ICMPv6 message MUST NOT terminate the state record for an SCTP association. Not even a little bit 🙅♀️
REC-43 All valid sequences of DCCP packets (defined in [RFC4340]) MUST be forwarded for all flows to exterior servers, and for any flows to interior servers that have explicitly permitted service codes 💜
REC-44 A gateway MAY abandon a DCCP state record once it's been idle for some time. When it does, the open flow idle-timeout MUST NOT be less than two hours four minutes, and the transitory flow idle-timeout MUST NOT be less than eight minutes. The idle-timeouts MAY be configurable by the network administrator ⏰
REC-45 If an Internet gateway forwards a DCCP flow, it MUST also forward ICMPv6 Destination Unreachable and Packet Too Big messages that contain DCCP headers matching the flow state record 🌸
REC-46 Receiving any sort of ICMPv6 message MUST NOT terminate the state record for a DCCP flow. Same energy as REC-42, periodt ✨
REC-47 Valid sequences of packets carrying Shim6 payload extension headers in their outer IP extension header chains MUST be forwarded for all outbound flows and for explicitly permitted flows. The content of the Shim6 payload extension header MAY be ignored for the purpose of state tracking 🧚
REC-48 Internet gateways with IPv6 simple security capabilities SHOULD implement a protocol that lets applications solicit inbound traffic without knowing in advance the addresses of the exterior nodes they expect to talk to 🍓
REC-49 Internet gateways with IPv6 simple security capabilities MUST provide an easy-to-select configuration option for a "transparent mode" of operation. In that mode, the gateway forwards all unsolicited flows regardless of forwarding direction, meaning it doesn't use its IPv6 simple security capabilities at all. The transparent mode of operation MAY be the default configuration 🌈
REC-50 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 came in from the following IETF participants, and the editor thanks every single one of them 💖
+-------------------+----------------------------+
| Jari Arkko | Ran Atkinson |
| Fred Baker | Norbert Bollow |
| Cameron Byrne | Brian Carpenter |
| Remi Despres | Arnaud Ebalard |
| Fabrice Fontaine | Jun-ichiro "itojun" Hagino |
| Thomas Herbst | Christian Huitema |
| Joel Jaeggli | Cullen Jennings |
| Suresh Krishnan | Erik Kline |
| Julien Laganier | Kurt Erik Lindqvist |
| Mohamed Boucadair | Keith Moore |
| Robert Moskowitz | Teemu Savolainen |
| Hemant Singh | Yaron Sheffer |
| Mark Townsley | Iljitsch van Beijnum |
| Magnus Westerlund | Dan Wing |
+-------------------+----------------------------+It has to be noted that a big chunk of the text describing the detailed requirements for TCP and UDP filtering is derived or transposed from [RFC4787] and [RFC5382]. The editors of those documents, Francois Audet and Saikat Guha, also deserve substantial credit for the form of this document 👑
6. Security Considerations 🔐
The IPv6 stateful filtering behaviour described in this document is meant to work like the filtering behaviour of commonly used IPv4/NAT gateways. Those 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], the true impact of these tools may be a reduction in security 😭. It's generally safe to assume that the impacts that document discusses for filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here.
Also, stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Proper security mechanisms implemented in the end nodes, together with the local network protection methods in [RFC4864], work without relying on network layer hacks and transport filters that may change over time. Meanwhile, defined security barriers assume that threats come from the exterior. That can lead to practices where applications are fully exposed to interior attack, which makes breaches much easier. Yikes 💀
The security functions described in this document may be considered redundant if all IPv6 hosts using a particular gateway have their own IPv6 host firewall capabilities enabled. At the time of writing, the vast majority of commercially available operating systems with IPv6 support include an IPv6 host firewall 🛡️
Worth noting explicitly: a practical side-effect of the recommendations in Section 3.2.4, which allow inbound IPsec and IKE flows from exterior to interior, is that they make more transparent communication possible through an unauthenticated mode of IPsec. That's described in "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec" [RFC5386]. This may be a departure from the transparency people expect from traditional IPv4/NAT residential gateways 🙃
Last but not least, residential gateways that implement simple security functions sit as a bastion between the interior and the exterior. That makes them a target for denial-of-service attacks against the interior network itself, from processes designed to eat up the gateway's resources, such as a ping or SYN flood 🚨. Gateways should use the same kinds of protection techniques as application servers on the Internet.
The IETF makes no statement, expressed or implied, as to whether using the capabilities described in this document ultimately improves security for any individual users or for the Internet community as a whole 🤷♀️
7. References 📚
7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(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
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
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
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
April 2008.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T.
Henderson, "Host Identity Protocol", RFC 5201,
April 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.7.2. Informative References 📚✨
Okay bestie, these are the "good to know" references. Not required reading to get the core ideas, but they're the receipts for everything else in the doc 💅
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
Mapping Protocol (NAT-PMP)", Work in Progress,
April 2008.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 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:
Defeating Denial of Service Attacks which employ IP
Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van
den Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communication (MIDCOM) Protocol Semantics", RFC 5189,
March 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP",
BCP 142, RFC 5382, October 2008.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386,
November 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway
Device Standardized Device Control Protocol",
September 2010, <http://upnp.org/specs/gw/igd2/>.
[WOODYATT-ALD]
Woodyatt, J., "Application Listener Discovery (ALD) for
IPv6", Work in Progress, July 2008.Author's Address 🎀
Here's where to find the editor, James Woodyatt, at Apple Inc. 🍎 Shoot him an email if you have questions about the doc 💌
James Woodyatt (editor)
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
US
EMail: jhw@apple.com📦 where this page comes from
- ietf: rfc6092 2011-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms