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

From: Joe Salowey <[email-masked]>
Date: Sun, 21 Aug 2011 22:07:58 -0700

This announcement is for the working group last call of  draft-ietf-tls-dtls-heartbeat-02.  Please send comments to the list by September 09, 2011.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 22 Aug 2011 09:08:19 +0200

On 08/22/2011 07:07 AM, Joe Salowey wrote:
> This announcement is for the working group last call of 
> draft-ietf-tls-dtls-heartbeat-02.  Please send comments to the list 
> by September 09, 2011.

As I understand the draft this extension is 2 things:
1. A keepalive ping for TLS and DTLS
2. PMTU discovery mechanism for DTLS

My unanswered comments on a previous post [0] still stand.
I expand below.

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?

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?

Note that I am not opposing to the idea of providing those, if there is
a good reason, but I don't see that now.

regards,
Nikos

[0]. http://www.ietf.org/mail-archive/web/tls/current/msg07580.html

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 22 Aug 2011 11:46:17 +0200

> 1. A keepalive ping for TLS and DTLS
Correct.
> 2. PMTU discovery mechanism for DTLS
Incorrect. It provides a test message mechanism which can be
used for path MTU discovery as described in
http://tools.ietf.org/html/rfc4821
> 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
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.
> 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.
> a good reason, but I don't see that now.
I don't know how you can do
* path MTU discovery for DTLS/UDP with having some messages like the HB messages.
* how to detect your peer is gone in case of DTLS/UDP where the
  app protocol provides no mechanism (which is fine for UDP, since there is no state). 
  If I remember correctly, IPFIX is an example for this.
When having this, it makes sense to provide this also for TLS, since you can
use it to tune your liveliness check without relying on the transport stack being
changed. This might also help for keeping NAT state around...
> [0]. http://www.ietf.org/mail-archive/web/tls/current/msg07580.html
As said above: the main difference is that UDP does not need any
state (assuming you use non-connected UDP sockets), DTLS does.

Best regards
Michael
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 22 Aug 2011 21:46:12 +0200

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

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

> 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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 23 Aug 2011 11:42:02 +0200

> missing some other application of this in TLS).
The original ID was only limited to DTLS. But it turns out that
you need nothing specific for TLS. Therefore it was suggested
to make it also available on TLS.
So you can check if your peer is there without relying on TCP keep alive.
Or refresh the NAT state. Up to the app writer.
> might be better for the draft text to express it as well). However is
Any suggested text?
> the 2 keep-alive messages).
This was used by the IPFix guys as a workaround. Just sending a
message which gets reflected is much simpler.
It might also be a problem sending data while doing session resumption.
(the node issuing the session resumption might not be the data sender...)

> being exchanged without the application noticing?
The application can call a function which sends a HB. If there is a
response, the app will not get anything. If there is no response,
the app will et notified that the DTLS session is gone...
We have a patch for OpenSSL available at
http://sctp.fh-muenster.de/dtls-patches.html
The retransmissions are handled by the DTLS implementation.
> different thread? Should I stop?
No. I just wanted to make clear that you should not start a timer
or something like that. We can take out "immediately".
> messages with older epochs to be discarded?
No. 
http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-06
contains:

   Note that because DTLS records may be reordered, a record from epoch
   1 may be received after epoch 2 has begun. In general,
   implementations SHOULD discard packets from earlier epochs, but if
   packet loss causes noticeable problems MAY choose to retain keying
   material from previous epochs for up to the default MSL specified for
   TCP [TCP] to allow for packet reordering. (Note: the intention here
   is that implementors use the current guidance from the IETF for MSL,
   not that they attempt to interrogate the MSL the system TCP stack is
   using.)  Until the handshake has completed, implementations MUST
   accept packets from the old epoch.

> times and another implementor discards my message because for him
That text was suggested by the TSV directorate...
It is up to the application writer what he wants to do. The longer
he waits, the longer it takes to detect that the peer is gone.
For congestion control the only thing which is important is that
you do send a not more than one HB per RTT. This is enforced by
the implementation with not having more than one outstanding HB.

Best regards
Michael