IPv6 Operations                                         j. woodyatt, Ed.
Internet-Draft                                                     Apple
Intended status: Best Current                               June 6, 2007
Practice
Expires: December 8, 2007


Recommended Simple Security Capabilities in Customer Premises Equipment
            for Providing Residential IPv6 Internet Service
                draft-ietf-v6ops-cpe-simple-security-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 8, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document makes specific recommendations to the makers of devices
   that provide "simple security" capabilities at the perimeter of
   local-area IPv6 networks in Internet-enabled homes and small offices.






woodyatt                Expires December 8, 2007                [Page 1]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Special Language . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Basic Sanitation . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Internet Layer Protocols . . . . . . . . . . . . . . . . .  5
     2.3.  Transport Layer Protocols  . . . . . . . . . . . . . . . .  6
   3.  Detailed Recommendations . . . . . . . . . . . . . . . . . . .  6
     3.1.  Stateless Filters  . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Connection-free Filters  . . . . . . . . . . . . . . . . .  7
       3.2.1.  UDP Filters  . . . . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Teredo-specific Filters  . . . . . . . . . . . . . . .  9
       3.2.3.  IPsec and Internet Key Exchange (IKE)  . . . . . . . .  9
       3.2.4.  Other Virtual Private Network Protocols  . . . . . . . 10
     3.3.  Connection-oriented Filters  . . . . . . . . . . . . . . . 10
       3.3.1.  TCP Filters  . . . . . . . . . . . . . . . . . . . . . 10
       3.3.2.  SCTP Filters . . . . . . . . . . . . . . . . . . . . . 13
       3.3.3.  DCCP Filters . . . . . . . . . . . . . . . . . . . . . 14
     3.4.  Passive Listeners  . . . . . . . . . . . . . . . . . . . . 14
   4.  Summary of Recommendations . . . . . . . . . . . . . . . . . . 14
   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18





















woodyatt                Expires December 8, 2007                [Page 2]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


1.  Introduction

   In "Local Network Protection for IPv6" [IPv6-NAP], IETF recommends
   'simple security' capabilities for gateway devices that enable
   delivery of Internet services in residential and small office
   settings.  The principle goal of these capabilties is to improve
   security of the IPv6 Internet without increasing the perceived
   complexity for users who just want to accomplish useful work.

   There is, at best, a constructive tension between the desires of
   users for transparent end-to-end connectivity on the one hand, and
   the need for local-area network administrators to detect and prevent
   intrusion by unauthorized public Internet users on the other.  The
   specific recommendations in this document are intended to promote
   optimal local-area network security while retaining full end-to-end
   transparency for users, and to highlight reasonable limitations on
   transparency where security considerations are deemed important.

   Residential and small office network administrators are expected to
   have no expertise in Internet engineering whatsoever.  Configuration
   interfaces for simple security in router/gateway appliances marketed
   toward them should be easy to understand and even easier to ignore.
   In particular, extra care should be taken in designing the baseline
   operating modes of unconfigured devices, since the security functions
   of most devices will never be changed from their factory set default.

1.1.  Special Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The key word "DEFAULT" in this document is to be interpreted as the
   configuration of a device, as applied by its vendor, prior to the
   operator changing it for the first time.


2.  Overview

   For the purposes of this document, residential Internet gateways are
   assumed to be fairly simple devices with a limited subset of the full
   range of possible features.  They function as default routers
   [RFC4294] for a single local-area network segment, e.g. an ethernet,
   a Wi-Fi network, a bridge between two or more such segments.  They
   have a single interface by which they connect to the public Internet,
   and they can obtain service by any combination of sub-IP mechanisms,
   including tunnels and transition mechanisms.  In referring to their
   security capabilities, it is reasonable to distinguish between the



