Re: [Syslog] Issues for dtls-udp Re: Missing dead peer detection in DTLS (Gerhard Muenz)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] Issues for dtls-udp Re: Missing dead peer detection in DTLS (Gerhard Muenz)
Hi,
> The definition of IPFIX Transport Sessions allows to distinguish the
> different sessions. In the case of UDP, the Transport Session is defined
> by the IP-5-Tuple plus the Observation Domain ID, which is a field in
> the IPFIX message header.
> In the case of DTLS/UDP, the Collector needs to maintain the DTLS state
> for each Exporter.
In the case of UDP, the application can get message through udp directly.
But for DTLS/UDP, each session maintains the DTLS state for each Exporter, and DTLS has no idea about
which session is for which exporter. Which need application maintains, like using IP-5-Tuple plus the Observation Domain ID
mapping to each session.
>
> A good question is when to remove the DTLS state because there is no
> connection termination. We remove it after a certain time without
> receiving any packets from the Exporter. However, we cannot be sure if
> the Exporter has also deleted its DTLS state :(
> This is another situation where DTLS Heartbeat extension is useful.
I share this opinion. "timeout" can also work for it.
> > There may many syslog sender send logs to one receiver, which
> brings up an issue of dtls-udp.
> > I wrote it in my proposal, in 5.3 as session demultiplexing.
> >
> > I think if the ipfix collector need support multiple exporter,
> ipfix need also support session demultiplexing,
> > but I didn't see that in your proposal, what's your consideration?
>
> You talk about draft-mentz-ipfix-dtls-recommendations-00?
> Note that this draft does not play the same role as
> draft-feng-syslog-transport-dtls-01 because IPFIX over DTLS/UDP is
> already standardized in RFC5101.
> draft-mentz-ipfix-dtls-recommendations-00 only covers DTLS specific
> implementation problems and might be considered as an update of RFC 5153
> (IPFIX Implementation Guidelines).
>
I mean that is the application need to implement when using DTLS/UDP as transport,
which is the issue of DTLS/UDP, I stated in my proposal, but I didn't see you add any comments
on it:(. That is why I asked if you have any other consideration. I asked for your valuable comments.
Thanks
Linda
> Gerhard
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.