Merge pull request #25 from ekinnear/ek/editorial_updates

Editorial pass, update authors

draft-seemann-quic-nat-traversal.md

@@ -21,6 +21,14 @@ author:
     organization: Protocol Labs
     email: martenseemann@gmail.com
 
+ -
+    fullname: Eric Kinnear
+    organization: Apple Inc.
+    street: One Apple Park Way
+    city: Cupertino, California 95014
+    country: United States of America
+    email: ekinnear@apple.com
+
 normative:
    MULTIPATH: I-D.ietf-quic-multipath
    CONNECT-UDP-LISTEN: I-D.ietf-masque-connect-udp-listen
@@ -32,10 +40,10 @@ informative:
 
 QUIC is well-suited to various NAT traversal techniques. As it operates over
 UDP, and because the QUIC header was designed to be demultipexed from other
-protocols, STUN can be used on the same UDP socket. This allows for using ICE
-with QUIC. Furthermore, QUIC’s path validation mechanism can be used to test the
-viability of an address candidate pair while at the same time creating the NAT
-bindings required for a direction connection, after which QUIC connection
+protocols, STUN can be used on the same UDP socket, enabling ICE to be used
+with QUIC. Furthermore, QUIC’s path validation mechanism can be used to test
+the viability of an address candidate pair while at the same time creating the
+NAT bindings required for a direction connection, after which QUIC connection
 migration can be used to migrate the connection to a direct path.
 
 --- middle
@@ -47,26 +55,26 @@ This document describes two ways to use QUIC ({{!RFC9000}}) to traverse NATs:
 1. Using ICE ({{!RFC8445}}) with an external signaling channel to select a pair
    of UDP addresses. Once candidate nomination is completed, a new QUIC
    connection between the two endpoints can be established.
-2. Using a (proxied) QUIC connection as the signaling channel.  QUIC's path
+2. Using a (proxied) QUIC connection as the signaling channel. QUIC's path
    validation logic is used to test connectivity of possible paths.
 
-The first option merely documents how NAT traversal can be achieved using
-unmodified QUIC and ICE stacks. The only requirement is the ability to send and
-receive non-QUIC (STUN ({{!RFC5389}})) packets on the UDP socket that a QUIC
-server is listening on. However, it necessitates running a separate signaling
-channel for the communication between the two ICE agents.
+The first option documents how NAT traversal can be achieved using unmodified
+QUIC and ICE stacks. The only requirement is the ability to send and receive
+non-QUIC (STUN ({{!RFC5389}})) packets on the UDP socket that a QUIC server is
+listening on. However, it necessitates running a separate signaling channel for
+the communication between the two ICE agents.
 
 The second option doesn't use ICE at all, although it makes use of some of the
 concepts, in particular the address matching logic described in {{!RFC8445}}. It
 is assumed that the nodes are connected via a proxied QUIC connection, for
 example using {{CONNECT-UDP-LISTEN}}. Using the QUIC extension defined in this
-documents, the nodes coordinate QUIC path validation attempts that create the
+document, the nodes coordinate QUIC path validation attempts that create the
 necessary NAT bindings to achieve traversal of the NAT. This mechanism makes
 extensive use of the path validation mechanism described in {{!RFC9000}}. In
 addition, the QUIC server needs the capability to initiate path validation,
 which, as per {{!RFC9000}}, is initiated by the client. Starting with a proxied
 QUIC connection allows the nodes to start exchanging application data right
-away, and switch to the direct connection once it has been established and
+away and switch to the direct connection once it has been established and
 deemed suitable for the application's needs.
 
 # Conventions and Definitions
@@ -80,15 +88,15 @@ after the two ICE agents have agreed on a candidate pair. This mode doesn't
 require any modification to existing QUIC stacks. In particular, it does not
 necessitate the negotiation of the extension defined in this document.
 
-For address discovery to work, QUIC and ICE need to use the same UDP socket
+For address discovery to work, QUIC and ICE need to use the same UDP socket.
 Since this requires demultiplexing of QUIC and STUN packets, the QUIC bit cannot
 be greased as described in {{!RFC9287}}.
 
 Once ICE has completed, the client immediately initiates a normal QUIC handshake
-using the server's address from the nominated address pair. The ICE connectivity
-checks should have created the necessary NAT bindings for the client's first
-flight to reach the server, and for the server's first flight to reach the
-client.
+using the server's address from the nominated address pair. The ICE
+connectivity checks should have created the necessary NAT bindings for the
+client's first flight to reach the server and for the server's first flight to
+reach the client.
 
 # NAT Traversal using the NAT Traversal QUIC Extension
 
@@ -100,7 +108,7 @@ might be established in parallel. When using QUIC Multipath {{MULTIPATH}}, these
 paths may be used at the some time, however, the mechanism described in this
 document does not require the use of QUIC multipath.
 
-ICE is not directly used, however, the logic run on the client makes use of
+Although ICE is not directly used, the logic run on the client makes use of
 ICE's candidate pairing logic (see especially {{Section 6.1.2.2 of RFC8445}}).
 Implementations are free to implement different algorithms as they see fit.
 
