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

[Michael Tüxen <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>