draft-ietf-v6ops-cpe-simple-security-13.txt   draft-ietf-v6ops-cpe-simple-security-14.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Informational September 28, 2010 Intended status: Informational September 29, 2010
Expires: April 1, 2011 Expires: April 2, 2011
Recommended Simple Security Capabilities in Customer Premises Equipment Recommended Simple Security Capabilities in Customer Premises Equipment
for Providing Residential IPv6 Internet Service for Providing Residential IPv6 Internet Service
draft-ietf-v6ops-cpe-simple-security-13 draft-ietf-v6ops-cpe-simple-security-14
Abstract Abstract
This document identifies a set of recommendations for the makers of This document identifies a set of recommendations for the makers of
devices describing how to provide for "simple security" capabilities devices describing how to provide for "simple security" capabilities
at the perimeter of local-area IPv6 networks in Internet-enabled at the perimeter of local-area IPv6 networks in Internet-enabled
homes and small offices. homes and small offices.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 1, 2011. This Internet-Draft will expire on April 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8
3.2.1. Internet Control and Management . . . . . . . . . . . 8 3.2.1. Internet Control and Management . . . . . . . . . . . 8
3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8 3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8
3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 9
3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10
3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 11 3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 11
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 21 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22
3.5. Management Applications . . . . . . . . . . . . . . . . . 22 3.5. Management Applications . . . . . . . . . . . . . . . . . 23
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
skipping to change at page 3, line 51 skipping to change at page 3, line 51
document as pertaining to a configuration as applied by a vendor, document as pertaining to a configuration as applied by a vendor,
prior to the administrator changing it for its initial activation. prior to the administrator changing it for its initial activation.
1.2. Use of Normative Keywords 1.2. Use of Normative Keywords
NOTE WELL: This document is not a standard, and conformance with it NOTE WELL: This document is not a standard, and conformance with it
is not required in order to claim conformance with IETF standards for is not required in order to claim conformance with IETF standards for
IPv6. It uses the normative keywords defined in the previous section IPv6. It uses the normative keywords defined in the previous section
only for precision. only for precision.
Particular attention is drawn to recommendation REC-46, which calls Particular attention is drawn to recommendation REC-47, which calls
for an easy way to set a gateway to a transparent mode of operation. for an easy way to set a gateway to a transparent mode of operation.
2. Overview 2. Overview
For the purposes of this document, residential Internet gateways are For the purposes of this document, residential Internet gateways are
assumed to be fairly simple devices with a limited subset of the full assumed to be fairly simple devices with a limited subset of the full
range of possible features. They function as default routers range of possible features. They function as default routers
[RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi [RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi
network, a bridge between two or more such segments. They have only network, a bridge between two or more such segments. They have only
one interface by which they can access the Internet service at any one interface by which they can access the Internet service at any
skipping to change at page 12, line 27 skipping to change at page 12, line 27
REC-26: The state records for flows initiated by outbound packets REC-26: The state records for flows initiated by outbound packets
that bear a Home Address destination option [RFC3775] are that bear a Home Address destination option [RFC3775] are
distinguished by the addition of the home address of the flow as well 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 as the interior care-of address. IPv6 gateways MUST NOT prohibit the
forwarding of any inbound packets bearing type 2 routing headers, forwarding of any inbound packets bearing type 2 routing headers,
which otherwise match a flow state record, and where A) the address which otherwise match a flow state record, and where A) the address
in the destination field of the IPv6 header matches the interior 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 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. Type 2 Routing Header matches the home address of the flow.
REC-27: If a gateway forwards a Mobility Header [RFC3775] flow, then REC-27: Valid sequences of Mobility Header [RFC3775] packets MUST be
forwarded for all outbound and explicitly permitted inbound Mobility
Header flows.
REC-28: If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward, in both directions, the IPv4 and IPv6 packets it MUST also forward, in both directions, the IPv4 and IPv6 packets
that are encapsulated in IPv6 associated with the tunnel between the that are encapsulated in IPv6 associated with the tunnel between the
home agent and the correspondent node. home agent and the correspondent node.
REC-28: If a gateway forwards a Mobility Header [RFC3775] flow, then REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward (in the reverse direction) ICMPv6 "Destination it MUST also forward (in the reverse direction) ICMPv6 "Destination
Unreachable" and "Packet Too Big" messages containing any headers Unreachable" and "Packet Too Big" messages containing any headers
that match the associated flow state records. that match the associated flow state records.
3.3. Connection-oriented Filters 3.3. Connection-oriented Filters
Most Internet applications use connection-oriented transport Most Internet applications use connection-oriented transport
protocols with orderly release semantics. These protocols include protocols with orderly release semantics. These protocols include
TCP, SCTP, DCCP, and potentially any future IETF standards-track TCP, SCTP, DCCP, and potentially any future IETF standards-track
transport protocols that use such semantics. Stateful packet filters transport protocols that use such semantics. Stateful packet filters
skipping to change at page 13, line 22 skipping to change at page 13, line 27
in the network. Upon receiving the other end's SYN packet, each end 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 responds with a SYN-ACK packet, which also cross in the network. The
connection is established at each endpoint once the SYN-ACK packets connection is established at each endpoint once the SYN-ACK packets
are received. are received.
To provide stateful packet filtering service for TCP, it is necessary To provide stateful packet filtering service for TCP, it is necessary
for a filter to receive, process and forward all packets for a flow for a filter to receive, process and forward all packets for a flow
that conform to valid transitions of the TCP state machine (Fig. 6, that conform to valid transitions of the TCP state machine (Fig. 6,
[RFC0793]). [RFC0793]).
REC-29: All valid sequences of TCP packets (defined in [RFC0793]) REC-30: All valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound flows and explicitly permitted inbound MUST be forwarded for outbound flows and explicitly permitted inbound
flows. In particular, both the normal TCP 3-way handshake mode of flows. In particular, both the normal TCP 3-way handshake mode of
operation and the simultaneous-open modes of operation MUST be operation and the simultaneous-open modes of operation MUST be
supported. supported.
It is possible to reconstruct enough of the state of a TCP flow to It is possible to reconstruct enough of the state of a TCP flow to
allow forwarding between an interior and exterior node even when the allow forwarding between an interior and exterior node even when the
filter starts operating after TCP enters the established state. In filter starts operating after TCP enters the established state. In
this case, because the filter has not seen the TCP window-scale this case, because the filter has not seen the TCP window-scale
option, it is not possible for the filter to enforce the TCP window option, it is not possible for the filter to enforce the TCP window
invariant by dropping out-of-window segments. invariant by dropping out-of-window segments.
REC-30: The TCP window invariant MUST NOT be enforced on flows for REC-31: The TCP window invariant MUST NOT be enforced on flows for
which the filter did not detect whether the window-scale option (see which the filter did not detect whether the window-scale option (see
[RFC1323]) was sent in the 3-way handshake or simultaneous open. [RFC1323]) was sent in the 3-way handshake or simultaneous open.
A stateful filter can allow an existing state record to be reused by A stateful filter can allow an existing state record to be reused by
an externally initiated flow if its security policy permits. Several an externally initiated flow if its security policy permits. Several
different policies are possible as described in [RFC4787] and different policies are possible as described in [RFC4787] and
extended in [RFC5382]. extended in [RFC5382].
REC-31: If application transparency is most important, then a REC-32: If application transparency is most important, then a
stateful packet filter SHOULD have "Endpoint independent filter" stateful packet filter SHOULD have "Endpoint independent filter"
behavior for TCP. If a more stringent filtering behavior is most behavior for TCP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "Address dependent filtering" important, then a filter SHOULD have "Address dependent filtering"
behavior. The filtering behavior MAY be an option configurable by behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the filtering the network administrator, and it MAY be independent of the filtering
behavior for UDP and other protocols. Filtering behavior SHOULD be behavior for UDP and other protocols. Filtering behavior SHOULD be
endpoint independent by DEFAULT in gateways intended for provisioning endpoint independent by DEFAULT in gateways intended for provisioning
without service-provider management. without service-provider management.
If an inbound SYN packet is filtered, either because a corresponding If an inbound SYN packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error silently, or to signal an error to the sender. Signaling an error
through ICMPv6 messages allows the sender to detect that the SYN did through ICMPv6 messages allows the sender to detect that the SYN did
not reach the intended destination. Discarding the packet, on the not reach the intended destination. Discarding the packet, on the
other hand, allows applications to perform simultaneous-open more other hand, allows applications to perform simultaneous-open more
reliably. A more detailed discussion of this issue can be found in reliably. A more detailed discussion of this issue can be found in
[RFC5382], but the basic outcome of it is that filters need to wait [RFC5382], but the basic outcome of it is that filters need to wait
on signaling errors until simultaneous-open will not be impaired. on signaling errors until simultaneous-open will not be impaired.
REC-32: By DEFAULT, a gateway MUST respond with an ICMPv6 REC-33: By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively prohibited) "Destination Unreachable" error code 1 (administratively prohibited)
to any unsolicited inbound SYN packet after waiting at least 6 to any unsolicited inbound SYN packet after waiting at least 6
seconds without first forwarding the associated outbound SYN or SYN/ seconds without first forwarding the associated outbound SYN or SYN/
ACK from the interior peer. ACK from the interior peer.
A TCP filter maintains state associated with in-progress connections A TCP filter maintains state associated with in-progress connections
and established flows. Because of this, a filter is susceptible to a and established flows. Because of this, a filter is susceptible to a
resource-exhaustion attack whereby an attacker (or virus) on the resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter creating state records. To defend against such attacks, a filter
skipping to change at page 15, line 17 skipping to change at page 15, line 21
The "established flow idle-timeout" for a stateful packet filter is The "established flow idle-timeout" for a stateful packet filter is
defined as the minimum time a TCP flow in the established phase must defined as the minimum time a TCP flow in the established phase must
remain idle before the filter considers the associated state record a remain idle before the filter considers the associated state record a
candidate for collection. The "transitory flow idle-timeout" for a candidate for collection. The "transitory flow idle-timeout" for a
filter is defined as the minimum time a TCP flow in the partially- filter is defined as the minimum time a TCP flow in the partially-
open or closing phases must remain idle before the filter considers open or closing phases must remain idle before the filter considers
the associated state record a candidate for collection. TCP flows in the associated state record a candidate for collection. TCP flows in
the TIME_WAIT state are not affected by the "transitory flow idle- the TIME_WAIT state are not affected by the "transitory flow idle-
timeout" parameter. timeout" parameter.
REC-33: If a gateway cannot determine whether the endpoints of a TCP REC-34: 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 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 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 flow idle-timeout" MUST NOT be less than two hours four minutes, as
discussed in [RFC5382]. The value of the "transitory flow idle- discussed in [RFC5382]. The value of the "transitory flow idle-
timeout" MUST NOT be less than four minutes. The value of the idle- timeout" MUST NOT be less than four minutes. The value of the idle-
timeouts MAY be configurable by the network administrator. timeouts MAY be configurable by the network administrator.
Behavior for handing RST packets, or TCP flows in the TIME_WAIT state Behavior for handing RST packets, or TCP flows in the TIME_WAIT state
is left unspecified. A gateway MAY hold state for a flow in is left unspecified. A gateway MAY hold state for a flow in
TIME_WAIT state to accommodate retransmissions of the last ACK. TIME_WAIT state to accommodate retransmissions of the last ACK.
skipping to change at page 16, line 7 skipping to change at page 16, line 11
endpoint on behalf of the other. Sending a RST notification allows endpoint on behalf of the other. Sending a RST notification allows
endpoint applications to recover more quickly, however, notifying endpoint applications to recover more quickly, however, notifying
endpoints might not always be possible if, for example, state records endpoints might not always be possible if, for example, state records
are lost due to power interruption. are lost due to power interruption.
Several TCP mechanisms depend on the reception of ICMPv6 error Several TCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of TCP segments. One such messages triggered by the transmission of TCP segments. One such
mechanism is path MTU discovery, which is required for correct mechanism is path MTU discovery, which is required for correct
operation of TCP. operation of TCP.
REC-34: If a gateway forwards a TCP flow, it MUST also forward ICMPv6 REC-35: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing "Destination Unreachable" and "Packet Too Big" messages containing
TCP headers that match the flow state record. TCP headers that match the flow state record.
REC-35: Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-36: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP flow. state record for a TCP flow.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows
can be terminated at multiple network addresses, IPv6 simple security can be terminated at multiple network addresses, IPv6 simple security
functions cannot achieve full transparency for SCTP applications. In functions cannot achieve full transparency for SCTP applications. In
multipath traversal scenarios, full transparency requires multipath traversal scenarios, full transparency requires
coordination between all the packet filter processes in the various coordination between all the packet filter processes in the various
paths between the endpoint network addresses. Such coordination is paths between the endpoint network addresses. Such coordination is
skipping to change at page 17, line 10 skipping to change at page 17, line 13
of the peers in simultaneous-open mode of operation will send an of the peers in simultaneous-open mode of operation will send an
ERROR or ABORT chunk along with the INIT-ACK chunk. The association ERROR or ABORT chunk along with the INIT-ACK chunk. The association
is established at each endpoint once an INIT-ACK chunks is received is established at each endpoint once an INIT-ACK chunks is received
at one end without an ERROR or ABORT chunk. at one end without an ERROR or ABORT chunk.
To provide stateful packet filtering service for SCTP, it is To provide stateful packet filtering service for SCTP, it is
necessary for a filter to receive, process and forward all packets necessary for a filter to receive, process and forward all packets
for an association that conform to valid transitions of the SCTP for an association that conform to valid transitions of the SCTP
state machine (Fig. 3, [RFC4960]). state machine (Fig. 3, [RFC4960]).
REC-36: All valid sequences of SCTP packets (defined in [RFC4960]) REC-37: All valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly permitted MUST be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP inbound associations. In particular, both the normal SCTP
association establishment and simultaneous-open modes of operation association establishment and simultaneous-open modes of operation
MUST be supported. MUST be supported.
If an inbound INIT packet is filtered, either because a corresponding If an inbound INIT packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error silently, or to signal an error to the sender. Signaling an error
through ICMPv6 messages allows the sender to detect that the INIT through ICMPv6 messages allows the sender to detect that the INIT
packet did not reach the intended destination. Discarding the packet did not reach the intended destination. Discarding the
packet, on the other hand, allows applications to perform packet, on the other hand, allows applications to perform
simultaneous-open more reliably. Delays in signaling errors can simultaneous-open more reliably. Delays in signaling errors can
prevent the impairment of simultaneous-open mode of operation. prevent the impairment of simultaneous-open mode of operation.
REC-37: By DEFAULT, a gateway MUST respond with an ICMPv6 REC-38: By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively prohibited), "Destination Unreachable" error code 1 (administratively prohibited),
to any unsolicited inbound INIT packet after waiting at least 6 to any unsolicited inbound INIT packet after waiting at least 6
seconds without first forwarding the associated outbound INIT from seconds without first forwarding the associated outbound INIT from
the interior peer. the interior peer.
An SCTP filter maintains state associated with in-progress and An SCTP filter maintains state associated with in-progress and
established associations. Because of this, a filter is susceptible established associations. Because of this, a filter is susceptible
to a resource-exhaustion attack whereby an attacker (or virus) on the to a resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter creating state records. To defend against such attacks, a filter
skipping to change at page 18, line 26 skipping to change at page 18, line 30
The "established association idle-timeout" for a stateful packet The "established association idle-timeout" for a stateful packet
filter is defined as the minimum time an SCTP association in the filter is defined as the minimum time an SCTP association in the
established phase must remain idle before the filter considers the established phase must remain idle before the filter considers the
corresponding state record a candidate for collection. The corresponding state record a candidate for collection. The
"transitory association idle-timeout" for a filter is defined as the "transitory association idle-timeout" for a filter is defined as the
minimum time an SCTP association in the partially-open or closing minimum time an SCTP association in the partially-open or closing
phases must remain idle before the filter considers the corresponding phases must remain idle before the filter considers the corresponding
state record a candidate for collection. state record a candidate for collection.
REC-38: If a gateway cannot determine whether the endpoints of an REC-39: If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state record if SCTP association are active, then it MAY abandon the state record if
it has been idle for some time. In such cases, the value of the it has been idle for some time. In such cases, the value of the
"established association idle-timeout" MUST NOT be less than two "established association idle-timeout" MUST NOT be less than two
hours four minutes. The value of the "transitory association idle- hours four minutes. The value of the "transitory association idle-
timeout" MUST NOT be less than four minutes. The value of the idle- timeout" MUST NOT be less than four minutes. The value of the idle-
timeouts MAY be configurable by the network administrator. timeouts MAY be configurable by the network administrator.
Behavior for handling ERROR and ABORT packets is left unspecified. A Behavior for handling ERROR and ABORT packets is left unspecified. A
gateway MAY hold state for an association after its closing phases gateway MAY hold state for an association after its closing phases
have completed to accommodate retransmissions of its final SHUTDOWN have completed to accommodate retransmissions of its final SHUTDOWN
skipping to change at page 19, line 12 skipping to change at page 19, line 17
left unspecified. When a gateway abandons a live association, for left unspecified. When a gateway abandons a live association, for
example due to a timeout expiring, the filter MAY send an ABORT example due to a timeout expiring, the filter MAY send an ABORT
packet to each endpoint on behalf of the other. Sending an ABORT packet to each endpoint on behalf of the other. Sending an ABORT
notification allows endpoint applications to recover more quickly, notification allows endpoint applications to recover more quickly,
however, notifying endpoints might not always be possible if, for however, notifying endpoints might not always be possible if, for
example, state records are lost due to power interruption. example, state records are lost due to power interruption.
Several SCTP mechanisms depend on the reception of ICMPv6 error Several SCTP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of SCTP packets. messages triggered by the transmission of SCTP packets.
REC-39: If a gateway forwards an SCTP association, it MUST also REC-40: If a gateway forwards an SCTP association, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing SCTP headers that match the association state messages containing SCTP headers that match the association state
record. record.
REC-40: Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-41: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for an SCTP association. state record for an SCTP association.
3.3.3. DCCP Filters 3.3.3. DCCP Filters
The connection semantics described in Datagram Congestion Control The connection semantics described in Datagram Congestion Control
Protocol (DCCP) [RFC4340] are very similar to those of TCP. An Protocol (DCCP) [RFC4340] are very similar to those of TCP. An
interior endpoint initiates a DCCP flow through a stateful packet interior endpoint initiates a DCCP flow through a stateful packet
filter by sending a DCCP-Request packet. Simultaneous open is not filter by sending a DCCP-Request packet. Simultaneous open is not
defined for DCCP. defined for DCCP.
In order to provide stateful packet filtering service for DCCP, it is In order to provide stateful packet filtering service for DCCP, it is
necessary for a filter to receive, process and forward all packets necessary for a filter to receive, process and forward all packets
for a flow that conform to valid transitions of the DCCP state for a flow that conform to valid transitions of the DCCP state
machine (Section 8, [RFC4340]). machine (Section 8, [RFC4340]).
REC-41: All valid sequences of DCCP packets (defined in [RFC4340]) REC-42: All valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all flows to exterior servers and those flows MUST be forwarded for all flows to exterior servers and those flows
to interior servers with explicitly permitted service codes. to interior servers with explicitly permitted service codes.
It is possible to reconstruct enough of the state of a DCCP flow to It is possible to reconstruct enough of the state of a DCCP flow to
allow forwarding between an interior and exterior node even when the allow forwarding between an interior and exterior node even when the
filter starts operating after DCCP enters the OPEN state. Also, a filter starts operating after DCCP enters the OPEN state. Also, a
filter can allow an existing state record to be reused by an filter can allow an existing state record to be reused by an
externally initiated flow if its security policy permits. As with externally initiated flow if its security policy permits. As with
TCP, several different policies are possible, with a good discussion TCP, several different policies are possible, with a good discussion
of the issue involved presented in [RFC4787] and extended in of the issue involved presented in [RFC4787] and extended in
skipping to change at page 20, line 39 skipping to change at page 20, line 44
The "open flow idle-timeout" for a stateful packet filter is defined The "open flow idle-timeout" for a stateful packet filter is defined
as the minimum time a DCCP flow in the open state must remain idle as the minimum time a DCCP flow in the open state must remain idle
before the filter considers the associated state record a candidate before the filter considers the associated state record a candidate
for collection. The "transitory flow idle-timeout" for a filter is for collection. The "transitory flow idle-timeout" for a filter is
defined as the minimum time a DCCP flow in the partially-open or defined as the minimum time a DCCP flow in the partially-open or
closing phases must remain idle before the filter considers the closing phases must remain idle before the filter considers the
associated state record a candidate for collection. DCCP flows in associated state record a candidate for collection. DCCP flows in
the TIMEWAIT state are not affected by the "transitory flow idle- the TIMEWAIT state are not affected by the "transitory flow idle-
timeout" parameter. timeout" parameter.
REC-42: A gateway MAY abandon a DCCP state record if it has been idle REC-43: A gateway MAY abandon a DCCP state record if it has been idle
for some time. In such cases, the value of the "established flow for some time. In such cases, the value of the "established flow
idle-timeout" MUST NOT be less than two hours four minutes. The idle-timeout" MUST NOT be less than two hours four minutes. The
value of the "transitory flow idle-timeout" MUST NOT be less than value of the "transitory flow idle-timeout" MUST NOT be less than
eight minutes. The value of the idle-timeouts MAY be configurable by eight minutes. The value of the idle-timeouts MAY be configurable by
the network administrator. the network administrator.
Behavior for handing DCCP-Reset packets, or flows in the TIMEWAIT Behavior for handing DCCP-Reset packets, or flows in the TIMEWAIT
state is left unspecified. A gateway MAY hold state for a flow in state is left unspecified. A gateway MAY hold state for a flow in
TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset. TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset.
However, since the TIMEWAIT state is commonly encountered by interior However, since the TIMEWAIT state is commonly encountered by interior
skipping to change at page 21, line 28 skipping to change at page 21, line 33
endpoint on behalf of the other. Sending a DCCP-Reset notification endpoint on behalf of the other. Sending a DCCP-Reset notification
allows endpoint applications to recover more quickly, however, allows endpoint applications to recover more quickly, however,
notifying endpoints might not always be possible if, for example, notifying endpoints might not always be possible if, for example,
state records are lost due to power interruption. state records are lost due to power interruption.
Several DCCP mechanisms depend on the reception of ICMPv6 error Several DCCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of DCCP packets. One such messages triggered by the transmission of DCCP packets. One such
mechanism is path MTU discovery, which is required for correct mechanism is path MTU discovery, which is required for correct
operation. operation.
REC-43: If an Internet gateway forwards a DCCP flow, it MUST also REC-44: If an Internet gateway forwards a DCCP flow, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing DCCP headers that match the flow state record. messages containing DCCP headers that match the flow state record.
REC-44: Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-45: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a DCCP flow. state record for a DCCP flow.
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6)
IPv6 simple security is applicable to residential networks with only IPv6 simple security is applicable to residential networks with only
one Internet service provider at a time. The use of Level 3 one Internet service provider at a time. The use of Level 3
Multihoming Shim Protocol for IPv6 (SHIM6) [RFC5533] as a site multi- Multihoming Shim Protocol for IPv6 (SHIM6) [RFC5533] as a site multi-
homing solution is not generally compatible with IPv6 simple homing solution is not generally compatible with IPv6 simple
security. No special recommendations with regard to SHIM6 are made security. No special recommendations with regard to SHIM6 are made
in this document. in this document.
skipping to change at page 22, line 28 skipping to change at page 22, line 37
One proposal that has been offered as an Internet Draft is the One proposal that has been offered as an Internet Draft is the
Application Listener Discovery Protocol [I-D.woodyatt-ald]. It Application Listener Discovery Protocol [I-D.woodyatt-ald]. It
remains to be seen whether the Internet Gateway Device profile of the remains to be seen whether the Internet Gateway Device profile of the
Universal Plug And Play protocol will be extended for IPv6. Other Universal Plug And Play protocol will be extended for IPv6. Other
proposals of note include the Middlebox Communication Protocol proposals of note include the Middlebox Communication Protocol
[RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until [RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until
a consensus emerges around a specific method, the following a consensus emerges around a specific method, the following
recommendations are the best guidance available. recommendations are the best guidance available.
REC-45: Internet gateways with IPv6 simple security capabilities REC-46: Internet gateways with IPv6 simple security capabilities
SHOULD implement a protocol to permit applications to solicit inbound SHOULD implement a protocol to permit applications to solicit inbound
traffic without advance knowledge of the addresses of exterior nodes traffic without advance knowledge of the addresses of exterior nodes
with which they expect to communicate. with which they expect to communicate.
REC-46: Internet gateways with IPv6 simple security capabilities MUST REC-47: Internet gateways with IPv6 simple security capabilities MUST
provide an easily selected configuration option that permits a provide an easily selected configuration option that permits a
"transparent mode" of operation that forwards all unsolicited flows "transparent mode" of operation that forwards all unsolicited flows
regardless of forwarding direction, i.e. not to use the IPv6 simple regardless of forwarding direction, i.e. not to use the IPv6 simple
security capabilities of the gateway. The transparent mode of security capabilities of the gateway. The transparent mode of
operation MAY be the default configuration. operation MAY be the default configuration.
In general, "transparent mode" will enable more flexibility and In general, "transparent mode" will enable more flexibility and
reliability for applications which require devices to be contacted reliability for applications which require devices to be contacted
inside the home directly, particularly in absence of a protocol as inside the home directly, particularly in absence of a protocol as
described in REC-45. Operating in transparent mode may come at the described in REC-46. Operating in transparent mode may come at the
expense of security if there are IPv6 nodes in the home that do not expense of security if there are IPv6 nodes in the home that do not
have their own host-based firewall capability and require a firewall have their own host-based firewall capability and require a firewall
in the gateway in order not to be compromised. in the gateway in order not to be compromised.
3.5. Management Applications 3.5. Management Applications
Subscriber managed residential gateways are unlikely ever to be Subscriber managed residential gateways are unlikely ever to be
completely zero-configuration, but their administrators will very completely zero-configuration, but their administrators will very
often possess no particular expertise in Internet engineering. In often possess no particular expertise in Internet engineering. In
general, the specification of management interfaces for residential general, the specification of management interfaces for residential
gateways is out of scope for this document, but security of gateways is out of scope for this document, but security of
subscriber managed gateways merit special attention here. subscriber managed gateways merit special attention here.
REC-47: By DEFAULT, subscriber managed residential gateways MUST NOT REC-48: By DEFAULT, subscriber managed residential gateways MUST NOT
offer management application services to the exterior network. offer management application services to the exterior network.
4. Summary of Recommendations 4. Summary of Recommendations
This section collects all of the recommendations made in this This section collects all of the recommendations made in this
document into a convenient list. document into a convenient list.
REC-1 Packets bearing in their outer IPv6 headers multicast source REC-1 Packets bearing in their outer IPv6 headers multicast source
addresses MUST NOT be forwarded or transmitted on any addresses MUST NOT be forwarded or transmitted on any
interface. interface.
skipping to change at page 26, line 43 skipping to change at page 26, line 49
that bear a Home Address destination option [RFC3775] are that bear a Home Address destination option [RFC3775] are
distinguished by the addition of the home address of the flow distinguished by the addition of the home address of the flow
as well as the interior care-of address. IPv6 gateways MUST as well as the interior care-of address. IPv6 gateways MUST
NOT prohibit the forwarding of any inbound packets bearing NOT prohibit the forwarding of any inbound packets bearing
type 2 routing headers, which otherwise match a flow state type 2 routing headers, which otherwise match a flow state
record, and where A) the address in the destination field of record, and where A) the address in the destination field of
the IPv6 header matches the interior care-of address of the the IPv6 header matches the interior care-of address of the
flow, and B) the Home Address field in the Type 2 Routing flow, and B) the Home Address field in the Type 2 Routing
Header matches the home address of the flow. Header matches the home address of the flow.
REC-27 If a gateway forwards a Mobility Header [RFC3775] flow, then REC-27 Valid sequences of Mobility Header [RFC3775] packets MUST be
forwarded for all outbound and explicitly permitted inbound
Mobility Header flows.
REC-28 If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward, in both directions, the IPv4 and IPv6 it MUST also forward, in both directions, the IPv4 and IPv6
packets that are encapsulated in IPv6 associated with the packets that are encapsulated in IPv6 associated with the
tunnel between the home agent and the correspondent node. tunnel between the home agent and the correspondent node.
REC-28 If a gateway forwards a Mobility Header [RFC3775] flow, then REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward (in the reverse direction) ICMPv6 it MUST also forward (in the reverse direction) ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing any headers that match the associated flow state containing any headers that match the associated flow state
records. records.
REC-29 All valid sequences of TCP packets (defined in [RFC0793]) REC-30 All valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound flows and explicitly permitted MUST be forwarded for outbound flows and explicitly permitted
inbound flows. In particular, both the normal TCP 3-way inbound flows. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes handshake mode of operation and the simultaneous-open modes
of operation MUST be supported. of operation MUST be supported.
REC-30 The TCP window invariant MUST NOT be enforced on flows for REC-31 The TCP window invariant MUST NOT be enforced on flows for
which the filter did not detect whether the window-scale which the filter did not detect whether the window-scale
option (see [RFC1323]) was sent in the 3-way handshake or option (see [RFC1323]) was sent in the 3-way handshake or
simultaneous open. simultaneous open.
REC-31 If application transparency is most important, then a REC-32 If application transparency is most important, then a
stateful packet filter SHOULD have "Endpoint independent stateful packet filter SHOULD have "Endpoint independent
filter" behavior for TCP. If a more stringent filtering filter" behavior for TCP. If a more stringent filtering
behavior is most important, then a filter SHOULD have behavior is most important, then a filter SHOULD have
"Address dependent filtering" behavior. The filtering "Address dependent filtering" behavior. The filtering
behavior MAY be an option configurable by the network behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering administrator, and it MAY be independent of the filtering
behavior for UDP and other protocols. Filtering behavior behavior for UDP and other protocols. Filtering behavior
SHOULD be endpoint independent by DEFAULT in gateways SHOULD be endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider intended for provisioning without service-provider
management. management.
REC-32 By DEFAULT, a gateway MUST respond with an ICMPv6 REC-33 By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively "Destination Unreachable" error code 1 (administratively
prohibited) to any unsolicited inbound SYN packet after prohibited) to any unsolicited inbound SYN packet after
waiting at least 6 seconds without first forwarding the waiting at least 6 seconds without first forwarding the
associated outbound SYN or SYN/ACK from the interior peer. associated outbound SYN or SYN/ACK from the interior peer.
REC-33 If a gateway cannot determine whether the endpoints of a TCP REC-34 If a gateway cannot determine whether the endpoints of a TCP
flow are active, then it MAY abandon the state record if it 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 has been idle for some time. In such cases, the value of the
"established flow idle-timeout" MUST NOT be less than two "established flow idle-timeout" MUST NOT be less than two
hours four minutes, as discussed in [RFC5382]. The value of hours four minutes, as discussed in [RFC5382]. The value of
the "transitory flow idle-timeout" MUST NOT be less than four the "transitory flow idle-timeout" MUST NOT be less than four
minutes. The value of the idle-timeouts MAY be configurable minutes. The value of the idle-timeouts MAY be configurable
by the network administrator. by the network administrator.
REC-34 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 REC-35 If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing TCP headers that match the flow state record. containing TCP headers that match the flow state record.
REC-35 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-36 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP flow. state record for a TCP flow.
REC-36 All valid sequences of SCTP packets (defined in [RFC4960]) REC-37 All valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly MUST be forwarded for outbound associations and explicitly
permitted inbound associations. In particular, both the permitted inbound associations. In particular, both the
normal SCTP association establishment and simultaneous-open normal SCTP association establishment and simultaneous-open
modes of operation MUST be supported. modes of operation MUST be supported.
REC-37 By DEFAULT, a gateway MUST respond with an ICMPv6 REC-38 By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively "Destination Unreachable" error code 1 (administratively
prohibited) to any unsolicited inbound INIT packet after prohibited) to any unsolicited inbound INIT packet after
waiting at least 6 seconds without first forwarding the waiting at least 6 seconds without first forwarding the
associated outbound INIT from the interior peer. associated outbound INIT from the interior peer.
REC-38 If a gateway cannot determine whether the endpoints of an REC-39 If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state SCTP association are active, then it MAY abandon the state
record if it has been idle for some time. In such cases, the record if it has been idle for some time. In such cases, the
value of the "established association idle-timeout" MUST NOT value of the "established association idle-timeout" MUST NOT
be less than two hours four minutes. The value of the be less than two hours four minutes. The value of the
"transitory association idle-timeout" MUST NOT be less than "transitory association idle-timeout" MUST NOT be less than
four minutes. The value of the idle-timeouts MAY be four minutes. The value of the idle-timeouts MAY be
configurable by the network administrator. configurable by the network administrator.
REC-39 If a gateway forwards an SCTP association, it MUST also REC-40 If a gateway forwards an SCTP association, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing SCTP headers that match the association messages containing SCTP headers that match the association
state record. state record.
REC-40 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-41 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for an SCTP association. state record for an SCTP association.
REC-41 All valid sequences of DCCP packets (defined in [RFC4340]) REC-42 All valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all flows to exterior servers and those MUST be forwarded for all flows to exterior servers and those
flows to interior servers with explicitly permitted service flows to interior servers with explicitly permitted service
codes. codes.
REC-42 A gateway MAY abandon a DCCP state record if it has been idle REC-43 A gateway MAY abandon a DCCP state record if it has been idle
for some time. In such cases, the value of the "established for some time. In such cases, the value of the "established
flow idle-timeout" MUST NOT be less than two hours four flow idle-timeout" MUST NOT be less than two hours four
minutes. The value of the "transitory flow idle-timeout" minutes. The value of the "transitory flow idle-timeout"
MUST NOT be less than eight minutes. The value of the idle- MUST NOT be less than eight minutes. The value of the idle-
timeouts MAY be configurable by the network administrator. timeouts MAY be configurable by the network administrator.
REC-43 If a gateway forwards a DCCP flow, it MUST also forward REC-44 If a gateway forwards a DCCP flow, it MUST also forward
ICMPv6 "Destination Unreachable" and "Packet Too Big" ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing DCCP headers that match the flow state messages containing DCCP headers that match the flow state
record. record.
REC-44 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-45 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a DCCP flow. state record for a DCCP flow.
REC-45 Gateways SHOULD implement a protocol to permit applications REC-46 Gateways SHOULD implement a protocol to permit applications
to solicit inbound traffic without advance knowledge of the to solicit inbound traffic without advance knowledge of the
addresses of exterior nodes with which they expect to addresses of exterior nodes with which they expect to
communicate. communicate.
REC-46 Gateways MUST provide an easily selected configuration option REC-47 Gateways MUST provide an easily selected configuration option
that permits a "transparent mode" of operation that forwards that permits a "transparent mode" of operation that forwards
all unsolicited flows regardless of forwarding direction, all unsolicited flows regardless of forwarding direction,
i.e. to disable the IPv6 simple security capabilities of the i.e. to disable the IPv6 simple security capabilities of the
gateway. The transparent mode of operation MAY be the gateway. The transparent mode of operation MAY be the
default configuration. default configuration.
REC-47 By DEFAULT, subscriber managed residential gateways MUST NOT REC-48 By DEFAULT, subscriber managed residential gateways MUST NOT
offer management application services to the exterior offer management application services to the exterior
network. network.
5. Contributors 5. Contributors
Comments and criticisms during the development of this document were Comments and criticisms during the development of this document were
received from the following IETF participants: received from the following IETF participants:
+-------------------+----------------------------+ +-------------------+----------------------------+
| Fred Baker | Norbert Bollow | | Fred Baker | Norbert Bollow |
skipping to change at page 34, line 15 skipping to change at page 34, line 20
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway UPnP Forum, "Universal Plug and Play Internet Gateway
Device Standardized Gateway Device Protocol", Device Standardized Gateway Device Protocol",
September 2006, September 2010, <http://upnp.org/specs/gw/igd2/>.
<http://www.upnp.org/standardizeddcps/igd.asp>.
Author's Address Author's Address
james woodyatt (editor) james woodyatt (editor)
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
US US
Email: jhw@apple.com Email: jhw@apple.com
 End of changes. 50 change blocks. 
53 lines changed or deleted 60 lines changed or added

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