draft-ietf-tsvwg-natsupp-17.txt   draft-ietf-tsvwg-natsupp-18.txt 
Network Working Group R. R. Stewart Network Working Group R. R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Standards Track M. Tüxen Intended status: Standards Track M. Tüxen
Expires: 14 January 2021 I. Rüngeler Expires: 29 January 2021 I. Rüngeler
Münster Univ. of Appl. Sciences Münster Univ. of Appl. Sciences
13 July 2020 28 July 2020
Stream Control Transmission Protocol (SCTP) Network Address Translation Stream Control Transmission Protocol (SCTP) Network Address Translation
Support Support
draft-ietf-tsvwg-natsupp-17 draft-ietf-tsvwg-natsupp-18
Abstract Abstract
The Stream Control Transmission Protocol (SCTP) provides a reliable The Stream Control Transmission Protocol (SCTP) provides a reliable
communications channel between two end-hosts in many ways similar to communications channel between two end-hosts in many ways similar to
the Transmission Control Protocol (TCP). With the widespread the Transmission Control Protocol (TCP). With the widespread
deployment of Network Address Translators (NAT), specialized code has deployment of Network Address Translators (NAT), specialized code has
been added to NAT functions for TCP that allows multiple hosts to been added to NAT functions for TCP that allows multiple hosts to
reside behind a NAT function and yet share a single IPv4 address, reside behind a NAT function and yet share a single IPv4 address,
even when two hosts (behind a NAT function) choose the same port even when two hosts (behind a NAT function) choose the same port
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 14 January 2021. This Internet-Draft will expire on 29 January 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 28 skipping to change at page 3, line 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 42 10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 42
10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 44 10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 44
10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 45 10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 45
10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 45 10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 45
10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 45 10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 45
11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45
12. Normative References . . . . . . . . . . . . . . . . . . . . 46 12. Normative References . . . . . . . . . . . . . . . . . . . . 46
13. Informative References . . . . . . . . . . . . . . . . . . . 48 13. Informative References . . . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
Stream Control Transmission Protocol (SCTP) [RFC4960] provides a Stream Control Transmission Protocol (SCTP) [RFC4960] provides a
reliable communications channel between two end-hosts in many ways reliable communications channel between two end-hosts in many ways
similar to TCP [RFC0793]. With the widespread deployment of Network similar to TCP [RFC0793]. With the widespread deployment of Network
Address Translators (NAT), specialized code has been added to NAT Address Translators (NAT), specialized code has been added to NAT
functions for TCP that allows multiple hosts to reside behind a NAT functions for TCP that allows multiple hosts to reside behind a NAT
functions using internal addresses (see [RFC6890]) and yet share functions using internal addresses (see [RFC6890]) and yet share
single IPv4 address, even when two hosts (behind a NAT function) single IPv4 address, even when two hosts (behind a NAT function)
skipping to change at page 20, line 51 skipping to change at page 20, line 51
internal port to an remote port for which the NAT function has no internal port to an remote port for which the NAT function has no
matching NAT binding table entry, it MUST allow the packet matching NAT binding table entry, it MUST allow the packet
containing the INIT chunk creating an NAT binding table entry. containing the INIT chunk creating an NAT binding table entry.
* If the packet containing the INIT chunk matches an existing NAT * If the packet containing the INIT chunk matches an existing NAT
binding table entry, it MUST validate that the disable restart binding table entry, it MUST validate that the disable restart
feature is supported and, if it does, allow the packet containing feature is supported and, if it does, allow the packet containing
the INIT chunk to be forwarded. the INIT chunk to be forwarded.
* If the disable restart feature is not supported, the NAT function * If the disable restart feature is not supported, the NAT function
MUST send a packet containing an ABORT chunk with the M bit set. SHOULD send a packet containing an ABORT chunk with the M bit set.
The 'Port Number Collision' error cause (see Section 5.2.3) MUST be The 'Port Number Collision' error cause (see Section 5.2.3) MUST be
included in the ABORT chunk sent in response to the packet containing included in the ABORT chunk sent in response to the packet containing
an INIT chunk. an INIT chunk.
If the collision is triggered by a packet containing an ASCONF chunk, If the collision is triggered by a packet containing an ASCONF chunk,
a packet containing an ERROR chunk with the 'Port Number Collision' a packet containing an ERROR chunk with the 'Port Number Collision'
error cause MUST be sent in response to the packet containing the error cause MUST be sent in response to the packet containing the
ASCONF chunk. ASCONF chunk.
skipping to change at page 23, line 46 skipping to change at page 23, line 46
6.5. Handling of Fragmented SCTP Packets by NAT Functions 6.5. Handling of Fragmented SCTP Packets by NAT Functions
SCTP minimizes the use of IP-level fragmentation. However, it can SCTP minimizes the use of IP-level fragmentation. However, it can
happen that using IP-level fragmentation is needed to continue an happen that using IP-level fragmentation is needed to continue an
SCTP association. For example, if the path MTU is reduced and there SCTP association. For example, if the path MTU is reduced and there
are still some DATA chunk in flight, which require packets larger are still some DATA chunk in flight, which require packets larger
than the new path MTU. If IP-level fragmentation can not be used, than the new path MTU. If IP-level fragmentation can not be used,
the SCTP association will be terminated in a non-graceful way. the SCTP association will be terminated in a non-graceful way.
Therefore, a NAT function MUST support IP reassembly of received Therefore, a NAT function MUST be able to handle IP-level fragmented
fragmented SCTP packets. The fragments may arrive in any order. SCTP packets. The fragments may arrive in any order.
When an SCTP packet has to be fragmented by the NAT function and the When an SCTP packet has to be fragmented by the NAT function and the
IP header forbids fragmentation a corresponding ICMP packet SHOULD be IP header forbids fragmentation, the NAT MUST send back a
sent. This allows for a faster recovery from this packet drop. corresponding ICMP message to the internal host. This allows for a
faster recovery from this packet drop.
6.6. Multi Point Traversal Considerations for Endpoints 6.6. Multi Point Traversal Considerations for Endpoints
If a multi-homed SCTP endpoint behind a NAT function connects to a If a multi-homed SCTP endpoint behind a NAT function connects to a
peer, it MUST first set up the association single-homed with only one peer, it MUST first set up the association single-homed with only one
address causing the first NAT function to populate its state. Then address causing the first NAT function to populate its state. Then
it SHOULD add each IP address using packets containing ASCONF chunks it SHOULD add each IP address using packets containing ASCONF chunks
sent via their respective NAT functions. The address to add is the sent via their respective NAT functions. The address to add is the
wildcard address and the lookup address SHOULD also contain the VTags wildcard address and the lookup address SHOULD also contain the VTags
parameter and optionally the Disable Restart parameter. parameter and optionally the Disable Restart parameter.
skipping to change at page 46, line 20 skipping to change at page 46, line 20
in [RFC4960], [RFC4895], and [RFC5061]. in [RFC4960], [RFC4895], and [RFC5061].
SCTP endpoints disabling the restart procedure, should monitor the SCTP endpoints disabling the restart procedure, should monitor the
status of all associations to mitigate resource exhaustion attacks by status of all associations to mitigate resource exhaustion attacks by
establishing a lot of associations sharing the same IP addresses and establishing a lot of associations sharing the same IP addresses and
port numbers. port numbers.
In any case, SCTP is protected by the verification tags and the usage In any case, SCTP is protected by the verification tags and the usage
of [RFC4895] against off-path attackers. of [RFC4895] against off-path attackers.
For IP-level fragmentation and reassembly related issues see
[RFC4963].
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446]. [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
skipping to change at page 48, line 38 skipping to change at page 48, line 42
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>. <https://www.rfc-editor.org/info/rfc3022>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
 End of changes. 10 change blocks. 
10 lines changed or deleted 19 lines changed or added

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