Re: Erik Kline's Yes on draft-ietf-quic-transport-33: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Martin,

On Wed, Jan 06, 2021 at 02:52:40PM +1100, Martin Thomson wrote:
> Hi Erik,
> 
> Thanks for the comments.   I'll answer your questions here, since I don't think they result in document changes.  We'll take the comments to GitHub, where they can be broken down into specific actions.
> 
> On Tue, Jan 5, 2021, at 17:18, Erik Kline via Datatracker wrote:
> > [ section 8.2.4 ]
> > 
> > * To be clear, this document is effectively saying that it takes no position
> >   on the interpretation of any ICMP errors received?  Is it up to the
> >   implementer to decide if "validated" (in as much as ICMP messages can be
> >   validated) Admin Prohibited messages, for example, should constitute a
> >   positive confirmation of path failure?  Or is there some very specific
> >   stance that should be taken ("never trust that lyin' ICMP!")?
> 
> I don't think we could reach consensus on a single policy for treatment of ICMP.  As you observe, some might regard ICMP as unreliable no matter the circumstances, others might trust but verify, and others might be happy to accept the signals without validation.  Support for RFC 4884 and larger packet samples might shift attitudes.
> 
> What I can say is that many implementations are not doing anything with ICMP, other than what the OS might automatically turn into socket errors.  That means that ICMP Unreachable can still have an effect in many stacks, but PTB doesn't enjoy the same privilege (at least to my knowledge, though I guess the OS could apply write size limits on its own, I don't know that any do).
> 
> > [ section 10.3 ]
> > 
> > * Does this "datagram ends with stateless reset token" scheme mean that
> >   implementations must check the output of every packet, including post
> >   encryption, and take some action if a (very low probability) collision
> >   occurs (meaning the output accidentally produces this 16 byte value
> >   but the packet is not intended to be a stateless reset)?
> 
> In practice, the exception that follows means that you don't need to perform the check very often.  Most implementations only check when they are unable to decrypt or - more applicable to servers - unable to determine which connection is able to handle the packet.  The relevant text says:

My reading is that Erik was asking about checking when generating the
packet, but your response seems to be about checking when receiving the
packet.  (I had aa similar question but didn't ask it since, as you note
below, the odds are in our favor.)

-Ben

> > This comparison can be performed for every inbound datagram. Endpoints MAY skip this check if any packet from a datagram is successfully processed. However, the comparison MUST be performed when the first packet in an incoming datagram either cannot be associated with a connection, or cannot be decrypted.
> 
> Those that do check every datagram do run a risk of encountering a collision.  But it is tiny.
> 
> To take an extreme example, a server instance that receives ~2^62 packets for every connection (the maximum number any single connection can have, and far more than you can practically send), and you have a large number of connections (2^17 connections is a lot, but maybe plausible), and you check every inbound packet against every connection, the odds of collision are in the same ballpark as the odds that a dedicated and resourceful attacker might have to break encryption[1] at 2^-51 [2].
> 
> The Internet is big enough that this will likely happen, but I'm of the opinion that this risk is acceptable.  In any case, avoiding extra cycles has the effect of driving this probability right down.
> 
> [1] We allow 2^-57 probability.
> [2] Well, maybe a little higher, but I'm too lazy to run the birthday paradox numbers.
>