Draft: draft-ietf-taps-impl

Commentary: Restructure to address Rearrange to include Rendezvous and Environment Discovery text in connection establishment . Remove that previous section . was intended to check the ordering of sections against the other drafts and to merge . I have merged the Rendezvous text into Connection Establishment , but I have n't changed any of the text yet . I am a little concerned about creating an interdependancy in the text between derriving endpoints ( name lookup ) and the ICE / TURN stuff . More generally , I am not sure what to say about name resolution and proxies ( ala ) . TOR opens a can of privacy worms for name lookup and racing paths that I am not sure how to address . 
 Looks good apart from typo ! 
 Having proxies to go through on a system ( SOCKS , HTTP Connect , etc ) or a set of TOR endpoints requires the implementation to do some nested / recursive work , and pass down endpoints correctly to protocol instances . The implementation document should describe this . 
 +1 
 There is already text in 4.1.3.3 . Protocol Options . Is that sufficient or do we need more ? 
 Review structure . What fits in pre - establishment . Relation system policy - cached state . Generalizes 
 Discussed in Singapore , we 'll have more structure comments later , but we 've done a lot of changes since then . 
 I like the change , as it makes the process much clearer and reduces the awkwardness of ICE / STUN . To model TOR , SOCKS , or other tunnelling protocols , I would refrain from seeing them as protocol stacks , but treat them as derived paths that only support these stacks . This removes the need for cupeling name resolution to the protocol stack , and looks quite natural to me as these derived paths may be available in the connection cache or need to be established for name resolution anyway before starting the real candidate racing . If we want to do so , it might be easier to talk about paths ( that have one or more corresponding local endpoints ) , derived paths , derived remote endpoints ( as result of name resolution on each path ) and protocol stacks .
