A few more RFC refs, answer the QUIC TODO

1 files changed, 12 insertions, 7 deletions

diff --git a/proposals/XXX-udp-app-support.md b/proposals/XXX-udp-app-support.md
index 54b0e41..b9bda00 100644
--- a/proposals/XXX-udp-app-support.md
+++ b/proposals/XXX-udp-app-support.md
@@ -200,11 +200,13 @@ We will analyze how these protocols affect Tor's UDP traffic requirements.
 
 ### QUIC
 
-RFC9000 defines QUIC, a multiplexed secure point-to-point protocol which supports reliable and unreliable delivery. The most common use is as an optional HTTP replacement, especially among Google services.
+[RFC9000](https://www.rfc-editor.org/rfc/rfc9000.html) defines QUIC, a multiplexed secure point-to-point protocol which supports reliable and unreliable delivery. The most common use is as an optional HTTP replacement, especially among Google services.
 
 QUIC does not normally try to traverse NAT; as an HTTP replacement, the server is expected to have a routable address.
 
-TODO: Look closer at the NAT rebinding attack described in the RFC, check how applicable that is for us.
+QUIC provides its own flexible connection lifetimes which may outlive individual network links or NAT mappings.
+The intention is to provide transparent roaming as mobile users change networks.
+This automated path discovery opens additional opportunities for malicious traffic, for which the RFC also offers mitigations. See *path validation* in section `8.2`, and the additional mitigations from section `9.3`.
 
 When QUIC is used as an optional upgrade path, we must compare any proposed UDP support against the baseline of a non-upgraded original connection.
 In these cases we are not looking for any specific compatibility enhancement, simply an avoidance of regression.
@@ -217,13 +219,16 @@ WebRTC is a large collection of protocols tuned to work together for media trans
 It is increasingly common, both for browser-based telephony and for peer to peer data transfer.
 Non-browser-based apps often implement WebRTC or have components in common with WebRTC.
 
-See RFC7734, RFC8825, RFC8445, RFC5389, others.
+Of particular importance to us, WebRTC uses the Interactive Connection Establishment (ICE) protocol to establish a bidirectional channel between endpoints that may or may not be behind a NAT with unknown configuration.
 
-TODO: Organize and expand references here.
+Any generalized solution to connection establishment, like ICE, will require sending connectivity test probes. These have an inherent hazard to anonymity: assuming no delays are inserted intentionally, the result is a broadcast of similar traffic across all available network interfaces. This could form a convenient correlation beacon for an attacker attempting to deanonymize users who use WebRTC over a Tor VPN.
 
-Of particular importance to us, WebRTC uses the Interactive Connection Establishment (ICE, RFC8445, RFC8838) protocol to establish a bidirectional channel between endpoints that may or may not be behind a NAT with unknown configuration.
-
-TODO: More about the specifics of how ICE effects us. More about privacy concerns.
+See
+[RFC8825](https://www.rfc-editor.org/rfc/rfc8825.html) _Overview: Real-Time Protocols for Browser-Based Applications_,
+[RFC8445](https://www.rfc-editor.org/rfc/rfc8445.html) _Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal_,
+[RFC8838](https://www.rfc-editor.org/rfc/rfc8838.html) _Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol_,
+[RFC5389](https://www.rfc-editor.org/rfc/rfc5389.html) _Session Traversal Utilities for NAT (STUN)_,
+and others.
 
 ## Common Applications