W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: PR for adding RtpSender.transport, RtpReceiver.transport, RTCDtlsTransport, RTCIceTransport, etc

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 24 Jul 2015 05:05:17 -0700
Message-ID: <CAJrXDUH3Wnkm44Vqj6mYc+7B5+_z6coQe96VJozD-x5pztzFaw@mail.gmail.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC