Re: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02

[Nikos Mavrogiannopoulos <[e-mail]>]

On 08/22/2011 11:46 AM, Michael Tüxen wrote:

>> I believe more rationale is needed in the draft on _why_ should 
>> these issues be solved at TLS or DTLS level. For (1), TCP has a
>> keepalive mechanism, so reintroducing it at TLS doesn't make much
>> sense, and UDP throws the burden to user protocol. So why not throw
>> the burden on the protocol above?
>> The only discussion on text is: "Sending HeartbeatRequest messages
>> allows the sender to make sure that it can reach the peer and the
>> peer is alive.  Even in case of TLS/TCP this allows this check at a
>> much higher rate than the TCP keepalive feature would allow." So is
>> this just a high-rate TCP keepalive? Why do we need that at the 
>> security layer? Why not propose a high-rate TCP keepalive?
> Regarding the keepalive feature: Our main motivation is not TCP
> keepalives. The point is that there are application protocols running
> over UDP which do not have a

Why not restrict the scope of this extension to DTLS then? (unless I'm
missing some other application of this in TLS).

> mechanism in the app protocol to do this. This is fine when running 
> over UDP since the lower layer does not have any state. However, when
> the lower layer becomes DTLS instead of UDP, there is state, and it
> is not a good idea to keep this state there forever. So having a way
> for DTLS to detect that the peer is gone, helps.

Ok, now I understand what you try to address with this extension (and it
might be better for the draft text to express it as well). However is
this the right solution for the problem? This does not make DTLS
stateless, thus it is different in operation as the previous UDP server.
Anyway you'll have to trigger the keepalive messages manually (with
input from the application layer) or after some fixed time.

Wouldn't this be equivalent (in resources and behavior) with trying
to resume the DTLS connection after a fixed amount of time?
(the handshake resumption is 3 messages, this is one message more than
the 2 keep-alive messages).

>> About (2) Both TCP and UDP don't bother with a special PMTU
>> discovery mechanism. Why should DTLS or TLS provide it? Are there
>> advantages on making a PMTU discovery at this level?
> Where else? TLS has no problem since TCP segments user messages.
> DTLS running over UDP can not rely on it. That is why DTLS should
> determine the PMTU. For doing this, it needs some messages for
> testing, preferable not app data which might et lost during the
> testing. Using the HB, you have a tool to do this without relying on
> ICMP message.

Just from curiosity how has this been implemented in a library (or how
you think of being implemented)? How did the keep-alive messages are
being exchanged without the application noticing?


Nits:
section 3:
> "it has to be answered with a corresponding HeartbeatResponse
> message
immediately."
I don't think the immediately adds to the sentence. It just adds
confusion. What if it was sending an application data packet on a
different thread? Should I stop?

> "HeartbeatRequest messages from older epochs SHOULD be discarded."
Why HeartbeatRequest messages are treated differently? Aren't all
messages with older epochs to be discarded?

5.2:
"HeartbeatRequest messages SHOULD only be sent after an idle period
that is at least multiple round trip times long."
This is more than unclear. Why not specify how many? What if I decide 2
times and another implementor discards my message because for him
multiple was > 3?


regards,
Nikos