draft-ietf-v6ops-cpe-simple-security-09.txt   draft-ietf-v6ops-cpe-simple-security-10.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Informational February 18, 2010 Intended status: Informational March 26, 2010
Expires: August 22, 2010 Expires: September 27, 2010
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-09 draft-ietf-v6ops-cpe-simple-security-10
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 22, 2010. This Internet-Draft will expire on September 27, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 4 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 6 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 6
2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 6 2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 6
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 7 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 7 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 7
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 8 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 9 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 9
3.2.1. Internet Control and Management . . . . . . . . . . . 9 3.2.1. Internet Control and Management . . . . . . . . . . . 9
3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 9 3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 9
3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. 6to4 Tunnels . . . . . . . . . . . . . . . . . . . . . 11 3.2.4. 6to4 Tunnels . . . . . . . . . . . . . . . . . . . . . 11
3.2.5. Teredo-specific Filters . . . . . . . . . . . . . . . 11 3.2.5. IPsec and Internet Key Exchange (IKE) . . . . . . . . 11
3.2.6. IPsec and Internet Key Exchange (IKE) . . . . . . . . 12
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . 22 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 21
3.5. Management Applications . . . . . . . . . . . . . . . . . 23 3.5. Management Applications . . . . . . . . . . . . . . . . . 22
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . 33 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 33
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 . . . . . . . . . 33 draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 33
A.3. draft-ietf-v6ops-cpe-simple-security-02 to A.3. draft-ietf-v6ops-cpe-simple-security-02 to
draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 34 draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 33
A.4. draft-ietf-v6ops-cpe-simple-security-03 to A.4. draft-ietf-v6ops-cpe-simple-security-03 to
draft-ietf-v6ops-cpe-simple-security-04 . . . . . . . . . 34 draft-ietf-v6ops-cpe-simple-security-04 . . . . . . . . . 34
A.5. draft-ietf-v6ops-cpe-simple-security-04 to A.5. draft-ietf-v6ops-cpe-simple-security-04 to
draft-ietf-v6ops-cpe-simple-security-05 . . . . . . . . . 34 draft-ietf-v6ops-cpe-simple-security-05 . . . . . . . . . 34
A.6. draft-ietf-v6ops-cpe-simple-security-05 to A.6. draft-ietf-v6ops-cpe-simple-security-05 to
draft-ietf-v6ops-cpe-simple-security-06 . . . . . . . . . 35 draft-ietf-v6ops-cpe-simple-security-06 . . . . . . . . . 35
A.7. draft-ietf-v6ops-cpe-simple-security-06 to A.7. draft-ietf-v6ops-cpe-simple-security-06 to
draft-ietf-v6ops-cpe-simple-security-07 . . . . . . . . . 36 draft-ietf-v6ops-cpe-simple-security-07 . . . . . . . . . 36
A.8. draft-ietf-v6ops-cpe-simple-security-07 to A.8. draft-ietf-v6ops-cpe-simple-security-07 to
draft-ietf-v6ops-cpe-simple-security-08 . . . . . . . . . 36 draft-ietf-v6ops-cpe-simple-security-08 . . . . . . . . . 36
A.9. draft-ietf-v6ops-cpe-simple-security-08 to A.9. draft-ietf-v6ops-cpe-simple-security-08 to
draft-ietf-v6ops-cpe-simple-security-09 . . . . . . . . . 36 draft-ietf-v6ops-cpe-simple-security-09 . . . . . . . . . 36
A.10. draft-ietf-v6ops-cpe-simple-security-09 to
draft-ietf-v6ops-cpe-simple-security-10 . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
In "Local Network Protection for IPv6" [RFC4864], IETF recommends Some IPv6 gateway devices that enable delivery of Internet services
'simple security' capabilities for gateway devices that enable in residential and small office settings are augmented with 'simple
delivery of Internet services in residential and small office security' capabilities as described in the Informational document
settings. The principle goal of these capabilities is to improve "Local Network Protected for IPv6" [RFC4864].
security of the IPv6 Internet without increasing the perceived
complexity for users who just want to accomplish useful work.
There is, at best, a constructive tension between the desires of The principle goal of these capabilities is to improve security of
users for transparent end-to-end connectivity on the one hand, and the IPv6 Internet without increasing the perceived complexity for
the need for local-area network administrators to detect and prevent users who just want to accomplish useful work. However, there is a
intrusion by unauthorized public Internet users on the other. The constructive tension between the desires of users for transparent
specific recommendations in this document are intended to promote end-to-end connectivity on the one hand, and the need for local-area
optimal local-area network security while retaining full end-to-end network administrators to detect and prevent intrusion by
unauthorized public Internet users on the other. The specific
recommendations in this document are intended to promote optimal
local-area network security while retaining full end-to-end
transparency for users, and to highlight reasonable limitations on transparency for users, and to highlight reasonable limitations on
transparency where security considerations are deemed important. transparency where security considerations are deemed important.
Residential and small office network administrators are expected to Residential and small office network administrators are expected to
have no expertise in Internet engineering whatsoever. Configuration have no expertise in Internet engineering whatsoever. Configuration
interfaces for simple security in router/gateway appliances marketed interfaces for simple security in router/gateway appliances marketed
toward them should be easy to understand and even easier to ignore. toward them should be easy to understand and even easier to ignore.
In particular, extra care should be taken in designing the baseline In particular, extra care should be taken in designing the baseline
operating modes of unconfigured devices, since the security functions operating modes of unconfigured devices, since the security functions
of most devices will never be changed from their factory set default. of most devices will never be changed from their factory set default.
The mechanisms described in this document cause packets to be
discarded by residential gateways in an attempt to make home networks
and the Internet more secure. However, some packets sent by
legitimate applications may also be discarded in the process,
affecting reliability and ease of use for these applications.
Note well: this document is not a standard and conformance with it is
not required in order to claim conformance with IETF standards for
IPv6. It uses the normative keywords defined below only for
precision. Particular attention is drawn to recommendation REC-41,
which calls for an easy way for a user to set a gateway to a
transparent mode.
1.1. Special Language 1.1. Special Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The key word "DEFAULT" in this document is to be interpreted as the The key word "DEFAULT" in this document is to be interpreted as the
configuration of a device, as applied by its vendor, prior to the configuration of a device, as applied by its vendor, prior to the
operator changing it for the first time. operator changing it for the first time.
skipping to change at page 5, line 41 skipping to change at page 6, line 7
and small offices often used private IPv4 network address realms and small offices often used private IPv4 network address realms
[RFC1918] with Network Address Translation (NAT) functions deployed [RFC1918] with Network Address Translation (NAT) functions deployed
to present all the hosts on the interior network as a single host to to present all the hosts on the interior network as a single host to
the Internet service provider. The stateful packet filtering the Internet service provider. The stateful packet filtering
behavior of NAT set user expectations that persist today with behavior of NAT set user expectations that persist today with
residential IPv6 service. "Local Network Protection for IPv6" residential IPv6 service. "Local Network Protection for IPv6"
[RFC4864] recommends applying stateful packet filtering at [RFC4864] recommends applying stateful packet filtering at
residential IPv6 gateways that conforms to the user expectations residential IPv6 gateways that conforms to the user expectations
already in place. already in place.
As the latest revision of this document is being drafted, Conventional stateful packet filters activate new states as a side
conventional stateful packet filters activate new states as a side
effect of forwarding outbound flow initiations from interior network effect of forwarding outbound flow initiations from interior network
nodes. This requires applications to have advance knowledge of the nodes. This requires applications to have advance knowledge of the
addresses of exterior nodes with which they expect to communicate. addresses of exterior nodes with which they expect to communicate.
Several proposals are currently under consideration for allowing Several proposals are currently under consideration for allowing
applications to solicit inbound traffic from exterior nodes without applications to solicit inbound traffic from exterior nodes without
advance knowledge of their addresses. While consensus within the advance knowledge of their addresses. While consensus within the
Internet engineering community has emerged that such protocols are Internet engineering community has emerged that such protocols are
necessary to implement in residential IPv6 gateways, the best current necessary to implement in residential IPv6 gateways, the best current
practice has not yet been established. practice has not yet been established.
skipping to change at page 6, line 25 skipping to change at page 6, line 38
end network security and routing extension headers for mobility are end network security and routing extension headers for mobility are
expected to pass Internet gateways freely. expected to pass Internet gateways freely.
Finally, Internet gateways that route multicast traffic are expected Finally, Internet gateways that route multicast traffic are expected
to implement appropriate filters for multicast to limit the scope of to implement appropriate filters for multicast to limit the scope of
multicast groups that span the demarcation between residential multicast groups that span the demarcation between residential
networks and service provider networks. networks and service provider networks.
2.2. Internet Layer Protocols 2.2. Internet Layer Protocols
In managed, enterprise networks, virtual private networking tunnels As virtual private networking tunnels are regarded as an unacceptably
are typically regarded as an additional attack surface. and they are wide attack surface, this document recommends the DEFAULT operating
often restricted or prohibited from traversing firewalls for that mode for residential IPv6 simple security is to treat IP-in-IP and
reason. However, it would be inappropriate to restrict virtual GRE tunneling protocols as opaque transport layers, i.e. inbound
private networking tunnels by default in unmanaged, residential tunnel initiations are denied and outbound tunnel initiations are
network usage scenarios. Therefore, this document recommends the accepted. IPsec transport and tunnel modes are explicitly secured by
DEFAULT operating mode for residential IPv6 simple security is to definition, so this document recommends the DEFAULT operating mode
permit all virtual private networking tunnel protocols to pass permit IPsec and Internet Key Exchange (IKE) flows to pass without
through the stateful filtering function. These include IPsec filtering.
transport and tunnel modes as well as other IP-in-IP protocols.
Where IPv6 simple security functions are integrated with an IPv4/NAT
gateway of any of the types described in [RFC4787], it's important to
keep IPv6 flows subject to a consistent policy. If the security
functions of an IPv6 residential gateway can be bypassed through
Teredo [RFC4380], then application developers will be encouraged to
use it even at nodes where native IPv6 service is available. This
will have the effect of impeding the completion of the transition to
native IPv6.
Residential IPv6 gateways are expected to continue operating as IPv4/
NAT gateways for the foreseeable future. To prevent Teredo from
acquiring a utility that it was never meant to have on networks where
both IPv4/NAT and native IPv6 services are available, gateways on
such networks SHOULD impede Teredo tunnels by blocking clients from
learning their mapped addresses and ports in the qualification
procedure described in sections 5.2.1 and 5.2.2 of [RFC4380]. (Note:
this is a necessary addition to the "automatic sunset" provision in
section 5.5 of [RFC4380] because it's all too common that nested
IPv4/NAT gateways are deployed unintentionally in residential
settings and without consideration for Internet architectural
implications.)
2.3. Transport Layer Protocols 2.3. Transport Layer Protocols
IPv6 simple security functions are principally concerned with the IPv6 simple security functions are principally concerned with the
stateful filtering of Internet Control and Management Protocol (ICMP) stateful filtering of Internet Control and Management Protocol (ICMP)
[RFC4884] and transport layers like User Datagram Protocol (UDP) [RFC4884] and transport layers like User Datagram Protocol (UDP)
[RFC0768] (and Lightweight User Datagram Protocol (UDP-Lite) [RFC0768] (and Lightweight User Datagram Protocol (UDP-Lite)
[RFC3828]), Transport Control Protocol (TCP) [RFC0793], the Stream [RFC3828]), Transport Control Protocol (TCP) [RFC0793], the Stream
Control Transmission Protocol (SCTP) [RFC4960], the Datagram Control Transmission Protocol (SCTP) [RFC4960], the Datagram
Congestion Control Protocol (DCCP) [RFC4340], and potentially any Congestion Control Protocol (DCCP) [RFC4340], and potentially any
standards-track transport protocols to be defined in the future. standards-track transport protocols to be defined in the future.
The general operating principle is that transport layer traffic is The general operating principle is that transport layer traffic is
not forwarded into the interior network of a residential IPv6 gateway not forwarded into the interior network of a residential IPv6 gateway
unless it has been solicited explicitly by interior nodes, e.g. by unless it has been solicited explicitly by interior transport
matching the reverse path for previously forwarded outbound traffic, endpoints, e.g. by matching the reverse path for previously forwarded
or by matching manually configured exceptions set by the network outbound traffic, or by matching manually configured exceptions set
administrator. All other traffic is expected to be discarded or by the network administrator. All other traffic is expected to be
rejected with an ICMPv6 error message to indicate the traffic is discarded or rejected with an ICMPv6 error message to indicate the
administratively prohibited. traffic is administratively prohibited.
3. Detailed Recommendations 3. Detailed Recommendations
This section describes the specific recommendations made by this This section describes the specific recommendations made by this
document in full detail. They are summarized into a convenient list document in full detail. They are summarized into a convenient list
in Section 4. in Section 4.
Some recommended filters are to be applied to all traffic that passes Some recommended filters are to be applied to all traffic that passes
through residential Internet gateways regardless of the direction through residential Internet gateways regardless of the direction
they are to be forwarded. Other recommended filters are intended to they are to be forwarded. Other recommended filters are intended to
skipping to change at page 8, line 25 skipping to change at page 8, line 16
Other stateless filters are recommended to implement ingress Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the boundaries, and to isolate certain local network services from the
public Internet. public Internet.
REC-1: Packets which bear in their outer IPv6 headers multicast REC-1: Packets which bear in their outer IPv6 headers multicast
source addresses MUST NOT be forwarded or transmitted on any source addresses MUST NOT be forwarded or transmitted on any
interface. interface.
REC-2: Packets which bear in their outer IPv6 headers multicast REC-2: Packets which bear in their outer IPv6 headers multicast
destination addresses of equal or narrower scope (see section 2.7 of destination addresses of equal or narrower scope (see IPv6 Scoped
IP Version 6 Addressing Architecture [RFC4291]) than the configured Address Architecture [RFC4007]) than the configured scope boundary
scope boundary level of the gateway MUST NOT be forwarded in any level of the gateway MUST NOT be forwarded in any direction. The
direction. The DEFAULT scope boundary level SHOULD be organization- DEFAULT scope boundary level SHOULD be organization-local scope, and
local scope, and it SHOULD be configurable by the network it SHOULD be configurable by the network admininistrator.
admininistrator.
REC-3: Packets bearing source and/or destination addresses forbidden REC-3: Packets bearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over the public to appear in the outer headers of packets transmitted over the public
Internet MUST NOT be forwarded. In particular, site-local addresses Internet MUST NOT be forwarded. In particular, site-local addresses
are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use
of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and
ORCHID prefixes. ORCHID prefixes.
REC-4: Packets bearing deprecated extension headers prior to their REC-4: Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be forwarded or first upper-layer-protocol header SHOULD NOT be forwarded or
skipping to change at page 9, line 31 skipping to change at page 9, line 22
difficulty for stateful packet filters because most of the difficulty for stateful packet filters because most of the
application state is not carried at the transport level. State application state is not carried at the transport level. State
records are created when communication is initiated and abandoned records are created when communication is initiated and abandoned
when no further communication is detected after some period of time. when no further communication is detected after some period of time.
3.2.1. Internet Control and Management 3.2.1. Internet Control and Management
Recommendations for filtering ICMPv6 messages in firewall devices are Recommendations for filtering ICMPv6 messages in firewall devices are
described separately in [RFC4890] and apply generally to residential described separately in [RFC4890] and apply generally to residential
gateways as to any class of router. No additional recommendations gateways as to any class of router. No additional recommendations
are made here. are made here, but it's important to note that Destination
Unreachable and Packet Too Big errors corresponding to filtering
states for all upper-layer transport protocols are important to the
proper function of the Internet.
3.2.2. Upper-layer Transport Protocols 3.2.2. Upper-layer Transport Protocols
Residential IPv6 gateways are not expected to prohibit the use of Residential IPv6 gateways are not expected to prohibit the use of
applications to be developed using future upper-layer transport applications to be developed using future upper-layer transport
protocols. In particular, transport protocols not otherwise protocols. In particular, transport protocols not otherwise
discussed in subsequent sections of this document are expected to be discussed in subsequent sections of this document are expected to be
treated consistently, i.e. as having connection-free semantics and no treated consistently, i.e. as having connection-free semantics and no
special requirements to inspect the transport headers. special requirements to inspect the transport headers.
skipping to change at page 10, line 11 skipping to change at page 10, line 5
protocols MUST BE indexable by a 3-tuple comprising the interior node protocols MUST BE indexable by a 3-tuple comprising the interior node
address, the exterior node address and the upper-layer transport address, the exterior node address and the upper-layer transport
protocol identifier. protocol identifier.
REC-11: Filter state records for generic upper-layer transport REC-11: Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer not protocols MUST NOT be deleted or recycled until an idle timer not
less than two minutes has expired without having forwarded a packet less than two minutes has expired without having forwarded a packet
matching the state in some configurable amount of time. By DEFAULT, matching the state in some configurable amount of time. By DEFAULT,
the idle timer for such state records is five minutes. the idle timer for such state records is five minutes.
REC-12: IPv6 gateways MUST forward ICMP Destination Unreachable and
Packet Too Big messages containing IP headers that match generic
upper-layer transport state 3-tuples.
3.2.3. UDP Filters 3.2.3. UDP Filters
"Network Address Translation (NAT) Behavioral Requirements for "Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP" [RFC4787] defines the terminology and best current Unicast UDP" [RFC4787] defines the terminology and best current
practice for stateful filtering of UDP applications in IPv4 with NAT, practice for stateful filtering of UDP applications in IPv4 with NAT,
which serves as the model for behavioral requirements for simple UDP which serves as the model for behavioral requirements for simple UDP
security in IPv6 gateways, notwithstanding the requirements related security in IPv6 gateways, notwithstanding the requirements related
specifically to network address translation. specifically to network address translation.
An interior endpoint initiates a UDP exchange through a stateful An interior endpoint initiates a UDP exchange through a stateful
packet filter by sending a packet to an exterior address. The filter packet filter by sending a packet to an exterior address. The filter
allocates (or reuses) a filter state record for the duration of the allocates (or reuses) a filter state record for the duration of the
exchange. The state record defines the interior and exterior IP exchange. The state record defines the interior and exterior IP
addresses and ports used between all packets in the exchange. addresses and ports used between all packets in the exchange.
State records for UDP exchanges remain active while they are in use State records for UDP exchanges remain active while they are in use
and only abandoned after an idle period of some time. and only abandoned after an idle period of some time.
REC-12: A state record for a UDP exchange where both interior and REC-13: A state record for a UDP exchange where both interior and
exterior ports are outside the well-known port range (ports 0-1023) exterior ports are outside the well-known port range (ports 0-1023)
MUST NOT expire in less than two minutes of idle time. The value of MUST NOT expire in less than two minutes of idle time. The value of
the UDP state record idle timer MAY be configurable. The DEFAULT is the UDP state record idle timer MAY be configurable. The DEFAULT is
five minutes. five minutes.
REC-13: A state record for a UDP exchange where one or both of the REC-14: A state record for a UDP exchange where one or both of the
interior and exterior ports are in the well-known port range (ports interior and exterior ports are in the well-known port range (ports
0-1023) MAY expire after a period of idle time shorter than two 0-1023) MAY expire after a period of idle time shorter than two
minutes to facilitate the operation of the IANA-registered service minutes to facilitate the operation of the IANA-registered service
assigned to the port in question. assigned to the port in question.
As [RFC4787] notes, outbound refresh is necessary for allowing the As [RFC4787] notes, outbound refresh is necessary for allowing the
interior endpoint to keep the state record alive. Inbound refresh interior endpoint to keep the state record alive. Inbound refresh
may be useful for applications with no outbound UDP traffic. may be useful for applications with no outbound UDP traffic.
However, allowing inbound refresh can allow an attacker in the However, allowing inbound refresh can allow an attacker in the
exterior or a misbehaving application to keep a state record alive exterior or a misbehaving application to keep a state record alive
indefinitely. This could be a security risk. Also, if the process indefinitely. This could be a security risk. Also, if the process
is repeated with different ports, over time, it could use up all the is repeated with different ports, over time, it could use up all the
state record memory and resources in the filter. state record memory and resources in the filter.
REC-14: A state record for a UDP exchange MUST be refreshed when a REC-15: A state record for a UDP exchange MUST be refreshed when a
packet is forwarded from the interior to the exterior, and it MAY be packet is forwarded from the interior to the exterior, and it MAY be
refreshed when a packet is forwarded in the reverse direction. refreshed when a packet is forwarded in the reverse direction.
As described in section 5.5 of [RFC4787], the connection-free As described in section 5.5 of [RFC4787], the connection-free
semantics of UDP pose a difficulty for packet filters in trying to semantics of UDP pose a difficulty for packet filters in trying to
recognize which packets comprise an application flow and which are recognize which packets comprise an application flow and which are
unsolicited. Various strategies have been used in IPv4/NAT gateways unsolicited. Various strategies have been used in IPv4/NAT gateways
with differing effects. with differing effects.
REC-15: If application transparency is most important, then a REC-16: 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 UDP. If a more stringent filtering behavior is most behavior for UDP. 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 TCP and other protocols. Filtering behavior SHOULD by behavior for TCP and other protocols. Filtering behavior SHOULD by
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.
Applications mechanisms may depend on the reception of ICMP error Applications mechanisms may depend on the reception of ICMP error
messages triggered by the transmission of UDP messages. One such messages triggered by the transmission of UDP messages. One such
mechanism is path MTU discovery. mechanism is path MTU discovery.
REC-16: If a gateway forwards a UDP exchange, it MUST also forward REC-17: If a gateway forwards a UDP exchange, it MUST also forward
ICMP Destination Unreachable messages containing UDP headers that ICMP Destination Unreachable and Packet Too Big messages containing
match the exchange state record. UDP headers that match the exchange state record.
REC-17: Receipt of any sort of ICMP message MUST NOT terminate the REC-18: Receipt of any sort of ICMP message MUST NOT terminate the
state record for a UDP exchange. state record for a UDP exchange.
REC-18: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same REC-19: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same
way as UDP exchanges, except that the upper-layer transport protocol way as UDP exchanges, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore UDP identifier for UDP-Lite is not the same as UDP, and therefore UDP
packets MUST NOT match UDP-Lite state records, and vice versa. packets MUST NOT match UDP-Lite state records, and vice versa.
3.2.4. 6to4 Tunnels 3.2.4. 6to4 Tunnels
Typical dual-stack IPv4/IPv6 residential gateways use private IPv4 Typical dual-stack IPv4/IPv6 residential gateways use private IPv4
address ranges and network address/port translation on a single IPv4 address ranges and network address/port translation on a single IPv4
address assigned by the service provider. The use of private address assigned by the service provider. The use of private
addresses prevents interior hosts from using 6to4 [RFC3068] tunnels. addresses prevents interior hosts from using 6to4 [RFC3068] tunnels.
3.2.5. Teredo-specific Filters 3.2.5. IPsec and Internet Key Exchange (IKE)
Transitional residential IPv6 gateways that also feature integrated
IPv4/NAT gateways require special filtering for Teredo tunnels.
REC-19: Where a globally routed IPv6 prefix is advertised on an
interior interface and IPv4 Internet service is provided with NAT
[RFC4787], the Teredo qualification procedure (see section 5.2.1 and
5.2.2 of [RFC4380]) for clients in the interior SHOULD be prohibited
by the IPv4/NAT stateful filter. This SHOULD be done by blocking
outbound UDP initiations to port 3544, the port reserved by IANA for
Teredo servers.
3.2.6. IPsec and Internet Key Exchange (IKE)
Internet protocol security (IPsec) offers greater flexibility and Internet protocol security (IPsec) offers greater flexibility and
better overall security than the simple security of stateful packet better overall security than the simple security of stateful packet
filtering at network perimeters. Therefore, residential IPv6 filtering at network perimeters. Therefore, residential IPv6
gateways need not prohibit IPsec traffic flows. gateways need not prohibit IPsec traffic flows.
REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with destination extension headers of type "Authenticated addresses, with destination extension headers of type "Authenticated
Header (AH)" [RFC4302] in their outer IP extension header chain. Header (AH)" [RFC4302] in their outer IP extension header chain.
skipping to change at page 16, line 14 skipping to change at page 15, line 49
packet to each endpoint on behalf of the other. Sending a RST packet to each endpoint on behalf of the other. Sending a RST
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 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.
REC-29: If a gateway forwards a TCP connection, it MUST also forward REC-29: If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that ICMP Destination Unreachable and Packet Too Big messages containing
match the connection state record. TCP headers that match the connection state record.
REC-30: Receipt of any sort of ICMP message MUST NOT terminate the REC-30: Receipt of any sort of ICMP message MUST NOT terminate the
state record for a TCP connection. state record for a TCP connection.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
Because Stream Control Transmission Protocol (SCTP) [RFC4960] Because Stream Control Transmission Protocol (SCTP) [RFC4960]
connections can be terminated at multiple network addresses, IPv6 connections can be terminated at multiple network addresses, IPv6
simple security functions cannot achieve full transparency for SCTP simple security functions cannot achieve full transparency for SCTP
applications. In multipath traversal scenarios, full transparency applications. In multipath traversal scenarios, full transparency
skipping to change at page 19, line 19 skipping to change at page 19, line 6
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 ICMP error Several SCTP mechanisms depend on the reception of ICMP error
messages triggered by the transmission of SCTP packets. messages triggered by the transmission of SCTP packets.
REC-34: If a gateway forwards an SCTP association, it MUST also REC-34: If a gateway forwards an SCTP association, it MUST also
forward ICMP Destination Unreachable messages containing SCTP headers forward ICMP Destination Unreachable and Packet Too Big messages
that match the association state record. containing SCTP headers that match the association state record.
REC-35: Receipt of any sort of ICMP message MUST NOT terminate the REC-35: Receipt of any sort of ICMP 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 connection through a stateful interior endpoint initiates a DCCP connection through a stateful
packet filter by sending a DCCP-Request packet. Simultaneous open is packet filter by sending a DCCP-Request packet. Simultaneous open is
skipping to change at page 21, line 37 skipping to change at page 21, line 23
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 DCCP mechanisms depend on the reception of ICMP error Several DCCP mechanisms depend on the reception of ICMP 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-38: If a gateway forwards a DCCP connection, it MUST also forward REC-38: If a gateway forwards a DCCP connection, it MUST also forward
ICMP Destination Unreachable messages containing DCCP headers that ICMP Destination Unreachable and Packet Too Big messages containing
match the connection state record. DCCP headers that match the connection state record.
REC-39: Receipt of any sort of ICMP message MUST NOT terminate the REC-39: Receipt of any sort of ICMP message MUST NOT terminate the
state record for a DCCP connection. state record for a DCCP connection.
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 default router, i.e. a single residential gateway to exactly one one default router, i.e. a single residential gateway to exactly one
Internet service provider. The use of Level 3 Multihoming Shim Internet service provider. The use of Level 3 Multihoming Shim
Protocol for IPv6 (SHIM6) [RFC5533] as a site multi-homing solution Protocol for IPv6 (SHIM6) [RFC5533] as a site multi-homing solution
skipping to change at page 22, line 14 skipping to change at page 21, line 49
reference addresses in SHIM6 headers when comparing and creating reference addresses in SHIM6 headers when comparing and creating
filter state corresponding to interior endpoint hosts. filter state corresponding to interior endpoint hosts.
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 [I-D.cheshire-nat-pmp] or [UPnP-IGD]. On IPv4/NAT networks either [I-D.cheshire-nat-pmp] or [UPnP-IGD]. On IPv4/NAT networks
connected by gateways without such services, applications must use connected by gateways without such services, applications must use
technique like Session Traversal Utilities for NAT (STUN) [RFC5389] techniques like Session Traversal Utilities for NAT (STUN) [RFC5389]
to obtain and maintain connectivity, despite the translation and to obtain and maintain connectivity, despite the translation and
filtering effects of NAT. filtering effects of NAT.
While NAT for IPv6 is unlikely to be used in most residential While NAT for IPv6 is unlikely to be used in most residential
gateways, the filtering effect of the simple security functions gateways, the filtering effect of the simple security functions
recommended by this document are derived from those in widespread use recommended by this document are derived from those in widespread use
on the IPv4 Internet, and a similar barrier to communication at on the IPv4 Internet, and a similar barrier to communication at
passive listeners is a natural outcome of its deployment. To avoid passive listeners is a natural outcome of its deployment. To avoid
the need for IPv6 applications to use techniques like STUN for the need for IPv6 applications to use techniques like STUN for
opening and maintaining dynamic filter state, something similar to opening and maintaining dynamic filter state, something similar to
NAT-PMP and UPnP-IGD but without actually supporting NAT needs to be NAT-PMP and UPnP-IGD but without actually supporting NAT needs to be
deployed. deployed. Alas, no consensus has yet emerged in the Internet
engineering community as to what is most appropriate for residential
Alas, no consensus has yet emerged in the Internet engineering IPv6 usage scenarios.
community as to what is most appropriate for residential IPv6 usage
scenarios.
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-40: Gateways SHOULD implement a protocol to permit applications REC-40: Gateways SHOULD implement a protocol to permit applications
to solicit inbound traffic without advance knowledge of the addresses to solicit inbound traffic without advance knowledge of the addresses
of exterior nodes with which they expect to communicate. of exterior nodes with which they expect to communicate.
REC-41: Gateways MUST provide an easily selected configuration option REC-41: Gateways MUST provide an easily selected configuration option
that permits operation in a mode that forwards all unsolicited flows that permits a "transparent mode" of operation that forwards all
regardless of forwarding direction. unsolicited flows regardless of forwarding direction, i.e. to disable
the IPv6 simple security capabilities of the gateway.
In general, "transparent mode" will enable more flexibility and
reliability for applications which require devices to be contacted
inside the home directly, particularly in absence of a protocol as
described in REC-40. Operating in transparent mode may come at the
expense of security if there are IPv6 nodes in the home that do not
have their own host-based firewall capability and require a firewall
in the gateway in order not to be compromised.
3.5. Management Applications 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.
skipping to change at page 23, line 26 skipping to change at page 23, line 15
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 interface. addresses MUST NOT be forwarded or transmitted on any interface.
REC-2 Packets which bear in their outer IPv6 headers multicast REC-2 Packets which bear in their outer IPv6 headers multicast
destination addresses of equal or narrower scope (see section 2.7 destination addresses of equal or narrower scope (see IPv6 Scoped
of IP Version 6 Addressing Architecture [RFC4291]) than the Address Architecture [RFC4007]) than the configured scope boundary
configured scope boundary level of the gateway MUST NOT be level of the gateway MUST NOT be forwarded in any direction. The
forwarded in any direction. The DEFAULT scope boundary level DEFAULT scope boundary level SHOULD be organization-local scope,
SHOULD be organization-local scope, and it SHOULD be configurable and it SHOULD be configurable by the network admininistrator.
by the network admininistrator.
REC-3 Packets bearing source and/or destination addresses forbidden REC-3 Packets bearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over the to appear in the outer headers of packets transmitted over the
public Internet MUST NOT be forwarded. In particular, site-local public Internet MUST NOT be forwarded. In particular, site-local
addresses are deprecated by [RFC3879], and [RFC5156] explicitly addresses are deprecated by [RFC3879], and [RFC5156] explicitly
forbids the use of addresses with IPv4-Mapped, IPv4-Compatible, forbids the use of addresses with IPv4-Mapped, IPv4-Compatible,
Documentation and ORCHID prefixes. Documentation and ORCHID prefixes.
REC-4 Packets bearing deprecated extension headers prior to their REC-4 Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be forwarded or first upper-layer-protocol header SHOULD NOT be forwarded or
skipping to change at page 24, line 31 skipping to change at page 24, line 19
protocols MUST BE indexable by a 3-tuple comprising the interior protocols MUST BE indexable by a 3-tuple comprising the interior
node address, the exterior node address and the upper-layer node address, the exterior node address and the upper-layer
transport protocol identifier. transport protocol identifier.
REC-11 Filter state records for generic upper-layer transport REC-11 Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer not protocols MUST NOT be deleted or recycled until an idle timer not
less than two minutes has expired without having forwarded a less than two minutes has expired without having forwarded a
packet matching the state in some configurable amount of time. By packet matching the state in some configurable amount of time. By
DEFAULT, the idle timer for such state records is five minutes. DEFAULT, the idle timer for such state records is five minutes.
REC-12 A state record for a UDP exchange where both interior and REC-12 IPv6 gateways MUST forward ICMP Destination Unreachable and
Packet Too Big messages containing IP headers that match generic
upper-layer transport state 3-tuples.
REC-13 A state record for a UDP exchange where both interior and
exterior ports are outside the well-known port range (ports exterior ports are outside the well-known port range (ports
0-1023) MUST NOT expire in less than two minutes of idle time. 0-1023) MUST NOT expire in less than two minutes of idle time.
The value of the UDP state record idle timer MAY be configurable. The value of the UDP state record idle timer MAY be configurable.
The DEFAULT is five minutes. The DEFAULT is five minutes.
REC-13 A state record for a UDP exchange where one or both of the REC-14 A state record for a UDP exchange where one or both of the
interior and exterior ports are in the well-known port range interior and exterior ports are in the well-known port range
(ports 0-1023) MAY expire after a period of idle time shorter than (ports 0-1023) MAY expire after a period of idle time shorter than
two minutes to facilitate the operation of the IANA-registered two minutes to facilitate the operation of the IANA-registered
service assigned to the port in question. service assigned to the port in question.
REC-14 A state record for a UDP exchange MUST be refreshed when a REC-15 A state record for a UDP exchange MUST be refreshed when a
packet is forwarded from the interior to the exterior, and it MAY packet is forwarded from the interior to the exterior, and it MAY
be refreshed when a packet is forwarded in the reverse direction. be refreshed when a packet is forwarded in the reverse direction.
REC-15 If application transparency is most important, then a REC-16 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 UDP. If a more stringent filtering behavior is most behavior for UDP. 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 the network administrator, and it MAY be independent of the
filtering behavior for TCP and other protocols. Filtering filtering behavior for TCP and other protocols. Filtering
behavior SHOULD by endpoint independent by DEFAULT in gateways behavior SHOULD by endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider management. intended for provisioning without service-provider management.
REC-16 If a gateway forwards a UDP exchange, it MUST also forward REC-17 If a gateway forwards a UDP exchange, it MUST also forward
ICMP Destination Unreachable messages containing UDP headers that ICMP Destination Unreachable and Packet Too Big messages
match the exchange state record. containing UDP headers that match the exchange state record.
REC-17 Receipt of any sort of ICMP message MUST NOT terminate the REC-18 Receipt of any sort of ICMP message MUST NOT terminate the
state record for a UDP exchange. state record for a UDP exchange.
REC-18 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same REC-19 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same
way as UDP exchanges, except that the upper-layer transport way as UDP exchanges, except that the upper-layer transport
protocol identifier for UDP-Lite is not the same as UDP, and protocol identifier for UDP-Lite is not the same as UDP, and
therefore UDP packets MUST NOT match UDP-Lite state records, and therefore UDP packets MUST NOT match UDP-Lite state records, and
vice versa. vice versa.
REC-19 Where a globally routed IPv6 prefix is advertised on an
interior interface and IPv4 Internet service is provided with NAT
[RFC4787], the Teredo qualification procedure (see section 5.2.1
and 5.2.2 of [RFC4380]) for clients in the interior MUST be
prohibited by the IPv4/NAT stateful filter. This SHOULD be done
by blocking outbound UDP initiations to port 3544, the port
reserved by IANA for Teredo servers.
REC-20 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-20 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with destination extension headers of type addresses, with destination extension headers of type
"Authenticated Header (AH)" [RFC4302] in their outer IP extension "Authenticated Header (AH)" [RFC4302] in their outer IP extension
header chain. header chain.
REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with an upper layer protocol of type "Encapsulating addresses, with an upper layer protocol of type "Encapsulating
Security Payload (ESP)" [RFC4303] in their outer IP extension Security Payload (ESP)" [RFC4303] in their outer IP extension
skipping to change at page 26, line 44 skipping to change at page 26, line 31
REC-28 If a gateway cannot determine whether the endpoints of a TCP REC-28 If a gateway cannot determine whether the endpoints of a TCP
connection are active, then it MAY abandon the state record if it connection are active, then it MAY abandon the state record if it
has been idle for some time. In such cases, the value of the has been idle for some time. In such cases, the value of the
"established connection idle-timeout" MUST NOT be less than two "established connection idle-timeout" MUST NOT be less than two
hours four minutes, as discussed in [RFC5382]. The value of the hours four minutes, as discussed in [RFC5382]. The value of the
"transitory connection idle-timeout" MUST NOT be less than four "transitory connection idle-timeout" MUST NOT be less than four
minutes. The value of the idle-timeouts MAY be configurable by minutes. The value of the idle-timeouts MAY be configurable by
the network administrator. the network administrator.
REC-29 If a gateway forwards a TCP connection, it MUST also forward REC-29 If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that ICMP Destination Unreachable and Packet Too Big messages
match the connection state record. containing TCP headers that match the connection state record.
REC-30 Receipt of any sort of ICMP message MUST NOT terminate the REC-30 Receipt of any sort of ICMP message MUST NOT terminate the
state record for a TCP connection. state record for a TCP connection.
REC-31 All valid sequences of SCTP packets (defined in [RFC4960]) REC-31 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 normal permitted inbound associations. In particular, both the normal
SCTP association establishment and simultaneous-open modes of SCTP association establishment and simultaneous-open modes of
operation MUST be supported. operation MUST be supported.
skipping to change at page 27, line 26 skipping to change at page 27, line 9
REC-33 If a gateway cannot determine whether the endpoints of an REC-33 If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state record 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 if it has been idle for some time. In such cases, the value of
the "established association idle-timeout" MUST NOT be less than the "established association idle-timeout" MUST NOT be less than
two hours four minutes. The value of the "transitory association two hours four minutes. The value of the "transitory association
idle-timeout" MUST NOT be less than four minutes. The value of idle-timeout" MUST NOT be less than four minutes. The value of
the idle-timeouts MAY be configurable by the network the idle-timeouts MAY be configurable by the network
administrator. administrator.
REC-34 If a gateway forwards an SCTP association, it MUST also REC-34 If a gateway forwards an SCTP association, it MUST also
forward ICMP Destination Unreachable messages containing SCTP forward ICMP Destination Unreachable and Packet Too Big messages
headers that match the association state record. containing SCTP headers that match the association state record.
REC-35 Receipt of any sort of ICMP message MUST NOT terminate the REC-35 Receipt of any sort of ICMP message MUST NOT terminate the
state record for an SCTP association. state record for an SCTP association.
REC-36 All valid sequences of DCCP packets (defined in [RFC4340]) REC-36 All valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all connections to exterior servers and MUST be forwarded for all connections to exterior servers and
those connections to interior servers with explicitly permitted those connections to interior servers with explicitly permitted
service codes. service codes.
REC-37 A gateway MAY abandon a DCCP state record if it has been idle REC-37 A gateway MAY abandon a DCCP state record if it has been idle
for some time. In such cases, the value of the "established for some time. In such cases, the value of the "established
connection idle-timeout" MUST NOT be less than two hours four connection idle-timeout" MUST NOT be less than two hours four
minutes. The value of the "transitory connection idle-timeout" minutes. The value of the "transitory connection 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-38 If a gateway forwards a DCCP connection, it MUST also forward REC-38 If a gateway forwards a DCCP connection, it MUST also forward
ICMP Destination Unreachable messages containing DCCP headers that ICMP Destination Unreachable and Packet Too Big messages
match the connection state record. containing DCCP headers that match the connection state record.
REC-39 Receipt of any sort of ICMP message MUST NOT terminate the REC-39 Receipt of any sort of ICMP message MUST NOT terminate the
state record for a DCCP connection. state record for a DCCP connection.
REC-40 Gateways SHOULD implement a protocol to permit applications REC-40 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 communicate. addresses of exterior nodes with which they expect to communicate.
REC-41 Gateways MUST provide an easily selected configuration option REC-41 Gateways MUST provide an easily selected configuration option
that permits operation in a mode that forwards all unsolicited that permits a "transparent mode" of operation that forwards all
flows regardless of forwarding direction. unsolicited flows regardless of forwarding direction, i.e. to
disable the IPv6 simple security capabilities of the gateway.
REC-42 By DEFAULT, subscriber managed residential gateways MUST NOT REC-42 By DEFAULT, subscriber managed residential gateways MUST NOT
offer management application services to the exterior network. offer management application services to the exterior 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 Fred Baker
skipping to change at page 29, line 36 skipping to change at page 29, line 18
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
The IPv6 stateful filtering behavior described in this document is The IPv6 stateful filtering behavior described in this document is
intended to be similar in function to the filtering behavior of intended to be similar in function to the filtering behavior of
commonly use IPv4/NAT gateways, which have been widely sold as a commonly use IPv4/NAT gateways, which have been widely sold as a
security tool for residential and small-office/home-office networks. security tool for residential and small-office/home-office networks.
As noted in the security considerations section of [RFC2993], the As noted in the security considerations section of [RFC2993], the
true impact of these tools may be a reduction in security. It may be true impact of these tools may be a reduction in security. It may be
generally assumed that the impacts discussed there related to generally assumed that the impacts discussed in that document related
filtering (and not translation) are to be expected with the simple to filtering (and not translation) are to be expected with the simple
IPv6 security mechanisms described here. IPv6 security mechanisms described here.
In particular, it's worth noting that stateful filters create the In particular, it's worth noting that stateful filters create the
illusion of a security barrier, but without the managed intent of a illusion of a security barrier, but without the managed intent of a
firewall. Appropriate security mechanisms implemented in the end firewall. Appropriate security mechanisms implemented in the end
nodes, in conjunction with the [RFC4864] local network protection nodes, in conjunction with the [RFC4864] local network protection
methods, function without reliance on network layer hacks and methods, function without reliance on network layer hacks and
transport filters that may change over time. Also, defined security transport filters that may change over time. Also, defined security
barriers assume that threats originate in the exterior, which may barriers assume that threats originate in the exterior, which may
lead to practices that result in applications being fully exposed to lead to practices that result in applications being fully exposed to
interior attack and which therefore make breaches much easier. interior attack and which therefore make breaches much easier.
The security functions described in this document may be considered
redundant in the event that all IPv6 hosts using a particular gateway
have their own IPv6 host firewall capabilities enabled. At the time
of this writing, the vast majority of commercially available
operating systems with support for IPv6 include IPv6 host firewall
capability.
Finally, residential gateways that implement simple security Finally, residential gateways that implement simple security
functions are a bastion between the interior and the exterior, and functions are a bastion between the interior and the exterior, and
therefore are a target of denial of service attacks against the therefore are a target of denial of service attacks against the
interior network itself by processes designed to consume the interior network itself by processes designed to consume the
resources of the gateway, e.g. a ping or SYN flood. Gateways should resources of the gateway, e.g. a ping or SYN flood. Gateways should
employ the same sorts of protection techniques as application servers employ the same sorts of protection techniques as application servers
on the Internet. on the Internet.
IETF makes no statement, expressed or implied, as to whether using
the capabilities described in this document ultimately improve
security for any individual users or for the Internet community as a
whole.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
skipping to change at page 30, line 39 skipping to change at page 30, line 32
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884, "Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007. April 2007.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
skipping to change at page 37, line 5 skipping to change at page 36, line 48
A.9. draft-ietf-v6ops-cpe-simple-security-08 to A.9. draft-ietf-v6ops-cpe-simple-security-08 to
draft-ietf-v6ops-cpe-simple-security-09 draft-ietf-v6ops-cpe-simple-security-09
o Add references to [RFC2827] and [RFC3704] for uRPF spoofing. o Add references to [RFC2827] and [RFC3704] for uRPF spoofing.
o Add REC-42 to discourage use of the WAN interface for management. o Add REC-42 to discourage use of the WAN interface for management.
o Updated contributors. o Updated contributors.
A.10. draft-ietf-v6ops-cpe-simple-security-09 to
draft-ietf-v6ops-cpe-simple-security-10
o Cite [RFC4007] in REC-2.
o Insert REC-12 to complete consistency of recommendations with
those in [RFC4890] and renumber subsequent recommendations.
o Completely remove recommendation to block Teredo.
o Soften the language recommending implementation of simple
security. Insert explicit note about intent of the document to
inform and not to prescribe.
o Editorial revision in section 2.2 to match the removal of section
3.2.7 in the -08 revision.
o Editorial improvements to promote the phrase "transparent mode" to
describe the alternative operating mode recommended in REC-41.
o Fix some minor spelling and grammar errors.
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. 57 change blocks. 
148 lines changed or deleted 171 lines changed or added

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