draft-ietf-v6ops-cpe-simple-security-08.txt   draft-ietf-v6ops-cpe-simple-security-09.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Informational October 19, 2009 Intended status: Informational February 18, 2010
Expires: April 22, 2010 Expires: August 22, 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-08 draft-ietf-v6ops-cpe-simple-security-09
Abstract
This document makes specific recommendations to the makers of devices
that provide "simple security" capabilities at the perimeter of
local-area IPv6 networks in Internet-enabled homes and small offices.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 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 April 22, 2010. This Internet-Draft will expire on August 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document makes specific recommendations to the makers of devices described in the BSD License.
that provide "simple security" capabilities at the perimeter of
local-area IPv6 networks in Internet-enabled homes and small offices.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 7
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 7 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 29 skipping to change at page 2, line 33
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. Teredo-specific Filters . . . . . . . . . . . . . . . 11
3.2.6. IPsec and Internet Key Exchange (IKE) . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22
3.5. Management Applications . . . . . . . . . . . . . . . . . 23
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . 32 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 . . . . . . . . . 32 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 . . . . . . . . . 33 draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 34
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 . . . . . . . . . 33 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 . . . . . . . . . 35 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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.9. draft-ietf-v6ops-cpe-simple-security-08 to
draft-ietf-v6ops-cpe-simple-security-09 . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
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 capabilities is to improve settings. The principle goal of these capabilities 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 8, line 15 skipping to change at page 8, line 15
participants are nodes on the interior network. participants are nodes on the interior network.
3.1. Stateless Filters 3.1. Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses, state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved packets to destinations with certain non-routable and/or reserved
prefixes and packets with deprecated extension headers. prefixes and packets with deprecated extension headers.
Other stateless filters are recommended to guard against spoofing, to Other stateless filters are recommended to implement ingress
enforce multicast scope boundaries, and to isolate certain local filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
network services from the public Internet. boundaries, and to isolate certain local network services from the
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 section 2.7 of
IP Version 6 Addressing Architecture [RFC4291]) than the configured IP Version 6 Addressing Architecture [RFC4291]) than the configured
scope boundary level of the gateway MUST NOT be forwarded in any scope boundary level of the gateway MUST NOT be forwarded in any
direction. The DEFAULT scope boundary level SHOULD be organization- direction. The DEFAULT scope boundary level SHOULD be organization-
skipping to change at page 17, line 7 skipping to change at page 17, line 7
Peer-to-peer applications use an alternate method of association Peer-to-peer applications use an alternate method of association
initiation termed simultaneous-open to traverse stateful filters. In initiation termed simultaneous-open to traverse stateful filters. In
the simultaneous-open mode of operation, both peers send INIT chunks the simultaneous-open mode of operation, both peers send INIT chunks
at the same time to establish an association. Upon receiving the at the same time to establish an association. Upon receiving the
other end's INIT chunk, each end responds with an INIT-ACK packet, 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 which is expected to traverse the same path in reverse. Because only
one SCTP association may exist between any two network addresses, one one SCTP association may exist between any two network addresses, one
of the peers in simultaneous-open mode of operation will send an of the peers in simultaneous-open mode of operation will send an
ERROR or ABORT chunk along with the INIT-ACK chunk. The association ERROR or ABORT chunk along with the INIT-ACK chunk. The association
is established at each endpoint once an INIT-ACK chunks is is established at each endpoint once an INIT-ACK chunks is received
receivedA at one end without an ERROR or ABORT chunk. at one end without an ERROR or ABORT chunk.
To provide stateful packet filtering service for SCTP, it is To provide stateful packet filtering service for SCTP, it is
necessary for a filter to receive, process and forward all packets necessary for a filter to receive, process and forward all packets
for an association that conform to valid transitions of the SCTP for an association that conform to valid transitions of the SCTP
state machine (Fig. 3, [RFC4960]). state machine (Fig. 3, [RFC4960]).
REC-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 permitted MUST be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP inbound associations. In particular, both the normal SCTP
association establishment and simultaneous-open modes of operation association establishment and simultaneous-open modes of operation
skipping to change at page 23, line 5 skipping to change at page 23, line 5
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 operation in a mode that forwards all unsolicited flows
regardless of forwarding direction. regardless of forwarding direction.
3.5. Management Applications
Subscriber managed residential gateways are unlikely ever to be
completely zero-configuration, but their administrators will very
often possess no particular expertise in Internet engineering. In
general, the specification of management interfaces for residential
gateways is out of scope for this document, but security of
subscriber managed gateways merit special attention here.
REC-42: By DEFAULT, subscriber managed residential gateways MUST NOT
offer management application services to the exterior network.
4. Summary of Recommendations 4. Summary of Recommendations
This section collects all of the recommendations made in this This section collects all of the recommendations made in this
document into a convenient list. document into a convenient list.
REC-1 Packets bearing in their outer IPv6 headers multicast source REC-1 Packets bearing in their outer IPv6 headers multicast source
addresses MUST NOT be forwarded or transmitted on any 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 section 2.7
skipping to change at page 27, line 48 skipping to change at page 28, line 13
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 operation in a mode that forwards all unsolicited
flows regardless of forwarding direction. flows regardless of forwarding direction.
REC-42 By DEFAULT, subscriber managed residential gateways MUST NOT
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
Norbert Bollow Norbert Bollow
Cameron Byrne
Brian Carpenter Brian Carpenter
Remi Despres Remi Despres
Fabrice Fontaine Fabrice Fontaine
Jun-ichiro itojun Hagino Jun-ichiro "itojun" Hagino
Thomas Herbst Thomas Herbst
Christian Huitema Christian Huitema
Joel Jaeggli Joel Jaeggli
Cullen Jennings Cullen Jennings
Suresh Krishnan Suresh Krishnan
skipping to change at page 31, line 33 skipping to change at page 32, line 7
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992. RFC 1337, May 1992.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005. RFC 4080, June 2005.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006. April 2006.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864, E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007. May 2007.
skipping to change at page 36, line 24 skipping to change at page 36, line 43
including REC-24. including REC-24.
o Improve section 3.4, Passive Listeners, with a reference to o Improve section 3.4, Passive Listeners, with a reference to
[RFC5389] and further explanation of motivation for [RFC5389] and further explanation of motivation for
recommendations. recommendations.
o Correct order of recommendations in summary section. o Correct order of recommendations in summary section.
o Update reference to [RFC5533]. o Update reference to [RFC5533].
A.9. draft-ietf-v6ops-cpe-simple-security-08 to
draft-ietf-v6ops-cpe-simple-security-09
o Add references to [RFC2827] and [RFC3704] for uRPF spoofing.
o Add REC-42 to discourage use of the WAN interface for management.
o Updated contributors.
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. 24 change blocks. 
32 lines changed or deleted 72 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/