woodyatt                Expires December 8, 2007                [Page 3]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   "interior" network, i.e. the local-area network, and the "exterior"
   network, i.e. the public Internet.  This document is concerned with
   the behavior of packet filters that police the flow of traffic
   between the interior and exterior networks of residential Internet
   gateways.

   The operational goals of security capabilities in Internet gateways
   are described with more detail in "Local Network Protection for IPv6"
   [IPv6-NAP], but they can be summarized as follows.

   o  Check all traffic to and from the public Internet for basic
      sanity, e.g. anti-spoofing and "martian" filters.

   o  Allow tracking of application usage by source and destination
      transport addresses.

   o  Provide a barrier against untrusted external influences on the
      interior network by requiring filter state to be activated by
      traffic originating at interior network nodes.

   o  Allow manually configured exceptions to the stateful filtering
      rules according to network administration policy.

   Prior to the widespread availability of IPv6 Internet service, homes
   and small offices often used private IPv4 network address realms
   [RFC1918] with Network Address Translation (NAT) functions deployed
   to present all the hosts on the interior network as a single host to
   the Internet service provider.  The stateful packet filtering
   behavior of NAT set user expectations that persist today with
   residential IPv6 service.  "Local Network Protection for IPv6"
   [IPv6-NAP] recommends applying stateful packet filtering at
   residential IPv6 gateways that conforms to the user expectations
   already in place.

   It should be noted that NAT for IPv6 is both strictly forbidden by
   the standards documents and strongly deprecated by Internet
   operators.  Only the perceived security benefits associated with
   stateful packet filtering, which NAT requires as a side effect, are
   thought relevant in the IPv6 residential usage scenario.

   As the latest revision of this document is being drafted,
   conventional stateful packet filters are activated as a side effect
   of outbound flow initiations from interior network nodes.  This
   requires applications to have advance knowledge of the addresses of
   exterior nodes with which they expect to communicate.  Several
   proposals are currently under consideration for allowing applications
   to solicit inbound traffic from exterior nodes without advance
   knowledge of their addresses.  While consensus within the Internet



woodyatt                Expires December 8, 2007                [Page 4]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   engineering community has emerged that such protocols are necessary
   to implement in residential IPv6 gateways, the best current practice
   has not yet been established.

2.1.  Basic Sanitation

   In addition to the functions required of all Internet routers
   [RFC4294], residential gateways are expected to have basic stateless
   filters for prohibiting certains kinds of traffic with invalid
   headers, e.g. martian packets, spoofs, routing header type code zero,
   etc.

   Internet gateways that route multicast traffic are expected to
   implement appropriate filters for scoped multicast addresses.  By
   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
   support in this document.  Consequently, I have not written any
   detailed recommendations to that effect. ]

2.2.  Internet Layer Protocols

   In managed, enterprise networks, virtual private networking tunnels
   are typically regarded as an additional attack surface. and they are
   often restricted or prohibited from traversing firewalls for that
   reason.  However, it would be inappropriate to restrict virtual
   private networking tunnels by default in unmanaged, residential
   network usage scenarios.  Therefore, this document recommends the
   DEFAULT operating mode for residential IPv6 simple security is to
   permit all virtual private networking tunnel protocols to pass
   through the stateful filtering function.  These include IPsec
   transport and tunnel modes as well as other IP-in-IP protocols.

   Where IPv6 simple security functions are integrated with an IPv4/NAT
   gateway of any of the types described in [RFC4787], it's important to
   keep IPv6 flows subject to a consistent policy.  If the security
   functions of an IPv6 residential gateway can be bypassed through
   Teredo [RFC4380], then application developers will be encouraged to
   use it even at nodes where native IPv6 service is available.  This
   will have the effect of impeding the completion of the transition to
   native IPv6.

   Residential IPv6 gateways are expected to continue operating as IPv4/
   NAT gateways for the foreseeable future.  To prevent Teredo from
   acquiring a utility that it was never meant to have on networks where
   both IPv4/NAT and native IPv6 services are available, gateways MUST



woodyatt                Expires December 8, 2007                [Page 5]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   impede Teredo tunnels by blocking clients from learning their mapped
   addresses and ports in the qualification procedure described in
   sections 5.2.1 and 5.2.2 of [RFC4380].  (Note: this is a necessary
   addition to the "automatic sunset" provision in section 5.5 of
   [RFC4380] because it's all too common that nested IPv4/NAT gateways
   are deployed unintentionally in residential settings and without
   consideration for Internet architectural implications.)

