Is everyone OK with the current state of the PR now? I made all the edits to address feedback that had consensus. Is there anything else? On Wed, Jun 24, 2015 at 3:01 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > > > > > > On Wed, Jun 24, 2015 at 12:27 AM, Harald Alvestrand <harald@alvestrand.no> > wrote: > > On 06/23/2015 10:38 PM, Peter Thatcher wrote: > > Does DtlsTransport really have a "disconnected"/retrying state? I guess > we could make it "disconnected" any time the underlying IceTransport is > disconnected, but that adds complexity. What value do we gain to make it > worthwhile? > > > I don't know DTLS well enough to say..... I'm sure there are states where > the ICE connection is working fine, but traffic isn't getting through > because something's wrong at the DTLS layer - it would be important to > clearly identify that we're in that state. > > > > The question is whether that's a temporary state or permanent state. If > permanent, just use the "failed" state. > > [Raju] Before a connected state is reached, a DTLS could go into > disconnected state due to Fatal Alert Messages related to certificate > issues (unknown CA, fingerprints don’t match etc.) or some other handshake > issues. Once connected state is reached, SRTP decoding issues could result > in DTLS alerts. An implementation may choose to go into disconnected state > when this happens. Other implementations may choose to ignore such Alerts > as going to disconnected state allows attacker to inject invalid pkts (with > valid RTP hdr) into an otherwise healthy stream to trigger alerts and > disrupting communication. > > https://tools.ietf.org/html/rfc5764#section-7.3.1 talks about these > alerts, but does not suggest any action to take on such alerts. > > > > BR > > Raju >
Received on Friday, 24 July 2015 12:06:26 UTC