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:
> 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.