2.3.  Transport Layer Protocols

   IPv6 simple security functions are principally concerned with the
   stateful filtering of transport layers like User Datagram Protocol
   (UDP) [RFC0768], Transport Control Protocol (TCP) [RFC0793], the
   Stream Control Transmission Protocol (SCTP) [RFC2960], the Datagram
   Congestion Control Protocol (DCCP) [RFC4340], and potentially any
   standards-track transport protocols to be defined in the future.

   The general operating principle is that transport layer traffic is
   only permitted into the interior network of a residential IPv6
   gateway when it has been solicited explicitly by interior nodes.  All
   other traffic is expected to be discarded or rejected with an ICMPv6
   error message to indicate the traffic is administratively prohibited.


3.  Detailed Recommendations

   This section describes the specific recommendations made by this
   document in full detail.  They are summarized into a convenient list
   in Section 4.

   Some recommended filters are to be applied to all traffic that passes
   through residential Internet gateways regardless of the direction
   they are to be forwarded.  However, most filters are expected to be
   sensitive to the direction that traffic is flowing.  Packets are said
   to be "outbound" if they originate from interior nodes to be
   forwarded to the Internet, and "inbound" if they originate from
   exterior nodes to be forwarded to any node or nodes on the interior
   prefix.  Flows, as opposed to packets, are said to be "outbound" if
   the initiator is an interior node and one or more of the participants
   are at exterior addresses.  Flows are said to be "inbound" if the
   initiator is an exterior node and one or more of the participants are
   nodes on the interior network.  The initiator of a flow is the first
   node to send a packet in the context of a given transport
   association, e.g. a TCP connection, et cetera.







woodyatt                Expires December 8, 2007                [Page 6]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


3.1.  Stateless Filters

   Certain kinds of IPv6 packets MUST NOT be forwarded in either
   direction by residential Internet gateways regardless of network
   state.  These include packets with multicast source addresses,
   packets to destinations with certain non-routable and/or reserved
   prefixes, and packets with deprecated extension headers.

   Other stateless filters are recommended to guard against spoofing and
   to enforce multicast scope boundaries.

   R1: Packets bearing in their outer IPv6 headers multicast source
   addresses MUST NOT be forwarded or transmitted on any interface.

   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.

3.2.  Connection-free Filters

   Some Internet applications use connection-free transport protocols
   with no release semantics, e.g.  UDP.  These protocols pose a special
   difficulty for stateful packet filters because most of the
   application state is not carried at the transport level.  State
   records are created when communication is initiated and abandoned
   when no further communication is detected after some period of time.





woodyatt                Expires December 8, 2007                [Page 7]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


3.2.1.  UDP Filters

   "NAT Behaviorial Requirements for UDP" [RFC4787] defines the
   terminology and best current practice for stateful filtering of UDP
   applications in IPv4 with NAT, which serves as the model for
   behaviorial requirements for simple UDP security in IPv6 gateways,
   notwithstanding the requirements related specifically to network
   address translation.

   An interior endpoint initiates a UDP exchange through a stateful
   packet filter by sending a packet to an exterior address.  The filter
   allocates (or reuses) a filter state record for the duration of the
   exchange.  The state record defines the interior and exterior IP
   addresses and ports used between all packets in the exchange.

   State records for UDP exchanges remain active while they are in use
   and only abandoned after an idle period of some time.

   R7: 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.

   R8: 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.

   As [RFC4787] notes, outbound refresh is necessary for allowing the
   interior endpoint to keep the state record alive.  Inbound refresh
   may be useful for applications with no outbound UDP traffic.
   However, allowing inbound refresh can allow an attacker in the
   exterior or a misbehaviing application to keep a state record alive
   indefinitely.  This could be a security risk.  Also, if the process
   is repeated with different ports, over time, it could use up all the
   state record memory and resources in the filter.

   R9: 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.

   As described in section 5.5 of [RFC4787], the connection-free
   semantics of UDP pose a difficulty for packet filters in trying to
   recognize which packets comprise an application flow and which are
   unsolicited.  Various strategies have been used in IPv4/NAT gateways
   with differing effects.



woodyatt                Expires December 8, 2007                [Page 8]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   R10: 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.

   Applications mechanisms may depend on the reception of ICMP error
   messages triggered by the transmission of UDP messages.  One such
   mechanism is path MTU discovery.

   R11: If a gateway forwards a UDP exchange, it MUST also forward ICMP
   Destination Unreachable messages containing UDP headers that match
   the exchange state record.

   R12: Receipt of any sort of ICMP message MUST NOT terminate the state
   record for a UDP exchange.

3.2.2.  Teredo-specific Filters

   Transitional residential IPv6 gateways that also feature integrated
   IPv4/NAT gateways require special filtering for Teredo tunnels.

   R13: 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].

   [ EDITOR'S NOTE: In the event [HOAGLAND] does not advance to
   publication as an RFC, then that heuristic will be reproduced here. ]

3.2.3.  IPsec and Internet Key Exchange (IKE)

   Internet protocol security (IPsec) offers greater flexibility and
   better overall security than the simple security of stateful packet
   filtering at network perimeters.  Therefore, residential IPv6
   gateways need not prohibit IPsec traffic flows.

   R14: 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.



woodyatt                Expires December 8, 2007                [Page 9]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   R15: 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.

   R16: 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].

3.2.4.  Other Virtual Private Network Protocols

   Residential IPv6 gateways are not expected to prohibit the use of
   virtual private networks in residential usage scenarios.

   R17: 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.

3.3.  Connection-oriented Filters

   Most Internet applications use connection-oriented transport
   protocols with orderly release semantics.  These protocols include
   the Transport Control Protocol (TCP) [RFC0793], the Stream Control
   Transmission Protocol (SCTP) [RFC2960], the Datagram Congestion
   Control Protocol (DCCP) [RFC4340], and potentially any future IETF
   standards-track transport protocols that use such semantics.
   Stateful packet filters track the state of individual transport
   connections and prohibit the forwarding of packets that do not match
   the state of an active connection and do not conform to a rule for
   the automatic creation of such state.

3.3.1.  TCP Filters

   An interior endpoint initiates a TCP connection through a stateful
   packet filter by sending a SYN packet.  The filter allocates (or
   reuses) a filter state record for the connection.  The state record
   defines the interior and exterior IP addresses and ports used for
   forwarding all packets for that connection.

   Peer-to-peer applications use an alternate method of connection
   initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse
   stateful filters.  In the simultaneous-open mode of operation, both
   peers send SYN packets for the same TCP connection.  The SYN packets
   cross in the network.  Upon receiving the other end's SYN packet,



woodyatt                Expires December 8, 2007               [Page 10]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   each end responds with a SYN-ACK packet, which also cross in the
   network.  The connection is established at each endpoint once the
   SYN-ACK packets are received.

   In order to provide stateful packet filtering service for TCP, it is
   necessary for a filter to receive, process and forward all packets
   for a connection that conform to valid transitions of the TCP state
   machine (Fig. 6, [RFC0793]).

   R17: 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.

   A stateful filter can allow an existing mapping to be reused by an
   externally initiated connection if its security policy permits.
   Several different policies are possible as described in "Network
   Address Translation (NAT) Behavioral Requirements for Unicast UDP
   [RFC4787] and extended in "NAT Behaviorial Requirements for TCP"
   [BEHAVE-TCP].

   R18: 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.

   If an inbound SYN packet is filtered, either because a corresponding
   state record does not exist or because of the filter's normal
   behavior, a filter has two basic choices: to discard the packet
   silently, or to signal an error to the sender.  Signaling an error
   through ICMP messages allows the sender to detect that the SYN did
   not reach the intended destination.  Discarding the packet, on the
   other hand, allows applications to perform simultaneous-open more
   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
   wait on signaling errors until simultaneous-open will not be
   impaired.

   R19: 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



