Working group last call for draft-ietf-tls-dtls-heartbeat-02

[Joseph Salowey (jsalowey)]

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.  


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

[Nikos Mavrogiannopoulos]

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
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

[Michael Tuexen-4]

On Aug 22, 2011, at 9:08 AM, Nikos Mavrogiannopoulos wrote:

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

>
> 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?

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.
>
>
> 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.
>
>
> 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.
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...
>
> regards,
> Nikos
>
> [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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

[Nikos Mavrogiannopoulos]

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



_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

[Michael Tuexen-4]

On Aug 22, 2011, at 9:46 PM, Nikos Mavrogiannopoulos wrote:

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

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.
>
>> 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
Any suggested text?
> 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).
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...)

>
>>> 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?

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.

>
>
> 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?

No. I just wanted to make clear that you should not start a timer
or something like that. We can take out "immediately".
>
>
>> "HeartbeatRequest messages from older epochs SHOULD be discarded."
> Why HeartbeatRequest messages are treated differently? Aren't all
> 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.


>
> 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?
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
>
>
> regards,
> Nikos
>
>
>
>

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

[Joseph Salowey (jsalowey)]

Working group last call has completed and there were a few minor revisions suggested.  Authors, please submit a revised draft to be submitted to the IESG.

Thanks,

Joe
On Aug 21, 2011, at 10:07 PM, 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.  
>
>
> _______________________________________________
> TLS mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

[Michael Tuexen-4]

On Sep 27, 2011, at 12:10 AM, Joe Salowey wrote:

> Working group last call has completed and there were a few minor revisions suggested.  Authors, please submit a revised draft to be submitted to the IESG.
Done.

The changes based on comments on the list between the -02 and -03 version are:

* Grammar / spelling.
* Some general clarifications in the text.
* Clarification of the formulas regarding the padding length
* Registry policies changed from Specification Required to Expert Review
* Reference to RFC4347 replaced by draft-ietf-tls-rfc4347-bis-06

Robin has updated the patch for OpenSSL which is available at
http://sctp.fh-muenster.de/dtls-patches.html
to this latest version. While doing that one additional detail was addressed:
When using a reliable transport protocol, TLS/DTLS does not run timers.
So it does not make sense to introduce one just for this extension.
Therefore the last sentence of section 3 was changed from

 If no corresponding HeartbeatResponse message has been received after a user configured
 amount of time, the DTLS/TLS connection SHOULD be terminated.

to

 If no corresponding HeartbeatResponse message has been received after some amount of
 time, the DTLS/TLS connection MAY be terminated by the user.

In the OpenSSL implementation a function is provided to figure out if a HB is in-fight.
So the application can check if a HB-Response has been received anytime it wants
and can take the appropriate action.

Best regards
Michael

> Thanks,
>
> Joe
> On Aug 21, 2011, at 10:07 PM, 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.  
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls