draft-ietf-v6ops-cpe-simple-security-02.txt   draft-ietf-v6ops-cpe-simple-security-03.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Best Current February 13, 2008 Intended status: Best Current July 29, 2008
Practice Practice
Expires: August 16, 2008 Expires: January 30, 2009
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-02 draft-ietf-v6ops-cpe-simple-security-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2008. This Internet-Draft will expire on January 30, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document makes specific recommendations to the makers of devices This document makes specific recommendations to the makers of devices
that provide "simple security" capabilities at the perimeter of that provide "simple security" capabilities at the perimeter of
local-area IPv6 networks in Internet-enabled homes and small offices. local-area IPv6 networks in Internet-enabled homes and small offices.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8
3.2.1. Upper-layer Transport Protocols . . . . . . . . . . . 8 3.2.1. Upper-layer Transport Protocols . . . . . . . . . . . 8
3.2.2. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. Teredo-specific Filters . . . . . . . . . . . . . . . 10 3.2.3. Teredo-specific Filters . . . . . . . . . . . . . . . 10
3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10
3.2.5. Other Virtual Private Network Protocols . . . . . . . 11 3.2.5. Other Virtual Private Network Protocols . . . . . . . 11
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 11 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 11
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 15 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 15
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 15 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 18
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 15 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 20
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 15 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 21
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30
A.1. draft-ietf-v6ops-cpe-simple-security-00 to A.1. draft-ietf-v6ops-cpe-simple-security-00 to
draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 23 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 30
A.2. draft-ietf-v6ops-cpe-simple-security-01 to A.2. draft-ietf-v6ops-cpe-simple-security-01 to
draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 24 draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3. draft-ietf-v6ops-cpe-simple-security-02 to
Intellectual Property and Copyright Statements . . . . . . . . . . 25 draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
In "Local Network Protection for IPv6" [RFC4864], IETF recommends In "Local Network Protection for IPv6" [RFC4864], IETF recommends
'simple security' capabilities for gateway devices that enable 'simple security' capabilities for gateway devices that enable
delivery of Internet services in residential and small office delivery of Internet services in residential and small office
settings. The principle goal of these capabilties is to improve settings. The principle goal of these capabilties is to improve
security of the IPv6 Internet without increasing the perceived security of the IPv6 Internet without increasing the perceived
complexity for users who just want to accomplish useful work. complexity for users who just want to accomplish useful work.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Peer-to-peer applications use an alternate method of connection Peer-to-peer applications use an alternate method of connection
initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse
stateful filters. In the simultaneous-open mode of operation, both stateful filters. In the simultaneous-open mode of operation, both
peers send SYN packets for the same TCP connection. The SYN packets peers send SYN packets for the same TCP connection. The SYN packets
cross in the network. Upon receiving the other end's SYN packet, 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 each end responds with a SYN-ACK packet, which also cross in the
network. The connection is established at each endpoint once the network. The connection is established at each endpoint once the
SYN-ACK packets are received. SYN-ACK packets are received.
In order to provide stateful packet filtering service for TCP, it is To provide stateful packet filtering service for TCP, it is necessary
necessary for a filter to receive, process and forward all packets for a filter to receive, process and forward all packets for a
for a connection that conform to valid transitions of the TCP state connection that conform to valid transitions of the TCP state machine
machine (Fig. 6, [RFC0793]). (Fig. 6, [RFC0793]).
R24: All valid sequences of TCP packets (defined in [RFC0793]) MUST R24: All valid sequences of TCP packets (defined in [RFC0793]) MUST
be forwarded for outbound connections and explicitly permitted be forwarded for outbound connections and explicitly permitted
inbound connections. In particular, both the normal TCP 3-way inbound connections. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes of handshake mode of operation and the simultaneous-open modes of
operation MUST be supported. operation MUST be supported.
It is possible to reconstruct enough of the state of a TCP connection It is possible to reconstruct enough of the state of a TCP connection
to allow forwarding between an interior and exterior node even when to allow forwarding between an interior and exterior node even when
the filter starts operating after TCP enters the established state. the filter starts operating after TCP enters the established state.
In this case, because the filter has not seen the TCP window-scale 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 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.
R25: The TCP window invariant MUST NOT be enforced on connections for R25: The TCP window invariant MUST NOT be enforced on connections 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 mapping to be reused by an A stateful filter can allow an existing state record to be reused by
externally initiated connection if its security policy permits. an externally initiated connection if its security policy permits.
Several different policies are possible as described in "Network Several different policies are possible as described in "Network
Address Translation (NAT) Behavioral Requirements for Unicast UDP Address Translation (NAT) Behavioral Requirements for Unicast UDP
[RFC4787] and extended in "NAT Behaviorial Requirements for TCP" [RFC4787] and extended in "NAT Behaviorial Requirements for TCP"
[BEHAVE-TCP]. [BEHAVE-TCP].
R26: If application transparency is most important, then a stateful R26: If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior for packet filter SHOULD have "Endpoint independent filter" behavior for
TCP. If a more stringent filtering behavior is most important, then TCP. If a more stringent filtering behavior is most important, then
a filter SHOULD have "Address dependent filtering" behavior. The a filter SHOULD have "Address dependent filtering" behavior. The
filtering behavior MAY be an option configurable by the network filtering behavior MAY be an option configurable by the network
skipping to change at page 13, line 19 skipping to change at page 13, line 19
wait on signaling errors until simultaneous-open will not be wait on signaling errors until simultaneous-open will not be
impaired. impaired.
R27: A gateway MUST NOT signal an error for an unsolicited inbound 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 SYN packet for at least 6 seconds after the packet is received. If
during this interval the gateway receives and forwards an outbound during this interval the gateway receives and forwards an outbound
SYN for the connection, then the gateway MUST discard the original SYN for the connection, then the gateway MUST discard the original
unsolicited inbound SYN packet without signaling an error. unsolicited inbound SYN packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN-- error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of network unless sending any response violates the security policy of the
administrator. network administrator.
A TCP filter maintains state associated with in-progrss and A TCP filter maintains state associated with in-progress and
established connections. Because of this, a filter is susceptible to established connections. Because of this, a filter is susceptible to
a resource-exhaustion attack whereby an attacker (or virus) on the 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 prevent such an attack, a filter needs to creating state records. To defend against such attacks, a filter
abandon unused state records after a sufficiently long period of needs to abandon unused state records after a sufficiently long
idleness. period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by abandon preferentially sessions for crashed endpoints, followed by
closed TCP connections and partially-open connections. A gateway can closed TCP connections and partially-open connections. A gateway can
check if an endpoint for a session has crashed by sending a TCP keep- check if an endpoint for a session has crashed by sending a TCP keep-
alive packet on behalf of the other endpoint and receiving a TCP RST alive packet on behalf of the other endpoint and receiving a TCP RST
packet in response. If the gateway connot determine whether the packet in response. If the gateway connot determine whether the
endpoint is active, then the associated state record needs to be endpoint is active, then the associated state record needs to be
retained until the TCP connection has been idle for some time. Note: retained until the TCP connection has been idle for some time. Note:
an established TCP connection can stay idle (but live) indefinitely; an established TCP connection can stay idle (but live) indefinitely;
hence, there is no fixed value for an idle-timeout that accomodates hence, there is no fixed value for an idle-timeout that accommodates
all applications. However, a large idle-timeout motivated by all applications. However, a large idle-timeout motivated by
recommendations in [RFC1122] and [RFC4294] can reduce the chances of recommendations in [RFC1122] and [RFC4294] can reduce the chances of
abandoning a live connection. abandoning a live connection.
TCP connections can stay in the established phase indefinitely TCP connections can stay in the established phase indefinitely
without exchanging packets. Some end-hosts can be configured to send without exchanging packets. Some end-hosts can be configured to send
keep-alive packets on such idle connections; by default, such packets keep-alive packets on such idle connections; by default, such packets
are sent every two hours, if enabled [RFC1122]. Consequently, a are sent every two hours, if enabled [RFC1122]. Consequently, a
filter that waits for slightly over two hours can detect idle filter that waits for slightly over two hours can detect idle
connections with keep-alive packets being sent at the default rate. connections with keep-alive packets being sent at the default rate.
skipping to change at page 15, line 9 skipping to change at page 15, line 9
example, state records are lost due to power interruption. example, state records are lost due to power interruption.
Several TCP mechanisms depend on the reception of ICMP error messages Several TCP mechanisms depend on the reception of ICMP error messages
triggered by the transmission of TCP segments. One such mechanism is triggered by the transmission of TCP segments. One such mechanism is
path MTU discovery, which is required for correct operation of TCP. path MTU discovery, which is required for correct operation of TCP.
R29: If a gateway forwards a TCP connection, it MUST also forward R29: If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that ICMP Destination Unreachable messages containing TCP headers that
match the connection state record. match the connection state record.
30: Receipt of any sort of ICMP message MUST NOT terminate the state R30: Receipt of any sort of ICMP message MUST NOT terminate the state
record for a TCP connection. record for a TCP connection.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
[ EDITOR: Insert verbiage here. ] Because Stream Control Transmission Protocol (SCTP) [RFC4960]
connections can be terminated at multiple network addresses, IPv6
simple security functions cannot achieve full transparency for SCTP
applications. In multipath traversal scenarios, full transparency
requires coordination between all the packet filter processes in the
various paths between the endpoint network addresses. Such
coordination is not "simple" and it is, therefore, beyond the scope
of this recommendation.
However, some SCTP applications are capable of tolerating the
inherent unipath restriction of IPv6 simple security, even in
multipath traversal scenarios. They expect similar connection-
oriented filtering behaviors as for TCP, but at the level of SCTP
associations, not stream connections. This section describes
specific recommendations for SCTP filtering for such traversal
scenarios.
An interior endpoint initiates SCTP associations through a stateful
packet filter by sending a packet comprising a single INIT chunk.
The filter allocates (or reuses) a filter state record for the
association. The state record defines the interior and exterior IP
addresses and the observed verification tag used for forwarding
packets in that association.
Peer-to-peer applications use an alternate method of association
initiation termed simultaneous-open to traverse stateful filters. In
the simultaneous-open mode of operation, both peers send INIT chunks
at the same time to establish an association. Upon receiving the
other end's INIT chunk, each end responds with an INIT-ACK packet,
which is expected to traverse the same path in reverse. Because only
one SCTP association may exist between any two network addresses, one
of the peers in simultaneous-open mode of operation will send an
ERROR or ABORT chunk along with the INIT-ACK chunk. The association
is established at each endpoint once an INIT-ACK chunks is
receivedA at one end without an ERROR or ABORT chunk.
To provide stateful packet filtering service for SCTP, it is
necessary for a filter to receive, process and forward all packets
for an association that conform to valid transitions of the SCTP
state machine (Fig. 3, [RFC4960]).
R31: All valid sequences of SCTP packets (defined in [RFC4960]) MUST
be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP
association establishment and simultaneous-open modes of operation
MUST be supported.
If an inbound INIT packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error
through ICMP messages allows the sender to detect that the INIT
packet did not reach the intended destination. Discarding the
packet, on the other hand, allows applications to perform
simultaneous-open more reliably. Delays in signaling errors can
prevent the impairment of simultaneous-open mode of operation.
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.
An SCTP filter maintains state associated with in-progress and
established associations. Because of this, a filter is susceptible
to a resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long
period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by
closed associations and partially opened associations. A similar
method is an option for SCTP filters in IPv6 gateways. A gateway can
check if an endpoint for an association has crashed by sending
HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the
gateway cannot determine whether the endpoint is active, then the
associated state records needs to be retained until the SCTP
association has been idle for some time. Note: an established SCTP
association can stay idle (but live) indefinitely, hence there is no
fixed value of an idle-timeout that accommodates all applications.
However, a large idle-timeout motivated by [RFC4294] can reduce the
chances of abandoning a live association.
SCTP associations can stay in the ESTABLISHED state indefinitely
without exchanging packets. Some end-hosts can be configured to send
HEARTBEAT chunks on such idle associations, but [RFC4960] does not
specify (or even suggest) a default time interval. A filter that
waits for slightly over two hours can detect idle associations with
HEARTBEAT packets being sent at the same rate as most hosts use for
TCP keep-alive, which is a reasonably similar system for this
purpose. SCTP associations in the partially-open or closing states,
on the other hand, can stay idle for at most four minutes while
waiting for in-flight packets to be delivered (assuming the suggested
SCTP protocol parameter values in Section 15 of [RFC4960]).
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.
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.
Behavior for handling ERROR and ABORT packets is left unspecified. A
gateway MAY hold state for an association after its closing phases
have completed to accommodate retransmissions of its final SHUTDOWN
ACK packets. However, holding state for a closed association can
limit the throughput of associations traversing a gateway with
limited resources. The discussion in [RFC1337] regarding the hazards
of TIME_WAIT assassination are relevant.
The handling of inbound non-INIT packets for which there is no active
state record is left unspecified. Such packets can be received if
the gateway abandons a live connection, or abandons an association in
the closing states before the transitory association idle-timeout
expires. The decision either to discard or to respond with an ICMP
Destination Unreachable error, code 1 (administratively prohibited)
is left to the implementation.
Behavior for notifying endpoints when abandoning live associations is
left unspecified. When a gateway abandons a live association, for
example due to a timeout expiring, the filter MAY send an ABORT
packet to each endpoint on behalf of the other. Sending an ABORT
notification allows endpoint applications to recover more quickly,
however, notifying endpoints might not always be possible if, for
example, state records are lost due to power interruption.
Several SCTP mechanisms depend on the reception of ICMP error
messages triggered by the transmission of SCTP packets.
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.
R35: Receipt of any sort of ICMP message MUST NOT terminate the state
record for an SCTP association.
3.3.3. DCCP Filters 3.3.3. DCCP Filters
[ EDITOR: Insert verbiage here. ] The connection semantics described in Datagram Congestion Control
Protocol (DCCP) [RFC4340] are very similar to those of TCP. An
interior endpoint initiates a DCCP connection through a stateful
packet filter by sending a DCCP-Request packet. Simultaneous open is
not defined for DCCP.
In order to provide stateful packet filtering service for DCCP, it is
necessary for a filter to receive, process and forward all packets
for a connection that conform to valid transitions of the DCCP state
machine (Section 8, [RFC4340]).
R36: All valid sequences of DCCP packets (defined in [RFC4340]) MUST
be forwarded for all connections to exterior servers and those
connections to interior servers with explicitly permitted service
codes.
It is possible to reconstruct enough of the state of a DCCP
connection to allow forwarding between an interior and exterior node
even when the filter starts operating after DCCP enters the OPEN
state. Also, a filter can allow an existing state record to be
reused by an externally initiated connection if its security policy
permits. As with TCP, several different policies are possible, with
a good discussion of the issue involved presented in Network Address
Translation (NAT) Behavioral Requirements for Unicast UDP [RFC4787]
and extended in NAT Behaviorial Requirements for TCP [BEHAVE-TCP].
If an inbound DCCP-Request packet is filtered, either because a
corresponding state record does not already exist for it or because
of the filter's normal behavior of refusing connections not
explicitly permitted, then a filter has two basic choices: to discard
the packet silently, or to signal an error to the sender. Signaling
an error through ICMP messages allows the sender to detect that the
DCCP-Request did not reach the intended destination. Discarding the
packet, on the other hand, only delays the failure to connect and
provides no measurable security.
A DCCP filter maintains state associated with in-progress and
established connections. Because of this, a filter is susceptible to
a resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for
creating state records. To prevent such an attack, a filter needs to
abandon unused state records after a sufficiently long period of
idleness.
A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by
closed TCP connections and partially-open connections. No such
method exists for DCCP, and connections can stay in the OPEN phase
indefinitely without exchanging packets. Hence, there is no fixed
value for an idle-timeout that accommodates all applications.
However, a large idle-timeout motivated by [RFC4294] can reduce the
chances of abandoning a live connection.
DCCP connections in the partially-open or closing phases can stay
idle for at most eight minutes while waiting for in-flight packets to
be delivered.
The "open connection idle-timeout" for a stateful packet filter is
defined as the minimum time a DCCP connection in the open state must
remain idle before the filter considers the associated state record a
candidate for collection. The "transitory connection idle-timeout"
for a filter is defined as the minimum time a DCCP connection in the
partially-open or closing phases must remain idle before the filter
considers the associated state record a candidate for collection.
DCCP connections in the TIMEWAIT state are not affected by the
"transitory connection idle-timeout" parameter.
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.
Behavior for handing DCCP-Reset packets, or connections in the
TIMEWAIT state is left unspecified. A gateway MAY hold state for a
connection in TIMEWAIT state to accommodate retransmissions of the
last DCCP-Reset. However, since the TIMEWAIT state is commonly
encountered by interior endpoints properly closing the DCCP
connection, holding state for a closed connection can limit the
throughput of connections through a gateway with limited resources.
[RFC1337] discusses hazards associated with TIME_WAIT assassination
in TCP, and similar hazards exists for DCCP.
The handling of non-SYN packets for which there is no active state
record is left unspecified. Such packets can be received if the
gateway abandons a live connection, or abandons a connection in the
TIMEWAIT state before the four minute 2MSL period expires. The
decision either to discard or to respond with an ICMP Destination
Unreachable error, code 1 (administratively prohibited) is left up to
the implementation.
Behavior for notifying endpoints when abandoning live connections is
left unspecified. When a gateway abandons a live connection, for
example due to a timeout expiring, the filter MAY send a DCCP-Reset
packet to each endpoint on behalf of the other. Sending a DCCP-Reset
notification allows endpoint applications to recover more quickly,
however, notifying endpoints might not always be possible if, for
example, state records are lost due to power interruption.
Several DCCP mechanisms depend on the reception of ICMP error
messages triggered by the transmission of DCCP packets. One such
mechanism is path MTU discovery, which is required for correct
operation.
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.
R39: Receipt of any sort of ICMP message MUST NOT terminate the state
record for a DCCP connection.
3.4. Passive Listeners 3.4. Passive Listeners
Some applications expect to solicit traffic from exterior nodes Some applications expect to solicit traffic from exterior nodes
without any advance knowledge of the exterior address. This without any advance knowledge of the exterior address. This
requirement is met by IPv4/NAT gateways typically by the use of requirement is met by IPv4/NAT gateways typically by the use of
either [NAT-PMP] or [UPnP-IGD]. either [NAT-PMP] or [UPnP-IGD].
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 [IPv6-ALD]. It remains to be Application Listener Discovery Protocol [IPv6-ALD]. It remains to be
skipping to change at page 19, line 37 skipping to change at page 25, line 11
R30 Receipt of any sort of ICMP message MUST NOT terminate the state R30 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a TCP connection. record for a TCP connection.
R31 Gateways MUST implement a protocol to permit applications to R31 Gateways MUST implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses solicit inbound traffic without advance knowledge of the addresses
of exterior nodes with which they expect to communicate. This of exterior nodes with which they expect to communicate. This
protocol MUST have a specification that meets the requirements of protocol MUST have a specification that meets the requirements of
[RFC3978], [RFC3979] and [RFC4748]. [RFC3978], [RFC3979] and [RFC4748].
R33 All valid sequences of SCTP packets (defined in [RFC4960]) MUST
be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP
association establishment and simultaneous-open modes of operation
MUST be supported.
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.
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.
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.
R35 Receipt of any sort of ICMP message MUST NOT terminate the state
record for an SCTP association.
R36 All valid sequences of DCCP packets (defined in [RFC4340]) MUST
be forwarded for all connections to exterior servers and those
connections to interior servers with explicitly permitted service
codes.
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.
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.
R39 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a DCCP connection.
5. Contributors 5. Contributors
Comments and criticisms during the development of this document were Comments and criticisms during the development of this document were
received from the following IETF participants: received from the following IETF participants:
Fred Baker Fred Baker
Norbert Bollow Norbert Bollow
Brian Carpenter Brian Carpenter
skipping to change at page 24, line 30 skipping to change at page 31, line 5
o Added section for generic upper layer transport protocols. o Added section for generic upper layer transport protocols.
o Expanded on recommendations for IPsec ESP filtering. o Expanded on recommendations for IPsec ESP filtering.
o Expanded overview of recommendations with discussion about IP o Expanded overview of recommendations with discussion about IP
mobility and IPsec interactions. mobility and IPsec interactions.
o Added a security considerations section. o Added a security considerations section.
A.3. draft-ietf-v6ops-cpe-simple-security-02 to
draft-ietf-v6ops-cpe-simple-security-03
o Fixed some spelling errors.
o Replace "prevent such attacks" with "defend against such attacks"
everywhere.
o Replace "mapping" with "state record" in the TCP filters section.
o Added recommendations for SCTP and DCCP.
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. 18 change blocks. 
34 lines changed or deleted 359 lines changed or added

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