woodyatt                Expires December 8, 2007               [Page 11]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   error, code 1 (administratively prohibited) for the original SYN--
   unless sending any response violates the security policy of network
   administrator.

   A TCP filter maintains state associated with in-progrss and
   established connections.  Because of this, a filter is susceptible to
   a resource-exhaustion attack whereby an attacker (or virus) on the
   interior attempts to cause the filter to exhaust its capacity for
   creating state records.  To prevent such an attack, a filter needs to
   abandon unused state records after a sufficiently long period of
   idleness.

   A common method used for TCP filters in IPv4/NAT gateways is to
   abandon preferentially sessions for crashed endpoints, followed by
   closed TCP connections and partially-open connections.  A gateway can
   check if an endpoint for a session has crashed by sending a TCP keep-
   alive packet on behalf of the other endpoint and receiving a TCP RST
   packet in response.  If the gateway connot determine whether the
   endpoint is active, then the associated state record needs to be
   retained until the TCP connection has been idle for some time.  Note:
   an established TCP connection can stay idle (but live) indefinitely;
   hence, there is no fixed value for an idle-timeout that accomodates
   all applications.  However, a large idle-timeout motivated by
   recommendations in [RFC1122] and [RFC4294] can reduce the chances of
   abandoning a live connection.

   TCP connections can stay in the established phase indefinitely
   without exchanging packets.  Some end-hosts can be configured to send
   keep-alive packets on such idle connections; by default, such packets
   are sent every two hours, if enabled [RFC1122].  Consequently, a
   filter that waits for slightly over two hours can detect idle
   connections with keep-alive packets being sent at the default rate.
   TCP connections in the partially-open or closing phases, on the other
   hand, can stay idle for at most four minutes while waiting for in-
   flight packets to be delivered [RFC1122].

   The "established connection idle-timeout" for a stateful packet
   filter is defined as the minimum time a TCP connection in the
   established phase must remain idle before the filter considers the
   associated state record a candidate for collection.  The "transitory
   connection idle-timeout" for a filter is defined as the minimum time
   a TCP connection in the partially-open or closing phases must remain
   idle before the filter considers the associated state record a
   candidate for collection.  TCP connections in the TIME_WAIT state are
   not affected by the "transitory connection idle-timeout" parameter.

   R20: If a gateway cannot determine whether the endpoints of a TCP
   connection are active, then it MAY abandon the state record if it has



woodyatt                Expires December 8, 2007               [Page 12]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


   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.

   Behavior for handing RST packets, or connections in the TIME_WAIT
   state is left unspecified.  A gateway MAY hold state for a connection
   in TIME_WAIT state to accommodate retransmissions of the last ACK.
   However, since the TIME_WAIT state is commonly encountered by
   interior endpoints properly closing the TCP connection, holding state
   for a closed connection can limit the throughput of connections
   through a gateway with limited resources.  [RFC1337] discusses
   hazards associated with TIME_WAIT assassination.

   The handling of non-SYN packets for which there is no active state
   record is left unspecified.  Such packets can be received if the
   gateway abandons a live connection, or abandons a connection in the
   TIME_WAIT state before the four minute TIME_WAIT period expires.  The
   decision either to discard or to respond with an ICMP Destination
   Unreachable error, code 1 (administratively prohibited) is left up to
   the implementation.

   Behavior for notifying endpoints when abandoning live connections is
   left unspecified.  When a gateway abandons a live connection, for
   example due to a timeout expiring, the filter MAY send a TCP RST
   packet to each endpoint on behalf of the other.  Sending a RST
   notification allows endpoint applications to recover more quickly,
   however, notifying endpoints might not always be possible if, for
   example, state records are lost due to power interruption.

   Several TCP mechanisms depend on the reception of ICMP error messages
   triggered by the transmission of TCP segments.  One such mechanism is
   path MTU discovery, which is required for correct operation of TCP.

   R21: If a gateway forwards a TCP connection, it MUST also forward
   ICMP Destination Unreachable messages containing TCP headers that
   match the connection state record.

   R22: Receipt of any sort of ICMP message MUST NOT terminate the state
   record for a TCP connection.

3.3.2.  SCTP Filters

   [ Insert verbiage here. ]






