idnits 2.17.1 draft-ietf-v6ops-cpe-simple-security-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 (September 29, 2010) is 4958 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5156 (Obsoleted by RFC 6890) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: Informational September 29, 2010 5 Expires: April 2, 2011 7 Recommended Simple Security Capabilities in Customer Premises Equipment 8 for Providing Residential IPv6 Internet Service 9 draft-ietf-v6ops-cpe-simple-security-14 11 Abstract 13 This document identifies a set of recommendations for the makers of 14 devices describing how to provide for "simple security" capabilities 15 at the perimeter of local-area IPv6 networks in Internet-enabled 16 homes and small offices. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 2, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Use of Normative Keywords . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5 58 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 59 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 60 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 62 3.2.1. Internet Control and Management . . . . . . . . . . . 8 63 3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8 64 3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 9 65 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10 66 3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 11 67 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12 68 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13 69 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16 70 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19 71 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21 72 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22 73 3.5. Management Applications . . . . . . . . . . . . . . . . . 23 74 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23 75 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 83 1. Introduction 85 Some IPv6 gateway devices that enable delivery of Internet services 86 in residential and small office settings may be augmented with 87 'simple security' capabilities as described in "Local Network 88 Protection for IPv6" [RFC4864]. In general, these capabilities cause 89 packets to be discarded in an attempt to make local networks and the 90 Internet more secure. However, it is worth noting that some packets 91 sent by legitimate applications may also be discarded in this 92 process, affecting reliability and ease of use for these 93 applications. 95 There is a constructive tension between the desires of users for 96 transparent end-to-end connectivity on the one hand, and the need for 97 local-area network administrators to detect and prevent intrusion by 98 unauthorized public Internet users on the other. This document is 99 intended to highlight reasonable limitations on end-to-end 100 transparency where security considerations are deemed important to 101 promote local and Internet security. 103 The reader is cautioned always to remember that the typical 104 residential or small office network administrator has no expertise 105 whatsoever in Internet engineering. Configuration interfaces for 106 router/gateway appliances marketed toward them should be easy to 107 understand and even easier to ignore. In particular, extra care 108 should be used in the design of baseline operating modes for 109 unconfigured devices, since most devices will never be changed from 110 their factory configurations. 112 1.1. Special Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 Additionally, the key word "DEFAULT" is to be interpreted in this 119 document as pertaining to a configuration as applied by a vendor, 120 prior to the administrator changing it for its initial activation. 122 1.2. Use of Normative Keywords 124 NOTE WELL: This document is not a standard, and conformance with it 125 is not required in order to claim conformance with IETF standards for 126 IPv6. It uses the normative keywords defined in the previous section 127 only for precision. 129 Particular attention is drawn to recommendation REC-47, which calls 130 for an easy way to set a gateway to a transparent mode of operation. 132 2. Overview 134 For the purposes of this document, residential Internet gateways are 135 assumed to be fairly simple devices with a limited subset of the full 136 range of possible features. They function as default routers 137 [RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi 138 network, a bridge between two or more such segments. They have only 139 one interface by which they can access the Internet service at any 140 one time, using any of several possible sub-IP mechanisms including 141 tunnels and transition mechanisms. 143 In referring to the security capabilities of residential gateways, it 144 is reasonable to distinguish between their "interior" network, i.e. 145 the local-area network, and their "exterior" networks, e.g. the 146 public Internet and the networks of Internet service providers. This 147 document is concerned only with the behavior of IP packet filters 148 that police the flow of traffic between the interior IPv6 network and 149 the exterior IPv6 networks of residential Internet gateways. 151 The operational goals of security capabilities in Internet gateways 152 are described with more detail in "Local Network Protection for IPv6" 153 [RFC4864], but they can be summarized as follows. 155 o Check all traffic to and from the public Internet for basic 156 sanity, e.g. anti-spoofing and "martian" [RFC4949] filters. 158 o Allow tracking of applications usage by source and destination 159 network addresses and ports. 161 o Provide a barrier against untrusted external influences on the 162 interior network by requiring filter state to be activated by 163 traffic originating at interior network nodes. 165 o Allow manually configured exceptions to the stateful filtering 166 rules according to network administrative policy. 168 o Isolate local network DHCPv6 and DNS resolver services from the 169 public Internet. 171 Prior to the widespread availability of IPv6 Internet service, homes 172 and small offices often used private IPv4 network address realms 173 [RFC1918] with Network Address Translation (NAT) functions deployed 174 to present all the hosts on the interior network as a single host to 175 the Internet service provider. The stateful packet filtering 176 behavior of NAT set user expectations that persist today with 177 residential IPv6 service. "Local Network Protection for IPv6" 178 [RFC4864] recommends applying stateful packet filtering at 179 residential IPv6 gateways that conforms to the user expectations 180 already in place. 182 Conventional stateful packet filters activate new states as a side 183 effect of forwarding outbound flow initiations from interior network 184 nodes. This requires applications to have advance knowledge of the 185 addresses of exterior nodes with which they expect to communicate. 186 Several proposals are currently under consideration for allowing 187 applications to solicit inbound traffic from exterior nodes without 188 advance knowledge of their addresses. While consensus within the 189 Internet engineering community has emerged that such protocols are 190 necessary to implement in residential IPv6 residential gateways, the 191 best current practice has not yet been established. 193 2.1. Basic Sanitation 195 In addition to the functions required of all Internet routers 196 [RFC4294], residential gateways are expected to have basic stateless 197 filters for prohibiting certain kinds of traffic with invalid 198 headers, e.g. "martian" packets, spoofs, routing header type code 199 zero, etc. (See Section 3.1 for more details.) 201 Conversely, simple Internet gateways are not expected to prohibit the 202 development of new applications. In particular, packets with end-to- 203 end network security and routing extension headers for mobility are 204 expected to pass Internet gateways freely. 206 Finally, Internet gateways that route multicast traffic are expected 207 to implement appropriate filters for multicast traffic to limit the 208 scope of multicast groups that span the demarcation between 209 residential networks and service provider networks. 211 2.2. Internet Layer Protocols 213 As virtual private networking tunnels are regarded as an unacceptably 214 wide attack surface, this document recommends the DEFAULT operating 215 mode for residential IPv6 simple security is to treat Generic Packet 216 Tunneling [RFC2473] and similar protocols as opaque transport layers, 217 i.e. inbound tunnel initiations are denied and outbound tunnel 218 initiations are accepted. 220 IPsec transport and tunnel modes are explicitly secured by 221 definition, so this document recommends the DEFAULT operating mode 222 permit IPsec. To facilitate the use of IPsec in support of IPv6 223 Mobility, Internet Key Exchange (IKE) protocol [RFC4306] and "Host 224 Identity Protocol (HIP)" [RFC5201] should also be permitted in the 225 DEFAULT operating mode. 227 2.3. Transport Layer Protocols 229 IPv6 simple security functions are principally concerned with the 230 stateful filtering of Internet Control Message Protocol (ICMPv6) 231 [RFC4443] and transport layers like User Datagram Protocol (UDP) 232 [RFC0768], Lightweight User Datagram Protocol (UDP-Lite) [RFC3828], 233 Transport Control Protocol (TCP) [RFC0793], the Stream Control 234 Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion 235 Control Protocol (DCCP) [RFC4340], and potentially any standards- 236 track transport protocols to be defined in the future. 238 The general operating principle is that transport layer traffic is 239 not forwarded into the interior network of a residential IPv6 gateway 240 unless it has been solicited explicitly by interior transport 241 endpoints, e.g. by matching the reverse path for previously forwarded 242 outbound traffic, or by matching configured exceptions set by the 243 network administrator. All other traffic is expected to be discarded 244 or rejected with an ICMPv6 error message to indicate the traffic is 245 administratively prohibited. 247 3. Detailed Recommendations 249 This section describes the specific recommendations made by this 250 document in full detail. Section 4 is a summary. 252 Some recommended filters are to be applied to all traffic that passes 253 through residential Internet gateways regardless of the direction 254 they are to be forwarded. Other recommended filters are intended to 255 be sensitive to the "direction" of traffic flows. Applied to 256 bidirectional transport flows, "direction" has a specific meaning in 257 this document. 259 Packets are said to be "outbound" if they originate at nodes located 260 in the interior network for exterior destinations, and "inbound" if 261 they arrive from exterior sources with interior destinations. 263 Flows are said to be "outbound" if the originator of the initial 264 packet in any given transport association is an interior node and one 265 or more of the participants are located in the exterior. Flows are 266 said to be "inbound" if the originator of the initial packet is an 267 exterior node and one or more of the participants are nodes on the 268 interior network. 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 implement ingress 279 filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope 280 boundaries, and to isolate certain local network services from the 281 public Internet. 283 REC-1: Packets which bear in their outer IPv6 headers multicast 284 source addresses MUST NOT be forwarded or transmitted on any 285 interface. 287 REC-2: Packets which bear in their outer IPv6 headers multicast 288 destination addresses of equal or narrower scope (see IPv6 Scoped 289 Address Architecture [RFC4007]) than the configured scope boundary 290 level of the gateway MUST NOT be forwarded in any direction. The 291 DEFAULT scope boundary level SHOULD be organization-local scope, and 292 it SHOULD be configurable by the network administrator. 294 REC-3: Packets bearing source and/or destination addresses forbidden 295 to appear in the outer headers of packets transmitted over the public 296 Internet MUST NOT be forwarded. In particular, site-local addresses 297 are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use 298 of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and 299 ORCHID prefixes. 301 REC-4: Packets bearing deprecated extension headers prior to their 302 first upper-layer-protocol header SHOULD NOT be forwarded or 303 transmitted on any interface. In particular, all packets with 304 routing extension header type 0 [RFC2460] preceding the first upper- 305 layer-protocol header MUST NOT be forwarded. See [RFC5095] for 306 additional background. 308 REC-5: Outbound packets MUST NOT be forwarded if the source address 309 in their outer IPv6 header does not have a unicast prefix configured 310 for use by globally reachable nodes on the interior network. 312 REC-6: Inbound packets MUST NOT be forwarded if the source address in 313 their outer IPv6 header has a global unicast prefix assigned for use 314 by globally reachable nodes on the interior network. 316 REC-7: By DEFAULT, packets with unique local source and/or 317 destination addresses [RFC4193] SHOULD NOT be forwarded to or from 318 the exterior network. 320 REC-8: By DEFAULT, inbound DNS queries received on exterior 321 interfaces MUST NOT be processed by any integrated DNS resolving 322 server. 324 REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on 325 exterior interfaces MUST NOT be processed by any integrated DHCPv6 326 server. 328 3.2. Connection-free Filters 330 Some Internet applications use connection-free transport protocols 331 with no release semantics, e.g. UDP. These protocols pose a special 332 difficulty for stateful packet filters because most of the 333 application state is not carried at the transport level. State 334 records are created when communication is initiated and abandoned 335 when no further communication is detected after some period of time. 337 3.2.1. Internet Control and Management 339 Recommendations for filtering ICMPv6 messages in firewall devices are 340 described separately in [RFC4890] and apply to residential gateways 341 with the additional recommendation that incoming "Destination 342 Unreachable" and "Packet Too Big" error messages that don't match any 343 filtering state should be dropped. 345 REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination 346 Unreachable" and "Packet Too Big" messages containing IP headers that 347 do not match generic upper-layer transport state records. 349 3.2.2. Upper-layer Transport Protocols 351 Residential IPv6 gateways are not expected to prohibit the use of 352 applications to be developed using future upper-layer transport 353 protocols. In particular, transport protocols not otherwise 354 discussed in subsequent sections of this document are expected to be 355 treated consistently, i.e. as having connection-free semantics and no 356 special requirements to inspect the transport headers. 358 In general, upper-layer transport filter state records are expected 359 to be created when an interior endpoint sends a packet to an exterior 360 address. The filter allocates (or reuses) a record for the duration 361 of communications, with an idle timer to delete the state record when 362 no further communications are detected. 364 REC-11: If application transparency is most important, then a 365 stateful packet filter SHOULD have "Endpoint independent filter" 366 behavior for generic upper-layer transport protocols. If a more 367 stringent filtering behavior is most important, then a filter SHOULD 368 have "Address dependent filtering" behavior. The filtering behavior 369 MAY be an option configurable by the network administrator, and it 370 MAY be independent of the filtering behavior for other protocols. 371 Filtering behavior SHOULD be endpoint independent by DEFAULT in 372 gateways intended for provisioning without service-provider 373 management. 375 REC-12: Filter state records for generic upper-layer transport 376 protocols MUST NOT be deleted or recycled until an idle timer not 377 less than two minutes has expired without having forwarded a packet 378 matching the state in some configurable amount of time. By DEFAULT, 379 the idle timer for such state records is five minutes. 381 3.2.3. UDP Filters 383 "Network Address Translation (NAT) Behavioral Requirements for 384 Unicast UDP" [RFC4787] defines the terminology and best current 385 practice for stateful filtering of UDP applications in IPv4 with NAT, 386 which serves as the model for behavioral requirements for simple UDP 387 security in IPv6 gateways, notwithstanding the requirements related 388 specifically to network address translation. 390 An interior endpoint initiates a UDP flow through a stateful packet 391 filter by sending a packet to an exterior address. The filter 392 allocates (or reuses) a filter state record for the duration of the 393 flow. The state record defines the interior and exterior IP 394 addresses and ports used between all packets in the flow. 396 State records for UDP flows remain active while they are in use and 397 only abandoned after an idle period of some time. 399 REC-13: A state record for a UDP flow where both source and 400 destination ports are outside the well-known port range (ports 401 0-1023) MUST NOT expire in less than two minutes of idle time. The 402 value of the UDP state record idle timer MAY be configurable. The 403 DEFAULT is five minutes. 405 REC-14: A state record for a UDP flow where one or both of the source 406 and destination ports are in the well-known port range (ports 0-1023) 407 MAY expire after a period of idle time shorter than two minutes to 408 facilitate the operation of the IANA-registered service assigned to 409 the port in question. 411 As [RFC4787] notes, outbound refresh is necessary for allowing the 412 interior endpoint to keep the state record alive. Inbound refresh 413 may be useful for applications with no outbound UDP traffic. 414 However, allowing inbound refresh can allow an attacker in the 415 exterior or a misbehaving application to keep a state record alive 416 indefinitely. This could be a security risk. Also, if the process 417 is repeated with different ports, over time, it could use up all the 418 state record memory and resources in the filter. 420 REC-15: A state record for a UDP flow MUST be refreshed when a packet 421 is forwarded from the interior to the exterior, and it MAY be 422 refreshed when a packet is forwarded in the reverse direction. 424 As described in Section 5.5 of [RFC4787], the connection-free 425 semantics of UDP pose a difficulty for packet filters in trying to 426 recognize which packets comprise an application flow and which are 427 unsolicited. Various strategies have been used in IPv4/NAT gateways 428 with differing effects. 430 REC-16: If application transparency is most important, then a 431 stateful packet filter SHOULD have "Endpoint independent filter" 432 behavior for UDP. If a more stringent filtering behavior is most 433 important, then a filter SHOULD have "Address dependent filtering" 434 behavior. The filtering behavior MAY be an option configurable by 435 the network administrator, and it MAY be independent of the filtering 436 behavior for TCP and other protocols. Filtering behavior SHOULD be 437 endpoint independent by DEFAULT in gateways intended for provisioning 438 without service-provider management. 440 Applications mechanisms may depend on the reception of ICMPv6 error 441 messages triggered by the transmission of UDP messages. One such 442 mechanism is path MTU discovery. 444 REC-17: If a gateway forwards a UDP flow, it MUST also forward ICMPv6 445 "Destination Unreachable" and "Packet Too Big" messages containing 446 UDP headers that match the flow state record. 448 REC-18: Receipt of any sort of ICMPv6 message MUST NOT terminate the 449 state record for a UDP flow. 451 REC-19: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as 452 UDP flows, except that the upper-layer transport protocol identifier 453 for UDP-Lite is not the same as UDP, and therefore UDP packets MUST 454 NOT match UDP-Lite state records, and vice versa. 456 3.2.4. IPsec and Internet Key Exchange (IKE) 458 The Internet protocol security suite (IPsec) offers greater 459 flexibility and better overall security than the simple security of 460 stateful packet filtering at network perimeters. Therefore, 461 residential IPv6 gateways need not prohibit IPsec traffic flows. 463 REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT 464 prohibit the forwarding of packets, to and from legitimate node 465 addresses, with destination extension headers of type "Authenticated 466 Header (AH)" [RFC4302] in their outer IP extension header chain. 468 REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT 469 prohibit the forwarding of packets, to and from legitimate node 470 addresses, with an upper layer protocol of type "Encapsulating 471 Security Payload (ESP)" [RFC4303] in their outer IP extension header 472 chain. 474 REC-22: If a gateway forwards an ESP flow, it MUST also forward (in 475 the reverse direction) ICMPv6 "Destination Unreachable" and "Packet 476 Too Big" messages containing ESP headers that match the flow state 477 record. 479 Internet Key Exchange (IKE) is a secure mechanism for performing 480 mutual authentication, exchanging cryptographic material and 481 establishing IPsec Security Associations between peers. Residential 482 IPv6 gateways are expected to facilitate the use of IPsec security 483 policies by allowing inbound IKE flows. 485 REC-23: In their DEFAULT operating mode, IPv6 gateways MUST NOT 486 prohibit the forwarding of any UDP packets, to and from legitimate 487 node addresses, with a destination port of 500, i.e. the port 488 reserved by IANA for the Internet Key Exchange (IKE) protocol 489 [RFC4306]. 491 REC-24: In all operating modes, IPv6 gateways SHOULD use filter state 492 records for Encapsulating Security Payload (ESP) [RFC4303] that are 493 indexable by a 3-tuple comprising the interior node address, the 494 exterior node address and the ESP protocol identifier. In 495 particular, the IPv4/NAT method of indexing state records also by 496 security parameters index (SPI) SHOULD NOT be used. Likewise, any 497 mechanism that depends on detection of Internet Key Exchange (IKE) 498 [RFC4306] initiations SHOULD NOT be used. 500 "Host Identity Protocol (HIP)" is a secure mechanism for establishing 501 host identity and secure communications between authenticated hosts. 502 Residential IPv6 gateways need not prohibit inbound HIP flows. 504 REC-25: In their DEFAULT operating mode, IPv6 gateways MUST NOT 505 prohibit the forwarding of packets, to and from legitimate node 506 addresses, with destination extension headers of type "Host Identity 507 Protocol (HIP)" [RFC5201] in their outer IP extension header chain. 509 3.2.5. Mobility Support in IPv6 511 Mobility support in IPv6 [RFC3775] relies on the use of an 512 encapsulation mechanism in flows between mobile nodes and their 513 correspondent nodes, involving the use of the type 2 IPv6 routing 514 header, the Home Address destination header option and the Mobility 515 extension header. In contrast to mobility support in IPv4, mobility 516 is a standard feature of IPv6, and no security benefit is generally 517 to be gained by denying communications with either interior or 518 exterior mobile nodes. 520 Not all usage scenarios of Mobility support in IPv6 are expected to 521 compatible with IPv6 simple security. In particular, exterior mobile 522 nodes are expected to be prohibited from establishing bindings with 523 interior correspondent nodes by the filtering of unsolicited inbound 524 Mobility Header messages unless they are the subject of an IPsec 525 security policy. 527 REC-26: The state records for flows initiated by outbound packets 528 that bear a Home Address destination option [RFC3775] are 529 distinguished by the addition of the home address of the flow as well 530 as the interior care-of address. IPv6 gateways MUST NOT prohibit the 531 forwarding of any inbound packets bearing type 2 routing headers, 532 which otherwise match a flow state record, and where A) the address 533 in the destination field of the IPv6 header matches the interior 534 care-of address of the flow, and B) the Home Address field in the 535 Type 2 Routing Header matches the home address of the flow. 537 REC-27: Valid sequences of Mobility Header [RFC3775] packets MUST be 538 forwarded for all outbound and explicitly permitted inbound Mobility 539 Header flows. 541 REC-28: If a gateway forwards a Mobility Header [RFC3775] flow, then 542 it MUST also forward, in both directions, the IPv4 and IPv6 packets 543 that are encapsulated in IPv6 associated with the tunnel between the 544 home agent and the correspondent node. 546 REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then 547 it MUST also forward (in the reverse direction) ICMPv6 "Destination 548 Unreachable" and "Packet Too Big" messages containing any headers 549 that match the associated flow state records. 551 3.3. Connection-oriented Filters 553 Most Internet applications use connection-oriented transport 554 protocols with orderly release semantics. These protocols include 555 TCP, SCTP, DCCP, and potentially any future IETF standards-track 556 transport protocols that use such semantics. Stateful packet filters 557 track the state of individual transport flows and prohibit the 558 forwarding of packets that do not match the state of an active flow 559 and do not conform to a rule for the automatic creation of such 560 state. 562 3.3.1. TCP Filters 564 An interior endpoint initiates a TCP flow through a stateful packet 565 filter by sending a SYN packet. The filter allocates (or reuses) a 566 filter state record for the flow. The state record defines the 567 interior and exterior IP addresses and ports used for forwarding all 568 packets for that flow. 570 Some peer-to-peer applications use an alternate method of connection 571 initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse 572 stateful filters. In the simultaneous-open mode of operation, both 573 peers send SYN packets for the same TCP flow. The SYN packets cross 574 in the network. Upon receiving the other end's SYN packet, each end 575 responds with a SYN-ACK packet, which also cross in the network. The 576 connection is established at each endpoint once the SYN-ACK packets 577 are received. 579 To provide stateful packet filtering service for TCP, it is necessary 580 for a filter to receive, process and forward all packets for a flow 581 that conform to valid transitions of the TCP state machine (Fig. 6, 582 [RFC0793]). 584 REC-30: All valid sequences of TCP packets (defined in [RFC0793]) 585 MUST be forwarded for outbound flows and explicitly permitted inbound 586 flows. In particular, both the normal TCP 3-way handshake mode of 587 operation and the simultaneous-open modes of operation MUST be 588 supported. 590 It is possible to reconstruct enough of the state of a TCP flow to 591 allow forwarding between an interior and exterior node even when the 592 filter starts operating after TCP enters the established state. In 593 this case, because the filter has not seen the TCP window-scale 594 option, it is not possible for the filter to enforce the TCP window 595 invariant by dropping out-of-window segments. 597 REC-31: The TCP window invariant MUST NOT be enforced on flows for 598 which the filter did not detect whether the window-scale option (see 599 [RFC1323]) was sent in the 3-way handshake or simultaneous open. 601 A stateful filter can allow an existing state record to be reused by 602 an externally initiated flow if its security policy permits. Several 603 different policies are possible as described in [RFC4787] and 604 extended in [RFC5382]. 606 REC-32: If application transparency is most important, then a 607 stateful packet filter SHOULD have "Endpoint independent filter" 608 behavior for TCP. If a more stringent filtering behavior is most 609 important, then a filter SHOULD have "Address dependent filtering" 610 behavior. The filtering behavior MAY be an option configurable by 611 the network administrator, and it MAY be independent of the filtering 612 behavior for UDP and other protocols. Filtering behavior SHOULD be 613 endpoint independent by DEFAULT in gateways intended for provisioning 614 without service-provider management. 616 If an inbound SYN packet is filtered, either because a corresponding 617 state record does not exist or because of the filter's normal 618 behavior, a filter has two basic choices: to discard the packet 619 silently, or to signal an error to the sender. Signaling an error 620 through ICMPv6 messages allows the sender to detect that the SYN did 621 not reach the intended destination. Discarding the packet, on the 622 other hand, allows applications to perform simultaneous-open more 623 reliably. A more detailed discussion of this issue can be found in 624 [RFC5382], but the basic outcome of it is that filters need to wait 625 on signaling errors until simultaneous-open will not be impaired. 627 REC-33: By DEFAULT, a gateway MUST respond with an ICMPv6 628 "Destination Unreachable" error code 1 (administratively prohibited) 629 to any unsolicited inbound SYN packet after waiting at least 6 630 seconds without first forwarding the associated outbound SYN or SYN/ 631 ACK from the interior peer. 633 A TCP filter maintains state associated with in-progress connections 634 and established flows. Because of this, a filter is susceptible to a 635 resource-exhaustion attack whereby an attacker (or virus) on the 636 interior attempts to cause the filter to exhaust its capacity for 637 creating state records. To defend against such attacks, a filter 638 needs to abandon unused state records after a sufficiently long 639 period of idleness. 641 A common method used for TCP filters in IPv4/NAT gateways is to 642 abandon preferentially flow state records for crashed endpoints, 643 followed by closed flows and partially-open flows. A gateway can 644 check if an endpoint for a session has crashed by sending a TCP keep- 645 alive packet on behalf of the other endpoint and receiving a TCP RST 646 packet in response. If the gateway cannot determine whether the 647 endpoint is active, then the associated state record needs to be 648 retained until the TCP flow has been idle for some time. Note: an 649 established TCP flow can stay idle (but live) indefinitely; hence, 650 there is no fixed value for an idle-timeout that accommodates all 651 applications. However, a large idle-timeout motivated by 652 recommendations in [RFC1122] and [RFC4294] can reduce the chances of 653 abandoning a live flow. 655 TCP flows can stay in the established phase indefinitely without 656 exchanging packets. Some end-hosts can be configured to send keep- 657 alive packets on such idle flows; by default, such packets are sent 658 every two hours, if enabled [RFC1122]. Consequently, a filter that 659 waits for slightly over two hours can detect idle flows with keep- 660 alive packets being sent at the default rate. TCP flows in the 661 partially-open or closing phases, on the other hand, can stay idle 662 for at most four minutes while waiting for in-flight packets to be 663 delivered [RFC1122]. 665 The "established flow idle-timeout" for a stateful packet filter is 666 defined as the minimum time a TCP flow in the established phase must 667 remain idle before the filter considers the associated state record a 668 candidate for collection. The "transitory flow idle-timeout" for a 669 filter is defined as the minimum time a TCP flow in the partially- 670 open or closing phases must remain idle before the filter considers 671 the associated state record a candidate for collection. TCP flows in 672 the TIME_WAIT state are not affected by the "transitory flow idle- 673 timeout" parameter. 675 REC-34: If a gateway cannot determine whether the endpoints of a TCP 676 flow are active, then it MAY abandon the state record if it has been 677 idle for some time. In such cases, the value of the "established 678 flow idle-timeout" MUST NOT be less than two hours four minutes, as 679 discussed in [RFC5382]. The value of the "transitory flow idle- 680 timeout" MUST NOT be less than four minutes. The value of the idle- 681 timeouts MAY be configurable by the network administrator. 683 Behavior for handing RST packets, or TCP flows in the TIME_WAIT state 684 is left unspecified. A gateway MAY hold state for a flow in 685 TIME_WAIT state to accommodate retransmissions of the last ACK. 686 However, since the TIME_WAIT state is commonly encountered by 687 interior endpoints properly closing the TCP flow, holding state for a 688 closed flow can limit the throughput of flows through a gateway with 689 limited resources. [RFC1337] discusses hazards associated with 690 TIME_WAIT assassination. 692 The handling of non-SYN packets for which there is no active state 693 record is left unspecified. Such packets can be received if the 694 gateway abandons a live flow, or abandons a flow in the TIME_WAIT 695 state before the four minute TIME_WAIT period expires. The decision 696 either to discard or to respond with an ICMPv6 "Destination 697 Unreachable" error code 1 (administratively prohibited) is left up to 698 the implementation. 700 Behavior for notifying endpoints when abandoning live flows is left 701 unspecified. When a gateway abandons a live flow, for example due to 702 a timeout expiring, the filter MAY send a TCP RST packet to each 703 endpoint on behalf of the other. Sending a RST notification allows 704 endpoint applications to recover more quickly, however, notifying 705 endpoints might not always be possible if, for example, state records 706 are lost due to power interruption. 708 Several TCP mechanisms depend on the reception of ICMPv6 error 709 messages triggered by the transmission of TCP segments. One such 710 mechanism is path MTU discovery, which is required for correct 711 operation of TCP. 713 REC-35: If a gateway forwards a TCP flow, it MUST also forward ICMPv6 714 "Destination Unreachable" and "Packet Too Big" messages containing 715 TCP headers that match the flow state record. 717 REC-36: Receipt of any sort of ICMPv6 message MUST NOT terminate the 718 state record for a TCP flow. 720 3.3.2. SCTP Filters 722 Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows 723 can be terminated at multiple network addresses, IPv6 simple security 724 functions cannot achieve full transparency for SCTP applications. In 725 multipath traversal scenarios, full transparency requires 726 coordination between all the packet filter processes in the various 727 paths between the endpoint network addresses. Such coordination is 728 not "simple" and it is, therefore, beyond the scope of this 729 recommendation. 731 However, some SCTP applications are capable of tolerating the 732 inherent unipath restriction of IPv6 simple security, even in 733 multipath traversal scenarios. They expect similar connection- 734 oriented filtering behaviors as for TCP, but at the level of SCTP 735 associations, not stream connections. This section describes 736 specific recommendations for SCTP filtering for such traversal 737 scenarios. 739 An interior endpoint initiates SCTP associations through a stateful 740 packet filter by sending a packet comprising a single INIT chunk. 741 The filter allocates (or reuses) a filter state record for the 742 association. The state record defines the interior and exterior IP 743 addresses and the observed verification tag used for forwarding 744 packets in that association. 746 Peer-to-peer applications use an alternate method of association 747 initiation termed simultaneous-open to traverse stateful filters. In 748 the simultaneous-open mode of operation, both peers send INIT chunks 749 at the same time to establish an association. Upon receiving the 750 other end's INIT chunk, each end responds with an INIT-ACK packet, 751 which is expected to traverse the same path in reverse. Because only 752 one SCTP association may exist between any two network addresses, one 753 of the peers in simultaneous-open mode of operation will send an 754 ERROR or ABORT chunk along with the INIT-ACK chunk. The association 755 is established at each endpoint once an INIT-ACK chunks is received 756 at one end without an ERROR or ABORT chunk. 758 To provide stateful packet filtering service for SCTP, it is 759 necessary for a filter to receive, process and forward all packets 760 for an association that conform to valid transitions of the SCTP 761 state machine (Fig. 3, [RFC4960]). 763 REC-37: All valid sequences of SCTP packets (defined in [RFC4960]) 764 MUST be forwarded for outbound associations and explicitly permitted 765 inbound associations. In particular, both the normal SCTP 766 association establishment and simultaneous-open modes of operation 767 MUST be supported. 769 If an inbound INIT packet is filtered, either because a corresponding 770 state record does not exist or because of the filter's normal 771 behavior, a filter has two basic choices: to discard the packet 772 silently, or to signal an error to the sender. Signaling an error 773 through ICMPv6 messages allows the sender to detect that the INIT 774 packet did not reach the intended destination. Discarding the 775 packet, on the other hand, allows applications to perform 776 simultaneous-open more reliably. Delays in signaling errors can 777 prevent the impairment of simultaneous-open mode of operation. 779 REC-38: By DEFAULT, a gateway MUST respond with an ICMPv6 780 "Destination Unreachable" error code 1 (administratively prohibited), 781 to any unsolicited inbound INIT packet after waiting at least 6 782 seconds without first forwarding the associated outbound INIT from 783 the interior peer. 785 An SCTP filter maintains state associated with in-progress and 786 established associations. Because of this, a filter is susceptible 787 to a resource-exhaustion attack whereby an attacker (or virus) on the 788 interior attempts to cause the filter to exhaust its capacity for 789 creating state records. To defend against such attacks, a filter 790 needs to abandon unused state records after a sufficiently long 791 period of idleness. 793 A common method used for TCP filters in IPv4/NAT gateways is to 794 abandon preferentially sessions for crashed endpoints, followed by 795 closed associations and partially opened associations. A similar 796 method is an option for SCTP filters in IPv6 gateways. A gateway can 797 check if an endpoint for an association has crashed by sending 798 HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the 799 gateway cannot determine whether the endpoint is active, then the 800 associated state records needs to be retained until the SCTP 801 association has been idle for some time. Note: an established SCTP 802 association can stay idle (but live) indefinitely, hence there is no 803 fixed value of an idle-timeout that accommodates all applications. 804 However, a large idle-timeout motivated by [RFC4294] can reduce the 805 chances of abandoning a live association. 807 SCTP associations can stay in the ESTABLISHED state indefinitely 808 without exchanging packets. Some end-hosts can be configured to send 809 HEARTBEAT chunks on such idle associations, but [RFC4960] does not 810 specify (or even suggest) a default time interval. A filter that 811 waits for slightly over two hours can detect idle associations with 812 HEARTBEAT packets being sent at the same rate as most hosts use for 813 TCP keep-alive, which is a reasonably similar system for this 814 purpose. SCTP associations in the partially-open or closing states, 815 on the other hand, can stay idle for at most four minutes while 816 waiting for in-flight packets to be delivered (assuming the suggested 817 SCTP protocol parameter values in Section 15 of [RFC4960]). 819 The "established association idle-timeout" for a stateful packet 820 filter is defined as the minimum time an SCTP association in the 821 established phase must remain idle before the filter considers the 822 corresponding state record a candidate for collection. The 823 "transitory association idle-timeout" for a filter is defined as the 824 minimum time an SCTP association in the partially-open or closing 825 phases must remain idle before the filter considers the corresponding 826 state record a candidate for collection. 828 REC-39: If a gateway cannot determine whether the endpoints of an 829 SCTP association are active, then it MAY abandon the state record if 830 it has been idle for some time. In such cases, the value of the 831 "established association idle-timeout" MUST NOT be less than two 832 hours four minutes. The value of the "transitory association idle- 833 timeout" MUST NOT be less than four minutes. The value of the idle- 834 timeouts MAY be configurable by the network administrator. 836 Behavior for handling ERROR and ABORT packets is left unspecified. A 837 gateway MAY hold state for an association after its closing phases 838 have completed to accommodate retransmissions of its final SHUTDOWN 839 ACK packets. However, holding state for a closed association can 840 limit the throughput of associations traversing a gateway with 841 limited resources. The discussion in [RFC1337] regarding the hazards 842 of TIME_WAIT assassination are relevant. 844 The handling of inbound non-INIT packets for which there is no active 845 state record is left unspecified. Such packets can be received if 846 the gateway abandons a live flow, or abandons an association in the 847 closing states before the transitory association idle-timeout 848 expires. The decision either to discard or to respond with an ICMPv6 849 "Destination Unreachable" error code 1 (administratively prohibited) 850 is left to the implementation. 852 Behavior for notifying endpoints when abandoning live associations is 853 left unspecified. When a gateway abandons a live association, for 854 example due to a timeout expiring, the filter MAY send an ABORT 855 packet to each endpoint on behalf of the other. Sending an ABORT 856 notification allows endpoint applications to recover more quickly, 857 however, notifying endpoints might not always be possible if, for 858 example, state records are lost due to power interruption. 860 Several SCTP mechanisms depend on the reception of ICMPv6 error 861 messages triggered by the transmission of SCTP packets. 863 REC-40: If a gateway forwards an SCTP association, it MUST also 864 forward ICMPv6 "Destination Unreachable" and "Packet Too Big" 865 messages containing SCTP headers that match the association state 866 record. 868 REC-41: Receipt of any sort of ICMPv6 message MUST NOT terminate the 869 state record for an SCTP association. 871 3.3.3. DCCP Filters 873 The connection semantics described in Datagram Congestion Control 874 Protocol (DCCP) [RFC4340] are very similar to those of TCP. An 875 interior endpoint initiates a DCCP flow through a stateful packet 876 filter by sending a DCCP-Request packet. Simultaneous open is not 877 defined for DCCP. 879 In order to provide stateful packet filtering service for DCCP, it is 880 necessary for a filter to receive, process and forward all packets 881 for a flow that conform to valid transitions of the DCCP state 882 machine (Section 8, [RFC4340]). 884 REC-42: All valid sequences of DCCP packets (defined in [RFC4340]) 885 MUST be forwarded for all flows to exterior servers and those flows 886 to interior servers with explicitly permitted service codes. 888 It is possible to reconstruct enough of the state of a DCCP flow to 889 allow forwarding between an interior and exterior node even when the 890 filter starts operating after DCCP enters the OPEN state. Also, a 891 filter can allow an existing state record to be reused by an 892 externally initiated flow if its security policy permits. As with 893 TCP, several different policies are possible, with a good discussion 894 of the issue involved presented in [RFC4787] and extended in 895 [RFC5382]. 897 If an inbound DCCP-Request packet is filtered, either because a 898 corresponding state record does not already exist for it or because 899 of the filter's normal behavior of refusing flows not explicitly 900 permitted, then a filter has two basic choices: to discard the packet 901 silently, or to signal an error to the sender. Signaling an error 902 through ICMPv6 messages allows the sender to detect that the DCCP- 903 Request did not reach the intended destination. Discarding the 904 packet, on the other hand, only delays the failure to connect and 905 provides no measurable security. 907 A DCCP filter maintains state associated with in-progress connections 908 and established flows. Because of this, a filter is susceptible to a 909 resource-exhaustion attack whereby an attacker (or virus) on the 910 interior attempts to cause the filter to exhaust its capacity for 911 creating state records. To prevent such an attack, a filter needs to 912 abandon unused state records after a sufficiently long period of 913 idleness. 915 A common method used for TCP filters in IPv4/NAT gateways is to 916 abandon preferentially sessions for crashed endpoints, followed by 917 closed TCP flows and partially-open flows. No such method exists for 918 DCCP, and flows can stay in the OPEN phase indefinitely without 919 exchanging packets. Hence, there is no fixed value for an idle- 920 timeout that accommodates all applications. However, a large idle- 921 timeout motivated by [RFC4294] can reduce the chances of abandoning a 922 live flow. 924 DCCP flows in the partially-open or closing phases can stay idle for 925 at most eight minutes while waiting for in-flight packets to be 926 delivered. 928 The "open flow idle-timeout" for a stateful packet filter is defined 929 as the minimum time a DCCP flow in the open state must remain idle 930 before the filter considers the associated state record a candidate 931 for collection. The "transitory flow idle-timeout" for a filter is 932 defined as the minimum time a DCCP flow in the partially-open or 933 closing phases must remain idle before the filter considers the 934 associated state record a candidate for collection. DCCP flows in 935 the TIMEWAIT state are not affected by the "transitory flow idle- 936 timeout" parameter. 938 REC-43: A gateway MAY abandon a DCCP state record if it has been idle 939 for some time. In such cases, the value of the "established flow 940 idle-timeout" MUST NOT be less than two hours four minutes. The 941 value of the "transitory flow idle-timeout" MUST NOT be less than 942 eight minutes. The value of the idle-timeouts MAY be configurable by 943 the network administrator. 945 Behavior for handing DCCP-Reset packets, or flows in the TIMEWAIT 946 state is left unspecified. A gateway MAY hold state for a flow in 947 TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset. 948 However, since the TIMEWAIT state is commonly encountered by interior 949 endpoints properly closing the DCCP flow, holding state for a closed 950 flow can limit the throughput of flows through a gateway with limited 951 resources. [RFC1337] discusses hazards associated with TIME_WAIT 952 assassination in TCP, and similar hazards exists for DCCP. 954 The handling of non-SYN packets for which there is no active state 955 record is left unspecified. Such packets can be received if the 956 gateway abandons a live flow, or abandons a flow in the TIMEWAIT 957 state before the four minute 2MSL period expires. The decision 958 either to discard or to respond with an ICMPv6 "Destination 959 Unreachable" error code 1 (administratively prohibited) is left up to 960 the implementation. 962 Behavior for notifying endpoints when abandoning live flows is left 963 unspecified. When a gateway abandons a live flow, for example due to 964 a timeout expiring, the filter MAY send a DCCP-Reset packet to each 965 endpoint on behalf of the other. Sending a DCCP-Reset notification 966 allows endpoint applications to recover more quickly, however, 967 notifying endpoints might not always be possible if, for example, 968 state records are lost due to power interruption. 970 Several DCCP mechanisms depend on the reception of ICMPv6 error 971 messages triggered by the transmission of DCCP packets. One such 972 mechanism is path MTU discovery, which is required for correct 973 operation. 975 REC-44: If an Internet gateway forwards a DCCP flow, it MUST also 976 forward ICMPv6 "Destination Unreachable" and "Packet Too Big" 977 messages containing DCCP headers that match the flow state record. 979 REC-45: Receipt of any sort of ICMPv6 message MUST NOT terminate the 980 state record for a DCCP flow. 982 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) 984 IPv6 simple security is applicable to residential networks with only 985 one Internet service provider at a time. The use of Level 3 986 Multihoming Shim Protocol for IPv6 (SHIM6) [RFC5533] as a site multi- 987 homing solution is not generally compatible with IPv6 simple 988 security. No special recommendations with regard to SHIM6 are made 989 in this document. 991 3.4. Passive Listeners 993 Some applications expect to solicit traffic from exterior nodes 994 without advance knowledge of the exterior addresses of their peers. 995 This requirement is met by IPv4/NAT gateways typically by the use of 996 either [I-D.cheshire-nat-pmp] or [UPnP-IGD]. On IPv4/NAT networks 997 connected by gateways without such services, applications must use 998 techniques like Session Traversal Utilities for NAT (STUN) [RFC5389] 999 to obtain and maintain connectivity, despite the translation and 1000 filtering effects of NAT. 1002 While NAT for IPv6 is unlikely to be used in most residential 1003 gateways, the filtering effect of the simple security functions 1004 recommended by this document are derived from those in widespread use 1005 on the IPv4 Internet, and a similar barrier to communication at 1006 passive listeners is a natural outcome of its deployment. To avoid 1007 the need for IPv6 applications to use techniques like STUN for 1008 opening and maintaining dynamic filter state, something similar to 1009 NAT-PMP and UPnP-IGD but without actually supporting NAT could be 1010 deployed. Alas, no consensus has yet emerged in the Internet 1011 engineering community as to what is most appropriate for residential 1012 IPv6 usage scenarios. 1014 One proposal that has been offered as an Internet Draft is the 1015 Application Listener Discovery Protocol [I-D.woodyatt-ald]. It 1016 remains to be seen whether the Internet Gateway Device profile of the 1017 Universal Plug And Play protocol will be extended for IPv6. Other 1018 proposals of note include the Middlebox Communication Protocol 1019 [RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until 1020 a consensus emerges around a specific method, the following 1021 recommendations are the best guidance available. 1023 REC-46: Internet gateways with IPv6 simple security capabilities 1024 SHOULD implement a protocol to permit applications to solicit inbound 1025 traffic without advance knowledge of the addresses of exterior nodes 1026 with which they expect to communicate. 1028 REC-47: Internet gateways with IPv6 simple security capabilities MUST 1029 provide an easily selected configuration option that permits a 1030 "transparent mode" of operation that forwards all unsolicited flows 1031 regardless of forwarding direction, i.e. not to use the IPv6 simple 1032 security capabilities of the gateway. The transparent mode of 1033 operation MAY be the default configuration. 1035 In general, "transparent mode" will enable more flexibility and 1036 reliability for applications which require devices to be contacted 1037 inside the home directly, particularly in absence of a protocol as 1038 described in REC-46. Operating in transparent mode may come at the 1039 expense of security if there are IPv6 nodes in the home that do not 1040 have their own host-based firewall capability and require a firewall 1041 in the gateway in order not to be compromised. 1043 3.5. Management Applications 1045 Subscriber managed residential gateways are unlikely ever to be 1046 completely zero-configuration, but their administrators will very 1047 often possess no particular expertise in Internet engineering. In 1048 general, the specification of management interfaces for residential 1049 gateways is out of scope for this document, but security of 1050 subscriber managed gateways merit special attention here. 1052 REC-48: By DEFAULT, subscriber managed residential gateways MUST NOT 1053 offer management application services to the exterior network. 1055 4. Summary of Recommendations 1057 This section collects all of the recommendations made in this 1058 document into a convenient list. 1060 REC-1 Packets bearing in their outer IPv6 headers multicast source 1061 addresses MUST NOT be forwarded or transmitted on any 1062 interface. 1064 REC-2 Packets which bear in their outer IPv6 headers multicast 1065 destination addresses of equal or narrower scope (see IPv6 1066 Scoped Address Architecture [RFC4007]) than the configured 1067 scope boundary level of the gateway MUST NOT be forwarded in 1068 any direction. The DEFAULT scope boundary level SHOULD be 1069 organization-local scope, and it SHOULD be configurable by 1070 the network administrator. 1072 REC-3 Packets bearing source and/or destination addresses forbidden 1073 to appear in the outer headers of packets transmitted over 1074 the public Internet MUST NOT be forwarded. In particular, 1075 site-local addresses are deprecated by [RFC3879], and 1076 [RFC5156] explicitly forbids the use of addresses with IPv4- 1077 Mapped, IPv4-Compatible, Documentation and ORCHID prefixes. 1079 REC-4 Packets bearing deprecated extension headers prior to their 1080 first upper-layer-protocol header SHOULD NOT be forwarded or 1081 transmitted on any interface. In particular, all packets 1082 with routing extension header type 0 [RFC2460] preceding the 1083 first upper-layer-protocol header MUST NOT be forwarded. 1084 (See [RFC5095] for additional background.) 1086 REC-5 Outbound packets MUST NOT be forwarded if the source address 1087 in their outer IPv6 header does not have a unicast prefix 1088 assigned for use by globally reachable nodes on the interior 1089 network. 1091 REC-6 Inbound packets MUST NOT be forwarded if the source address 1092 in their outer IPv6 header has a global unicast prefix 1093 assigned for use by globally reachable nodes on the interior 1094 network. 1096 REC-7 By DEFAULT, packets with unique local source and/or 1097 destination addresses [RFC4193] SHOULD NOT be forwarded to or 1098 from the exterior network. 1100 REC-8 By DEFAULT, inbound DNS queries received on exterior 1101 interfaces MUST NOT be processed by any integrated DNS 1102 resolving server. 1104 REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on 1105 exterior interfaces MUST NOT be processed by any integrated 1106 DHCPv6 server. 1108 REC-10 IPv6 gateways MUST forward ICMPv6 "Destination Unreachable" 1109 and "Packet Too Big" messages containing IP headers that 1110 match generic upper-layer transport state records. 1112 REC-11 If application transparency is most important, then a 1113 stateful packet filter SHOULD have "Endpoint independent 1114 filter" behavior for generic upper-layer transport protocols. 1115 If a more stringent filtering behavior is most important, 1116 then a filter SHOULD have "Address dependent filtering" 1117 behavior. The filtering behavior MAY be an option 1118 configurable by the network administrator, and it MAY be 1119 independent of the filtering behavior for other protocols. 1120 Filtering behavior SHOULD be endpoint independent by DEFAULT 1121 in gateways intended for provisioning without service- 1122 provider management. 1124 REC-12 Filter state records for generic upper-layer transport 1125 protocols MUST NOT be deleted or recycled until an idle timer 1126 not less than two minutes has expired without having 1127 forwarded a packet matching the state in some configurable 1128 amount of time. By DEFAULT, the idle timer for such state 1129 records is five minutes. 1131 REC-13 A state record for a UDP flow where both source and 1132 destination ports are outside the well-known port range 1133 (ports 0-1023) MUST NOT expire in less than two minutes of 1134 idle time. The value of the UDP state record idle timer MAY 1135 be configurable. The DEFAULT is five minutes. 1137 REC-14 A state record for a UDP flow where one or both of the source 1138 and destination ports are in the well-known port range (ports 1139 0-1023) MAY expire after a period of idle time shorter than 1140 two minutes to facilitate the operation of the IANA- 1141 registered service assigned to the port in question. 1143 REC-15 A state record for a UDP flow MUST be refreshed when a packet 1144 is forwarded from the interior to the exterior, and it MAY be 1145 refreshed when a packet is forwarded in the reverse 1146 direction. 1148 REC-16 If application transparency is most important, then a 1149 stateful packet filter SHOULD have "Endpoint independent 1150 filter" behavior for UDP. If a more stringent filtering 1151 behavior is most important, then a filter SHOULD have 1152 "Address dependent filtering" behavior. The filtering 1153 behavior MAY be an option configurable by the network 1154 administrator, and it MAY be independent of the filtering 1155 behavior for TCP and other protocols. Filtering behavior 1156 SHOULD be endpoint independent by DEFAULT in gateways 1157 intended for provisioning without service-provider 1158 management. 1160 REC-17 If a gateway forwards a UDP flow, it MUST also forward ICMPv6 1161 "Destination Unreachable" and "Packet Too Big" messages 1162 containing UDP headers that match the flow state record. 1164 REC-18 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1165 state record for a UDP flow. 1167 REC-19 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as 1168 UDP flows, except that the upper-layer transport protocol 1169 identifier for UDP-Lite is not the same as UDP, and therefore 1170 UDP packets MUST NOT match UDP-Lite state records, and vice 1171 versa. 1173 REC-20 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1174 prohibit the forwarding of packets, to and from legitimate 1175 node addresses, with destination extension headers of type 1176 "Authenticated Header (AH)" [RFC4302] in their outer IP 1177 extension header chain. 1179 REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1180 prohibit the forwarding of packets, to and from legitimate 1181 node addresses, with an upper layer protocol of type 1182 "Encapsulating Security Payload (ESP)" [RFC4303] in their 1183 outer IP extension header chain. 1185 REC-22 If a gateway forwards an ESP flow, it MUST also forward (in 1186 the reverse direction) ICMPv6 "Destination Unreachable" and 1187 "Packet Too Big" messages containing ESP headers that match 1188 the flow state record. 1190 REC-23 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1191 prohibit the forwarding of any UDP packets, to and from 1192 legitimate node addresses, with a destination port of 500, 1193 i.e. the port reserved by IANA for the Internet Key Exchange 1194 Protocol [RFC4306]. 1196 REC-24 In all operating modes, IPv6 gateways SHOULD use filter state 1197 records for Encapsulating Security Payload (ESP) [RFC4303] 1198 that are indexable by a 3-tuple comprising the interior node 1199 address, the exterior node address and the ESP protocol 1200 identifier. In particular, the IPv4/NAT method of indexing 1201 state records also by security parameters index (SPI) SHOULD 1202 NOT be used. Likewise, any mechanism that depends on 1203 detection of Internet Key Exchange (IKE) [RFC4306] 1204 initiations SHOULD NOT be used. 1206 REC-25 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1207 prohibit the forwarding of packets, to and from legitimate 1208 node addresses, with destination extension headers of type 1209 "Host Identity Protocol (HIP)" [RFC5201] in their outer IP 1210 extension header chain. 1212 REC-26 The state records for flows initiated by outbound packets 1213 that bear a Home Address destination option [RFC3775] are 1214 distinguished by the addition of the home address of the flow 1215 as well as the interior care-of address. IPv6 gateways MUST 1216 NOT prohibit the forwarding of any inbound packets bearing 1217 type 2 routing headers, which otherwise match a flow state 1218 record, and where A) the address in the destination field of 1219 the IPv6 header matches the interior care-of address of the 1220 flow, and B) the Home Address field in the Type 2 Routing 1221 Header matches the home address of the flow. 1223 REC-27 Valid sequences of Mobility Header [RFC3775] packets MUST be 1224 forwarded for all outbound and explicitly permitted inbound 1225 Mobility Header flows. 1227 REC-28 If a gateway forwards a Mobility Header [RFC3775] flow, then 1228 it MUST also forward, in both directions, the IPv4 and IPv6 1229 packets that are encapsulated in IPv6 associated with the 1230 tunnel between the home agent and the correspondent node. 1232 REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then 1233 it MUST also forward (in the reverse direction) ICMPv6 1234 "Destination Unreachable" and "Packet Too Big" messages 1235 containing any headers that match the associated flow state 1236 records. 1238 REC-30 All valid sequences of TCP packets (defined in [RFC0793]) 1239 MUST be forwarded for outbound flows and explicitly permitted 1240 inbound flows. In particular, both the normal TCP 3-way 1241 handshake mode of operation and the simultaneous-open modes 1242 of operation MUST be supported. 1244 REC-31 The TCP window invariant MUST NOT be enforced on flows for 1245 which the filter did not detect whether the window-scale 1246 option (see [RFC1323]) was sent in the 3-way handshake or 1247 simultaneous open. 1249 REC-32 If application transparency is most important, then a 1250 stateful packet filter SHOULD have "Endpoint independent 1251 filter" behavior for TCP. If a more stringent filtering 1252 behavior is most important, then a filter SHOULD have 1253 "Address dependent filtering" behavior. The filtering 1254 behavior MAY be an option configurable by the network 1255 administrator, and it MAY be independent of the filtering 1256 behavior for UDP and other protocols. Filtering behavior 1257 SHOULD be endpoint independent by DEFAULT in gateways 1258 intended for provisioning without service-provider 1259 management. 1261 REC-33 By DEFAULT, a gateway MUST respond with an ICMPv6 1262 "Destination Unreachable" error code 1 (administratively 1263 prohibited) to any unsolicited inbound SYN packet after 1264 waiting at least 6 seconds without first forwarding the 1265 associated outbound SYN or SYN/ACK from the interior peer. 1267 REC-34 If a gateway cannot determine whether the endpoints of a TCP 1268 flow are active, then it MAY abandon the state record if it 1269 has been idle for some time. In such cases, the value of the 1270 "established flow idle-timeout" MUST NOT be less than two 1271 hours four minutes, as discussed in [RFC5382]. The value of 1272 the "transitory flow idle-timeout" MUST NOT be less than four 1273 minutes. The value of the idle-timeouts MAY be configurable 1274 by the network administrator. 1276 REC-35 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 1277 "Destination Unreachable" and "Packet Too Big" messages 1278 containing TCP headers that match the flow state record. 1280 REC-36 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1281 state record for a TCP flow. 1283 REC-37 All valid sequences of SCTP packets (defined in [RFC4960]) 1284 MUST be forwarded for outbound associations and explicitly 1285 permitted inbound associations. In particular, both the 1286 normal SCTP association establishment and simultaneous-open 1287 modes of operation MUST be supported. 1289 REC-38 By DEFAULT, a gateway MUST respond with an ICMPv6 1290 "Destination Unreachable" error code 1 (administratively 1291 prohibited) to any unsolicited inbound INIT packet after 1292 waiting at least 6 seconds without first forwarding the 1293 associated outbound INIT from the interior peer. 1295 REC-39 If a gateway cannot determine whether the endpoints of an 1296 SCTP association are active, then it MAY abandon the state 1297 record if it has been idle for some time. In such cases, the 1298 value of the "established association idle-timeout" MUST NOT 1299 be less than two hours four minutes. The value of the 1300 "transitory association idle-timeout" MUST NOT be less than 1301 four minutes. The value of the idle-timeouts MAY be 1302 configurable by the network administrator. 1304 REC-40 If a gateway forwards an SCTP association, it MUST also 1305 forward ICMPv6 "Destination Unreachable" and "Packet Too Big" 1306 messages containing SCTP headers that match the association 1307 state record. 1309 REC-41 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1310 state record for an SCTP association. 1312 REC-42 All valid sequences of DCCP packets (defined in [RFC4340]) 1313 MUST be forwarded for all flows to exterior servers and those 1314 flows to interior servers with explicitly permitted service 1315 codes. 1317 REC-43 A gateway MAY abandon a DCCP state record if it has been idle 1318 for some time. In such cases, the value of the "established 1319 flow idle-timeout" MUST NOT be less than two hours four 1320 minutes. The value of the "transitory flow idle-timeout" 1321 MUST NOT be less than eight minutes. The value of the idle- 1322 timeouts MAY be configurable by the network administrator. 1324 REC-44 If a gateway forwards a DCCP flow, it MUST also forward 1325 ICMPv6 "Destination Unreachable" and "Packet Too Big" 1326 messages containing DCCP headers that match the flow state 1327 record. 1329 REC-45 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1330 state record for a DCCP flow. 1332 REC-46 Gateways SHOULD implement a protocol to permit applications 1333 to solicit inbound traffic without advance knowledge of the 1334 addresses of exterior nodes with which they expect to 1335 communicate. 1337 REC-47 Gateways MUST provide an easily selected configuration option 1338 that permits a "transparent mode" of operation that forwards 1339 all unsolicited flows regardless of forwarding direction, 1340 i.e. to disable the IPv6 simple security capabilities of the 1341 gateway. The transparent mode of operation MAY be the 1342 default configuration. 1344 REC-48 By DEFAULT, subscriber managed residential gateways MUST NOT 1345 offer management application services to the exterior 1346 network. 1348 5. Contributors 1350 Comments and criticisms during the development of this document were 1351 received from the following IETF participants: 1353 +-------------------+----------------------------+ 1354 | Fred Baker | Norbert Bollow | 1355 | Cameron Byrne | Brian Carpenter | 1356 | Remi Despres | Arnaud Ebalard | 1357 | Fabrice Fontaine | Jun-ichiro "itojun" Hagino | 1358 | Thomas Herbst | Christian Huitema | 1359 | Joel Jaeggli | Cullen Jennings | 1360 | Suresh Krishnan | Erik Kline | 1361 | Julien Laganier | Kurt Erik Lindqvist | 1362 | Boucadair Mohamed | Keith Moore | 1363 | Robert Moskowitz | Teemu Savolainen | 1364 | Hemant Singh | Yaron Sheffer | 1365 | Mark Townsley | Iljitsch van Beijnum | 1366 | Magnus Westerlund | Dan Wing | 1367 +-------------------+----------------------------+ 1369 The editor thanks them all for their contributions. 1371 It must be noted that a substantial portion of the text describing 1372 the detailed requirements for TCP and UDP filtering is derived or 1373 transposed from [RFC4787] and [RFC5382]. The editors of those 1374 documents, Francois Audet and Saikat Guha, also deserve substantial 1375 credit for the form of the present document. 1377 6. IANA Considerations 1379 This memo includes no request to IANA. 1381 7. Security Considerations 1383 The IPv6 stateful filtering behavior described in this document is 1384 intended to be similar in function to the filtering behavior of 1385 commonly use IPv4/NAT gateways, which have been widely sold as a 1386 security tool for residential and small-office/home-office networks. 1387 As noted in the security considerations section of [RFC2993], the 1388 true impact of these tools may be a reduction in security. It may be 1389 generally assumed that the impacts discussed in that document related 1390 to filtering (and not translation) are to be expected with the simple 1391 IPv6 security mechanisms described here. 1393 In particular, it is worth noting that stateful filters create the 1394 illusion of a security barrier, but without the managed intent of a 1395 firewall. Appropriate security mechanisms implemented in the end 1396 nodes, in conjunction with the [RFC4864] local network protection 1397 methods, function without reliance on network layer hacks and 1398 transport filters that may change over time. Also, defined security 1399 barriers assume that threats originate in the exterior, which may 1400 lead to practices that result in applications being fully exposed to 1401 interior attack and which therefore make breaches much easier. 1403 The security functions described in this document may be considered 1404 redundant in the event that all IPv6 hosts using a particular gateway 1405 have their own IPv6 host firewall capabilities enabled. At the time 1406 of this writing, the vast majority of commercially available 1407 operating systems with support for IPv6 include IPv6 host firewall 1408 capability. 1410 Also worth noting explicitly, a practical side-effect of the 1411 recommendations in Section 3.2.4, to allow inbound IPsec and IKE 1412 flows from exterior to interior, is to facilitate more transparent 1413 communication by the use of Better-Than-Nothing-Security: An 1414 Unauthenticated Mode of IPsec [RFC5386], and this may be a departure 1415 from expectations of transparency set by traditional IPv4/NAT 1416 residential gateways. 1418 Finally, residential gateways that implement simple security 1419 functions are a bastion between the interior and the exterior, and 1420 therefore are a target of denial of service attacks against the 1421 interior network itself by processes designed to consume the 1422 resources of the gateway, e.g. a ping or SYN flood. Gateways should 1423 employ the same sorts of protection techniques as application servers 1424 on the Internet. 1426 IETF makes no statement, expressed or implied, as to whether using 1427 the capabilities described in this document ultimately improve 1428 security for any individual users or for the Internet community as a 1429 whole. 1431 8. References 1433 8.1. Normative References 1435 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1436 August 1980. 1438 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1439 RFC 793, September 1981. 1441 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1442 for High Performance", RFC 1323, May 1992. 1444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1445 Requirement Levels", BCP 14, RFC 2119, March 1997. 1447 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1448 (IPv6) Specification", RFC 2460, December 1998. 1450 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1451 and M. Carney, "Dynamic Host Configuration Protocol for 1452 IPv6 (DHCPv6)", RFC 3315, July 2003. 1454 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1455 in IPv6", RFC 3775, June 2004. 1457 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1458 G. Fairhurst, "The Lightweight User Datagram Protocol 1459 (UDP-Lite)", RFC 3828, July 2004. 1461 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1462 Addresses", RFC 3879, September 2004. 1464 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1465 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1466 March 2005. 1468 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1469 Addresses", RFC 4193, October 2005. 1471 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1472 December 2005. 1474 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1475 RFC 4303, December 2005. 1477 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1478 RFC 4306, December 2005. 1480 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1481 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1483 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1484 Message Protocol (ICMPv6) for the Internet Protocol 1485 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1487 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1488 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1489 RFC 4787, January 2007. 1491 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1492 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1494 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1495 RFC 4960, September 2007. 1497 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1498 of Type 0 Routing Headers in IPv6", RFC 5095, 1499 December 2007. 1501 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 1502 April 2008. 1504 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1505 "Host Identity Protocol", RFC 5201, April 2008. 1507 8.2. Informative References 1509 [I-D.cheshire-nat-pmp] 1510 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1511 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1513 [I-D.woodyatt-ald] 1514 Woodyatt, J., "Application Listener Discovery (ALD) for 1515 IPv6", draft-woodyatt-ald-03 (work in progress), 1516 July 2008. 1518 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1519 Communication Layers", STD 3, RFC 1122, October 1989. 1521 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 1522 RFC 1337, May 1992. 1524 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1525 E. Lear, "Address Allocation for Private Internets", 1526 BCP 5, RFC 1918, February 1996. 1528 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1529 IPv6 Specification", RFC 2473, December 1998. 1531 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1532 Defeating Denial of Service Attacks which employ IP Source 1533 Address Spoofing", BCP 38, RFC 2827, May 2000. 1535 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1536 November 2000. 1538 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1539 Networks", BCP 84, RFC 3704, March 2004. 1541 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1542 Bosch, "Next Steps in Signaling (NSIS): Framework", 1543 RFC 4080, June 2005. 1545 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 1546 April 2006. 1548 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1549 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1550 May 2007. 1552 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1553 RFC 4949, August 2007. 1555 [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 1556 Communication (MIDCOM) Protocol Semantics", RFC 5189, 1557 March 2008. 1559 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1560 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1561 RFC 5382, October 2008. 1563 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 1564 Security: An Unauthenticated Mode of IPsec", RFC 5386, 1565 November 2008. 1567 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1568 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1569 October 2008. 1571 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1572 Shim Protocol for IPv6", RFC 5533, June 2009. 1574 [UPnP-IGD] 1575 UPnP Forum, "Universal Plug and Play Internet Gateway 1576 Device Standardized Gateway Device Protocol", 1577 September 2010, . 1579 Author's Address 1581 james woodyatt (editor) 1582 Apple Inc. 1583 1 Infinite Loop 1584 Cupertino, CA 95014 1585 US 1587 Email: jhw@apple.com