draft-ietf-v6ops-cpe-simple-security-01.txt   draft-ietf-v6ops-cpe-simple-security-02.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Best Current December 21, 2007 Intended status: Best Current February 13, 2008
Practice Practice
Expires: June 23, 2008 Expires: August 16, 2008
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-01 draft-ietf-v6ops-cpe-simple-security-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2008. This Internet-Draft will expire on August 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document makes specific recommendations to the makers of devices This document makes specific recommendations to the makers of devices
that provide "simple security" capabilities at the perimeter of that provide "simple security" capabilities at the perimeter of
local-area IPv6 networks in Internet-enabled homes and small offices. local-area IPv6 networks in Internet-enabled homes and small offices.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5 2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8
3.2.1. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Upper-layer Transport Protocols . . . . . . . . . . . 8
3.2.2. Teredo-specific Filters . . . . . . . . . . . . . . . 9 3.2.2. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10 3.2.3. Teredo-specific Filters . . . . . . . . . . . . . . . 10
3.2.4. Other Virtual Private Network Protocols . . . . . . . 10 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 10 3.2.5. Other Virtual Private Network Protocols . . . . . . . 11
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 11
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 14 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 15
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 14 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 15
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 14 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 15
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 15
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . 17 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. draft-ietf-v6ops-cpe-simple-security-01 to
Intellectual Property and Copyright Statements . . . . . . . . . . 19 draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
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 5, line 20 skipping to change at page 5, line 20
2.1. Basic Sanitation 2.1. Basic Sanitation
In addition to the functions required of all Internet routers In addition to the functions required of all Internet routers
[RFC4294], residential gateways are expected to have basic stateless [RFC4294], residential gateways are expected to have basic stateless
filters for prohibiting certains kinds of traffic with invalid filters for prohibiting certains kinds of traffic with invalid
headers, e.g. martian packets, spoofs, routing header type code zero, headers, e.g. martian packets, spoofs, routing header type code zero,
etc. etc.
Internet gateways that route multicast traffic are expected to Internet gateways that route multicast traffic are expected to
implement appropriate filters for scoped multicast addresses. By implement appropriate filters for scoped multicast addresses.
DEFAULT, residential Internet gateways SHOULD be organization-local
scope boundaries, i.e. traffic is only forwarded to multicast
destinations of wider than organization-local scope.
[ EDITOR'S NOTE: I don't know whether or what to say about mobility Conversely, simple Internet gateways are not expected to prohibit the
support in this document. Consequently, I have not written any development of new applications. In particular, packets with end-to-
detailed recommendations to that effect. ] end network security and routing extension headers for mobility are
expected to pass Internet gateways freely.
2.2. Internet Layer Protocols 2.2. Internet Layer Protocols
In managed, enterprise networks, virtual private networking tunnels In managed, enterprise networks, virtual private networking tunnels
are typically regarded as an additional attack surface. and they are are typically regarded as an additional attack surface. and they are
often restricted or prohibited from traversing firewalls for that often restricted or prohibited from traversing firewalls for that
reason. However, it would be inappropriate to restrict virtual reason. However, it would be inappropriate to restrict virtual
private networking tunnels by default in unmanaged, residential private networking tunnels by default in unmanaged, residential
network usage scenarios. Therefore, this document recommends the network usage scenarios. Therefore, this document recommends the
DEFAULT operating mode for residential IPv6 simple security is to DEFAULT operating mode for residential IPv6 simple security is to
skipping to change at page 6, line 19 skipping to change at page 6, line 17
sections 5.2.1 and 5.2.2 of [RFC4380]. (Note: this is a necessary 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 addition to the "automatic sunset" provision in section 5.5 of
[RFC4380] because it's all too common that nested IPv4/NAT gateways [RFC4380] because it's all too common that nested IPv4/NAT gateways
are deployed unintentionally in residential settings and without are deployed unintentionally in residential settings and without
consideration for Internet architectural implications.) 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 transport layers like User Datagram Protocol stateful filtering of transport layers like User Datagram Protocol
(UDP) [RFC0768], Transport Control Protocol (TCP) [RFC0793], the (UDP) [RFC0768] (and Lightweight User Datagram Protocol (UDP-Lite)
Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram [RFC3828]), Transport Control Protocol (TCP) [RFC0793], the Stream
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
only permitted into the interior network of a residential IPv6 only permitted into the interior network of a residential IPv6
gateway when it has been solicited explicitly by interior nodes. All gateway when it has been solicited explicitly by interior nodes. All
other traffic is expected to be discarded or rejected with an ICMPv6 other traffic is expected to be discarded or rejected with an ICMPv6
error message to indicate the traffic is administratively prohibited. error message to indicate the traffic is administratively prohibited.
3. Detailed Recommendations 3. Detailed Recommendations
skipping to change at page 8, line 14 skipping to change at page 8, line 14
3.2. Connection-free Filters 3.2. Connection-free Filters
Some Internet applications use connection-free transport protocols Some Internet applications use connection-free transport protocols
with no release semantics, e.g. UDP. These protocols pose a special with no release semantics, e.g. UDP. These protocols pose a special
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. UDP Filters 3.2.1. Upper-layer Transport Protocols
Residential IPv6 gateways are not expected to prohibit the use of
applications to be developed using future upper-layer transport
protocols. In particular, transport protocols not otherwise
discussed in subsequent sections of this document are expected to be
treated consistently, i.e. as having connection-free semantics and no
special requirements to inspect the transport headers.
In general, upper-layer transport filter state records are expected
to be created when an interior endpoint sends a packet to an exterior
address. The filter allocates (or reuses) a record for the duration
of communications, with an idle timer to delete the state record when
no further communications are detected.
R9: Filter state records for generic upper-layer transport protocols
MUST BE indexable by a 3-tuple comprising the interior node address,
the exterior node address and the upper-layer transport protocol
identifier.
R10: Filter state records for generic upper-layer transport protocols
MUST NOT be deleted or recycled until an idle timer not less than two
minutes has expired without having forwarded a packet matching the
state in some configurable amount of time. By DEFAULT, the idle
timer for such state records is five minutes.
3.2.2. UDP Filters
"NAT Behaviorial Requirements for UDP" [RFC4787] defines the "NAT Behaviorial Requirements for UDP" [RFC4787] defines the
terminology and best current practice for stateful filtering of UDP terminology and best current practice for stateful filtering of UDP
applications in IPv4 with NAT, which serves as the model for applications in IPv4 with NAT, which serves as the model for
behaviorial requirements for simple UDP security in IPv6 gateways, behaviorial requirements for simple UDP security in IPv6 gateways,
notwithstanding the requirements related specifically to network notwithstanding the requirements related specifically to network
address translation. 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.
R8: A state record for a UDP exchange where both interior and R11: 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.
R9: A state record for a UDP exchange where one or both of the R12: 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 misbehaviing 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.
R10: A state record for a UDP exchange MUST be refreshed when a R13: 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.
R11: If application transparency is most important, then a stateful R14: 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
UDP. If a more stringent filtering behavior is most important, then UDP. 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 TCP and other protocols. for TCP and other protocols.
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.
R12: If a gateway forwards a UDP exchange, it MUST also forward ICMP R15: If a gateway forwards a UDP exchange, it MUST also forward ICMP
Destination Unreachable messages containing UDP headers that match Destination Unreachable messages containing UDP headers that match
the exchange state record. the exchange state record.
R13: Receipt of any sort of ICMP message MUST NOT terminate the state R16: Receipt of any sort of ICMP message MUST NOT terminate the state
record for a UDP exchange. record for a UDP exchange.
3.2.2. Teredo-specific Filters R17: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way
as UDP exchanges, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore UDP
packets MUST NOT match UDP-Lite state records, and vice versa.
3.2.3. Teredo-specific Filters
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.
R14: 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. This MAY be done by
discarding Teredo packets identified by the heuristic defined in discarding Teredo packets identified by the heuristic defined in
"Teredo Security Concerns Beyond What Is In RFC 4380" [HOAGLAND]. "Teredo Security Concerns Beyond What Is In RFC 4380" [HOAGLAND].
[ EDITOR'S NOTE: In the event [HOAGLAND] does not advance to [ EDITOR: In the event [HOAGLAND] does not advance to publication as
publication as an RFC, then that heuristic will be reproduced here. ] an RFC, then that heuristic will be reproduced here. ]
3.2.3. 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.
R15: 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.
R16: 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 Payload with an upper layer protocol of type "Encapsulating Security Payload
(ESP)" [RFC4303] in their outer IP extension header chain. (ESP)" [RFC4303] in their outer IP extension header chain.
R17: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R21: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of any UDP packets, to and from legitimate node the forwarding of any UDP packets, to and from legitimate node
addresses, with a destination port of 500, i.e. the port reserved by addresses, with a destination port of 500, i.e. the port reserved by
IANA for the Internet Key Exchange Protocol [RFC4306]. IANA for the Internet Key Exchange Protocol [RFC4306].
3.2.4. Other Virtual Private Network Protocols R22: In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] that are
indexable by a 3-tuple comprising the interior node address, the
exterior node address and the ESP protocol identifier. In
particular, the IPv4/NAT method of indexing state records also by
security parameters index (SPI) SHOULD NOT be used. Likewise, any
mechanism that depends on detection of Internet Key Exchange (IKE)
[RFC4306] initiations SHOULD NOT be used.
3.2.5. Other Virtual Private Network Protocols
Residential IPv6 gateways are not expected to prohibit the use of Residential IPv6 gateways are not expected to prohibit the use of
virtual private networks in residential usage scenarios. virtual private networks in residential usage scenarios.
R18: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R23: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding, to and from legitimate node addresses, with upper the forwarding, to and from legitimate node addresses, with upper
layer protocol of type IP version 6, and SHOULD NOT prohibit the layer protocol of type IP version 6, and SHOULD NOT prohibit the
forwarding of other tunneled networking protocols commonly used for forwarding of other tunneled networking protocols commonly used for
virtual private networking, e.g. IP version 4, Generic Routing virtual private networking, e.g. IP version 4, Generic Routing
Encapsulation, etcetera. Encapsulation, etcetera.
3.3. Connection-oriented Filters 3.3. Connection-oriented Filters
Most Internet applications use connection-oriented transport Most Internet applications use connection-oriented transport
protocols with orderly release semantics. These protocols include protocols with orderly release semantics. These protocols include
skipping to change at page 11, line 27 skipping to change at page 12, line 16
cross in the network. Upon receiving the other end's SYN packet, cross in the network. Upon receiving the other end's SYN packet,
each end responds with a SYN-ACK packet, which also cross in the each end responds with a SYN-ACK packet, which also cross in the
network. The connection is established at each endpoint once the network. The connection is established at each endpoint once the
SYN-ACK packets are received. SYN-ACK packets are received.
In order to provide stateful packet filtering service for TCP, it is In order to provide stateful packet filtering service for TCP, it is
necessary for a filter to receive, process and forward all packets necessary for a filter to receive, process and forward all packets
for a connection that conform to valid transitions of the TCP state for a connection that conform to valid transitions of the TCP state
machine (Fig. 6, [RFC0793]). machine (Fig. 6, [RFC0793]).
R19: All valid sequences of TCP packets (defined in [RFC0793]) MUST R24: All valid sequences of TCP packets (defined in [RFC0793]) MUST
be forwarded for outbound connections and explicitly permitted be forwarded for outbound connections and explicitly permitted
inbound connections. In particular, both the normal TCP 3-way inbound connections. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes of handshake mode of operation and the simultaneous-open modes of
operation MUST be supported. operation MUST be supported.
It is possible to reconstruct enough of the state of a TCP connection
to allow forwarding between an interior and exterior node even when
the filter starts operating after TCP enters the established state.
In this case, because the filter has not seen the TCP window-scale
option, it is not possible for the filter to enforce the TCP window
invariant by dropping out-of-window segments.
R25: The TCP window invariant MUST NOT be enforced on connections for
which the filter did not detect whether the window-scale option (see
[RFC1323]) was sent in the 3-way handshake or simultaneous open.
A stateful filter can allow an existing mapping to be reused by an A stateful filter can allow an existing mapping to be reused by an
externally initiated connection if its security policy permits. externally initiated connection if its security policy permits.
Several different policies are possible as described in "Network Several different policies are possible as described in "Network
Address Translation (NAT) Behavioral Requirements for Unicast UDP Address Translation (NAT) Behavioral Requirements for Unicast UDP
[RFC4787] and extended in "NAT Behaviorial Requirements for TCP" [RFC4787] and extended in "NAT Behaviorial Requirements for TCP"
[BEHAVE-TCP]. [BEHAVE-TCP].
R20: 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 [BEHAVE-TCP], but the basic outcome of it is that filters need to
wait on signaling errors until simultaneous-open will not be wait on signaling errors until simultaneous-open will not be
impaired. impaired.
R21: A gateway MUST NOT signal an error for an unsolicited inbound R27: A gateway MUST NOT signal an error for an unsolicited inbound
SYN packet for at least 6 seconds after the packet is received. If SYN packet for at least 6 seconds after the packet is received. If
during this interval the gateway receives and forwards an outbound during this interval the gateway receives and forwards an outbound
SYN for the connection, then the gateway MUST discard the original SYN for the connection, then the gateway MUST discard the original
unsolicited inbound SYN packet without signaling an error. unsolicited inbound SYN packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN-- error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of network unless sending any response violates the security policy of network
administrator. administrator.
A TCP filter maintains state associated with in-progrss and A TCP filter maintains state associated with in-progrss and
skipping to change at page 13, line 15 skipping to change at page 14, line 16
The "established connection idle-timeout" for a stateful packet The "established connection idle-timeout" for a stateful packet
filter is defined as the minimum time a TCP connection in the filter is defined as the minimum time a TCP connection in the
established phase must remain idle before the filter considers the established phase must remain idle before the filter considers the
associated state record a candidate for collection. The "transitory associated state record a candidate for collection. The "transitory
connection idle-timeout" for a filter is defined as the minimum time connection idle-timeout" for a filter is defined as the minimum time
a TCP connection in the partially-open or closing phases must remain a TCP connection in the partially-open or closing phases must remain
idle before the filter considers the associated state record a idle before the filter considers the associated state record a
candidate for collection. TCP connections in the TIME_WAIT state are candidate for collection. TCP connections in the TIME_WAIT state are
not affected by the "transitory connection idle-timeout" parameter. not affected by the "transitory connection idle-timeout" parameter.
R22: If a gateway cannot determine whether the endpoints of a TCP R28: If a gateway cannot determine whether the endpoints of a TCP
connection are active, then it MAY abandon the state record if it has 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 been idle for some time. In such cases, the value of the
"established connection idle-timeout" MUST NOT be less than two hours "established connection idle-timeout" MUST NOT be less than two hours
four minutes. The value of the "transitory connection idle-timeout" four minutes. The value of the "transitory connection idle-timeout"
MUST NOT be less than four minutes. The value of the idle-timeouts MUST NOT be less than four minutes. The value of the idle-timeouts
MAY be configurable by the network administrator. MAY be configurable by the network administrator.
Behavior for handing RST packets, or connections in the TIME_WAIT Behavior for handing RST packets, or connections in the TIME_WAIT
state is left unspecified. A gateway MAY hold state for a connection state is left unspecified. A gateway MAY hold state for a connection
in TIME_WAIT state to accommodate retransmissions of the last ACK. in TIME_WAIT state to accommodate retransmissions of the last ACK.
skipping to change at page 13, line 52 skipping to change at page 15, line 5
example due to a timeout expiring, the filter MAY send a TCP RST example due to a timeout expiring, the filter MAY send a TCP RST
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.
R23: If a gateway forwards a TCP connection, it MUST also forward R29: If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that ICMP Destination Unreachable messages containing TCP headers that
match the connection state record. match the connection state record.
R24: Receipt of any sort of ICMP message MUST NOT terminate the state 30: Receipt of any sort of ICMP message MUST NOT terminate the state
record for a TCP connection. record for a TCP connection.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
[ Insert verbiage here. ] [ EDITOR: Insert verbiage here. ]
3.3.3. DCCP Filters 3.3.3. DCCP Filters
[ Insert verbiage here. ] [ EDITOR: Insert verbiage here. ]
3.4. Passive Listeners 3.4. Passive Listeners
Some applications expect to solicit traffic from exterior nodes Some applications expect to solicit traffic from exterior nodes
without any advance knowledge of the exterior address. This without any advance knowledge of the exterior address. This
requirement is met by IPv4/NAT gateways typically by the use of requirement is met by IPv4/NAT gateways typically by the use of
either [NAT-PMP] or [UPnP-IGD]. either [NAT-PMP] or [UPnP-IGD].
One proposal that has been offered as an Internet Draft is the One proposal that has been offered as an Internet Draft is the
Application Listener Discovery Protocol [IPv6-ALD]. It remains to be Application Listener Discovery Protocol [IPv6-ALD]. It remains to be
seen whether the Internet Gateway Device profile of the Universal seen whether the Internet Gateway Device profile of the Universal
Plug And Play protocol will be extended for IPv6. Other proposals of Plug And Play protocol will be extended for IPv6. Other proposals of
note include the Middlebox Communication Protocol [RFC3989] and the note include the Middlebox Communication Protocol [RFC3989] and the
Next Steps in Signaling framework [RFC4080]. No consensus has yet Next Steps in Signaling framework [RFC4080]. No consensus has yet
emerged in the Internet engineering community as to which proposal is emerged in the Internet engineering community as to which proposal is
most appropriate for residential IPv6 usage scenarios. most appropriate for residential IPv6 usage scenarios.
R25: 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 [RFC3978],
[RFC3979] and [RFC4748]. [RFC3979] and [RFC4748].
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.
[ EDITOR'S NOTE: This section is left intentionally incomplete while R1 Packets bearing in their outer IPv6 headers multicast source
discussion on the V6CPE Design Team mailing list establishes a addresses MUST NOT be forwarded or transmitted on any interface.
consensus about what to present at IETF 68 in Chicago. ]
R1-Rn: Insert summary of recommendations R1-Rn here. R2 Packets bearing in their outer IPv6 headers multicast destination
addresses of equal or narrower scope that the configured scope
boundary level of the gateway MUST NOT be forwarded in any
direction. The DEFAULT scope boundary level SHOULD be
organization-local scope.
R3 Packets bearing deprecated extension headers prior to their first
upper-layer-protocol header MUST NOT be forwarded or transmitted
on any interface. In particular, all packets with routing
extension header type 0 [RFC2460] preceding the first upper-layer-
protocol header MUST NOT be forwarded.
R4 Outbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header does not have a unicast prefix assigned
for use by globally reachable nodes on the interior network.
R4 Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for
use by globally reachable nodes on the interior network.
R5 Packets MAY be discarded if the source and/or destination address
in the outer IPv6 header is a unique local address. By DEFAULT,
gateways SHOULD NOT forward packets across unique local address
scope boundaries.
R6 By DEFAULT, inbound non-recursive DNS queries received on exterior
interfaces MUST NOT be processed by any integrated DNS proxy
resolving server.
R7 Inbound DHCP discovery packets received on exterior interfaces
MUST NOT be processed by any integrated DHCP server.
R8 Inbound packets not matching any existing filter state record for
a permitted transport flow MUST NOT be forwarded to the interior
network, and an ICMP Error message of type Administratively
Prohibited MUST be sent to the source address.
R9 Filter state records for generic upper-layer transport protocols
MUST BE indexable by a 3-tuple comprising the interior node
address, the exterior node address and the upper-layer transport
protocol identifier.
R10 Filter state records for generic upper-layer transport protocols
MUST NOT be deleted or recycled until an idle timer not less than
two minutes has expired without having forwarded a packet matching
the state in some configurable amount of time. By DEFAULT, the
idle timer for such state records is five minutes.
R11 A state record for a UDP exchange where both interior and
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 the UDP state record idle timer MAY be configurable.
The DEFAULT is five minutes.
R12 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 0-1023) MAY expire after a period of idle time shorter than
two minutes to facilitate the operation of the IANA-registered
service assigned to the port in question.
R13 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 refreshed when a packet is forwarded in the reverse direction.
R14 If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior
for UDP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "Address dependent filtering"
behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the
filtering behavior for TCP and other protocols.
R15 If a gateway forwards a UDP exchange, it MUST also forward ICMP
Destination Unreachable messages containing UDP headers that match
the exchange state record.
R16 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a UDP exchange.
R17 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way
as UDP exchanges, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore UDP
packets MUST NOT match UDP-Lite state records, and vice versa.
R18 Where an IPv6 prefix is advertised on an interior interface
alongside an IPv4 private address [RFC1918] 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. This
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
the forwarding of packets, to and from legitimate node addresses,
with destination extension headers of type "Authenticated Header
(AH)" [RFC4302] in their outer IP extension header chain.
R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses,
with an upper layer protocol of type "Encapsulating Security
Payload (ESP)" [RFC4303] in their outer IP extension header chain.
R21 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of any UDP packets, to and from legitimate node
addresses, with a destination port of 500, i.e. the port reserved
by IANA for the Internet Key Exchange Protocol [RFC4306].
R22 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding, to and from legitimate node addresses, with upper
layer protocol of type IP version 6, and SHOULD NOT prohibit the
forwarding of other tunneled networking protocols commonly used
for virtual private networking, e.g. IP version 4, Generic
Routing Encapsulation, etcetera.
R23 In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] that
are indexable by a 3-tuple comprising the interior node address,
the exterior node address and the ESP protocol identifier. In
particular, the IPv4/NAT method of indexing state records also by
security parameters index (SPI) SHOULD NOT be used. Likewise, any
mechanism that depends on detection of Internet Key Exchange (IKE)
[RFC4306] initiations SHOULD NOT be used.
R24 All valid sequences of TCP packets (defined in [RFC0793]) MUST
be forwarded for outbound connections and explicitly permitted
inbound connections. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes of
operation MUST be supported.
R25 The TCP window invariant MUST NOT be enforced on connections for
which the filter did not detect whether the window-scale option
(see [RFC1323]) was sent in the 3-way handshake or simultaneous
open.
R26 If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior
for TCP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "Address dependent filtering"
behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the
filtering behavior for UDP and other protocols.
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 during this interval the gateway receives and forwards an
outbound SYN for the connection, then the gateway MUST discard the
original unsolicited inbound SYN packet without signaling an
error. Otherwise, the gateway SHOULD send an ICMP Destination
Unreachable error, code 1 (administratively prohibited) for the
original SYN-- unless sending any response violates the security
policy of network administrator.
R28 If a gateway cannot determine whether the endpoints of a TCP
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
"established connection idle-timeout" MUST NOT be less than two
hours four minutes. The value of the "transitory connection idle-
timeout" MUST NOT be less than four minutes. The value of the
idle-timeouts MAY be configurable by the network administrator.
R29 If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that
match the connection state record.
R30 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a TCP connection.
R31 Gateways MUST implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses
of exterior nodes with which they expect to communicate. This
protocol MUST have a specification that meets the requirements of
[RFC3978], [RFC3979] and [RFC4748].
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: Jun-ichiro itojun received from the following IETF participants:
Hagino, Kurt Erik Lindqvist and Fred Baker.
[ Insert list of additional contributors here. ] Fred Baker
Norbert Bollow
Brian Carpenter
Jun-ichiro itojun Hagino
Thomas Herbst
Christian Huitema
Cullen Jennings
Suresh Krishnan
Erik Kline
Kurt Erik Lindqvist
Iljitsch van Beijnum
Yaron Sheffer
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 [BEHAVE-TCP] and [RFC4787],
and some form of attribution here may therefore be appopriate. and 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
All drafts are required to have a security considerations section. The IPv6 stateful filtering behavior described in this document is
See RFC 3552 [RFC3552] for a guide. intended to be similar in function to the filtering behavior of
commonly use IPv4/NAT gateways, which have been widely sold as a
security tool for residential and small-offce/home-office networks.
As noted in the security considerations section of [RFC2993], the
true impact of these tools may be a reduction in security. It may be
generally assumed that the impacts discussed there related to
filtering (and not translation) are to be expected with the simple
IPv6 security mechanisms described here.
[ EDITOR'S NOTE: Yes, I'm sure there are security considerations, but In particular, it's worth noting that stateful filters create the
I'm currently at a loss for words to describe them. This section illusion of a security barrier, but without the managed intent of a
needs careful wordsmithing prior to the next revision. ] firewall. Appropriate security mechanisms implemented in the end
nodes, in conjunction with the [RFC4864] local network protection
methods, function without reliance on network layer hacks and
transport filters that may change over time. Also, defined security
barriers assume that threats originate in the exterior, which may
lead to practices that result in applications being fully exposed to
interior attack and which therefore make breaches much easier.
Finally, residential gateways that implement simple security
functions are a bastion between the interior and the exterior, and
therefore are a target of denial of service attacks against the
interior network itself by processes designed to consume the
resources of the gateway, e.g. a ping or SYN flood. Gateways should
employ the same sorts of protection techniques as application servers
on the Internet.
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.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[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
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005. 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)",
skipping to change at page 16, line 44 skipping to change at page 22, line 31
8.2. Informative References 8.2. Informative References
[BEHAVE-TCP] [BEHAVE-TCP]
Guha, S., Biswas, K., Sivakumar, S., Ford, B., and P. Guha, S., Biswas, K., Sivakumar, S., Ford, B., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", Srisuresh, "NAT Behavioral Requirements for TCP",
April 2007, April 2007,
<http://tools.ietf.org/html/draft-ietf-behave-tcp>. <http://tools.ietf.org/html/draft-ietf-behave-tcp>.
[HOAGLAND] [HOAGLAND]
Hoagland, J., "Teredo Security Concerns Beyond What Is In Hoagland, J. and S. Krishnan, "Teredo Security Concerns
RFC 4380", May 2007, <http://tools.ietf.org/html/ Beyond What Is In RFC 4380", July 2007, <http://
tools.ietf.org/html/
draft-hoagland-v6ops-teredosecconcerns>. draft-hoagland-v6ops-teredosecconcerns>.
[IPv6-ALD] [IPv6-ALD]
Woodyatt, j., "Application Listener Discovery (ALD) for Woodyatt, j., "Application Listener Discovery (ALD) for
IPv6", May 2007, IPv6", May 2007,
<http://tools.ietf.org/html/draft-woodyatt-ald>. <http://tools.ietf.org/html/draft-woodyatt-ald>.
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port [NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
Mapping Protocol (NAT-PMP)", November 2001, Mapping Protocol (NAT-PMP)", November 2001,
<http://tools.ietf.org/html/draft-cheshire-nat-pmp>. <http://tools.ietf.org/html/draft-cheshire-nat-pmp>.
skipping to change at page 17, line 19 skipping to change at page 23, line 6
[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.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
Text on Security Considerations", BCP 72, RFC 3552, November 2000.
July 2003.
[RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox [RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communications (MIDCOM) Protocol Semantics", RFC 3989, Communications (MIDCOM) Protocol Semantics", RFC 3989,
February 2005. February 2005.
[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,
skipping to change at page 18, line 15 skipping to change at page 24, line 5
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 [HOAGLAND].
A.2. draft-ietf-v6ops-cpe-simple-security-01 to
draft-ietf-v6ops-cpe-simple-security-02
o Inserted R20, i.e. do not enforce TCP window invariant unless the
TCP window-scale is known for the state.
o Filled out Section 4.
o Added reference to [RFC1323].
o Updated the reference for [HOAGLAND].
o Expanded list of contributers and commenters.
o Mention that UDP-Lite should be handled just like UDP.
o Added section for generic upper layer transport protocols.
o Expanded on recommendations for IPsec ESP filtering.
o Expanded overview of recommendations with discussion about IP
mobility and IPsec interactions.
o Added a security considerations section.
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 Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 49 change blocks. 
78 lines changed or deleted 380 lines changed or added

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