[Ice] an extra review of draft-ietf-ice-rfc5245bis-05

[Miika Komu <[e-mail]>]

Hi folks,

I have promised offline Christer some feedback about the ICE-bis draft. 
It's mostly nits and descriptions that were difficult to follow. Here 
goes nothing :)

 >  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
 >  2.  Overview of ICE . . . . . . . . . . . . . . . . . . . . . . .   6
 >    2.1.  Gathering Candidate Addresses . . . . . . . . . . . . . .   8
 >    2.2.  Connectivity Checks . . . . . . . . . . . . . . . . . . .  10
 >    2.3.  Sorting Candidates  . . . . . . . . . . . . . . . . . . .  11
 >    2.4.  Frozen Candidates . . . . . . . . . . . . . . . . . . . .  12
 >    2.5.  Security for Checks . . . . . . . . . . . . . . . . . . .  13
 >    2.6.  Concluding ICE  . . . . . . . . . . . . . . . . . . . . .  13
 >    2.7.  Lite Implementations  . . . . . . . . . . . . . . . . . .  14
 >    2.8.  Usages of ICE . . . . . . . . . . . . . . . . . . . . . .  15
 >  3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  15
 >  4.  ICE Candidate Gathering and Exchange  . . . . . . . . . . . .  18
 >    4.1.  Procedures for Full Implementation  . . . . . . . . . . .  19
 >      4.1.1.  Gathering Candidates  . . . . . . . . . . . . . . . .  19
 >        4.1.1.1.  Host Candidates . . . . . . . . . . . . . . . . .  20
 >        4.1.1.2.  Server Reflexive and Relayed Candidates . . . . .  21
 >        4.1.1.3.  Computing Foundations . . . . . . . . . . . . . .  23
 >        4.1.1.4.  Keeping Candidates Alive  . . . . . . . . . . . .  23
 >      4.1.2.  Prioritizing Candidates . . . . . . . . . . . . . . .  23
 >        4.1.2.1.  Recommended Formula . . . . . . . . . . . . . . .  24
 >        4.1.2.2.  Guidelines for Choosing Type and Local
 >                  Preferences . . . . . . . . . . . . . . . . . . .  25
 >      4.1.3.  Eliminating Redundant Candidates  . . . . . . . . . .  26
 >    4.2.  Lite Implementation Procedures  . . . . . . . . . . . . .  26
 >    4.3.  Encoding the Candidate Information  . . . . . . . . . . .  27

As visible from the table of contents, the text is a bit heavily nested 
which makes it a bit hard to read. My editorial suggestion would be to 
remind the reader about the context always when you go back in hierarchy 
e.g. from 4.1.1.4. to 4.1.2 as follows:

4.1.2. Prioritizing Candidates

After completing candidate gathering, the next step for a full
implementation is to prioritize candidates. [...]

 > 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . .  62

I really liked the example in the end even though the scenario was a
bit simplified (i.e., one end had a public address). I was somehow 
expecting was packet diagrams for ICE-based STUN messages,
but they are not included at all.

 > 2.6.  Concluding ICE
 >
 >  ICE checks are performed in a specific sequence, so that high-
 >  priority candidate pairs are checked first, followed by lower-
 >  priority ones.  One way to conclude ICE is to declare victory as soon
 >  as a check for each component of each media stream completes
 >  successfully.  Indeed, this is a reasonable algorithm, and details
 >  for it are provided below.  However, it is possible that a packet
 >  loss will cause a higher-priority check to take longer to complete.
 >  In that case, allowing ICE to run a little longer might produce
 >  better results.  More fundamentally, however, the prioritization
 >  defined by this specification may not yield "optimal" results.  As an
 >  example, if the aim is to select low-latency media paths, usage of a
 >  relay is a hint that latencies may be higher, but it is nothing more
 >  than a hint.  An actual round-trip time (RTT) measurement could be
 >  made, and it might demonstrate that a pair with lower priority is
 >  actually better than one with higher priority.
 >
 >  Consequently, ICE assigns one of the agents in the role of the
 >  CONTROLLING AGENT, and the other of the CONTROLLED AGENT.  The
 >  controlling agent gets to nominate which candidate pairs will get
 >  used for media amongst the ones that are valid.
 >
 >  When nominating, the controlling agent lets the checks continue until
 >  at least one valid candidate pair for each media stream is found.
 >  Then, it picks amongst those that are valid, and sends a second STUN
 >  request on its NOMINATED candidate pair, but this time with a flag
 >  set to tell the peer that this pair has been nominated for use.  This
 >  is shown in Figure 4.
 >
 >
 >  L                        R
 >  -                        -
 >  STUN request ->          \  L's
 >            <- STUN response  /  check
 >
 >             <- STUN request  \  R's
 >  STUN response ->         /  check
 >
 >  STUN request + flag ->   \  L's
 >            <- STUN response  /  check
 >
 >
 >                          Figure 4: Nomination
 >
 >  Once the STUN transaction with the flag completes, both sides cancel
 >  any future checks for that media stream.  ICE will now send media
 >  using this pair.  The pair an ICE agent is using for media is called
 >  the SELECTED PAIR.
 >
 >  Once ICE is concluded, it can be restarted at any time for one or all
 >  of the media streams by either agent.  This is done by sending an
 >  updated candidate information indicating a restart.

