[Discuss] Heartbleed and UDP

[smallm at panix.com (Mike Small)]

"Edward Ned Harvey (blu)" <blu at nedharvey.com> writes:

>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
>> 
>> > It may be dumb that the spec says the payload has to be variable or
>> > even that there's a heartbeat requirement at all for the TCP case...
>> 
>> I've been wondering about the latter point as well, and I haven't yet
>> heard any explanations. (I also didn't get why the payload varied, but
>> that's a minor point.)
>> 
>> For those not aware, the heartbeat feature was added to facilitate
>> running TLS over UDP, where there is a need to exchange some data
>> periodically to keep NAT port mappings active.
>
> You guys seem to think that TCP doesn't require any kind of keepalive?
> If that is your belief, it's incorrect (at least sometimes).  While
> your endpoints might not need a keepalive on TCP, and certain (dumb)
> firewalls use static port mappings rather than randomly generated
> stateful port mappings, and therefore the dumb firewalls might not
> need a keepalive either...  There certainly are a lot of firewalls
> that maintain mapping tables of the internal sockets to external
> socket, and will not (cannot) remember those indefinitely.  So they
> will timeout inactive connections, normally within a few minutes.

I don't know, the criticism I'd read elsewhere was that it would be
better handled at a different layer, improving existing TCP keepalives
or leaving it to the application. I know next to nothing about network
programming. It just sounded unappealing at a superficial level that
there be another keepalive in TLS if TCP keepalive exists (but is too
infrequent on Linux to suit NAT routers?). OpenBSD's ripped the feature
out, so we'll see if there's fallout, at least for their uses.