On Wed, Sep 16, 2015 at 03:29:40PM -0400, Dave Garrett wrote: > I'd be fine with phrasing it as: implementations MUST send all alerts > when indicated, and SHOULD make a best-effort to ensure they get > delivered to the peer.
+1. Perhaps some text explaining the difficulty in the latter and offering some implementation advice. Something like: Sending a fatal alert is easy, but ensuring that the peer gets it when running over TCP or similar can be difficult because a shutdown or close will result in the peer getting an RST if data is received from it before the alert is sent. Depending on the TCP stack, giving the alert a chance of being received may require delaying the closing of the connection by some amount of time. A "simple" way to do this is to "service" a pool of pending-close connections on a timer, or at the next new connection or insertion of a new delayed-close connection into the pool. A reasonably low implementation cost method is to have a fixed-sized pool of pending-close connections, closing the oldest connection whenever adding a new pending-close connection to a full pool. Note that any scheme that can leave pending-close connections alive possibly indefinitely will also consume the associated TCP PCB resources indefinitely. The second paragraph might be giving too much implementation advice. Nico -- _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
