Subject: Re: [TLS] Draft minutes for IETF-75 available

From: Gerhard Muenz <[email-masked]>
Date: Mon, 03 Aug 2009 22:03:39 +0200

Hi,

> Draft minutes for IETF 75 are available here:
> 
> http://www.ietf.org/proceedings/75/minutes/tls.txt
> 
> Let me know if you have corrections.

Probably here:

> 3. DTLS Heartbeat - Presented by Michael Tuexen
> 
> Draft: http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt
> 
> Pasi Eronen (AD): I can see this being useful in cases, but I can also see
>       it being solved in the lower layer protocols.  EG, in IPFIX I

lower => upper ? (otherwise, it does not make sense)

>       can very much see them solving it at their layer.
> Michael Tuexen: I see your point but...
> Pasi: I can also see this useful for PMTU discovery.
> Michael: That's true but it doesn't necessarily work for bi-directional
> 	differences.  You can another message which contains extra

missing verb?

> 	stuff for doing discovery.  SCTP has opaque data for doing
> 	things like that.  I like the discovery message, but I think
> 	it should be another message.
> Eric (Jabber): this is relevant in TCP cases as well.
> 
> Question: if you use this in UDP, the draft says you must not send them
>       while you're waiting for a response.
> Michael: Only one heart-beat request in flight at a time.  I don't want
> 	to have a congestion control problem
> 
> Wes Hardaker: agree with EKR that it is useful it TCP as well,
>       though you need to document differences.  Longer discussion on
>       the rational behind it.  

Some thoughts about the proposal to solve Heartbeat at the IPFIX layer
(from me as a contributor to IPFIX):
It is extremely unlikely that we will change the IPFIX protocol from
unidirectional to bidirectional just because DTLS-over-UDP requires it.
In my opinion, if we had to choose, it would be more likely that we
would update RFC5101 saying that DTLS is not required any more for
IPFIX-over-UDP implementations, and that the usage of
IPFIX-over-DTLS/UDP is not recommended because of the dead peer
detection problem.
IPFIX cannot reasonably deploy DTLS for UDP without the proposed
Heartbeat extension. The available workarounds are not very nice.

Regards,
Gerhard

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 3 Aug 2009 13:34:18 -0700

Thanks Gerhard,

Minutes updated.   

Some questions below:

<snip> 
> Some thoughts about the proposal to solve Heartbeat at the 
> IPFIX layer (from me as a contributor to IPFIX):
> It is extremely unlikely that we will change the IPFIX 
> protocol from unidirectional to bidirectional just because 
> DTLS-over-UDP requires it.
> In my opinion, if we had to choose, it would be more likely 
> that we would update RFC5101 saying that DTLS is not required 
> any more for IPFIX-over-UDP implementations, and that the 
> usage of IPFIX-over-DTLS/UDP is not recommended because of 
> the dead peer detection problem.

[Joe] Is IPFIX defined over UDP without DTLS?  If so, would
IPFIX-over-UDP have a dead peer detection problem of its own?  

> IPFIX cannot reasonably deploy DTLS for UDP without the 
> proposed Heartbeat extension. The available workarounds are 
> not very nice.
>

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 03 Aug 2009 23:03:21 +0200

Joseph,

> IPFIX-over-UDP have a dead peer detection problem of its own?  

Thanks for you interest in this problem.

The answer is yes and no.

Yes, it is a problem because with UDP the Exporter will never know
exactly if the Collector is up and receiving IPFIX Messages. A
non-existing Collector can be detected via returned ICMP messages
(destination unreachable and the like). However, such messages are often
blocked by firewalls.

However, no, it is not such a big problem because UDP is unrealiable anyway.

The big difference between IPFIX-over-UDP and IPFIX-over-DTLS/UDP is
that you can always start or restart a UDP Collector without touching
the Exporter. If the Collector is listening on the correct UDP port, it
will receive the Templates after a while (Templates are retransmitted
periodically when UDP is used), and then, it will be able to start or
resume decoding IPFIX Messages.

With DTLS/UDP, the Exporter must initiate the DTLS renegotiation after
the Collector has restarted. This is because the Collector does not know
which Exporters actually exist (like a server which does not know its
clients in advance). So, the Exporter should somehow know when a
renegotiation is necessary. It seems that DTLS Heartbeat would nicely
solve this.

Regards,
Gerhard

---

From: <[email-masked]>
Date: Fri, 7 Aug 2009 11:18:06 +0200

Gerhard Muenz wrote:

> With DTLS/UDP, the Exporter must initiate the DTLS renegotiation
> after the Collector has restarted. This is because the Collector
> does not know which Exporters actually exist (like a server which
> does not know its clients in advance). So, the Exporter should
> somehow know when a renegotiation is necessary. It seems that DTLS
> Heartbeat would nicely solve this.

<not wearing any hats>

Thanks for the explanation! I now agree that IPFIX-over-UDP and
IPFIX-over-DTLS/UDP indeed have a crucial difference here, and 
the heartbeat extension would nicely solve this problem. 

It's also very simple extension, and might be useful for other
situations, too (it could be useful for TLS-over-TCP -- and
it would allow the DTLS library to implement Path MTU Discovery,
instead of leaving that to applications), so I support doing
this work.

Best regards,
Pasi