I would clarify that both sides check separately for connectivity even 
when using the aggressive nomination.

 > 2.7.  Lite Implementations
 >
 >  In order for ICE to be used in a call, both agents need to support
 >  it.  However, certain agents will always be connected to the public
 >  Internet and have a public IP address at which it can receive packets
 >  from any correspondent.  To make it easier for these devices to
 >  support ICE, ICE defines a special type of implementation called LITE
 >  (in contrast to the normal FULL implementation).  A lite
 >  implementation doesn't gather candidates; it includes only host
 >  candidates for any media stream.  Lite agents do not generate
 >  connectivity checks or run the state machines, though they need to be
 >  able to respond to connectivity checks.  When a lite implementation
 >  connects with a full implementation, the full agent takes the role of
 >  the controlling agent, and the lite agent takes on the controlled
 >  role.  When two lite implementations connect, no checks are sent.

The last sentence left me in limbo; how are addresses selected then? 
It's explained later, but some hint would be great here.

 > 2.8.  Usages of ICE
 >
 >  This document specifies generic use of ICE with protocols that
 >  provide means to exchange candidate information between the ICE
 >  Peers.  The specific details of (i.e how to encode candidate
 >  information and the actual candidate exchange process) for different
 >  protocols using ICE are described in separate usage documents.  One
 >  possible way the agents can exchange the candidate information is to
 >  use [RFC3264] based Offer/Answer semantics as part of the SIP
 >  [RFC3261] protocol [I-D.ietf-mmusic-ice-sip-sdp].
 >
 > 3.  Terminology
 >
 > [...]
 >
 >  Foundation:  An arbitrary string that is the same for two candidates
 >     that have the same type, base IP address, protocol (UDP, TCP,
 >     etc.), and STUN or TURN server.  If any of these are different,
 >     then the foundation will be different.  Two candidate pairs with
 >     the same foundation pairs are likely to have similar network
 >     characteristics.  Foundations are used in the frozen algorithm.

What do you mean by type? This is explained later, but some hint would 
be good here.

 >  Check List:  An ordered set of candidate pairs that an agent will use
 >     to generate checks.

How many check lists are there? One per media stream?

 > 4.1.3.  Eliminating Redundant Candidates
 >
 >  Next, the agent eliminates redundant candidates.  A candidate is
 >  redundant if its transport address equals another candidate, and its
 >  base equals the base of that other candidate.  Note that two
 >  candidates can have the same transport address yet have different
 >  bases, and these would not be considered redundant.

When does this occur (multihoming?)?

 >  Frequently, a
 >  server reflexive candidate and a host candidate will be redundant
 >  when the agent is not behind a NAT.  The agent SHOULD eliminate the
 >  redundant candidate with the lower priority.
 >
 >  This process is common across the initiating and responding agents.

I would clarify that the process is about eliminating *local*
candidates (i.e. not pairs which is called pruning). It's easy to mix 
the terms...

 > 4.2.  Lite Implementation Procedures
 >
 >  Lite implementations only utilize host candidates.  A lite
 >  implementation MUST, for each component of each media stream,
 >  allocate zero or one IPv4 candidates.  It MAY allocate zero or more
 >  IPv6 candidates, but no more than one per each IPv6 address utilized
 >  by the host.  Since there can be no more than one IPv4 candidate per
 >  component of each media stream, if an agent has multiple IPv4
 >  addresses, it MUST choose one for allocating the candidate.  If a
 >  host is dual-stack, it is RECOMMENDED that it allocate one IPv4
 >  candidate and one global IPv6 address.  With the lite implementation,
 >  ICE cannot be used to dynamically choose amongst candidates.
 >  Therefore, including more than one candidate from a particular scope
 >  is NOT RECOMMENDED, since only a connectivity check can truly
 >  determine whether to use one address or the other.

