Anti-amplification limits

[MikeBishop]

RFC 9000 requires that:

• Datagrams carrying Initial packets be expanded to 1200+ bytes
• Servers verify the client address on handshake and when the address changes through migration / rebinding
• The server can send no more than 3x the received bytes until the client's address is validated, both during the handshake and following client migration / rebinding

This draft states in the Security Considerations that "the anti-amplification limits as specified in Section 8 of [QUIC-TRANSPORT] need to be followed to limit the amplification risk." However, there's no text that describes how this maps into multipath behavior.

My proposal is that:

• The packet on a new path SHOULD be expanded to 1200+ bytes (PADDING, etc.) for the first 1 RTT or until validation completes
• When a packet is received from an unverified address, an endpoint MUST NOT send more than 3x the received bytes until address validation completes

[mirjak]

This is the same as migration and already specified in RFC9000. I think we should not specify the same thing in two document that's why we decided to add a reference to section 8 of RFC9000 instead.

[MikeBishop]

I agree that's the goal, but I don't agree that the existing pointer is detailed enough or in the right place to help implementers make the connection.

New paths aren't migration; we explicitly talk about what happens when an existing path migrates, and say that's separate from new paths being constructed. So we should clearly state that the Section 8 requirements for migration also apply to new path creation. I think it's fine for that to live in 10.2 and just be a little more explicit.

But I think we do implementers a disservice if we don't call out those requirements in context, specifically in Section 3.1:

• We already require that Path Initiation perform Address Validation by sending a PATH_CHALLENGE; RFC 9000 requires packets containing PATH_CHALLENGE to be expanded to at least 1200 bytes. Let's add a sentence highlighting that requirement and referencing Section 8.2.1 of RFC 9000. (While I think expanding more packets in that first RTT might be beneficial, I can live with not requiring anything more.)
• Similarly, highlight that upon receiving a new path from an unvalidated address, the server will need to respect the anti-amplification limits from Section 8 of RFC 9000 and point there for more details.

To be clear, I think it's perfectly reasonable not to double-specify; I'd just like us to point to RFC9000 with a reminder of existing requirements to help people find them. I'm happy to write a PR; I think this would be a fairly small change.

[huitema]

I am trying to reconcile Mike's PR with the decision to allow path creation without an explicit challenge, see PR #442. We already have text making reference to RFC 9000. My proposal is to only take the part of #430 that updates the security section.

[mirjak]

@MikeBishop we merged #442. Can you confirm that this addressed the issue (and close it)? Thanks!