【翻译】ietf-quic-draft-24: 9. Connection Migration

英文原文链接: 9. Connection Migration

  连接 ID 的使用允许连接在端点改变地址（IP和端口）时可以继续使用，比如发生了网络切换。
这一节描述发生地址改变的一端的处理过程。
  QUIC 的设计依赖与在握手期间保持一个固定的地址。端点不可以在握手完成之前开始连接迁移
（详见 QUIC-TLS 4.1.2）。

  如果在握手期间对端发送了传输参数 disable_active_migration，那么端点不可以通过不同的本地
地址发送包来主动开始连接迁移。发送传输参数 disable_active_migration 的一端，如果探测到对端
已经迁移到一个不同的网络，那它要么直接丢弃该路径上到来的包且不需要发送无状态的 Reset 包，
要么开始验证路径有效性从而允许对端迁移。生成一个无状态的 Reset 包或者关闭连接将会允许网络
中第三方通过伪造或者修改QUIC 流量来关闭连接。

  不是对端所有地址改变都是有意或主动的迁移。可能对端正在 NAT 重绑定：因为中间件设备导致地址
变化，此时 NAT 会分配一个新的出口端口甚至出口 IP。如果端点探测到对端地址发生了变化，那么必
须执行路径有效性验证（详见 8.2），除非它已经验证并通过了这个新地址。
  如果端点没有有效路径来发送包，那么它可以丢弃连接状态。能够连接迁移的端点在丢弃连接状态前可
以等待一个新的可用路径。
  本文将连接迁移等同于新的客户端地址（详见 9.6）。客户端负责开始所有的连接迁移。服务端不会向某
个客户端地址发送非探测包（详见 9.1），除非它从改地址收到非探测包。如果客户端收到了来自未知地
址的包，它必须丢弃这些包。

9.1. Probing a New Path

  端点可以使用一个新的本地地址来验证路径有效性，从而在迁移到该地址之前探测对端的可达性
（详见8.2）。
  路径有效性验证失败只是意味着这条新的路径对该连接不可用，因此这种失败不应导致连接结束，除非
没有其他有效的替代路径可用。

  端点可以从新的本地地址使用一个新的连接 ID 来探测对端（详见 9.5）。使用新的本地地址的一端需要
确保对端至少有一个可用的新连接 ID，这就要求它在探测的时候发送 NEW_CONNECTION_ID 帧。从对端
收到 PATH_CHALLENGE 帧意味着对端在该路径上探测可达性，端点将为每一个 PATH_CHALLENGE 帧
响应一个 PATH_RESPONSE。

  PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING 属于探测帧，其他帧
属于非探测帧。只包含探测帧的包称为探测包，否则称为非探测包。

9.2. Initiating Connection Migration

  端点通过向某个新地址发送包含非探测帧的包来迁移指该地址。
  各个端点在连接建立期间会验证对方地址的有效性，因此迁移的一端可以向它已知的对端当前地址发送数
据（译者注：连接建立完成后）。于是，端点可以迁移到一个新的地址而不需要先去验证对端的地址。
  在迁移的时候，新的路径可能不支持端点当前的发送速率，因此需要重新设置拥塞控制器（详见 9.4）。
  新路径可能不支持 ECN（Explicit Congestion Notification），因此需要验证端点支持 ECN（详见 13.4）。

  从新地址收到新路径上已发数据的确认只是对端可达性的一项必要不充分条件。确认信息可以从任何路
径接收，因此收到确认信息对端就一定可达是不成立的。为了在新路径上建立可达性，端点可以并发在
新路径上开始路径有效性验证（详见 8.2）。

9.3. Responding to Connection Migration

  从对端的新地址收到一个包含非探测帧的包意味着对端已经迁移到了改地址。为了响应这样的包，端点必
须开始将后续的包发送至该地址，同时必须开始进行路径有效性验证（详见 8.2）以确认对端拥有该新地址。

  端点可以向一个未被验证的地址发送数据，但它必须要防止潜在的攻击（详见 9.3.1、9.3.2）。如果
端点最近接触过对端的某个地址，那么可以不用验证该地址。

  端点只有在响应包号最大的非探测包时才改变用来发送包的地址，这样可以确保端点在收到乱序包时不
会向对端的一个旧地址发送包。

  在迁移到发送非探测包的地址后，端点可以放弃其他地址的路径有效性验证。

  收到来自对端新地址的包也有可能是因为对端发生了 NAT 的重绑定。

  在确认了客户端的新地址后，服务端应该向客户端发送新的地址有效令牌（详见 8.0）。

9.3.1. Peer Address Spoofing

  对端通过伪造源地址导致端点发送大量数据到一个非目标主机是可能发生的。如果端点发送远远超过伪造
的对端发送的数据量，那么连接迁移可能被攻击者用来向受害主机发起放大攻击。
  端点被要求验证对端新地址的有效性从而确保对端拥有改地址（详见 9.3）。当对端地址被认为是有效
时，端点必须限制向该地址的发送速率。端点在每个估算的 RTT 中不可以发送大小超过最小拥塞窗口
（kMinimumWindow，详见 QUIC-RECOVERY）的数据，没有这个限制的话，端点可能被用来拒绝服
务攻击。
  由于端点不会对该地址统计 RTT，因此 RTT 应该默认为初始值（详见 QUIC-RECOVERY）。
  如果端点跳过了对端地址的有效性验证（详见 9.3 ），那么它不需要限制发送速率。

9.3.2. On-Path Address Spoofing

  连接路径上的某个攻击者可以通过拷贝或转发一个携带伪造地址的包来进行假的连接迁移。伪造地址
包看起来像是来自连接迁移的包，而原始包则会被视为重复包而被丢弃。在假连接迁移后，源地址的
有效性验证会失败，因为原地址对应的实体没有相应的加密密钥来读取或者响应 PATH_CHALLENGE 帧。
   为了防止连接从这样的伪造迁移失败，端点必须在验证新地址失败后重新使用对端最后一个有效地址。
  如果端点未保留对端最后一个有效地址，那么它必须静默地关闭连接，即丢弃所有连接状态。这将使得
该连接的新包以通用的方式被处理。例如，端点可以发送一个无状态的重置包来响应新到来的包。
  注意，收到从对端合法地址发送的更高包号的包时，会触发另外的连接迁移。这会放弃伪造迁移的地址
有效性验证。

9.3.3. Off-Path Packet Forwarding

  一个可以观察包的连接路径外的攻击者可以转发真包的拷贝到对端。如果拷贝包比真包更早到达，会被
认为是 NAT 重绑定，而真包则会被认为是重复报而被丢弃，如果攻击者可以继续转发拷贝包，它可以使
用自己的这条路径进行连接迁移。这将使得攻击者处于连接路径上，从而可以观察或者丢弃所有后续的包。
  与 9.3.2 小节的攻击方式不同，上述攻击者会成功验证新路径的有效性。
  这种攻击方式要求攻击者的路径与原本的路径一样快。如果源端发送的包较少，或者正好在包丢的时候
攻击，攻击效果更好。
  从原路径收到非探测包会产生更大的已接收包包号，从而使得端点转移会该路径。在该路径上引出这样
的包会增加攻击失败的可能性。因此减轻迁移攻击需要依赖这些非探测包的交换。
  为了响应明显的连接迁移，端点必须验证之前活跃的路径上使用了 PATH_CHALLENGE 帧，这会使端
点在该路径上发送新包。如果该路径不再可用，验证会超时或失败，如果该路径可用但将不被使用，则验
证会成功，但只会使端点在该路径上发送探测包。
  在活跃路径上收到 PATH_CHALLENGE 帧的端点应该发送一个非探测包作为响应。如果非探测包早
于攻击者转发的拷贝包到达，会使得连接迁移会原来的路径。随后任何迁移到其他路径的行为将会重
复上述过程。
  这种防御方式并不完美，但不是一个严重的问题。如果攻击者使用的路径比原路径更快速，那么无法
区分是发生了攻击还是有优化的路由。
  端点可以使用启发式的方法来改善对这类攻击的探测。例如，如果最近在旧路径上收到了包，那么重绑
定是不太可能的，IPv6 的重绑定也类似。端点可以寻找重复包，相反的，连接 ID 的变化更可能意味着
是一个有意的迁移而不是攻击。

9.4. Loss Detection and Congestion Control

  新路径的可用承载量可能与旧路径的不一样。旧路径上已发送的包不应该影响新路径上拥塞控制或
者 RTT 的统计。
  在确认对端拥有新地址时，端点必须立即为新路径重置拥塞控制器和 RTT 估算器（详见 
QUIC-RECOVERY 的 A.3 和 B.3）为一个初始值，除非端点知道新路径当前的发送速率和 RTT 估计值。
   例如，如果只是客户端的端口发生了变化，端点可能推断这是一个 NAT 重绑定，即新路径可能与旧路
 径拥有相似的带宽和 RTT，当然，这种判断是不太完美的。如果判断错误，拥塞控制器和 RTT 估算器
 是需要调整以适应新路径的。通常，建议实现在新路径上需要谨慎使用以前的值。
  当端点在连接迁移阶段从多个发送数据或者探测信息时，接收端会有明显的重排序，因为两条路径可能
有不同的 RTT。接收端将会发送确认包，覆盖所有从不同路径上收到的包。
  在迁移阶段可能有多条路径被使用，但一个拥塞控制上下文和丢失恢复上下文（详见 
QUIC-RECOVERY）是足够的。例如，端点会延后切换到新的拥塞控制上下文，直到它确认旧路径不再
被需要。
  发送方可以制作特定探测包以使丢失探测可以独立执行，并且不会过度的造成拥塞控制器降低  它的发
送速率。
  端点可以在发送一个 PATH_CHALLENGE 后设置一个单独的定时器，只有在收到 PATH_RESPONSE
 时才会取消该定时器；如果还没收到 PATH_RESPONSE 就超时了，端点可以发送一个新的 
 PATH_CHALLENGE，并且为定时器设置一个更长的超时时间。 

9.5. Privacy Implications of Connection Migration

  在多个网络路径上使用同一个连接 ID 会被中间人将这些路径上的活动关联起来，端点在网络之间移
动的时候可能不希望被对端以外的实体发现这些关联性，因此在通过不同的本地地址发送数据时要使用
不同的连接 ID（详见 5.1）。为了达到该目的，端点需要保证它们提供的不同连接 ID 之间不具有关联性。
  任何时候，端点可以改变目的连接 ID 的值为一个未曾在其他路径上使用过的。

  端点在初始化连接迁移（详见 9.2）或者探测一个新的网络路径（详见 9.1）时，必须使用新的连接 ID。
  如果收到对端带了新地址的包，且这些包使用了一个对端未曾使用过的活跃连接 ID，那么端点会认为对
端的地址发生了改变，此时端点必须使用新的连接 ID 来响应。
  在不同的网络路径上的每个方向使用不同的连接 ID，可以消除使用连接 ID 来把不同网络路径上同一个连
接的包关联起来的可能性。头部保护确保了包号不会被用来关联同一个连接的活动，但这并不能防止包
的其他属性比如时间、大小等，被用来建立类似的关联。
  意外改变路径但为该表连接 ID 的情况是有可能发生的。例如，网络不活跃一段时间后，NAT 重绑定
可能导致包从一个新的路径发送，但连接 ID 并未改变。
  网络不活跃一段时间后，如果需要发送数据，客户端可能会利用一个新的连接 ID 和源 UDP 端口来减少
关联性，此时在发送数据时改变 UDP 端口能让对方认为是发生了连接迁移。这可以确保支持连接迁移的
机制被执行，即使是那些并未经历连接迁移的或者 NAT 重绑定的客户端来说。
  没有可能连接 ID 的端点不能探测新的路径或者初始化连接迁移，也不能去响应对端连接迁移的探测。为
了确保可以连接迁移，同时不会让不同路径上的包被关联，端点应该在端点连接迁移之前提供新的连接 
ID（详见 5.1.1）。如果对端没有可用的连接 ID，进行连接迁移的一端要在所有从新路径发出的包中包
含一个 NEW_CONNECTION_ID 帧。

9.6. Server’s Preferred Address

  QUIC 允许服务端在一个 IP 地址上接收连接，然后在握手后立即将这些连接转移到另外的一个首选地址；
  当客户端向多个服务端共享的地址发起连接，但希望使用单薄地址来保证连接的稳定性时，QUIC 的这
种做法是非常有用的，这一章讲述服务端如何迁移到首选地址。

  如何在连接期间迁移到一个新的服务端地址暂时留在未来的计划中。如果客户端从新的服务端地址收
到包，而这个新地址不在 preferred_address 传输参数中，那么客户端应该丢弃这些包。

9.6.1. Communicating a Preferred Address

  服务端通过在 TLS 握手中包含 preferred_address 传输参数来传递首选地址。

  服务端可以传送每个地址族（IPv4、IPv6）的一个首选地址，以允许客户端根据自己的网络附件来选择
其中一个。

  一旦握手完成，客户端应该从服务端的两个首选地址中选择一个，并使用 preferred_address 传输参数
中的连接 ID 来验证选中地址的路径有效性（详见 8.2）
  如果路径有效性验证成功，客户端应该立即使用新的连接 ID 将待发送的包全部发送到新的服务端地址，
并且不再使用旧的服务端地址；如果路径有效性验证失败，客户端必须将待发送的包发送到原来的服务
端地址（译者注：即旧的服务端地址）。

9.6.2. Responding to Connection Migration

  服务端在接收一个连接后可能在任何时间收到携带新地址的包；如果这个包包含 PATH_CHALLENGE 帧，
那么服务端需要对应的发送一个 PATH_RESPONSE（详见 8.2）。服务端必须一直从它的旧地址发送其他
的非探测帧，直到它从首选地址收到客户端的非探测包并且已经成功验证该新路径。
  服务端必须从它的首选地址去探测到客户端的路径，这可以防止攻击者发情伪造的连接迁移。
  一旦服务端验证完路径，并且从首选地址收到了一个更大包号的非探测包，那么它也要开始仅从首选地址
向客户端发送非探测包。它应该丢弃从该连接的旧地址接收到的包，但可以继续处理该地址上因为延迟的包
（译者注：也就是在收到更大包号的非探测包之前旧地址上的包因为延迟未及时到达服务端，这些包可以被
继续处理）。

9.6.3. Interaction of Client Migration and Preferred Address

  客户端在它迁移到服务端首选地址之前需要进行连接迁移，这样，客户端应该从其新的地址同时对服务
端的原始地址和首选地址进行路径有效性验证。
  如果对服务端首选地址的路径有效性验证成功，客户端必须中止原始路径的验证，并且开始使用首选地址
进行迁移。如果原始地址验证成功而首选地址失败了，客户端可以从新地址迁移，并继续向服务端的旧地址
发送数据。
  如果到首选地址的连接不是来自客户端的相同地址，服务端必须启动保护机制来防止潜在的攻击（详见 
9.3.1、9.3.2）；除了有意的同时迁移，上述情况是有可能发生的，因为客户端使用了不同的 NAT 绑定来
访问服务端的首选地址。
  一旦从一个不同的地址收到探测包，服务端应该向客户端的这个新地址发起路径有效性验证。服务端不
可以在对新地址的验证完成前向该地址发送超过最小拥塞窗口大小的非探测包。客户端在迁移到一个新
地址时，应该使用服务端熟悉的首选地址。

9.7. Use of IPv6 Flow-Label and Migration

  使用 IPv6 发送数据的端点应该应用 IPv6 标识以兼容 RFC6437，除非本地 API 不允许设置 IPv6 标识。
IPv6 标识应该是一个用源地址、目的地址、源 UDP 端口、目的 UDP 端口、以及目的连接 ID 生成的
伪随机值；
   新生成的标识必须与之前使用过的标识保持较低的关联性，因为关联性高会把多路径上的活动建立
 关联（详见 9.5）。
  标识生成的一个可能实现是使用源地址、目的地址、源 UDP 端口、目的 UDP 端口、目的连接 ID 以及
本地密钥生成的加密哈希值。