I didn't quite follow the last sentence, please rephrase?

 >  Each component has an ID assigned to it, called the component ID.
 >  For RTP-based media streams, unless RTCP is multiplexed in the same
 >  port with RTP, the RTP itself has a component ID of 1, and RTCP a
 >  component ID of 2.  If an agent is using RTCP without multiplexing,
 >  it MUST obtain candidates for it.  However, absence of a component ID
 >  2 as such does not imply use of RTCP/RTP multiplexing, as it could
 >  also mean that RTCP is not used.
 >
 >  Each candidate is assigned a foundation.  The foundation MUST be
 >  different for two candidates allocated from different IP addresses,
 >  and MUST be the same otherwise.

What do you mean by allocation? Please elaborate.

 > 5.1.3.1.  Forming Candidate Pairs
 >
 >  First, the agent takes each of its candidates for a media stream
 >  (called LOCAL CANDIDATES) and pairs them with the candidates it
 >  received from its peer (called REMOTE CANDIDATES) for that media
 >  stream.  In order to prevent the attacks described in Section 13.4.1,
 >  agents MAY limit the number of candidates they'll accept in an
 >  candidate exchange process.  A local candidate is paired with a
 >  remote candidate if and only if the two candidates have the same
 >  component ID and have the same IP address version.  It is possible
 >  that some of the local candidates won't get paired with remote
 >  candidates, and some of the remote candidates won't get paired with
 >  local candidates.  This can happen if one agent doesn't include
 >  candidates for the all of the components for a media stream.  If this
 >  happens, the number of components for that media stream is
 >  effectively reduced, and considered to be equal to the minimum across
 >  both agents of the maximum component ID provided by each agent across
 >  all components for the media stream.

I didn't quite follow the last statement.

 > 5.1.3.2.  Computing Pair Priority and Ordering Pairs
 >
 >  Once the pairs are formed, a candidate pair priority is computed.
 >  Let G be the priority for the candidate provided by the controlling
 >  agent.  Let D be the priority for the candidate provided by the
 >  controlled agent.  The priority for a pair is computed as:
 >
 >     pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
 >
 >  Where G>D?1:0 is an expression whose value is 1 if G is greater than
 >  D, and 0 otherwise.  Once the priority is assigned, the agent sorts
 >  the candidate pairs in decreasing order of priority.  If two pairs
 >  have identical priority, the ordering amongst them is arbitrary.

Please clarify that the pair priority should be stored in 64-bit
integer in an implementation.

 > 5.1.3.3.  Pruning the Pairs
 >
 >  This sorted list of candidate pairs is used to determine a sequence
 >  of connectivity checks that will be performed.  Each check involves
 >  sending a request from a local candidate to a remote candidate.
 >  Since an agent cannot send requests directly from a reflexive
 >  candidate, but only from its base, the agent next goes through the
 >  sorted list of candidate pairs.  For each pair where the local
 >  candidate is server reflexive, the server reflexive candidate MUST be
 >  replaced by its base.  Once this has been done, the agent MUST prune
 >  the list.  This is done by removing a pair if its local and remote
 >  candidates are identical to the local and remote candidates of a pair
 >  higher up on the priority list.  The result is a sequence of ordered
 >  candidate pairs, called the check list for that media stream.
 >
 >  In addition, in order to limit the attacks described in
 >  Section 13.4.1, an agent MUST limit the total number of connectivity
 >  checks the agent performs across all check lists to a specific value,
 >  and this value MUST be configurable.  A default of 100 is
 >  RECOMMENDED.  This limit is enforced by discarding the lower-priority
 >  candidate pairs until there are less than 100.

Does 100 include retransmissions?

It is RECOMMENDED
 >  that a lower value be utilized when possible, set to the maximum
 >  number of plausible checks that might be seen in an actual deployment
 >  configuration.  The requirement for configuration is meant to provide
 >  a tool for fixing this value in the field if, once deployed, it is
 >  found to be problematic.