Paragraph (version A):
Connection establishment is divided into two top-level steps:
Candidate Gathering, to identify the paths, protocols, and endpoints
to use, and Candidate Racing, in which the necessary protocol
handshakes are conducted so that the transport system can select
which set to use.
Paragraph (version B):
Connection establishment is divided into two top-level steps:
Candidate Gathering, to identify the paths, protocols, and endpoints
to use, and Candidate Racing, in which the necessary protocol
handshakes are conducted so that the transport system can select
which set to use.  This document structures candidates for racing as
a tree.
Paragraph (version B):
Both Local and Remote Endpoint Candidates must be discovered during
connection establishment.  To support ICE, or similar protocols, that
involve out-of-band indirect signalling to exchange candidates with
the Remote Endpoint, it's important to be able to query the set of
candidate Local Endpoints, and give the protocol stack a set of
candidate Remote Endpoints, before it attempts to establish
connections.
Paragraph (version B):
The set of possible Local Endpoints is gathered.  In the simple case,
this merely enumerates the local interfaces and protocols, allocates
ephemeral source ports.  For example, a system that has WiFi and
Ethernet and supports IPv4 and IPv6 might gather four candidate
locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on
WiFi) that can form the source for a transient.
Paragraph (version B):
If NAT traversal is required, the process of gathering Local
Endpoints becomes broadly equivalent to the ICE candidate gathering
phase RFC5245.  The endpoint determines its server reflexive Local
Endpoints (i.e., the translated address of a local, on the other side
of a NAT) and relayed locals (e.g., via a TURN server or other
relay), for each interface and network protocol.  These are added to
the set of candidate Local Endpoints for this connection.
Paragraph (version B):
Gathering Local Endpoints is primarily a local operation, although it
might involve exchanges with a STUN server to derive server reflexive
locals, or with a TURN server or other relay to derive relayed
locals.  It does not involve communication with the Remote Endpoint.
Paragraph (version B):
The Remote Endpoint is typically a name that needs to be resolved
into a set of possible addresses that can be used for communication.
Resolving the Remote Endpoint is the process of recursively
performing such name lookups, until fully resolved, to return the set
of candidates for the remote of this connection.
Paragraph (version B):
How this is done will depend on the type of the Remote Endpoint, and
can also be specific to each Local Endpoint.  A common case is when
the Remote Endpoint is a DNS name, in which case it is resolved to
give a set of IPv4 and IPv6 addresses representing that name.  Some
types of remote might require more complex resolution.  Resolving the
Remote Endpoint for a peer-to-peer connection might involve
communication with a rendezvous server, which in turn contacts the
peer to gain consent to communicate and retrieve its set of candidate
locals, which are returned and form the candidate remote addresses
for contacting that peer.
Paragraph (version B):
Resolving the remote is not a local operation.  It will involve a
directory service, and can require communication with the remote to
rendezvous and exchange peer addresses.  This can expose some or all
of the candidate locals to the remote.
Paragraph (version A):
The set of possible Local Endpoints is gathered.  In the simple
case, this merely enumerates the local interfaces and protocols,
allocates ephemeral source ports.  For example, a system that has
WiFi and Ethernet and supports IPv4 and IPv6 might gather four
candidate locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on
WiFi, and IPv6 on WiFi) that can form the source for a transient.
Paragraph (version A):
If NAT traversal is required, the process of gathering Local
Endpoints becomes broadly equivalent to the ICE candidate
gathering phase RFC5245.  The endpoint determines its server
reflexive Local Endpoints (i.e., the translated address of a
local, on the other side of a NAT) and relayed locals (e.g., via a
TURN server or other relay), for each interface and network
protocol.  These are added to the set of candidate Local Endpoints
for this connection.
Paragraph (version A):
Gathering Local Endpoints is primarily a local operation, although
it might involve exchanges with a STUN server to derive server
reflexive locals, or with a TURN server or other relay to derive
relayed locals.  It does not involve communication with the Remote
Endpoint.
Paragraph (version A):
The Remote Endpoint is typically a name that needs to be resolved
into a set of possible addresses that can be used for
communication.  Resolving the Remote Endpoint is the process of
recursively performing such name lookups, until fully resolved, to
return the set of candidates for the remote of this connection.
Paragraph (version A):
How this is done will depend on the type of the Remote Endpoint,
and can also be specific to each Local Endpoint.  A common case is
when the Remote Endpoint is a DNS name, in which case it is
resolved to give a set of IPv4 and IPv6 addresses representing
that name.  Some types of remote might require more complex
resolution.  Resolving the Remote Endpoint for a peer-to-peer
connection might involve communication with a rendezvous server,
which in turn contacts the peer to gain consent to communicate and
retrieve its set of candidate locals, which are returned and form
the candidate remote addresses for contacting that peer.
Paragraph (version A):
Resolving the remote is _not_ a local operation.  It will involve
a directory service, and can require communication with the remote
to rendezvous and exchange peer addresses.  This can expose some
or all of the candidate locals to the remote.
Paragraph (version A):
The set of candidate Local Endpoints and the set of candidate
Remote Endpoints are paired, to derive a priority ordered set of
Candidate Paths that can potentially be used to establish a
Connection.
Paragraph (version A):
Then, communication is attempted over each candidate path, in
priority order.  If there are multiple candidates with the same
priority, then connection establishment proceeds simultaneously
and uses the transient that wins the race to be established.
Otherwise, connection establishment is sequential, paced at a rate
that should not congest the network.  Depending on the chosen
transport, this phase might involve racing TCP connections to a
server over IPv4 and IPv6 RFC8305, or it could involve a STUN
exchange to establish peer-to-peer UDP connectivity RFC5245, or
some other means.
Paragraph (version A):
Once connectivity has been established, unused resources can be
released and the chosen path can be confirmed.  This is primarily
required when establishing peer-to-peer connectivity, where
connections supporting relayed locals that were not required can
be closed, and where an associated signalling operation might be
needed to inform middleboxes and proxies of the chosen path.
Keep-alive messages may also be sent, as appropriate, to ensure
NAT and firewall state is maintained, so the Connection remains
operational.
Paragraph (version A):
To support ICE, or similar protocols, that involve an out-of-band
indirect signalling exchange to exchange candidates with the Remote
Endpoint, it's important to be able to query the set of candidate
Local Endpoints, and give the protocol stack a set of candidate
Remote Endpoints, before it attempts to establish connections.