@@ -109,15 +117,15 @@ This mode needs be negotiated during the handshake, see {{negotiate-extension}}.
 ## Gathering Address Candidates
 
 The gathering of address candidates is out of scope for this document. Endpoints
-MAY use the logic described in {{Sections 5.1.1 and 5.2 of RFC8445}}, or use
-address candidates provided by the application.
+MAY use the logic described in {{Sections 5.1.1 and 5.2 of RFC8445}}, or they
+MAY use address candidates provided by the application.
 
 ## Sending Address Candidates to the Client
 
 The server sends its address candidates to the client using ADD_ADDRESS frames.
 It SHOULD NOT wait until address candidate discovery has finished, instead, it
-SHOULD send address candidates as soon as they become available. This allows
-speeding up the NAT traversal, and is similar to Trickle ICE ({{!RFC8838}}).
+SHOULD send address candidates as soon as they become available. This speeds up
+the NAT traversal and is similar to Trickle ICE ({{!RFC8838}}).
 
 Addresses sent to the client can be removed using the REMOVE_ADDRESS frame if
 the address candidate becomes stale, e.g. because the network interface becomes
@@ -133,21 +141,21 @@ The client matches the address candidates sent by the server with its own
 address candidates, forming candidate pairs. {{Section 5.1 of RFC8445}}
 describes an algorithm for pairing address candidates. Since the pairing
 algorithm is only run on the client side, the endpoints do not need to agree on
-the algorithm used, and the client is free to use a different algorithms.
+the algorithm used, and the client is free to use a different algorithm.
 
 ## Probing Paths
 
 The client sends candidate pairs to the server using PUNCH_ME_NOW frames. The
 client SHOULD start path validation (see {{Section 8.2 of RFC9000}}) for the
 respective path immediately after sending the PUNCH_ME_NOW frame.
 
-On the server side, path validation SHOULD be started immediately when receiving
-a PUNCH_ME_NOW frame. This document introduces the concept of path validation on
+The server SHOULD start path validation immediately upon receipt of a
+PUNCH_ME_NOW frame. This document introduces the concept of path validation on
 the server side, since {{!RFC9000}} assumes that any QUIC server is able to
 receive packets on a path without creating a NAT binding first. Path validation
-on the server side works as described in {{Section 8.2.1 of RFC9000}}, with
-additional rate-limiting (see {{amplification-attack}}) to prevent amplification
-attacks.
+on the server works as described in {{Section 8.2.1 of RFC9000}}, with
+additional rate-limiting (see {{amplification-attack}}) to prevent
+amplification attacks.
 
 Path probing happens in rounds, allowing the peers to limit the bandwidth
 consumed by sending path validation packets. For every round, the client MUST
@@ -186,7 +194,7 @@ of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR.
 
 For the server, the value of this transport parameter is a variable-length
 integer, the concurrency limit. The concurrency limit limits the amount of
-concurrent NAT traversal attempts, and can be used to limit the bandwith
+concurrent NAT traversal attempts and can be used to limit the bandwith
 required to execute the path validation. Any value larger than 0 is valid. A
 client implementation that understands this transport parameter MUST treat the
 receipt of a value that is not a variable-length integer, or the receipt of the
@@ -224,10 +232,12 @@ IPv4:
 
 IPv6:
 
-: The IPv6 address. Only present if the least significant bit of the frame
-type is 1.
+: The IPv6 address. Only present if the least significant bit of the frame type
+   is 1.
 
-Port: The port number.
+Port: 
+
+: The port number.
 
 ADD_ADDRESS frames are ack-eliciting. When lost, they SHOULD be retransmitted,
 unless the address is not active anymore.
@@ -249,7 +259,7 @@ PUNCH_ME_NOW Frame {
 }
 ~~~
 
-The ADD_ADDRESS frame contains the following fields:
+The PUNCH_ME_NOW frame contains the following fields:
 
 Round:
 
@@ -306,15 +316,15 @@ PROTOCOL_VIOLATION.
 
 # Security Considerations
 
-This document expands QUIC's path validation logic to the server side, allowing
-the client to request sending of path validation packets on unverified paths. A
-malicious client can direct traffic to a target IP. This attack is similar to
+This document expands QUIC's path validation logic to QUIC servers, allowing a
+QUIC client to request sending of path validation packets on unverified paths.
+A malicious client can direct traffic to a target IP. This attack is similar to
 the IP address spoofing attack that address validation during connection
 establishment (see {{Section 8.1 of RFC9000}}) is designed to prevent. In
 practice however, IP address spoofing is often additionally mitigated by both
-the ingress and egress network at the IP layer, which is not possible when using
-this extension. The server therefore needs to carefully limit the amount of data
-it sends on unverified paths.
+the ingress and egress network at the IP layer, which is not possible when
+using this extension. The server therefore needs to carefully limit the amount
+of data it sends on unverified paths.
 
 
 # IANA Considerations