draft-ietf-tsvwg-behave-requirements-update-03.txt   draft-ietf-tsvwg-behave-requirements-update-04.txt 
TSVWG R. Penno TSVWG R. Penno
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Best Current Practice S. Perreault Intended status: Best Current Practice S. Perreault
Expires: February 13, 2016 Jive Communications Expires: February 15, 2016 Jive Communications
M. Boucadair M. Boucadair
France Telecom France Telecom
S. Sivakumar S. Sivakumar
Cisco Cisco
K. Naito K. Naito
NTT NTT
August 12, 2015 August 14, 2015
Network Address Translation (NAT) Behavioral Requirements Updates Network Address Translation (NAT) Behavioral Requirements Updates
draft-ietf-tsvwg-behave-requirements-update-03 draft-ietf-tsvwg-behave-requirements-update-04
Abstract Abstract
This document clarifies and updates several requirements of RFC4787, This document clarifies and updates several requirements of RFC4787,
RFC5382 and RFC5508 based on operational and development experience. RFC5382 and RFC5508 based on operational and development experience.
The focus of this document is NAT44. The focus of this document is NAT44.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 13, 2016. This Internet-Draft will expire on February 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
6. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 7 6. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 7
6.1. Outbound Mapping Refresh and Error Packets . . . . . . . 7 6.1. Outbound Mapping Refresh and Error Packets . . . . . . . 7
7. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 7 7. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 7
8. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8 9. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8
10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 8 10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 8
11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 8 11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 8
12. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 9 12. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
14. Security Considerations . . . . . . . . . . . . . . . . . . . 9 14. Security Considerations . . . . . . . . . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
15.1. Normative References . . . . . . . . . . . . . . . . . . 9 15.1. Normative References . . . . . . . . . . . . . . . . . . 10
15.2. Informative References . . . . . . . . . . . . . . . . . 10 15.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
[RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT [RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT
interoperability and conformance. But with widespread deployment and interoperability and conformance. But with widespread deployment and
evolution of Network Address Translation (NAT) more development and evolution of Network Address Translation (NAT) more development and
operational experience was acquired some areas of the original operational experience was acquired some areas of the original
documents need further clarification or updates. This document documents need further clarification or updates. This document
provides such clarifications and updates. provides such clarifications and updates.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
in this document could be easily adapted such that the parity in this document could be easily adapted such that the parity
is preserved (i.e., force the lowest order bit of the resulting 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 port number to 0 or 1 according to whether even or odd parity
is desired)." is desired)."
10. IP Identification (IP ID) 10. IP Identification (IP ID)
Update: A NAT SHOULD handle the Identification field of translated Update: A NAT SHOULD handle the Identification field of translated
IPv4 packets as specified in Section 5.3.1 of [RFC6864]. 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 11. ICMP Query Mappings Timeout
Section 3.1 of [RFC5508] precises that ICMP Query Mappings are to be Section 3.1 of [RFC5508] precises that ICMP Query Mappings are to be
maintained by a NAT. However, the specification doesn't discuss maintained by a NAT. However, the specification doesn't discuss
Query Mapping timeout values. Section 3.2 of [RFC5508] only Query Mapping timeout values. Section 3.2 of [RFC5508] only
discusses ICMP Query Session Timeouts. discusses ICMP Query Session Timeouts.
Update: ICMP Query Mappings MAY be deleted once the last the session Update: ICMP Query Mappings MAY be deleted once the last the session
using the mapping is deleted. using the mapping is deleted.
skipping to change at page 9, line 33 skipping to change at page 9, line 30
mappings from external IP address to internal IP address in mappings from external IP address to internal IP address in
addition to the ICMP Query Mappings described in Section 3.1 of addition to the ICMP Query Mappings described in Section 3.1 of
[RFC5508]. [RFC5508].
13. IANA Considerations 13. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
14. Security Considerations 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 Because some of the clarifications and updates (e.g., Section 2) are
also fro NAT44. 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 The update in Section 3 allows for an optimized NAT resource usage.
NAT MAY provide a configurable parameter to limit the number of In order to avoid service disruption, the NAT MUST invoke this
inbound sessions spawned from a EIF mapping. 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. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 9 change blocks. 
21 lines changed or deleted 52 lines changed or added

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