refactor(proto): Raise limit of path responses kept around per PathData

noq-proto/src/connection/paths.rs

@@ -853,8 +853,20 @@ pub(crate) struct PathResponses {
 
 impl PathResponses {
     pub(crate) fn push(&mut self, packet: u64, token: u64, network_path: FourTuple) {
-        /// Arbitrary permissive limit to prevent abuse
-        const MAX_PATH_RESPONSES: usize = 16;
+        /// An arbitrary permissive limit to prevent abuse.
+        ///
+        /// If we've negotiated the n0 NAT Traversal extension, and one user might have a lot
+        /// of addresses, e.g. because of having lots of interfaces (we've seen >25 interfaces
+        /// on Macs with docker and other things), then we need to be able to process at least
+        /// as many PATH_CHALLENGE frames as there are interfaces.
+        /// On top of that, there are retries, which make it possible that we need to process
+        /// even more.
+        ///
+        /// Considering that there can be up to 2 `PathData`s per active `PathId`, and
+        /// reasonable default values for maximum concurrent multipath paths are ~8 and each
+        /// `PathResponse` struct takes up 72 bytes at the moment this, means an attacker can
+        /// cause us to keep `32 * 2 * 8 * 72 = ~37KB` of data around.
+        const MAX_PATH_RESPONSES: usize = 32;
         let response = PathResponse {
             packet,
             token,

noq-proto/src/tests/proptests.rs

@@ -24,7 +24,7 @@ use crate::{
 
 // These TransportConfig constants are designed to match iroh for now.
 const MAX_MULTIPATH_PATHS: u32 = 8;
-const MAX_QNT_ADDRS: u8 = 12;
+const MAX_QNT_ADDRS: u8 = 32;
 const PATH_MAX_IDLE_TIMEOUT: Duration = Duration::from_secs(15);
 const HEARTBEAT_INTERVAL: Duration = Duration::from_secs(5);