idnits 2.17.1 draft-ietf-v6ops-cpe-simple-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 845. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 21, 2007) is 5933 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4748 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 3989 (Obsoleted by RFC 5189) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations j. woodyatt, Ed. 3 Internet-Draft Apple 4 Intended status: Best Current December 21, 2007 5 Practice 6 Expires: June 23, 2008 8 Recommended Simple Security Capabilities in Customer Premises Equipment 9 for Providing Residential IPv6 Internet Service 10 draft-ietf-v6ops-cpe-simple-security-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 23, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document makes specific recommendations to the makers of devices 44 that provide "simple security" capabilities at the perimeter of 45 local-area IPv6 networks in Internet-enabled homes and small offices. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5 53 2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5 54 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 55 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 56 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 7 57 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 58 3.2.1. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8 59 3.2.2. Teredo-specific Filters . . . . . . . . . . . . . . . 9 60 3.2.3. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10 61 3.2.4. Other Virtual Private Network Protocols . . . . . . . 10 62 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 10 63 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11 64 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 14 65 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 14 66 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 14 67 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14 68 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 75 A.1. draft-ietf-v6ops-cpe-simple-security-00 to 76 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 17 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Intellectual Property and Copyright Statements . . . . . . . . . . 19 80 1. Introduction 82 In "Local Network Protection for IPv6" [RFC4864], IETF recommends 83 'simple security' capabilities for gateway devices that enable 84 delivery of Internet services in residential and small office 85 settings. The principle goal of these capabilties is to improve 86 security of the IPv6 Internet without increasing the perceived 87 complexity for users who just want to accomplish useful work. 89 There is, at best, a constructive tension between the desires of 90 users for transparent end-to-end connectivity on the one hand, and 91 the need for local-area network administrators to detect and prevent 92 intrusion by unauthorized public Internet users on the other. The 93 specific recommendations in this document are intended to promote 94 optimal local-area network security while retaining full end-to-end 95 transparency for users, and to highlight reasonable limitations on 96 transparency where security considerations are deemed important. 98 Residential and small office network administrators are expected to 99 have no expertise in Internet engineering whatsoever. Configuration 100 interfaces for simple security in router/gateway appliances marketed 101 toward them should be easy to understand and even easier to ignore. 102 In particular, extra care should be taken in designing the baseline 103 operating modes of unconfigured devices, since the security functions 104 of most devices will never be changed from their factory set default. 106 1.1. Special Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 The key word "DEFAULT" in this document is to be interpreted as the 113 configuration of a device, as applied by its vendor, prior to the 114 operator changing it for the first time. 116 2. Overview 118 For the purposes of this document, residential Internet gateways are 119 assumed to be fairly simple devices with a limited subset of the full 120 range of possible features. They function as default routers 121 [RFC4294] for a single local-area network segment, e.g. an ethernet, 122 a Wi-Fi network, a bridge between two or more such segments. They 123 have a single interface by which they connect to the public Internet, 124 and they can obtain service by any combination of sub-IP mechanisms, 125 including tunnels and transition mechanisms. In referring to their 126 security capabilities, it is reasonable to distinguish between the 127 "interior" network, i.e. the local-area network, and the "exterior" 128 network, i.e. the public Internet. This document is concerned with 129 the behavior of packet filters that police the flow of traffic 130 between the interior and exterior networks of residential Internet 131 gateways. 133 The operational goals of security capabilities in Internet gateways 134 are described with more detail in "Local Network Protection for IPv6" 135 [RFC4864], but they can be summarized as follows. 137 o Check all traffic to and from the public Internet for basic 138 sanity, e.g. anti-spoofing and "martian" filters. 140 o Allow tracking of application usage by source and destination 141 transport addresses. 143 o Provide a barrier against untrusted external influences on the 144 interior network by requiring filter state to be activated by 145 traffic originating at interior network nodes. 147 o Allow manually configured exceptions to the stateful filtering 148 rules according to network administration policy. 150 o Isolate local network DHCP and DNS proxy resolver services from 151 the public Internet. 153 Prior to the widespread availability of IPv6 Internet service, homes 154 and small offices often used private IPv4 network address realms 155 [RFC1918] with Network Address Translation (NAT) functions deployed 156 to present all the hosts on the interior network as a single host to 157 the Internet service provider. The stateful packet filtering 158 behavior of NAT set user expectations that persist today with 159 residential IPv6 service. "Local Network Protection for IPv6" 160 [RFC4864] recommends applying stateful packet filtering at 161 residential IPv6 gateways that conforms to the user expectations 162 already in place. 164 It should be noted that NAT for IPv6 is both strictly forbidden by 165 the standards documents and strongly deprecated by Internet 166 operators. Only the perceived security benefits associated with 167 stateful packet filtering, which NAT requires as a side effect, are 168 thought relevant in the IPv6 residential usage scenario. 170 As the latest revision of this document is being drafted, 171 conventional stateful packet filters are activated as a side effect 172 of outbound flow initiations from interior network nodes. This 173 requires applications to have advance knowledge of the addresses of 174 exterior nodes with which they expect to communicate. Several 175 proposals are currently under consideration for allowing applications 176 to solicit inbound traffic from exterior nodes without advance 177 knowledge of their addresses. While consensus within the Internet 178 engineering community has emerged that such protocols are necessary 179 to implement in residential IPv6 gateways, the best current practice 180 has not yet been established. 182 2.1. Basic Sanitation 184 In addition to the functions required of all Internet routers 185 [RFC4294], residential gateways are expected to have basic stateless 186 filters for prohibiting certains kinds of traffic with invalid 187 headers, e.g. martian packets, spoofs, routing header type code zero, 188 etc. 190 Internet gateways that route multicast traffic are expected to 191 implement appropriate filters for scoped multicast addresses. By 192 DEFAULT, residential Internet gateways SHOULD be organization-local 193 scope boundaries, i.e. traffic is only forwarded to multicast 194 destinations of wider than organization-local scope. 196 [ EDITOR'S NOTE: I don't know whether or what to say about mobility 197 support in this document. Consequently, I have not written any 198 detailed recommendations to that effect. ] 200 2.2. Internet Layer Protocols 202 In managed, enterprise networks, virtual private networking tunnels 203 are typically regarded as an additional attack surface. and they are 204 often restricted or prohibited from traversing firewalls for that 205 reason. However, it would be inappropriate to restrict virtual 206 private networking tunnels by default in unmanaged, residential 207 network usage scenarios. Therefore, this document recommends the 208 DEFAULT operating mode for residential IPv6 simple security is to 209 permit all virtual private networking tunnel protocols to pass 210 through the stateful filtering function. These include IPsec 211 transport and tunnel modes as well as other IP-in-IP protocols. 213 Where IPv6 simple security functions are integrated with an IPv4/NAT 214 gateway of any of the types described in [RFC4787], it's important to 215 keep IPv6 flows subject to a consistent policy. If the security 216 functions of an IPv6 residential gateway can be bypassed through 217 Teredo [RFC4380], then application developers will be encouraged to 218 use it even at nodes where native IPv6 service is available. This 219 will have the effect of impeding the completion of the transition to 220 native IPv6. 222 Residential IPv6 gateways are expected to continue operating as IPv4/ 223 NAT gateways for the foreseeable future. To prevent Teredo from 224 acquiring a utility that it was never meant to have on networks where 225 both IPv4/NAT and native IPv6 services are available, gateways MUST 226 impede Teredo tunnels by blocking clients from learning their mapped 227 addresses and ports in the qualification procedure described in 228 sections 5.2.1 and 5.2.2 of [RFC4380]. (Note: this is a necessary 229 addition to the "automatic sunset" provision in section 5.5 of 230 [RFC4380] because it's all too common that nested IPv4/NAT gateways 231 are deployed unintentionally in residential settings and without 232 consideration for Internet architectural implications.) 234 2.3. Transport Layer Protocols 236 IPv6 simple security functions are principally concerned with the 237 stateful filtering of transport layers like User Datagram Protocol 238 (UDP) [RFC0768], Transport Control Protocol (TCP) [RFC0793], the 239 Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram 240 Congestion Control Protocol (DCCP) [RFC4340], and potentially any 241 standards-track transport protocols to be defined in the future. 243 The general operating principle is that transport layer traffic is 244 only permitted into the interior network of a residential IPv6 245 gateway when it has been solicited explicitly by interior nodes. All 246 other traffic is expected to be discarded or rejected with an ICMPv6 247 error message to indicate the traffic is administratively prohibited. 249 3. Detailed Recommendations 251 This section describes the specific recommendations made by this 252 document in full detail. They are summarized into a convenient list 253 in Section 4. 255 Some recommended filters are to be applied to all traffic that passes 256 through residential Internet gateways regardless of the direction 257 they are to be forwarded. However, most filters are expected to be 258 sensitive to the direction that traffic is flowing. Packets are said 259 to be "outbound" if they originate from interior nodes to be 260 forwarded to the Internet, and "inbound" if they originate from 261 exterior nodes to be forwarded to any node or nodes on the interior 262 prefix. Flows, as opposed to packets, are said to be "outbound" if 263 the initiator is an interior node and one or more of the participants 264 are at exterior addresses. Flows are said to be "inbound" if the 265 initiator is an exterior node and one or more of the participants are 266 nodes on the interior network. The initiator of a flow is the first 267 node to send a packet in the context of a given transport 268 association, e.g. a TCP connection, et cetera. 270 3.1. Stateless Filters 272 Certain kinds of IPv6 packets MUST NOT be forwarded in either 273 direction by residential Internet gateways regardless of network 274 state. These include packets with multicast source addresses, 275 packets to destinations with certain non-routable and/or reserved 276 prefixes, and packets with deprecated extension headers. 278 Other stateless filters are recommended to guard against spoofing, to 279 enforce multicast scope boundaries, and to isolate certain local 280 network services from the public Internet. 282 R1: Packets bearing in their outer IPv6 headers multicast source 283 addresses MUST NOT be forwarded or transmitted on any interface. 285 R2: Packets bearing in their outer IPv6 headers multicast destination 286 addresses of equal or narrower scope that the configured scope 287 boundary level of the gateway MUST NOT be forwarded in any direction. 288 The DEFAULT scope boundary level SHOULD be organization-local scope. 290 R3: Packets bearing deprecated extension headers prior to their first 291 upper-layer-protocol header MUST NOT be forwarded or transmitted on 292 any interface. In particular, all packets with routing extension 293 header type 0 [RFC2460] preceding the first upper-layer-protocol 294 header MUST NOT be forwarded. 296 R4: Outbound packets MUST NOT be forwarded if the source address in 297 their outer IPv6 header does not have a unicast prefix assigned for 298 use by globally reachable nodes on the interior network. 300 R4: Inbound packets MUST NOT be forwarded if the source address in 301 their outer IPv6 header has a global unicast prefix assigned for use 302 by globally reachable nodes on the interior network. 304 R5: Packets MAY be discarded if the source and/or destination address 305 in the outer IPv6 header is a unique local address. By DEFAULT, 306 gateways SHOULD NOT forward packets across unique local address scope 307 boundaries. 309 R6: By DEFAULT, inbound non-recursive DNS queries received on 310 exterior interfaces MUST NOT be processed by any integrated DNS proxy 311 resolving server. 313 R7: Inbound DHCP discovery packets received on exterior interfaces 314 MUST NOT be processed by any integrated DHCP server. 316 3.2. Connection-free Filters 318 Some Internet applications use connection-free transport protocols 319 with no release semantics, e.g. UDP. These protocols pose a special 320 difficulty for stateful packet filters because most of the 321 application state is not carried at the transport level. State 322 records are created when communication is initiated and abandoned 323 when no further communication is detected after some period of time. 325 3.2.1. UDP Filters 327 "NAT Behaviorial Requirements for UDP" [RFC4787] defines the 328 terminology and best current practice for stateful filtering of UDP 329 applications in IPv4 with NAT, which serves as the model for 330 behaviorial requirements for simple UDP security in IPv6 gateways, 331 notwithstanding the requirements related specifically to network 332 address translation. 334 An interior endpoint initiates a UDP exchange through a stateful 335 packet filter by sending a packet to an exterior address. The filter 336 allocates (or reuses) a filter state record for the duration of the 337 exchange. The state record defines the interior and exterior IP 338 addresses and ports used between all packets in the exchange. 340 State records for UDP exchanges remain active while they are in use 341 and only abandoned after an idle period of some time. 343 R8: A state record for a UDP exchange where both interior and 344 exterior ports are outside the well-known port range (ports 0-1023) 345 MUST NOT expire in less than two minutes of idle time. The value of 346 the UDP state record idle timer MAY be configurable. The DEFAULT is 347 five minutes. 349 R9: A state record for a UDP exchange where one or both of the 350 interior and exterior ports are in the well-known port range (ports 351 0-1023) MAY expire after a period of idle time shorter than two 352 minutes to facilitate the operation of the IANA-registered service 353 assigned to the port in question. 355 As [RFC4787] notes, outbound refresh is necessary for allowing the 356 interior endpoint to keep the state record alive. Inbound refresh 357 may be useful for applications with no outbound UDP traffic. 358 However, allowing inbound refresh can allow an attacker in the 359 exterior or a misbehaviing application to keep a state record alive 360 indefinitely. This could be a security risk. Also, if the process 361 is repeated with different ports, over time, it could use up all the 362 state record memory and resources in the filter. 364 R10: A state record for a UDP exchange MUST be refreshed when a 365 packet is forwarded from the interior to the exterior, and it MAY be 366 refreshed when a packet is forwarded in the reverse direction. 368 As described in section 5.5 of [RFC4787], the connection-free 369 semantics of UDP pose a difficulty for packet filters in trying to 370 recognize which packets comprise an application flow and which are 371 unsolicited. Various strategies have been used in IPv4/NAT gateways 372 with differing effects. 374 R11: If application transparency is most important, then a stateful 375 packet filter SHOULD have "Endpoint independent filter" behavior for 376 UDP. If a more stringent filtering behavior is most important, then 377 a filter SHOULD have "Address dependent filtering" behavior. The 378 filtering behavior MAY be an option configurable by the network 379 administrator, and it MAY be independent of the filtering behavior 380 for TCP and other protocols. 382 Applications mechanisms may depend on the reception of ICMP error 383 messages triggered by the transmission of UDP messages. One such 384 mechanism is path MTU discovery. 386 R12: If a gateway forwards a UDP exchange, it MUST also forward ICMP 387 Destination Unreachable messages containing UDP headers that match 388 the exchange state record. 390 R13: Receipt of any sort of ICMP message MUST NOT terminate the state 391 record for a UDP exchange. 393 3.2.2. Teredo-specific Filters 395 Transitional residential IPv6 gateways that also feature integrated 396 IPv4/NAT gateways require special filtering for Teredo tunnels. 398 R14: Where an IPv6 prefix is advertised on an interior interface 399 alongside an IPv4 private address [RFC1918] and IPv4 Internet service 400 is provided with NAT [RFC4787], the Teredo qualification procedure 401 (see section 5.2.1 and 5.2.2 of [RFC4380]) for clients in the 402 interior MUST be prohibited by the IPv4/NAT stateful filter. This 403 SHOULD be done by blocking outbound UDP initiations to port 3544, the 404 port reserved by IANA for Teredo servers. This MAY be done by 405 discarding Teredo packets identified by the heuristic defined in 406 "Teredo Security Concerns Beyond What Is In RFC 4380" [HOAGLAND]. 408 [ EDITOR'S NOTE: In the event [HOAGLAND] does not advance to 409 publication as an RFC, then that heuristic will be reproduced here. ] 411 3.2.3. IPsec and Internet Key Exchange (IKE) 413 Internet protocol security (IPsec) offers greater flexibility and 414 better overall security than the simple security of stateful packet 415 filtering at network perimeters. Therefore, residential IPv6 416 gateways need not prohibit IPsec traffic flows. 418 R15: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 419 the forwarding of packets, to and from legitimate node addresses, 420 with destination extension headers of type "Authenticated Header 421 (AH)" [RFC4302] in their outer IP extension header chain. 423 R16: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 424 the forwarding of packets, to and from legitimate node addresses, 425 with an upper layer protocol of type "Encapsulating Security Payload 426 (ESP)" [RFC4303] in their outer IP extension header chain. 428 R17: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 429 the forwarding of any UDP packets, to and from legitimate node 430 addresses, with a destination port of 500, i.e. the port reserved by 431 IANA for the Internet Key Exchange Protocol [RFC4306]. 433 3.2.4. Other Virtual Private Network Protocols 435 Residential IPv6 gateways are not expected to prohibit the use of 436 virtual private networks in residential usage scenarios. 438 R18: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 439 the forwarding, to and from legitimate node addresses, with upper 440 layer protocol of type IP version 6, and SHOULD NOT prohibit the 441 forwarding of other tunneled networking protocols commonly used for 442 virtual private networking, e.g. IP version 4, Generic Routing 443 Encapsulation, etcetera. 445 3.3. Connection-oriented Filters 447 Most Internet applications use connection-oriented transport 448 protocols with orderly release semantics. These protocols include 449 the Transport Control Protocol (TCP) [RFC0793], the Stream Control 450 Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion 451 Control Protocol (DCCP) [RFC4340], and potentially any future IETF 452 standards-track transport protocols that use such semantics. 453 Stateful packet filters track the state of individual transport 454 connections and prohibit the forwarding of packets that do not match 455 the state of an active connection and do not conform to a rule for 456 the automatic creation of such state. 458 3.3.1. TCP Filters 460 An interior endpoint initiates a TCP connection through a stateful 461 packet filter by sending a SYN packet. The filter allocates (or 462 reuses) a filter state record for the connection. The state record 463 defines the interior and exterior IP addresses and ports used for 464 forwarding all packets for that connection. 466 Peer-to-peer applications use an alternate method of connection 467 initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse 468 stateful filters. In the simultaneous-open mode of operation, both 469 peers send SYN packets for the same TCP connection. The SYN packets 470 cross in the network. Upon receiving the other end's SYN packet, 471 each end responds with a SYN-ACK packet, which also cross in the 472 network. The connection is established at each endpoint once the 473 SYN-ACK packets are received. 475 In order to provide stateful packet filtering service for TCP, it is 476 necessary for a filter to receive, process and forward all packets 477 for a connection that conform to valid transitions of the TCP state 478 machine (Fig. 6, [RFC0793]). 480 R19: All valid sequences of TCP packets (defined in [RFC0793]) MUST 481 be forwarded for outbound connections and explicitly permitted 482 inbound connections. In particular, both the normal TCP 3-way 483 handshake mode of operation and the simultaneous-open modes of 484 operation MUST be supported. 486 A stateful filter can allow an existing mapping to be reused by an 487 externally initiated connection if its security policy permits. 488 Several different policies are possible as described in "Network 489 Address Translation (NAT) Behavioral Requirements for Unicast UDP 490 [RFC4787] and extended in "NAT Behaviorial Requirements for TCP" 491 [BEHAVE-TCP]. 493 R20: If application transparency is most important, then a stateful 494 packet filter SHOULD have "Endpoint independent filter" behavior for 495 TCP. If a more stringent filtering behavior is most important, then 496 a filter SHOULD have "Address dependent filtering" behavior. The 497 filtering behavior MAY be an option configurable by the network 498 administrator, and it MAY be independent of the filtering behavior 499 for UDP and other protocols. 501 If an inbound SYN packet is filtered, either because a corresponding 502 state record does not exist or because of the filter's normal 503 behavior, a filter has two basic choices: to discard the packet 504 silently, or to signal an error to the sender. Signaling an error 505 through ICMP messages allows the sender to detect that the SYN did 506 not reach the intended destination. Discarding the packet, on the 507 other hand, allows applications to perform simultaneous-open more 508 reliably. A more detailed discussion of this issue can be found in 509 [BEHAVE-TCP], but the basic outcome of it is that filters need to 510 wait on signaling errors until simultaneous-open will not be 511 impaired. 513 R21: A gateway MUST NOT signal an error for an unsolicited inbound 514 SYN packet for at least 6 seconds after the packet is received. If 515 during this interval the gateway receives and forwards an outbound 516 SYN for the connection, then the gateway MUST discard the original 517 unsolicited inbound SYN packet without signaling an error. 518 Otherwise, the gateway SHOULD send an ICMP Destination Unreachable 519 error, code 1 (administratively prohibited) for the original SYN-- 520 unless sending any response violates the security policy of network 521 administrator. 523 A TCP filter maintains state associated with in-progrss and 524 established connections. Because of this, a filter is susceptible to 525 a resource-exhaustion attack whereby an attacker (or virus) on the 526 interior attempts to cause the filter to exhaust its capacity for 527 creating state records. To prevent such an attack, a filter needs to 528 abandon unused state records after a sufficiently long period of 529 idleness. 531 A common method used for TCP filters in IPv4/NAT gateways is to 532 abandon preferentially sessions for crashed endpoints, followed by 533 closed TCP connections and partially-open connections. A gateway can 534 check if an endpoint for a session has crashed by sending a TCP keep- 535 alive packet on behalf of the other endpoint and receiving a TCP RST 536 packet in response. If the gateway connot determine whether the 537 endpoint is active, then the associated state record needs to be 538 retained until the TCP connection has been idle for some time. Note: 539 an established TCP connection can stay idle (but live) indefinitely; 540 hence, there is no fixed value for an idle-timeout that accomodates 541 all applications. However, a large idle-timeout motivated by 542 recommendations in [RFC1122] and [RFC4294] can reduce the chances of 543 abandoning a live connection. 545 TCP connections can stay in the established phase indefinitely 546 without exchanging packets. Some end-hosts can be configured to send 547 keep-alive packets on such idle connections; by default, such packets 548 are sent every two hours, if enabled [RFC1122]. Consequently, a 549 filter that waits for slightly over two hours can detect idle 550 connections with keep-alive packets being sent at the default rate. 551 TCP connections in the partially-open or closing phases, on the other 552 hand, can stay idle for at most four minutes while waiting for in- 553 flight packets to be delivered [RFC1122]. 555 The "established connection idle-timeout" for a stateful packet 556 filter is defined as the minimum time a TCP connection in the 557 established phase must remain idle before the filter considers the 558 associated state record a candidate for collection. The "transitory 559 connection idle-timeout" for a filter is defined as the minimum time 560 a TCP connection in the partially-open or closing phases must remain 561 idle before the filter considers the associated state record a 562 candidate for collection. TCP connections in the TIME_WAIT state are 563 not affected by the "transitory connection idle-timeout" parameter. 565 R22: If a gateway cannot determine whether the endpoints of a TCP 566 connection are active, then it MAY abandon the state record if it has 567 been idle for some time. In such cases, the value of the 568 "established connection idle-timeout" MUST NOT be less than two hours 569 four minutes. The value of the "transitory connection idle-timeout" 570 MUST NOT be less than four minutes. The value of the idle-timeouts 571 MAY be configurable by the network administrator. 573 Behavior for handing RST packets, or connections in the TIME_WAIT 574 state is left unspecified. A gateway MAY hold state for a connection 575 in TIME_WAIT state to accommodate retransmissions of the last ACK. 576 However, since the TIME_WAIT state is commonly encountered by 577 interior endpoints properly closing the TCP connection, holding state 578 for a closed connection can limit the throughput of connections 579 through a gateway with limited resources. [RFC1337] discusses 580 hazards associated with TIME_WAIT assassination. 582 The handling of non-SYN packets for which there is no active state 583 record is left unspecified. Such packets can be received if the 584 gateway abandons a live connection, or abandons a connection in the 585 TIME_WAIT state before the four minute TIME_WAIT period expires. The 586 decision either to discard or to respond with an ICMP Destination 587 Unreachable error, code 1 (administratively prohibited) is left up to 588 the implementation. 590 Behavior for notifying endpoints when abandoning live connections is 591 left unspecified. When a gateway abandons a live connection, for 592 example due to a timeout expiring, the filter MAY send a TCP RST 593 packet to each endpoint on behalf of the other. Sending a RST 594 notification allows endpoint applications to recover more quickly, 595 however, notifying endpoints might not always be possible if, for 596 example, state records are lost due to power interruption. 598 Several TCP mechanisms depend on the reception of ICMP error messages 599 triggered by the transmission of TCP segments. One such mechanism is 600 path MTU discovery, which is required for correct operation of TCP. 602 R23: If a gateway forwards a TCP connection, it MUST also forward 603 ICMP Destination Unreachable messages containing TCP headers that 604 match the connection state record. 606 R24: Receipt of any sort of ICMP message MUST NOT terminate the state 607 record for a TCP connection. 609 3.3.2. SCTP Filters 611 [ Insert verbiage here. ] 613 3.3.3. DCCP Filters 615 [ Insert verbiage here. ] 617 3.4. Passive Listeners 619 Some applications expect to solicit traffic from exterior nodes 620 without any advance knowledge of the exterior address. This 621 requirement is met by IPv4/NAT gateways typically by the use of 622 either [NAT-PMP] or [UPnP-IGD]. 624 One proposal that has been offered as an Internet Draft is the 625 Application Listener Discovery Protocol [IPv6-ALD]. It remains to be 626 seen whether the Internet Gateway Device profile of the Universal 627 Plug And Play protocol will be extended for IPv6. Other proposals of 628 note include the Middlebox Communication Protocol [RFC3989] and the 629 Next Steps in Signaling framework [RFC4080]. No consensus has yet 630 emerged in the Internet engineering community as to which proposal is 631 most appropriate for residential IPv6 usage scenarios. 633 R25: Gateways MUST implement a protocol to permit applications to 634 solicit inbound traffic without advance knowledge of the addresses of 635 exterior nodes with which they expect to communicate. This protocol 636 MUST have a specification that meets the requirements of [RFC3978], 637 [RFC3979] and [RFC4748]. 639 4. Summary of Recommendations 641 This section collects all of the recommendations made in this 642 document into a convenient list. 644 [ EDITOR'S NOTE: This section is left intentionally incomplete while 645 discussion on the V6CPE Design Team mailing list establishes a 646 consensus about what to present at IETF 68 in Chicago. ] 647 R1-Rn: Insert summary of recommendations R1-Rn here. 649 5. Contributors 651 Comments and criticisms during the development of this document were 652 received from the following IETF participants: Jun-ichiro itojun 653 Hagino, Kurt Erik Lindqvist and Fred Baker. 655 [ Insert list of additional contributors here. ] 657 Much of the text describing the detailed requirements for TCP and UDP 658 filtering is derived or transposed from [BEHAVE-TCP] and [RFC4787], 659 and some form of attribution here may therefore be appopriate. 661 6. IANA Considerations 663 This memo includes no request to IANA. 665 7. Security Considerations 667 All drafts are required to have a security considerations section. 668 See RFC 3552 [RFC3552] for a guide. 670 [ EDITOR'S NOTE: Yes, I'm sure there are security considerations, but 671 I'm currently at a loss for words to describe them. This section 672 needs careful wordsmithing prior to the next revision. ] 674 8. References 676 8.1. Normative References 678 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 679 August 1980. 681 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 682 RFC 793, September 1981. 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 688 (IPv6) Specification", RFC 2460, December 1998. 690 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 691 RFC 3978, March 2005. 693 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 694 Technology", BCP 79, RFC 3979, March 2005. 696 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 697 December 2005. 699 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 700 RFC 4303, December 2005. 702 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 703 RFC 4306, December 2005. 705 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 706 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 708 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 709 Network Address Translations (NATs)", RFC 4380, 710 February 2006. 712 [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF 713 Trust", BCP 78, RFC 4748, October 2006. 715 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 716 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 717 RFC 4787, January 2007. 719 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 720 RFC 4960, September 2007. 722 8.2. Informative References 724 [BEHAVE-TCP] 725 Guha, S., Biswas, K., Sivakumar, S., Ford, B., and P. 726 Srisuresh, "NAT Behavioral Requirements for TCP", 727 April 2007, 728 . 730 [HOAGLAND] 731 Hoagland, J., "Teredo Security Concerns Beyond What Is In 732 RFC 4380", May 2007, . 735 [IPv6-ALD] 736 Woodyatt, j., "Application Listener Discovery (ALD) for 737 IPv6", May 2007, 738 . 740 [NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port 741 Mapping Protocol (NAT-PMP)", November 2001, 742 . 744 [RFC1122] Braden, R., "Requirements for Internet Hosts - 745 Communication Layers", STD 3, RFC 1122, October 1989. 747 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 748 RFC 1337, May 1992. 750 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 751 E. Lear, "Address Allocation for Private Internets", 752 BCP 5, RFC 1918, February 1996. 754 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 755 Text on Security Considerations", BCP 72, RFC 3552, 756 July 2003. 758 [RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 759 Communications (MIDCOM) Protocol Semantics", RFC 3989, 760 February 2005. 762 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 763 Bosch, "Next Steps in Signaling (NSIS): Framework", 764 RFC 4080, June 2005. 766 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 767 April 2006. 769 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 770 E. Klein, "Local Network Protection for IPv6", RFC 4864, 771 May 2007. 773 [UPnP-IGD] 774 UPnP Forum, "Universal Plug and Play Internet Gateway 775 Device Standardized Gateway Device Protocol", 776 September 2006, 777 . 779 Appendix A. Change Log 781 A.1. draft-ietf-v6ops-cpe-simple-security-00 to 782 draft-ietf-v6ops-cpe-simple-security-01 784 o Added requirements for sequestering DHCP and DNS proxy resolver 785 services to the local network. 787 o Fixed numbering of recommendations. 789 o Local Network Protection is now [RFC4864]. 791 o SCTP is now [RFC4960]. 793 o Moved some references to informative. 795 o Corrected the reference for [HOAGLAND]. 797 Author's Address 799 james woodyatt (editor) 800 Apple Inc. 801 1 Infinite Loop 802 Cupertino, CA 95014 803 US 805 Email: jhw@apple.com 807 Full Copyright Statement 809 Copyright (C) The IETF Trust (2007). 811 This document is subject to the rights, licenses and restrictions 812 contained in BCP 78, and except as set forth therein, the authors 813 retain all their rights. 815 This document and the information contained herein are provided on an 816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 818 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 819 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 820 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 823 Intellectual Property 825 The IETF takes no position regarding the validity or scope of any 826 Intellectual Property Rights or other rights that might be claimed to 827 pertain to the implementation or use of the technology described in 828 this document or the extent to which any license under such rights 829 might or might not be available; nor does it represent that it has 830 made any independent effort to identify any such rights. Information 831 on the procedures with respect to rights in RFC documents can be 832 found in BCP 78 and BCP 79. 834 Copies of IPR disclosures made to the IETF Secretariat and any 835 assurances of licenses to be made available, or the result of an 836 attempt made to obtain a general license or permission for the use of 837 such proprietary rights by implementers or users of this 838 specification can be obtained from the IETF on-line IPR repository at 839 http://www.ietf.org/ipr. 841 The IETF invites any interested party to bring to its attention any 842 copyrights, patents or patent applications, or other proprietary 843 rights that may cover technology that may be required to implement 844 this standard. Please address the information to the IETF at 845 ietf-ipr@ietf.org. 847 Acknowledgment 849 Funding for the RFC Editor function is provided by the IETF 850 Administrative Support Activity (IASA).