[quicwg/base-drafts] Limits on PATH_CHALLENGE/RESPONSE rate (#2129)

ekr <notifications@github.com> Wed, 12 December 2018 16:39 UTC

Date: Wed, 12 Dec 2018 08:39:40 -0800
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab711c65f8b52e92036b57c3b4f04580d23bd804bb92cf000000011828fbcc92a169ce1743a996@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2129@github.com>
Subject: [quicwg/base-drafts] Limits on PATH_CHALLENGE/RESPONSE rate (#2129)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c1139ccc066a_689c3fdf18cd45c41542639"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/34Wh_00BqwrsquO9kjYf2_5EMms>

```On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.
However, because a PATH_CHALLENGE might be sent from a spoofed address, an
endpoint MUST limit the rate at which it sends PATH_RESPONSE frames and MAY
silently discard PATH_CHALLENGE frames that would cause it to respond at a
higher rate.
```

It's pretty hard to understand what the normative force of this is, given that it doesn't explain what the limit is. I think there's actually a simple rule we should propose, which is one PATH_CHALLENGE frame per packet (with others to be ignored). Given that we require duplicate suppression at the packet level, that will have an amplification factor of 1:1, which you can get by a variety of other mechanisms. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2129

[quicwg/base-drafts] Limits on PATH_CHALLENGE/RES… ekr
Re: [quicwg/base-drafts] Limits on PATH_CHALLENGE… Martin Thomson
Re: [quicwg/base-drafts] Limits on PATH_CHALLENGE… Martin Thomson