One document matched: draft-ietf-v6ops-cpe-simple-security-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- OPEN ISSUES REMAINING
-->
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0768 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC1323 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1323.xml">
<!ENTITY RFC1337 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1337.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2993 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2993.xml">
<!ENTITY RFC3828 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3828.xml">
<!ENTITY RFC3978 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3978.xml">
<!ENTITY RFC3979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3979.xml">
<!ENTITY RFC3989 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3989.xml">
<!ENTITY RFC4080 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4080.xml">
<!ENTITY RFC4302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
<!ENTITY RFC4340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
<!ENTITY RFC4294 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4294.xml">
<!ENTITY RFC4748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4748.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC4864 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use. (Here they are set differently than their defaults in
xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="bcp" docName="draft-ietf-v6ops-cpe-simple-security-03"
ipr="full3978">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<front>
<title abbrev="Simple Security in IPv6 Gateway CPE">
Recommended Simple Security Capabilities in Customer Premises Equipment
for Providing Residential IPv6 Internet Service
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="james woodyatt" initials="j.h" role="editor"
surname="woodyatt">
<organization abbrev='Apple'>Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>
<email>jhw@apple.com</email>
</address>
</author>
<!-- Another author who claims to be an editor -->
<date year="2008" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year
is specified, xml2rfc will fill in the current day and month for you.
If the year is not the current one, it is necessary to specify at least
a month (xml2rfc assumes day="1" if not specified for the purpose of
calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Operations and Management</area>
<workgroup>IPv6 Operations</workgroup>
<keyword>IPv6</keyword>
<keyword>CPE</keyword>
<keyword>Security</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor='intro' title="Introduction">
<t>In "Local Network Protection for IPv6" <xref target="RFC4864"/>, IETF
recommends 'simple security' capabilities for gateway devices that enable
delivery of Internet services in residential and small office settings.
The principle goal of these capabilties is to improve security of the
IPv6 Internet without increasing the perceived complexity for users who
just want to accomplish useful work.</t>
<t>There is, at best, 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.</t>
<t>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.</t>
<section anchor='req-lang' title="Special Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>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.</t>
</section>
</section>
<section anchor='overview' title="Overview">
<t>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
<xref target='RFC4294'/> 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.</t>
<t>The operational goals of security capabilities in Internet gateways
are described with more detail in "Local Network Protection for IPv6"
<xref target="RFC4864"/>, but they can be summarized as follows.</t>
<t><list style='symbols'>
<t>Check all traffic to and from the public Internet for basic sanity,
e.g. anti-spoofing and "martian" filters.</t>
<t>Allow tracking of application usage by source and destination
transport addresses.</t>
<t>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.</t>
<t>Allow manually configured exceptions to the stateful filtering rules
according to network administration policy.</t>
<t>Isolate local network DHCP and DNS proxy resolver services from the
public Internet.</t>
</list></t>
<t>Prior to the widespread availability of IPv6 Internet service, homes
and small offices often used private IPv4 network address realms
<xref target='RFC1918'/> 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" <xref
target="RFC4864"/> recommends applying stateful packet filtering at
residential IPv6 gateways that conforms to the user expectations already
in place.</t>
<t>It should be noted that NAT for IPv6 is both strictly forbidden by the
standards documents and strongly deprecated by Internet operators. Only
the perceived security benefits associated with stateful packet
filtering, which NAT requires as a side effect, are thought relevant in
the IPv6 residential usage scenario.</t>
<t>As the latest revision of this document is being drafted, conventional
stateful packet filters are activated as a side effect of 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.</t>
<section title='Basic Sanitation'>
<t>In addition to the functions required of all Internet routers
<xref target='RFC4294'/>, 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.</t>
<t>Internet gateways that route multicast traffic are expected to
implement appropriate filters for scoped multicast addresses.</t>
<t>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.</t>
</section>
<section title='Internet Layer Protocols'>
<t>In managed, enterprise networks, virtual private networking tunnels
are typically regarded as an additional attack surface. and they are
often restricted or prohibited from traversing firewalls for that
reason. However, it would be inappropriate to restrict virtual private
networking tunnels by default in unmanaged, residential network usage
scenarios. Therefore, this document recommends the DEFAULT operating
mode for residential IPv6 simple security is to permit all virtual
private networking tunnel protocols to pass through the stateful
filtering function. These include IPsec transport and tunnel modes
as well as other IP-in-IP protocols.</t>
<t>Where IPv6 simple security functions are integrated with an IPv4/NAT
gateway of any of the types described in <xref target='RFC4787'/>, it's
important to keep IPv6 flows subject to a consistent policy. If the
security functions of an IPv6 residential gateway can be bypassed
through <xref target='RFC4380'>Teredo</xref>, then application
developers will be encouraged to use it even at nodes where native IPv6
service is available. This will have the effect of impeding the
completion of the transition to native IPv6.</t>
<t>Residential IPv6 gateways are expected to continue operating as
IPv4/NAT gateways for the foreseeable future. To prevent Teredo from
acquiring a utility that it was never meant to have on networks where
both IPv4/NAT and native IPv6 services are available, gateways MUST
impede Teredo tunnels by blocking clients from learning their mapped
addresses and ports in the qualification procedure described in
sections 5.2.1 and 5.2.2 of <xref target='RFC4380'/>. (Note: this is a
necessary addition to the "automatic sunset" provision in section 5.5
of <xref target='RFC4380'/> because it's all too common that nested
IPv4/NAT gateways are deployed unintentionally in residential settings
and without consideration for Internet architectural implications.)</t>
</section>
<section title='Transport Layer Protocols'>
<t>IPv6 simple security functions are principally concerned with the
stateful filtering of transport layers like <xref target='RFC0768'>User
Datagram Protocol (UDP)</xref> (and <xref target='RFC3828'>Lightweight
User Datagram Protocol (UDP-Lite)</xref>), <xref target='RFC0793'>
Transport Control Protocol (TCP)</xref>, the <xref target='RFC4960'>
Stream Control Transmission Protocol (SCTP)</xref>, the
<xref target='RFC4340'>Datagram Congestion Control Protocol (DCCP)
</xref>, and potentially any standards-track transport protocols to be
defined in the future.</t>
<t>The general operating principle is that transport layer traffic is
only permitted into the interior network of a residential IPv6 gateway
when it has been solicited explicitly by interior nodes. All other
traffic is expected to be discarded or rejected with an ICMPv6 error
message to indicate the traffic is administratively prohibited.</t>
</section>
</section>
<section anchor='details' title='Detailed Recommendations'>
<t>This section describes the specific recommendations made by this
document in full detail. They are summarized into a convenient list in
<xref target='summary'/>.</t>
<t>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. However, most filters are expected to be sensitive
to the direction that traffic is flowing. 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 initiator is an interior
node and one or more of the participants are at exterior addresses.
Flows are said to be "inbound" if the initiator is an exterior node and
one or more of the participants are nodes on the interior network. The
initiator of a flow is the first node to send a packet in the context of
a given transport association, e.g. a TCP connection, et cetera.</t>
<section anchor='stateless' title='Stateless Filters'>
<t>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.</t>
<t>Other stateless filters are recommended to guard against spoofing,
to enforce multicast scope boundaries, and to isolate certain local
network services from the public Internet.</t>
<t>R1: Packets bearing in their outer IPv6 headers multicast source
addresses MUST NOT be forwarded or transmitted on any interface.</t>
<t>R2: Packets bearing in their outer IPv6 headers multicast
destination addresses of equal or narrower scope that 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.</t>
<t>R3: Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header MUST NOT be forwarded or transmitted
on any interface. In particular, all packets with routing extension
header type 0 <xref target='RFC2460'/> preceding the first
upper-layer-protocol header MUST NOT be forwarded.</t>
<t>R4: 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.</t>
<t>R4: 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.</t>
<t>R5: Packets MAY be discarded if the source and/or destination
address in the outer IPv6 header is a unique local address. By
DEFAULT, gateways SHOULD NOT forward packets across unique local
address scope boundaries.</t>
<t>R6: By DEFAULT, inbound non-recursive DNS queries received on
exterior interfaces MUST NOT be processed by any integrated DNS proxy
resolving server.</t>
<t>R7: Inbound DHCP discovery packets received on exterior interfaces
MUST NOT be processed by any integrated DHCP server.</t>
</section>
<section anchor='clts-filters' title='Connection-free Filters'>
<t>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.</t>
<section anchor='other' title='Upper-layer Transport Protocols'>
<t>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.</t>
<t>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.</t>
<t>R9: 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.</t>
<t>R10: 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.</t>
</section>
<section anchor='udp-filter' title='UDP Filters'>
<t><xref target='RFC4787'>"NAT Behaviorial Requirements for UDP"
</xref> defines the terminology and best current practice for
stateful filtering of UDP applications in IPv4 with NAT, which serves
as the model for behaviorial requirements for simple UDP security in
IPv6 gateways, notwithstanding the requirements related specifically
to network address translation.</t>
<t>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.</t>
<t>State records for UDP exchanges remain active while they are in
use and only abandoned after an idle period of some time.</t>
<t>R11: 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.</t>
<t>R12: 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.</t>
<t>As <xref target='RFC4787'/> 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.</t>
<t>R13: 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.</t>
<t>As described in section 5.5 of <xref target='RFC4787'/>, 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.</t>
<t>R14: 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.</t>
<t>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.</t>
<t>R15: If a gateway forwards a UDP exchange, it MUST also forward
ICMP Destination Unreachable messages containing UDP headers that
match the exchange state record.</t>
<t>R16: Receipt of any sort of ICMP message MUST NOT terminate the
state record for a UDP exchange.</t>
<t>R17: UDP-Lite exchanges <xref target='RFC3828'/> SHOULD be handled
in the same way as UDP exchanges, except that the upper-layer
transport protocol identifier for UDP-Lite is not the same as UDP,
and therefore UDP packets MUST NOT match UDP-Lite state records, and
vice versa.</t>
</section>
<section anchor='teredo' title='Teredo-specific Filters'>
<t>Transitional residential IPv6 gateways that also feature
integrated IPv4/NAT gateways require special filtering for Teredo
tunnels.</t>
<t>R18: Where an IPv6 prefix is advertised on an interior interface
alongside an IPv4 private address <xref target='RFC1918'/> and IPv4
Internet service is provided with NAT <xref target='RFC4787'/>, the
Teredo qualification procedure (see section 5.2.1 and 5.2.2 of
<xref target='RFC4380'/>) for clients in the interior MUST be
prohibited by the IPv4/NAT stateful filter. This SHOULD be done by
blocking outbound UDP initiations to port 3544, the port reserved by
IANA for Teredo servers. This MAY be done by discarding Teredo
packets identified by the heuristic defined in
<xref target='HOAGLAND'>"Teredo Security Concerns Beyond What Is In
RFC 4380"</xref>.</t>
<t>[ EDITOR: In the event <xref target='HOAGLAND'/> does not
advance to publication as an RFC, then that heuristic will be
reproduced here. ]</t>
</section>
<section anchor='ipsec' title='IPsec and Internet Key Exchange (IKE)'>
<t>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.</t>
<t>R19: 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
<xref target='RFC4302'>"Authenticated Header (AH)"</xref> in their
outer IP extension header chain.</t>
<t>R20: 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
<xref target='RFC4303'>"Encapsulating Security Payload (ESP)"</xref>
in their outer IP extension header chain.</t>
<t>R21: 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 <xref target='RFC4306'>Internet Key Exchange
Protocol</xref>.</t>
<t>R22: In all operating modes, IPv6 gateways SHOULD use filter
state records for <xref target='RFC4303'>Encapsulating Security
Payload (ESP)</xref> 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
<xref target='RFC4306'>Internet Key Exchange (IKE)</xref> initiations
SHOULD NOT be used.</t>
</section>
<section anchor='vpn' title='Other Virtual Private Network Protocols'>
<t>Residential IPv6 gateways are not expected to prohibit the use of
virtual private networks in residential usage scenarios.</t>
<t>R23: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding, to and from legitimate node addresses, with
upper layer protocol of type IP version 6, and SHOULD NOT prohibit
the forwarding of other tunneled networking protocols commonly used
for virtual private networking, e.g. IP version 4, Generic Routing
Encapsulation, etcetera.</t>
</section>
</section>
<section anchor='cots-filters' title='Connection-oriented Filters'>
<t>Most Internet applications use connection-oriented transport
protocols with orderly release semantics. These protocols include the
Transport Control Protocol (TCP) <xref target='RFC0793'/>, the Stream
Control Transmission Protocol (SCTP) <xref target='RFC4960'/>, the
Datagram Congestion Control Protocol (DCCP) <xref target='RFC4340'/>,
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.</t>
<section anchor='tcp-filter' title='TCP Filters'>
<t>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.</t>
<t>Peer-to-peer applications use an alternate method of connection
initiation termed simultaneous-open (Fig. 8, <xref
target='RFC0793'/>) 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.</t>
<t>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, <xref target='RFC0793'/>).</t>
<t>R24: All valid sequences of TCP packets (defined in <xref
target='RFC0793'/>) 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.</t>
<t>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.</t>
<t>R25: The TCP window invariant MUST NOT be enforced on connections
for which the filter did not detect whether the window-scale option
(see <xref target='RFC1323'/>) was sent in the 3-way handshake or
simultaneous open.</t>
<t>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 <xref
target='RFC4787'>"Network Address Translation (NAT) Behavioral
Requirements for Unicast UDP</xref> and extended in <xref
target='BEHAVE-TCP'>"NAT Behaviorial Requirements for
TCP"</xref>.</t>
<t>R26: 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.</t>
<t>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
<xref target='BEHAVE-TCP'/>, but the basic outcome of it is that
filters need to wait on signaling errors until simultaneous-open will
not be impaired.</t>
<t>R27: A gateway MUST NOT signal an error for an unsolicited inbound
SYN packet for at least 6 seconds after the packet is received. If
during this interval the gateway receives and forwards an outbound
SYN for the connection, then the gateway MUST discard the original
unsolicited inbound SYN packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of the
network administrator.</t>
<t>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.</t>
<t>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 <xref target='RFC1122'/> and
<xref target='RFC4294'/> can reduce the chances of abandoning a live
connection.</t>
<t>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 <xref target='RFC1122'/>.
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 <xref
target='RFC1122'/>.</t>
<t>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.</t>
<t>R28: 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. 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.</t>
<t>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. <xref target='RFC1337'/>
discusses hazards associated with TIME_WAIT assassination.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>R29: If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that
match the connection state record.</t>
<t>R30: Receipt of any sort of ICMP message MUST NOT terminate the
state record for a TCP connection.</t>
</section>
<section anchor='sctp-filter' title='SCTP Filters'>
<t>Because <xref target='RFC4960'>Stream Control Transmission
Protocol (SCTP)</xref> 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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, <xref target='RFC4960'/>).</t>
<t>R31: All valid sequences of SCTP packets (defined in <xref
target='RFC4960'/>) 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.</t>
<t>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.</t>
<t>R32: A gateway MUST NOT signal an error for an unsolicited inbound
INIT packet for at least 6 seconds after the packet is received. If
during this interval the gateway receives and forwards an outbound
INIT packet for the association, the the gateway MUST discard the
original unsolicited inbound INIT packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original INIT--
unless sending any response violates the security policy of the
network administrator.</t>
<t>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.</t>
<t>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 <xref target="RFC4294"/>
can reduce the chances of abandoning a live association.</t>
<t>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 <xref
target="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
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 <xref
target="RFC4960"/>).</t>
<t>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.</t>
<t>R33: 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.</t>
<t>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 <xref target="RFC1337"/>
regarding the hazards of TIME_WAIT assassination are relevant.</t>
<t>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.</t>
<t>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.</t>
<t>Several SCTP mechanisms depend on the reception of ICMP error
messages triggered by the transmission of SCTP packets.</t>
<t>R34: If a gateway forwards an SCTP association, it MUST also
forward ICMP Destination Unreachable messages containing SCTP headers
that match the association state record.</t>
<t>R35: Receipt of any sort of ICMP message MUST NOT terminate the
state record for an SCTP association.</t>
</section>
<section anchor='dccp-filter' title='DCCP Filters'>
<t>The connection semantics described in <xref
target='RFC4340'>Datagram Congestion Control Protocol
(DCCP)</xref> 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.</t>
<t>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, <xref target="RFC4340"/>).</t>
<t>R36: All valid sequences of DCCP packets (defined in <xref
target="RFC4340"/>) MUST be forwarded for all connections to exterior
servers and those connections to interior servers with explicitly
permitted service codes.</t>
<t>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 <xref
target="RFC4787">Network Address Translation (NAT) Behavioral
Requirements for Unicast UDP</xref> and extended in <xref
target="BEHAVE-TCP">NAT Behaviorial Requirements for TCP</xref>.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC4294"/>
can reduce the chances of abandoning a live connection.</t>
<t>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.</t>
<t>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.</t>
<t>R37: 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>R38: If a gateway forwards a DCCP connection, it MUST also forward
ICMP Destination Unreachable messages containing DCCP headers that
match the connection state record.</t>
<t>R39: Receipt of any sort of ICMP message MUST NOT terminate the
state record for a DCCP connection.</t>
</section>
</section>
<section anchor='app-listen' title='Passive Listeners'>
<t>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
<xref target='NAT-PMP'/> or <xref target='UPnP-IGD'/>.</t>
<t>One proposal that has been offered as an Internet Draft is the
<xref target='IPv6-ALD'>Application Listener Discovery Protocol</xref>.
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 <xref target='RFC3989'>Middlebox
Communication Protocol</xref> and the <xref target='RFC4080'>Next Steps
in Signaling framework</xref>. No consensus has yet emerged in the
Internet engineering community as to which proposal is most
appropriate for residential IPv6 usage scenarios.</t>
<t>R31: Gateways MUST 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. This protocol
MUST have a specification that meets the requirements of
<xref target='RFC3978'/>, <xref target='RFC3979'/> and
<xref target='RFC4748'/>.</t>
</section>
</section>
<section anchor="summary" title="Summary of Recommendations">
<t>This section collects all of the recommendations made in this
document into a convenient list.</t>
<t><list style='hanging'>
<t hangText='R1'>Packets bearing in their outer IPv6 headers multicast
source addresses MUST NOT be forwarded or transmitted on any
interface.</t>
<t hangText='R2'>Packets bearing in their outer IPv6 headers multicast
destination addresses of equal or narrower scope that 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.</t>
<t hangText='R3'>Packets bearing deprecated extension headers prior to
their first upper-layer-protocol header MUST NOT be forwarded or
transmitted on any interface. In particular, all packets with routing
extension header type 0 <xref target='RFC2460'/> preceding the first
upper-layer-protocol header MUST NOT be forwarded.</t>
<t hangText='R4'>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.</t>
<t hangText='R4'>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.</t>
<t hangText='R5'>Packets MAY be discarded if the source and/or
destination address in the outer IPv6 header is a unique local address.
By DEFAULT, gateways SHOULD NOT forward packets across unique local
address scope boundaries.</t>
<t hangText='R6'>By DEFAULT, inbound non-recursive DNS queries received
on exterior interfaces MUST NOT be processed by any integrated DNS
proxy resolving server.</t>
<t hangText='R7'>Inbound DHCP discovery packets received on exterior
interfaces MUST NOT be processed by any integrated DHCP server.</t>
<t hangText='R8'>Inbound packets not matching any existing filter state
record for a permitted transport flow MUST NOT be forwarded to the
interior network, and an ICMP Error message of type Administratively
Prohibited MUST be sent to the source address.</t>
<t hangText='R9'>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.</t>
<t hangText='R10'>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.</t>
<t hangText='R11'>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.</t>
<t hangText='R12'>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.</t>
<t hangText='R13'>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.</t>
<t hangText='R14'>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.</t>
<t hangText='R15'>If a gateway forwards a UDP exchange, it MUST also
forward ICMP Destination Unreachable messages containing UDP headers
that match the exchange state record.</t>
<t hangText='R16'>Receipt of any sort of ICMP message MUST NOT
terminate the state record for a UDP exchange.</t>
<t hangText='R17'>UDP-Lite exchanges <xref target='RFC3828'/> SHOULD be
handled in the same way as UDP exchanges, except that the upper-layer
transport protocol identifier for UDP-Lite is not the same as UDP,
and therefore UDP packets MUST NOT match UDP-Lite state records, and
vice versa.</t>
<t hangText='R18'>Where an IPv6 prefix is advertised on an interior
interface alongside an IPv4 private address <xref target='RFC1918'/>
and IPv4 Internet service is provided with NAT <xref
target='RFC4787'/>, the Teredo qualification procedure (see section
5.2.1 and 5.2.2 of <xref target='RFC4380'/>) for clients in the
interior MUST be prohibited by the IPv4/NAT stateful filter. This
SHOULD be done by blocking outbound UDP initiations to port 3544, the
port reserved by IANA for Teredo servers. This MAY be done by
discarding Teredo packets identified by the heuristic defined in
<xref target='HOAGLAND'>"Teredo Security Concerns Beyond What Is In
RFC 4380"</xref>.</t>
<t hangText='R19'>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
<xref target='RFC4302'>"Authenticated Header (AH)"</xref> in their
outer IP extension header chain.</t>
<t hangText='R20'>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
<xref target='RFC4303'>"Encapsulating Security Payload (ESP)"</xref>
in their outer IP extension header chain.</t>
<t hangText='R21'>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 <xref target='RFC4306'>Internet Key Exchange
Protocol</xref>.</t>
<t hangText='R22'>In their DEFAULT operating mode, IPv6 gateways MUST
NOT prohibit the forwarding, to and from legitimate node addresses,
with upper layer protocol of type IP version 6, and SHOULD NOT prohibit
the forwarding of other tunneled networking protocols commonly used
for virtual private networking, e.g. IP version 4, Generic Routing
Encapsulation, etcetera.</t>
<t hangText='R23'>In all operating modes, IPv6 gateways SHOULD use
filter state records for <xref target='RFC4303'>Encapsulating Security
Payload (ESP)</xref> 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
<xref target='RFC4306'>Internet Key Exchange (IKE)</xref> initiations
SHOULD NOT be used.</t>
<t hangText='R24'>All valid sequences of TCP packets (defined in <xref
target='RFC0793'/>) 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.</t>
<t hangText='R25'>The TCP window invariant MUST NOT be enforced on
connections for which the filter did not detect whether the
window-scale option (see <xref target='RFC1323'/>) was sent in the
3-way handshake or simultaneous open.</t>
<t hangText='R26'>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.</t>
<t hangText='R27'>A gateway MUST NOT signal an error for an unsolicited
inbound SYN packet for at least 6 seconds after the packet is received.
If during this interval the gateway receives and forwards an outbound
SYN for the connection, then the gateway MUST discard the original
unsolicited inbound SYN packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of network
administrator.</t>
<t hangText='R28'>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. 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.</t>
<t hangText='R29'>If a gateway forwards a TCP connection, it MUST also
forward ICMP Destination Unreachable messages containing TCP headers
that match the connection state record.</t>
<t hangText='R30'>Receipt of any sort of ICMP message MUST NOT
terminate the state record for a TCP connection.</t>
<t hangText='R31'>Gateways MUST 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.
This protocol MUST have a specification that meets the requirements of
<xref target='RFC3978'/>, <xref target='RFC3979'/> and
<xref target='RFC4748'/>.</t>
<t hangText='R33'>All valid sequences of SCTP packets (defined in <xref
target='RFC4960'/>) 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.</t>
<t hangText='R34'>A gateway MUST NOT signal an error for an unsolicited
inbound INIT packet for at least 6 seconds after the packet is
received. If during this interval the gateway receives and forwards an
outbound INIT packet for the association, the the gateway MUST discard
the original unsolicited inbound INIT packet without signaling an
error. Otherwise, the gateway SHOULD send an ICMP Destination
Unreachable error, code 1 (administratively prohibited) for the
original INIT-- unless sending any response violates the security
policy of the network administrator.</t>
<t hangText='R33'>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.</t>
<t hangText='R34'>If a gateway forwards an SCTP association, it MUST
also forward ICMP Destination Unreachable messages containing SCTP
headers that match the association state record.</t>
<t hangText='R35'>Receipt of any sort of ICMP message MUST NOT
terminate the state record for an SCTP association.</t>
<t hangText='R36'>All valid sequences of DCCP packets (defined in <xref
target="RFC4340"/>) MUST be forwarded for all connections to exterior
servers and those connections to interior servers with explicitly
permitted service codes.</t>
<t hangText='R37'>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.</t>
<t hangText='R38'>If a gateway forwards a DCCP connection, it MUST also
forward ICMP Destination Unreachable messages containing DCCP headers
that match the connection state record.</t>
<t hangText='R39'>Receipt of any sort of ICMP message MUST NOT
terminate the state record for a DCCP connection.</t>
</list></t>
</section>
<section anchor="contrib" title="Contributors">
<t>Comments and criticisms during the development of this document were
received from the following IETF participants:</t>
<t><list>
<t>Fred Baker</t>
<t>Norbert Bollow</t>
<t>Brian Carpenter</t>
<t>Jun-ichiro itojun Hagino</t>
<t>Thomas Herbst</t>
<t>Christian Huitema</t>
<t>Cullen Jennings</t>
<t>Suresh Krishnan</t>
<t>Erik Kline</t>
<t>Kurt Erik Lindqvist</t>
<t>Iljitsch van Beijnum</t>
<t>Yaron Sheffer</t>
<t>Dan Wing</t>
</list></t>
<t>Much of the text describing the detailed requirements for TCP and UDP
filtering is derived or transposed from <xref target='BEHAVE-TCP'/> and
<xref target='RFC4787'/>, and some form of attribution here may therefore
be appopriate.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>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-offce/home-office networks. As noted in the
security considerations section of <xref target='RFC2993'/>, the true
impact of these tools may be a reduction in security. It may be
generally assumed that the impacts discussed there related to
filtering (and not translation) are to be expected with the simple IPv6
security mechanisms described here.</t>
<t>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 <xref target='RFC4864'/> 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.</t>
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation
libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629;
here (as shown)
2. simply use a PI "less than character"?rfc
include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same directory as the including file. You can also define the
XML_LIBRARY environment variable with a value containing a set of
directories to search. These can be either in the local filing system or
remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC0768;
&RFC0793;
&RFC1323;
&RFC2119;
&RFC2460;
&RFC3828;
&RFC3978;
&RFC3979;
&RFC4302;
&RFC4303;
&RFC4306;
&RFC4340;
&RFC4380;
&RFC4748;
&RFC4787;
&RFC4960;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1122;
&RFC1337;
&RFC1918;
&RFC2993;
&RFC3989;
&RFC4080;
&RFC4294;
&RFC4864;
<reference anchor='BEHAVE-TCP'
target='http://tools.ietf.org/html/draft-ietf-behave-tcp'>
<front>
<title>NAT Behavioral Requirements for TCP</title>
<author initials='S.' surname='Guha'>
<organization abbrev='Cornell U.'>Cornell University</organization>
</author>
<author initials='K.' surname='Biswas'>
<organization abbrev='Cisco'>Cisco Systems</organization>
</author>
<author initials='S.' surname='Sivakumar'>
<organization abbrev='Cisco'>Cisco Systems</organization>
</author>
<author initials='B.' surname='Ford'>
<organization abbrev='M.I.T.'>
Massachusetts Institute of Technology
</organization>
</author>
<author initials='P.' surname='Srisuresh'>
<organization>Consultant</organization>
</author>
<date month='April' year='2007'/>
</front>
</reference>
<reference anchor='HOAGLAND'
target='http://tools.ietf.org/html/draft-hoagland-v6ops-teredosecconcerns'>
<front>
<title>Teredo Security Concerns Beyond What Is In RFC 4380</title>
<author initials='J.' surname='Hoagland'>
<organization abbrev='Symantec'>Symantec Corporation</organization>
</author>
<author initials='S.' surname='Krishnan'>
<organization abbrev='Ericsson'>Ericsson</organization>
</author>
<date month='July' year='2007'/>
</front>
</reference>
<reference anchor='IPv6-ALD'
target='http://tools.ietf.org/html/draft-woodyatt-ald'>
<front>
<title>Application Listener Discovery (ALD) for IPv6</title>
<author initials='j.h.' surname='Woodyatt'>
<organization abbrev='Apple'>Apple Inc.</organization>
</author>
<date month='May' year='2007'/>
</front>
</reference>
<reference anchor='NAT-PMP'
target='http://tools.ietf.org/html/draft-cheshire-nat-pmp'>
<front>
<title>NAT Port Mapping Protocol (NAT-PMP)</title>
<author initials='S.' surname='Cheshire'>
<organization abbrev='Apple'>Apple, Inc.</organization>
</author>
<author initials='M.' surname='Krochmal'>
<organization abbrev='Apple'>Apple, Inc.</organization>
</author>
<author initials='K.' surname='Sekar'>
<organization abbrev='Sharpcast'>Sharpcast, Inc.</organization>
</author>
<date month='November' year='2001'/>
</front>
</reference>
<reference anchor='UPnP-IGD'
target='http://www.upnp.org/standardizeddcps/igd.asp'>
<front>
<title>Universal Plug and Play Internet Gateway Device Standardized
Gateway Device Protocol</title>
<author fullname='UPnP Forum'>
<organization>UPnP Forum</organization>
</author>
<date month='September' year='2006'/>
</front>
</reference>
<!-- A reference written by by an organization not a person. -->
</references>
<!-- Change Log -->
<section anchor='changelog' title="Change Log">
<section title='draft-ietf-v6ops-cpe-simple-security-00 to
draft-ietf-v6ops-cpe-simple-security-01'>
<t><list style='symbols'>
<t>Added requirements for sequestering DHCP and DNS proxy resolver
services to the local network.</t>
<t>Fixed numbering of recommendations.</t>
<t>Local Network Protection is now <xref target='RFC4864'/>.</t>
<t>SCTP is now <xref target='RFC4960'/>.</t>
<t>Moved some references to informative.</t>
<t>Corrected the reference for <xref target='HOAGLAND'/>.</t>
</list></t>
</section>
<section title='draft-ietf-v6ops-cpe-simple-security-01 to
draft-ietf-v6ops-cpe-simple-security-02'>
<t><list style='symbols'>
<t>Inserted R20, i.e. do not enforce TCP window invariant unless the
TCP window-scale is known for the state.</t>
<t>Filled out <xref target='summary'/>.</t>
<t>Added reference to <xref target='RFC1323'/>.</t>
<t>Updated the reference for <xref target='HOAGLAND'/>.</t>
<t>Expanded list of contributers and commenters.</t>
<t>Mention that UDP-Lite should be handled just like UDP.</t>
<t>Added section for generic upper layer transport protocols.</t>
<t>Expanded on recommendations for IPsec ESP filtering.</t>
<t>Expanded overview of recommendations with discussion about IP
mobility and IPsec interactions.</t>
<t>Added a security considerations section.</t>
</list></t>
</section>
<section title='draft-ietf-v6ops-cpe-simple-security-02 to
draft-ietf-v6ops-cpe-simple-security-03'>
<t><list style='symbols'>
<t>Fixed some spelling errors.</t>
<t>Replace "prevent such attacks" with "defend against such attacks"
everywhere.</t>
<t>Replace "mapping" with "state record" in the TCP filters
section.</t>
<t>Added recommendations for SCTP and DCCP.</t>
</list></t>
</section>
</section>
<!-- Open Issues To Resolve
+ SCTP and DCCP section are unwritten.
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:22:44 |