--- 1/draft-ietf-tsvwg-behave-requirements-update-03.txt 2015-08-14 06:15:01.343429680 -0700 +++ 2/draft-ietf-tsvwg-behave-requirements-update-04.txt 2015-08-14 06:15:01.371430364 -0700 @@ -1,25 +1,25 @@ TSVWG R. Penno Internet-Draft Cisco Intended status: Best Current Practice S. Perreault -Expires: February 13, 2016 Jive Communications +Expires: February 15, 2016 Jive Communications M. Boucadair France Telecom S. Sivakumar Cisco K. Naito NTT - August 12, 2015 + August 14, 2015 Network Address Translation (NAT) Behavioral Requirements Updates - draft-ietf-tsvwg-behave-requirements-update-03 + draft-ietf-tsvwg-behave-requirements-update-04 Abstract This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAT44. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 13, 2016. + This Internet-Draft will expire on February 15, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -66,26 +66,26 @@ 6. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 7 6.1. Outbound Mapping Refresh and Error Packets . . . . . . . 7 7. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 7 8. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8 10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 8 11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 8 12. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 14. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 15.2. Informative References . . . . . . . . . . . . . . . . . 10 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 15.2. Informative References . . . . . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction [RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT interoperability and conformance. But with widespread deployment and evolution of Network Address Translation (NAT) more development and operational experience was acquired some areas of the original documents need further clarification or updates. This document provides such clarifications and updates. @@ -359,25 +359,20 @@ in this document could be easily adapted such that the parity is preserved (i.e., force the lowest order bit of the resulting port number to 0 or 1 according to whether even or odd parity is desired)." 10. IP Identification (IP ID) Update: A NAT SHOULD handle the Identification field of translated IPv4 packets as specified in Section 5.3.1 of [RFC6864]. - Discussion: This recommendation may have undesired effects on the - performance of the NAT in environments in which fragmentation is - massively experienced. Such issue can be used as an attack vector - against NATs. - 11. ICMP Query Mappings Timeout Section 3.1 of [RFC5508] precises that ICMP Query Mappings are to be maintained by a NAT. However, the specification doesn't discuss Query Mapping timeout values. Section 3.2 of [RFC5508] only discusses ICMP Query Session Timeouts. Update: ICMP Query Mappings MAY be deleted once the last the session using the mapping is deleted. @@ -399,28 +394,64 @@ mappings from external IP address to internal IP address in addition to the ICMP Query Mappings described in Section 3.1 of [RFC5508]. 13. IANA Considerations This document does not require any IANA action. 14. Security Considerations - NAT behavioral considerations are discussed in [RFC4787]. + NAT behavioral considerations are discussed in [RFC4787], [RFC5382], + and [RFC5508]. - Security considerations discussed in Section 5 of [RFC6146] apply - also fro NAT44. + Because some of the clarifications and updates (e.g., Section 2) are + inspired from NAT64, the security considerations discussed in + Section 5 of [RFC6146] apply also for this specification. - In the case of EIF mappings due to high risk of resource crunch, a - NAT MAY provide a configurable parameter to limit the number of - inbound sessions spawned from a EIF mapping. + The update in Section 3 allows for an optimized NAT resource usage. + In order to avoid service disruption, the NAT MUST invoke this + functionality only if packets are to be sen to distinct destination + addresses. + + Some of the updates (e.g., Section 6, Section 9, and Section 11) + allow for an increased security compared to [RFC4787], [RFC5382], and + [RFC5508]. Particularly: + + o The updates in Section 6 and Section 11 prevent an illegitimate + node to maintain mappings activated in the NAT while these + mappings should be cleared. + + o Port randomization (Section 9) complicates tracking hosts located + behind a NAT. + + Section 4 and Section 12 propose updates that increase the + serviceability of a host located behind a NAT. These updates do not + introduce any additional security concerns to [RFC4787], [RFC5382], + and [RFC5508]. + + The updates in Section 5 and Section 7 allow for a better NAT + transparency from an application standpoint. Hosts which require a + restricted filtering behavior should enable security-dedicated + features (e.g., ACL) either locally or by soliciting a dedicated + security device (e.g., firewall). + + The update in Section 8 induces security concerns that are specific + to the protocol used to interact with the NAT. For example, if PCP + is used to explicitly request parity preservation for a given + mapping, the security considerations discussed in [RFC6887] should be + taken into account. + + The update in Section 10 may have undesired effects on the + performance of the NAT in environments in which fragmentation is + massively experienced. Such issue may be used as an attack vector + against NATs. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .