[quicwg/base-drafts] 25361f: Address validation for connection migration

[Martin Thomson <[e-mail]>]

  Branch: refs/heads/proof-of-receipt
  Home:   https://github.com/quicwg/base-drafts
  Commit: 25361f2fa61da64d37210c18cc64c2ca1819eff0
      https://github.com/quicwg/base-drafts/commit/25361f2fa61da64d37210c18cc64c2ca1819eff0
  Author: Martin Thomson <[e-mail]>
  Date:   2017-10-16 (Mon, 16 Oct 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Address validation for connection migration

This has been much-discussed, and it's a relatively isolated change, so I did it.

This modifies PING to have an optional payload and adds a PONG frame to echo
the PING.  An empty PING generates an ACK; a PING with a payload demands a
PONG.

Generating an unguessable PING is the basis of mid-connection address
validation.  If the PING is sent on the new path, and the PONG comes back, then
the remote address is probably OK to use.

I've taken the discussion in the issue into consideration here.  There's a lot
of potential nuance to capture in terms of how an endpoint might reduce and
restore send rates, but I've done what I can to thread the gap between allowing
unbounded sending along new and untested paths and allowing connections to get
back to doing business.

It's annoying that this makes PING and PONG so disparate.  I think that we have
a re-ordering of frames in our near future to correct minor infidelities like
this.  I didn't want to do that here and pollute this PR though.

Closes #161.


  Commit: c0419697a6c7d3058db0d601a05e5bcace365bc2
      https://github.com/quicwg/base-drafts/commit/c0419697a6c7d3058db0d601a05e5bcace365bc2
  Author: Martin Thomson <[e-mail]>
  Date:   2017-10-16 (Mon, 16 Oct 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Avoid attack on address validation during connection migration

The attack here is that an attacker might duplicate a legitimate packet and
send that packet from an invalid address such that it arrives before the real
copy.  That causes the recipient to think that there was a connection
migration.  They will attempt to validate that address and this will fail.  The
connection is then closed.

The fix is to cause a migration back to the original, legitimate address.  For
this to work, you need two things:

1. when a migration happens, abandon any validation on the old address on the
   expectation that it will fail

2. when a migration happens, make sure that you try to trigger packets from the
   old address first

For the second point, I decided to mandate address validation, rather than an
ordinary PING.  The reason being that you have to retransmit the packet on that
path and I doubt that implementations will want to have two sets of special
machinery for transmiting - and retransmitting - frames on a specific path.
Maybe this is too much of a constraint on implementations, so I'd like to hear
from people about whether they would prefer a more generic requirement (send
any packet that demands acknowledgment would work, it doesn't even have to be
the same packet every time, though the usual situation will be that the packet
will be lost, so you probably don't want to send anything important).


  Commit: 0f0ca7fa49d63b11aca4b9941d86f3da0d06a4df
      https://github.com/quicwg/base-drafts/commit/0f0ca7fa49d63b11aca4b9941d86f3da0d06a4df
  Author: Martin Thomson <[e-mail]>
  Date:   2017-10-16 (Mon, 16 Oct 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  More review comments


  Commit: ef3864a594dfe7b687828c41296d7d30351e77fe
      https://github.com/quicwg/base-drafts/commit/ef3864a594dfe7b687828c41296d7d30351e77fe
  Author: Martin Thomson <[e-mail]>
  Date:   2017-10-16 (Mon, 16 Oct 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Require new PING on loss


Compare: https://github.com/quicwg/base-drafts/compare/3ba9c175da01...ef3864a594df