I would clarify that pruning refers to filtering out candidate *pairs*
(i.e. not local addresses, which would be "eliminating redundant
candidates". It's easy to mix the terms...

 > 5.2.  Lite Implementation Procedures
 >
 >  Lite implementations skips most of the steps in Section 5 except for
 >  verifying the peer's ICE support and determining its role in the ICE
 >  processing.
 >
 >  On determining the role for a lite implementation being the
 >  controlling agent means selecting a candidate pair based on the ones
 >  in the candidate exchange (for IPv4, there is only ever one pair),
 >  and then updating the peer with the new candidate information
 >  reflecting that selection, when needed (it is never needed for an
 >  IPv4-only host).

Why it's not needed for an IPv4-only host?

 > The controlled agent is told which candidate pairs
 >  to use for each media stream, and no further candidate updates are
 >  needed to signal this information.

Who tells the controlled agent? Why further updates are not needed?

 > 6.1.2.1.  PRIORITY
 >
 >  An agent MUST include the PRIORITY attribute in its Binding request.
 >  The attribute MUST be set equal to the priority that would be
 >  assigned, based on the algorithm in Section 4.1.2, to a peer
 >  reflexive candidate, should one be learned as a consequence of this
 >  check (see Section 6.1.2.4.2.1 for how peer reflexive candidates are
 >  learned).  This priority value will be computed identically to how
 >  the priority for the local candidate of the pair was computed, except
 >  that the type preference is set to the value for peer reflexive
 >  candidate types.

This was difficult to follow, please elaborate:

* Is the priority attribute for a single local address or address pair?
* What if reflexive address is not learned?

 > 6.1.2.2.  USE-CANDIDATE
 >
 >  The controlling agent includes the USE-CANDIDATE attribute in order
 >  to nominate a candidate pair Section 6.2.1.1.  The controlled agent
 >  MUST NOT include the USE-CANDIDATE attribute in its Binding request.

...*in* Section...

 > 6.1.2.3.  ICE-CONTROLLED and ICE-CONTROLLING
 >
 >  The agent MUST include the ICE-CONTROLLED attribute in the request if
 >  it is in the controlled role, and MUST include the ICE-CONTROLLING
 >  attribute in the request if it is in the controlling role.
 >
 >  The content of either attribute are used as tie-breaker values when
 >  an ICE role conflict occurs Section 6.1.3.1.1.
 >
 >  The ICE-CONTROLLED and ICE-CONTROLLING attributes are defined in
 >  Section 14.1.

Are ICE-CONTROLLED and ICE-CONTROLLING supposed to be set in all
connectivity checks (including responses)? If yes, is this mentioned
in the document? I read about this from here:

https://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01

    "Note that, even if a using
    protocol does not need to use the role conflict detection mechanism,
    it must include the ICE-CONTOLLED and ICE-CONTROLLING attributes in
    its connectivity checks as described in Section 7 of ICE.  This
    ensures that it is possible to easily build gateways between
    different protocols using ICE."

(Btw, I didn't quite understand the gateway comment)

 > 6.1.2.4.1.  Failure Cases
 >
 > [...]
 >
 >  Agents MAY support receipt of ICMP errors for connectivity checks.
 >  If the STUN transaction generates an ICMP error, the agent sets the
 >  state of the pair to Failed.  If the STUN transaction generates a
 >  STUN error response that is unrecoverable (as defined in [RFC5389])
 >  or times out, the agent sets the state of the pair to Failed.

ICMP messages can be forged easier than STUN messages. This could be
used to block STUN agents without being a man-in-the-middle?

 > 6.1.2.4.2.1.  Discovering Peer Reflexive Candidates
 >
 >  The agent checks the mapped address from the STUN response.  If the
 >  transport address does not match any of the local candidates that the
 >  agent knows about, the mapped address represents a new candidate -- a
 >  peer reflexive candidate.  Like other candidates, it has a type,
 >  base, priority, and foundation.  They are computed as follows:
 >
 >  o  Its type is equal to peer reflexive.
 >
 >  o  Its base is set equal to the local candidate of the candidate pair
 >     from which the STUN check was sent.
 >
 >  o  Its priority is set equal to the value of the PRIORITY attribute
 >     in the Binding request.
 >
 >  o  Its foundation is selected as described in Section 4.1.1.3.
 >
 >  This peer reflexive candidate is then added to the list of local
 >  candidates for the media stream.  Its username fragment and password
 >  are the same as all other local candidates for that media stream.
 >  However, the peer reflexive candidate is not paired with other remote
 >  candidates.  This is not necessary; a valid pair will be generated
 >  from it momentarily based on the procedures in Section 6.1.2.4.2.2.
 >  If an agent wishes to pair the peer reflexive candidate with other
 >  remote candidates besides the one in the valid pair that will be
 >  generated, the agent MAY generate an update the peer with the
 >  candidate information that includes the peer reflexive candidate.

I think the update procedure has not been defined yet, so maybe
reference the corresponding section in the draft?

 > 6.1.2.4.2.2.  Constructing a Valid Pair
 >
 >  The agent constructs a candidate pair whose local candidate equals
 >  the mapped address of the response, and whose remote candidate equals
 >  the destination address to which the request was sent.  This is
 >  called a valid pair, since it has been validated by a STUN
 >  connectivity check.  The valid pair may equal the pair that generated
 >  the check, may equal a different pair in the check list, or may be a
 >  pair not currently on any check list.  If the pair equals the pair
 >  that generated the check or is on a check list currently, it is also
 >  added to the VALID LIST, which is maintained by the agent for each
 >  media stream.  This list is empty at the start of ICE processing, and
 >  fills as checks are performed, resulting in valid candidate pairs.
 >
 >  It will be very common that the pair will not be on any check list.
 >  Recall that the check list has pairs whose local candidates are never
 >  server reflexive; those pairs had their local candidates converted to
 >  the base of the server reflexive candidates, and then pruned if they
 >  were redundant.  When the response to the STUN check arrives, the
 >  mapped address will be reflexive if there is a NAT between the two.
 >  In that case, the valid pair will have a local candidate that doesn't
 >  match any of the pairs in the check list.
 >
 >  If the pair is not on any check list, the agent computes the priority
 >  for the pair based on the priority of each candidate, using the
 >  algorithm in Section 5.1.3.  The priority of the local candidate
 >  depends on its type.  If it is not peer reflexive, it is equal to the
 >  priority signaled for that candidate in the candidate exchange.  If
 >  it is peer reflexive, it is equal to the PRIORITY attribute the agent
 >  placed in the Binding request that just completed.  The priority of
 >  the remote candidate is taken from the candidate information of the
 >  peer.  If the candidate does not appear there, then the check must
 >  have been a triggered check to a new remote candidate.

Where there? Who triggered the check?

 > 6.1.2.4.2.3.  Updating Pair States
 >
 >  2.  If there is a pair in the valid list for every component of this
 >      media stream (where this is the actual number of components being
 >      used, in cases where the number of components signaled in the
 >      candidate exchange differs from initiating to responding agent),
 >      the success of this check may unfreeze checks for other media
 >      streams.

I didn't quite follow the remark in the parenthesis. Please elaborate?

 > 6.1.3.1.2.  Computing Mapped Address
 >
 >  For requests being received on a relayed candidate, the source
 >  transport address used for STUN processing (namely, generation of the
 >  XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the
 >  TURN server.  That source transport address will be present in the
 >  XOR-PEER-ADDRESS attribute of a Data Indication message, if the
 >  Binding request was delivered through a Data Indication.  If the
 >  Binding request was delivered through a ChannelData message, the
 >  source transport address is the one that was bound to the channel.

ChannelData has not been introduced yet in the document.

 > 6.1.3.1.3.  Learning Peer Reflexive Candidates
 >
 > [...]
 >
 >  o  The foundation of the candidate is set to an arbitrary value,
 >     different from the foundation for all other remote candidates.  If
 >     any subsequent candidate exchanges contain this peer reflexive
 >     candidate, it will signal the actual foundation for the candidate.

What do you mean by the last statement? Please elaborate?

 > [...]
 >  This candidate is added to the list of remote candidates.  However,
 >  the agent does not pair this candidate with any local candidates.

Why? This leaves the reader in a limbo...

 > 6.1.3.1.4.  Triggered Checks
 >
 > [...]
 >
 >  These steps are done to facilitate rapid completion of ICE when both
 >  agents are behind NAT.
 >
 >  o  If the pair is not already on the check list:
 >
 >     *  The pair is inserted into the check list based on its priority.
 >
 >     *  Its state is set to Waiting.
 >
 >     *  The pair is enqueued into the triggered check queue.

Does this refer to peer reflexive candidates? If so, I guess this
contradicts with 6.1.3.1.3 (check my previous comment)?

 > 6.1.3.1.5.  Updating the Nominated Flag
 >
 > [...]
 >  o  If the state of this pair is In-Progress, if its check produces a
 >     successful result, the resulting valid pair has its nominated flag
 >     set when the response arrives.  This may end ICE processing for
 >     this media stream when it arrives; see Section 6.2.

...In-Progress, *and* if its check...

 > 11.3.  RTO
 >
 >  During the ICE gathering phase, ICE agents SHOULD calculate the RTO
 >  value using the following formula:
 >
 >
 >
 >    RTO = MAX (500ms, Ta * (Num-Of-Pairs))
 >
 >
 >    Num-Of-Pairs: the number of pairs of candidates
 >    with STUN or TURN servers.

What do you mean with number of pairs of candidates here? Please elaborate?

 > 12.  Example
 >
 >  The example is based on the simplified topology of Figure 8.
 >
 >
 >                           +-------+
 >                           |STUN   |
 >                           |Server |
 >                           +-------+
 >                               |
 >                    +---------------------+
 >                    |                     |
 >                    |      Internet       |
 >                    |                     |
 >                    +---------------------+
 >                      |                |
 >                      |                |
 >               +---------+             |
 >               |   NAT   |             |
 >               +---------+             |
 >                    |                  |
 >                    |                  |
 >                 +-----+            +-----+
 >                 |  L  |            |  R  |
 >                 +-----+            +-----+
 >
 >                       Figure 8: Example Topology

I suggest adding the IP addresses and ports also into the figure for
easier referencing.

 > [...]
 >            L             NAT           STUN             R
 >            |RTP STUN alloc.              |              |
 >            |(1) STUN Req  |              |              |
 >            |S=$L-PRIV-1   |              |              |
 >            |D=$STUN-PUB-1 |              |              |
 >            |------------->|              |              |
 >            |              |(2) STUN Req  |              |
 >            |              |S=$NAT-PUB-1  |              |
 >            |              |D=$STUN-PUB-1 |              |
 >            |              |------------->|              |
 >            |              |(3) STUN Res  |              |
 >            |              |S=$STUN-PUB-1 |              |
 >            |              |D=$NAT-PUB-1  |              |
 >            |              |MA=$NAT-PUB-1 |              |
 >            |              |<-------------|              |
 >            |(4) STUN Res  |              |              |
 >            |S=$STUN-PUB-1 |              |              |
 >            |D=$L-PRIV-1   |              |              |
 >            |MA=$NAT-PUB-1 |              |              |
 >            |<-------------|              |              |
 >            |(5) L's Candidate Information|              |
 >            |------------------------------------------->|
 >            |              |              |              | RTP STUN
 >            |              |              |              | alloc.
 >            |              |              |(6) STUN Req  |
 >            |              |              |S=$R-PUB-1    |
 >            |              |              |D=$STUN-PUB-1 |
 >            |              |              |<-------------|
 >            |              |              |(7) STUN Res  |
 >            |              |              |S=$STUN-PUB-1 |
 >            |              |              |D=$R-PUB-1    |
 >            |              |              |MA=$R-PUB-1   |
 >            |              |              |------------->|
 >            |(8) R's Candidate Information|              |
 >            |<-------------------------------------------|
 >            |              |(9) Bind Req  |              |Begin
 >            |              |S=$R-PUB-1    |              |Connectivity
 >            |              |D=L-PRIV-1    |              |Checks
 >            |              |<----------------------------|
 >            |              |Dropped       |              |


I think the packet (9) should be dropped earlier (between STUN and R).


 > [...]
 >  Agents L and R both pair up the candidates.  They both initially have
 >  two pairs.

Why don't you list all the pairs explicitly here?

 > [...]
 >  Soon after receipt of the STUN Binding request from agent L (message
 >  11), agent R will generate its triggered check.  This check happens
 >  to match the next one on its check list -- from its host candidate to
 >  agent L's server reflexive candidate.

What is the significance of the check matching the next on its check
list? This was brought up, but not explained.

 > 13.1.  Attacks on Connectivity Checks
 >
 > [...]
 >  Forcing the fake valid result works in a similar way.  The agent
 >  needs to wait for the Binding request from each agent, and inject a
 >  fake success response.

....The *attacker* needs to wait...

 > 13.3.  Attacks on Relayed Candidate Gathering
 >
 >  An attacker might attempt to disrupt the gathering of relayed
 >  candidates, forcing the client to believe it has a false relayed
 >  candidate.  Exchanges with the TURN server are authenticated using a
 >  long-term credential.  Consequently, injection of fake responses or
 >  requests will not work.  In addition, unlike Binding requests,
 >  Allocate requests are not susceptible to replay attacks with modified
 >  source IP addresses and ports, since the source IP address and port
 >  are not utilized to provide the client with its relayed candidate.

...source IP address and port in *packet headers*... (right?)