woodyatt                Expires December 8, 2007               [Page 13]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


3.3.3.  DCCP Filters

   [ Insert verbiage here. ]

3.4.  Passive Listeners

   Some applications expect to solicit traffic from exterior nodes
   without any advance knowledge of the exterior address.  This
   requirement is met by IPv4/NAT gateways typically by the use of
   either [NAT-PMP] or [UPnP-IGD].

   One proposal that has been offered as an Internet Draft is the
   Application Listener Discovery Protocol [IPv6-ALD].  It remains to be
   seen whether the Internet Gateway Device profile of the Universal
   Plug And Play protocol will be extended for IPv6.  Other proposals of
   note include the Middlebox Communication Protocol [RFC3989] and the
   Next Steps in Signaling framework [RFC4080].  No consensus has yet
   emerged in the Internet engineering community as to which proposal is
   most appropriate for residential IPv6 usage scenarios.

   R23: 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].


4.  Summary of Recommendations

   This section collects all of the recommendations made in this
   document into a convenient list.

   [ EDITOR'S NOTE: This section is left intentionally incomplete while
   discussion on the V6CPE Design Team mailing list establishes a
   consensus about what to present at IETF 68 in Chicago. ]

   R1-Rn:  Insert summary of recommendations R1-Rn here.


5.  Contributors

   [ Insert list of contributors here. ]

   Much of the text describing the detailed requirements for TCP and UDP
   filtering is derived or transposed from [BEHAVE-TCP] and [RFC4787],
   and some form of attribution here may therefore be appopriate.





woodyatt                Expires December 8, 2007               [Page 14]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.

   [ EDITOR'S NOTE: Yes, I'm sure there are security considerations, but
   I'm currently at a loss for words to describe them.  This section
   needs careful wordsmithing prior to the next revision. ]


8.  References

8.1.  Normative References

   [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]
              Hoagland, J., "Teredo Security Concerns Beyond What Is In
              RFC 4380", May 2007, <http://tools.ietf.org/html/
              draft-hoagland-v6ops-teredoconcerns>.

   [IPv6-NAP]
              Van de Velde, G., Hain, T., Droms, R., and B. Carpenter,
              "Local Network Protection for IPv6", January 2007,
              <http://tools.ietf.org/html/draft-ietf-v6ops-nap>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,



woodyatt                Expires December 8, 2007               [Page 15]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
              RFC 3978, March 2005.

   [RFC3979]  Bradner, S., "Intellectual Property Rights in IETF
              Technology", BCP 79, RFC 3979, March 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4748]  Bradner, S., "RFC 3978 Update to Recognize the IETF
              Trust", BCP 78, RFC 4748, October 2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

8.2.  Informative References

   [IPv6-ALD]
              Woodyatt, j., "Application Listener Discovery (ALD) for
              IPv6", May 2007,
              <http://tools.ietf.org/html/draft-woodyatt-ald>.

   [NAT-PMP]  Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
              Mapping Protocol (NAT-PMP)", November 2001,
              <http://tools.ietf.org/html/draft-cheshire-nat-pmp>.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1337]  Braden, B., "TIME-WAIT Assassination Hazards in TCP",



woodyatt                Expires December 8, 2007               [Page 16]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


              RFC 1337, May 1992.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC3989]  Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
              Communications (MIDCOM) Protocol Semantics", RFC 3989,
              February 2005.

   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
              Bosch, "Next Steps in Signaling (NSIS): Framework",
              RFC 4080, June 2005.

   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
              April 2006.

   [UPnP-IGD]
              UPnP Forum, "Universal Plug and Play Internet Gateway
              Device Standardized Gateway Device Protocol",
              September 2006,
              <http://www.upnp.org/standardizeddcps/igd.asp>.


Appendix A.  Additional Stuff

   This becomes an Appendix.


Author's Address

   james woodyatt (editor)
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   US

   Email: jhw@apple.com









woodyatt                Expires December 8, 2007               [Page 17]


Internet-Draft     Simple Security in IPv6 Gateway CPE         June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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).





woodyatt                Expires December 8, 2007               [Page 18]