draft-ietf-v6ops-cpe-simple-security-03.txt   draft-ietf-v6ops-cpe-simple-security-04.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Best Current July 29, 2008 Intended status: BCP March 23, 2009
Practice Expires: September 24, 2009
Expires: January 30, 2009
Recommended Simple Security Capabilities in Customer Premises Equipment Recommended Simple Security Capabilities in Customer Premises Equipment
for Providing Residential IPv6 Internet Service for Providing Residential IPv6 Internet Service
draft-ietf-v6ops-cpe-simple-security-03 draft-ietf-v6ops-cpe-simple-security-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 January 30, 2009. This Internet-Draft will expire on September 24, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 28 skipping to change at page 2, line 29
3.2.3. Teredo-specific Filters . . . . . . . . . . . . . . . 10 3.2.3. Teredo-specific Filters . . . . . . . . . . . . . . . 10
3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10
3.2.5. Other Virtual Private Network Protocols . . . . . . . 11 3.2.5. Other Virtual Private Network Protocols . . . . . . . 11
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 11 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 11
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 15 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 15
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 18 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 18
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 20 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 20
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 21 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 21
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . 30 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 29
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 . . . . . . . . . 30 draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 30
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 . . . . . . . . . 31 draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 30
A.4. draft-ietf-v6ops-cpe-simple-security-03 to
draft-ietf-v6ops-cpe-simple-security-04 . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
In "Local Network Protection for IPv6" [RFC4864], IETF recommends In "Local Network Protection for IPv6" [RFC4864], IETF recommends
'simple security' capabilities for gateway devices that enable 'simple security' capabilities for gateway devices that enable
delivery of Internet services in residential and small office delivery of Internet services in residential and small office
settings. The principle goal of these capabilties is to improve settings. The principle goal of these capabilties is to improve
security of the IPv6 Internet without increasing the perceived security of the IPv6 Internet without increasing the perceived
complexity for users who just want to accomplish useful work. complexity for users who just want to accomplish useful work.
skipping to change at page 10, line 28 skipping to change at page 10, line 28
Transitional residential IPv6 gateways that also feature integrated Transitional residential IPv6 gateways that also feature integrated
IPv4/NAT gateways require special filtering for Teredo tunnels. IPv4/NAT gateways require special filtering for Teredo tunnels.
R18: Where an IPv6 prefix is advertised on an interior interface R18: Where an IPv6 prefix is advertised on an interior interface
alongside an IPv4 private address [RFC1918] and IPv4 Internet service alongside an IPv4 private address [RFC1918] and IPv4 Internet service
is provided with NAT [RFC4787], the Teredo qualification procedure is provided with NAT [RFC4787], the Teredo qualification procedure
(see section 5.2.1 and 5.2.2 of [RFC4380]) for clients in the (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 interior MUST be prohibited by the IPv4/NAT stateful filter. This
SHOULD be done by blocking outbound UDP initiations to port 3544, the SHOULD be done by blocking outbound UDP initiations to port 3544, the
port reserved by IANA for Teredo servers. This MAY be done by port reserved by IANA for Teredo servers.
discarding Teredo packets identified by the heuristic defined in
"Teredo Security Concerns Beyond What Is In RFC 4380" [HOAGLAND].
[ EDITOR: In the event [HOAGLAND] does not advance to publication as
an RFC, then that heuristic will be reproduced here. ]
3.2.4. IPsec and Internet Key Exchange (IKE) 3.2.4. 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.
R19: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R19: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
skipping to change at page 12, line 38 skipping to change at page 12, line 33
R25: The TCP window invariant MUST NOT be enforced on connections for R25: The TCP window invariant MUST NOT be enforced on connections for
which the filter did not detect whether the window-scale option (see which the filter did not detect whether the window-scale option (see
[RFC1323]) was sent in the 3-way handshake or simultaneous open. [RFC1323]) was sent in the 3-way handshake or simultaneous open.
A stateful filter can allow an existing state record to be reused by A stateful filter can allow an existing state record to be reused by
an externally initiated connection if its security policy permits. an externally initiated connection if its security policy permits.
Several different policies are possible as described in "Network Several different policies are possible as described in "Network
Address Translation (NAT) Behavioral Requirements for Unicast UDP Address Translation (NAT) Behavioral Requirements for Unicast UDP
[RFC4787] and extended in "NAT Behaviorial Requirements for TCP" [RFC4787] and extended in "NAT Behaviorial Requirements for TCP"
[BEHAVE-TCP]. [RFC5382].
R26: If application transparency is most important, then a stateful R26: If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior for packet filter SHOULD have "Endpoint independent filter" behavior for
TCP. If a more stringent filtering behavior is most important, then TCP. If a more stringent filtering behavior is most important, then
a filter SHOULD have "Address dependent filtering" behavior. The a filter SHOULD have "Address dependent filtering" behavior. The
filtering behavior MAY be an option configurable by the network filtering behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering behavior administrator, and it MAY be independent of the filtering behavior
for UDP and other protocols. for UDP and other protocols.
If an inbound SYN packet is filtered, either because a corresponding If an inbound SYN packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error silently, or to signal an error to the sender. Signaling an error
through ICMP messages allows the sender to detect that the SYN did through ICMP messages allows the sender to detect that the SYN did
not reach the intended destination. Discarding the packet, on the not reach the intended destination. Discarding the packet, on the
other hand, allows applications to perform simultaneous-open more other hand, allows applications to perform simultaneous-open more
reliably. A more detailed discussion of this issue can be found in reliably. A more detailed discussion of this issue can be found in
[BEHAVE-TCP], but the basic outcome of it is that filters need to [RFC5382], but the basic outcome of it is that filters need to wait
wait on signaling errors until simultaneous-open will not be on signaling errors until simultaneous-open will not be impaired.
impaired.
R27: A gateway MUST NOT signal an error for an unsolicited inbound R27: A gateway MUST NOT signal an error for an unsolicited inbound
SYN packet for at least 6 seconds after the packet is received. If SYN packet for at least 6 seconds after the packet is received. If
during this interval the gateway receives and forwards an outbound during this interval the gateway receives and forwards an outbound
SYN for the connection, then the gateway MUST discard the original SYN for the connection, then the gateway MUST discard the original
unsolicited inbound SYN packet without signaling an error. unsolicited inbound SYN packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN-- error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of the unless sending any response violates the security policy of the
network administrator. network administrator.
skipping to change at page 18, line 47 skipping to change at page 18, line 42
codes. codes.
It is possible to reconstruct enough of the state of a DCCP It is possible to reconstruct enough of the state of a DCCP
connection to allow forwarding between an interior and exterior node connection to allow forwarding between an interior and exterior node
even when the filter starts operating after DCCP enters the OPEN even when the filter starts operating after DCCP enters the OPEN
state. Also, a filter can allow an existing state record to be state. Also, a filter can allow an existing state record to be
reused by an externally initiated connection if its security policy reused by an externally initiated connection if its security policy
permits. As with TCP, several different policies are possible, with permits. As with TCP, several different policies are possible, with
a good discussion of the issue involved presented in Network Address a good discussion of the issue involved presented in Network Address
Translation (NAT) Behavioral Requirements for Unicast UDP [RFC4787] Translation (NAT) Behavioral Requirements for Unicast UDP [RFC4787]
and extended in NAT Behaviorial Requirements for TCP [BEHAVE-TCP]. and extended in NAT Behaviorial Requirements for TCP [RFC5382].
If an inbound DCCP-Request packet is filtered, either because a If an inbound DCCP-Request packet is filtered, either because a
corresponding state record does not already exist for it or because corresponding state record does not already exist for it or because
of the filter's normal behavior of refusing connections not of the filter's normal behavior of refusing connections not
explicitly permitted, then a filter has two basic choices: to discard explicitly permitted, then a filter has two basic choices: to discard
the packet silently, or to signal an error to the sender. Signaling the packet silently, or to signal an error to the sender. Signaling
an error through ICMP messages allows the sender to detect that the an error through ICMP messages allows the sender to detect that the
DCCP-Request did not reach the intended destination. Discarding the DCCP-Request did not reach the intended destination. Discarding the
packet, on the other hand, only delays the failure to connect and packet, on the other hand, only delays the failure to connect and
provides no measurable security. provides no measurable security.
skipping to change at page 20, line 44 skipping to change at page 20, line 39
match the connection state record. match the connection state record.
R39: Receipt of any sort of ICMP message MUST NOT terminate the state R39: Receipt of any sort of ICMP message MUST NOT terminate the state
record for a DCCP connection. record for a DCCP connection.
3.4. Passive Listeners 3.4. Passive Listeners
Some applications expect to solicit traffic from exterior nodes Some applications expect to solicit traffic from exterior nodes
without any advance knowledge of the exterior address. This without any advance knowledge of the exterior address. This
requirement is met by IPv4/NAT gateways typically by the use of requirement is met by IPv4/NAT gateways typically by the use of
either [NAT-PMP] or [UPnP-IGD]. either [I-D.cheshire-nat-pmp] or [UPnP-IGD].
One proposal that has been offered as an Internet Draft is the One proposal that has been offered as an Internet Draft is the
Application Listener Discovery Protocol [IPv6-ALD]. It remains to be Application Listener Discovery Protocol [I-D.woodyatt-ald]. It
seen whether the Internet Gateway Device profile of the Universal remains to be seen whether the Internet Gateway Device profile of the
Plug And Play protocol will be extended for IPv6. Other proposals of Universal Plug And Play protocol will be extended for IPv6. Other
note include the Middlebox Communication Protocol [RFC3989] and the proposals of note include the Middlebox Communication Protocol
Next Steps in Signaling framework [RFC4080]. No consensus has yet [RFC3989] and the Next Steps in Signaling framework [RFC4080]. No
emerged in the Internet engineering community as to which proposal is consensus has yet emerged in the Internet engineering community as to
most appropriate for residential IPv6 usage scenarios. which proposal is most appropriate for residential IPv6 usage
scenarios.
R31: Gateways MUST implement a protocol to permit applications to R31: Gateways MUST implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses of solicit inbound traffic without advance knowledge of the addresses of
exterior nodes with which they expect to communicate. This protocol exterior nodes with which they expect to communicate. This protocol
MUST have a specification that meets the requirements of [RFC3978], MUST have a specification that meets the requirements of [RFC5378],
[RFC3979] and [RFC4748]. [RFC3979], [RFC4748] and [RFC4879].
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.
R1 Packets bearing in their outer IPv6 headers multicast source R1 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.
R2 Packets bearing in their outer IPv6 headers multicast destination R2 Packets bearing in their outer IPv6 headers multicast destination
skipping to change at page 23, line 19 skipping to change at page 23, line 16
as UDP exchanges, except that the upper-layer transport protocol 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.
R18 Where an IPv6 prefix is advertised on an interior interface R18 Where an IPv6 prefix is advertised on an interior interface
alongside an IPv4 private address [RFC1918] and IPv4 Internet alongside an IPv4 private address [RFC1918] and IPv4 Internet
service is provided with NAT [RFC4787], the Teredo qualification service is provided with NAT [RFC4787], the Teredo qualification
procedure (see section 5.2.1 and 5.2.2 of [RFC4380]) for clients 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 in the interior MUST be prohibited by the IPv4/NAT stateful
filter. This SHOULD be done by blocking outbound UDP initiations filter. This SHOULD be done by blocking outbound UDP initiations
to port 3544, the port reserved by IANA for Teredo servers. This to port 3544, the port reserved by IANA for Teredo servers.
MAY be done by discarding Teredo packets identified by the
heuristic defined in "Teredo Security Concerns Beyond What Is In
RFC 4380" [HOAGLAND].
R19 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R19 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
with destination extension headers of type "Authenticated Header with destination extension headers of type "Authenticated Header
(AH)" [RFC4302] in their outer IP extension header chain. (AH)" [RFC4302] in their outer IP extension header chain.
R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
with an upper layer protocol of type "Encapsulating Security with an upper layer protocol of type "Encapsulating Security
Payload (ESP)" [RFC4303] in their outer IP extension header chain. Payload (ESP)" [RFC4303] in their outer IP extension header chain.
skipping to change at page 25, line 9 skipping to change at page 24, line 48
ICMP Destination Unreachable messages containing TCP headers that ICMP Destination Unreachable messages containing TCP headers that
match the connection state record. match the connection state record.
R30 Receipt of any sort of ICMP message MUST NOT terminate the state R30 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a TCP connection. record for a TCP connection.
R31 Gateways MUST implement a protocol to permit applications to R31 Gateways MUST implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses solicit inbound traffic without advance knowledge of the addresses
of exterior nodes with which they expect to communicate. This of exterior nodes with which they expect to communicate. This
protocol MUST have a specification that meets the requirements of protocol MUST have a specification that meets the requirements of
[RFC3978], [RFC3979] and [RFC4748]. [RFC5378], [RFC3979], [RFC4879] and [RFC4748].
R33 All valid sequences of SCTP packets (defined in [RFC4960]) MUST R33 All valid sequences of SCTP packets (defined in [RFC4960]) MUST
be forwarded for outbound associations and explicitly permitted be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP inbound associations. In particular, both the normal SCTP
association establishment and simultaneous-open modes of operation association establishment and simultaneous-open modes of operation
MUST be supported. MUST be supported.
R34 A gateway MUST NOT signal an error for an unsolicited inbound R34 A gateway MUST NOT signal an error for an unsolicited inbound
INIT packet for at least 6 seconds after the packet is received. INIT packet for at least 6 seconds after the packet is received.
If during this interval the gateway receives and forwards an If during this interval the gateway receives and forwards an
skipping to change at page 26, line 45 skipping to change at page 26, line 40
Kurt Erik Lindqvist Kurt Erik Lindqvist
Iljitsch van Beijnum Iljitsch van Beijnum
Yaron Sheffer Yaron Sheffer
Dan Wing Dan Wing
Much of the text describing the detailed requirements for TCP and UDP Much of the text describing the detailed requirements for TCP and UDP
filtering is derived or transposed from [BEHAVE-TCP] and [RFC4787], filtering is derived or transposed from [RFC5382] and [RFC4787], and
and some form of attribution here may therefore be appopriate. some form of attribution here may therefore be appopriate.
6. IANA Considerations 6. IANA Considerations
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
skipping to change at page 28, line 15 skipping to change at page 28, line 7
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005. Technology", BCP 79, RFC 3979, March 2005.
[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 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF
Trust", BCP 78, RFC 4748, October 2006. Trust", RFC 4748, October 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.
[RFC4879] Narten, T., "Clarification of the Third Party Disclosure
Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
8.2. Informative References [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[BEHAVE-TCP]
Guha, S., Biswas, K., Sivakumar, S., Ford, B., and P.
Srisuresh, "NAT Behavioral Requirements for TCP",
April 2007,
<http://tools.ietf.org/html/draft-ietf-behave-tcp>.
[HOAGLAND] 8.2. Informative References
Hoagland, J. and S. Krishnan, "Teredo Security Concerns
Beyond What Is In RFC 4380", July 2007, <http://
tools.ietf.org/html/
draft-hoagland-v6ops-teredosecconcerns>.
[IPv6-ALD] [I-D.cheshire-nat-pmp]
Woodyatt, j., "Application Listener Discovery (ALD) for Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
IPv6", May 2007, draft-cheshire-nat-pmp-03 (work in progress), April 2008.
<http://tools.ietf.org/html/draft-woodyatt-ald>.
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port [I-D.woodyatt-ald]
Mapping Protocol (NAT-PMP)", November 2001, Woodyatt, J., "Application Listener Discovery (ALD) for
<http://tools.ietf.org/html/draft-cheshire-nat-pmp>. IPv6", draft-woodyatt-ald-03 (work in progress),
July 2008.
[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.
skipping to change at page 29, line 49 skipping to change at page 29, line 33
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.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway UPnP Forum, "Universal Plug and Play Internet Gateway
Device Standardized Gateway Device Protocol", Device Standardized Gateway Device Protocol",
September 2006, September 2006,
<http://www.upnp.org/standardizeddcps/igd.asp>. <http://www.upnp.org/standardizeddcps/igd.asp>.
Appendix A. Change Log Appendix A. Change Log
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 draft-ietf-v6ops-cpe-simple-security-01
skipping to change at page 30, line 23 skipping to change at page 30, line 13
services to the local network. services to the local network.
o Fixed numbering of recommendations. o Fixed numbering of recommendations.
o Local Network Protection is now [RFC4864]. o Local Network Protection is now [RFC4864].
o SCTP is now [RFC4960]. o SCTP is now [RFC4960].
o Moved some references to informative. o Moved some references to informative.
o Corrected the reference for [HOAGLAND]. o Corrected the reference for
draft-hoagland-v6ops-teredosecconcerns.
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 draft-ietf-v6ops-cpe-simple-security-02
o Inserted R20, i.e. do not enforce TCP window invariant unless the o Inserted R20, i.e. do not enforce TCP window invariant unless the
TCP window-scale is known for the state. TCP window-scale is known for the state.
o Filled out Section 4. o Filled out Section 4.
o Added reference to [RFC1323]. o Added reference to [RFC1323].
o Updated the reference for [HOAGLAND]. o Updated the reference for draft-hoagland-v6ops-teredosecconcerns.
o Expanded list of contributers and commenters. o Expanded list of contributers and commenters.
o Mention that UDP-Lite should be handled just like UDP. o Mention that UDP-Lite should be handled just like UDP.
o Added section for generic upper layer transport protocols. o Added section for generic upper layer transport protocols.
o Expanded on recommendations for IPsec ESP filtering. o Expanded on recommendations for IPsec ESP filtering.
o Expanded overview of recommendations with discussion about IP o Expanded overview of recommendations with discussion about IP
skipping to change at page 31, line 17 skipping to change at page 31, line 5
o Fixed some spelling errors. o Fixed some spelling errors.
o Replace "prevent such attacks" with "defend against such attacks" o Replace "prevent such attacks" with "defend against such attacks"
everywhere. everywhere.
o Replace "mapping" with "state record" in the TCP filters section. o Replace "mapping" with "state record" in the TCP filters section.
o Added recommendations for SCTP and DCCP. o Added recommendations for SCTP and DCCP.
A.4. draft-ietf-v6ops-cpe-simple-security-03 to
draft-ietf-v6ops-cpe-simple-security-04
o Removed references to draft-hoagland-v6ops-teredosecconcerns.
o Updated reference to [RFC5382].
o Add reference to [RFC4879].
o Use SYSTEM resources for referencing Internet Drafts.
o Updated IPR boilerplate.
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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 32 change blocks. 
69 lines changed or deleted 75 lines changed or added

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