When a local stream is removed, shouldn't the remote peer emitting "removestream" be enough to handle the removal?
Or is renegotiation purely a formality to ensure an identical representation of the changed SDP on both peers?
Related
I was researching on QUIC protocol and my professor asked me this question. QUIC is said to be built on UDP and uses TLS packets. TLS itself requires reliable connection that is TCP. So, why QUIC is not said to be built on TCP?
PS: Please correct me if my concepts are wrong and if possible, please explain in deep how QUIC packets work.
QUIC is said to be built on UDP and uses TLS packets.
QUIC (RFC 9000) does not use TLS "packets".
Technically, TLS uses the term "record" to indicate a block of bytes that defines how the protocol is framed. A record specifies the TLS protocol version, the length of the record, etc.
Inside TLS frames there are one or more TLS messages that specify cryptographic information or commands.
The TLS records are transported by TCP.
What QUIC does instead is to reuse some of the TLS messages, but nothing of the TLS record layer.
For example, in TCP the first bytes sent by a client are typically a TLS record that wraps the ClientHello message.
In QUIC, instead, the first bytes are a QUIC Initial packet, that wraps a CRYPTO frame, that wraps the ClientHello message, and all of these bytes must fit into a UDP datagram (they typically do, and the Initial packet even carries a PADDING frame to make the initial bytes at least 1200).
Refer to RFC 9001 for more details about how TLS is used in QUIC.
More broadly about QUIC, it is based on UDP but borrows many TCP features (retransmissions, flow control, etc.) that basically make it an alternative to TCP in the sense that it is a reliable network protocol, with additional security (encryption) features built-in, borrowed by TLS.
TCP is clear-text and relies on TLS layered on top to provide encryption.
QUIC is a mix of TCP features and TLS features (there is no clear-text QUIC), without layering.
When you say "Why QUIC is not said to be built on TCP?", I say "QUIC is not built on TCP, it is built on UDP. However, QUIC borrows TCP features that make QUIC provide similar functionalities as TCP, in particular reliability and flow control, that are not provided by UDP".
For example, in Jetty we have implemented HTTP/1.1 and HTTP/2 (that are TCP-based protocols) on top of QUIC, using a single, persistent, QUIC stream.
This shows that QUIC can be indeed a replacement for TCP, as it can carry protocols that were designed for TCP.
QUIC includes TLS in it to allow it to be used over UDP in the same way as TCP works.
Why bother reinventing TCP and not just use TCP? Well TCP is kind of “stuck” as it’s slow to roll out new changes that fundamentally change how TCP works. Enhancing it to allow new features like multiplex streams will take a loooong time to roll out everywhere TCP is supported.
QUIC is built over simple UDP packets and everything else is handled at either end by QUIC and all the routers and networks in the middle don’t need to know about these new QUIC features.
The RFCs are all written by committee, and the structure and language is often confusing, so it is easy to mix things up.
A full TLS implementation requires a reliable transport, which as of today is provided by TCP and SCTP (RFC3436).
QUIC (RFC9001) doesn't actually require a full TLS implementation though, and instead simply re-uses parts of the TLSv1.3 standard:
4.1. Interface to TLS
As shown in Figure 4, the interface from QUIC to TLS consists of four
primary functions:
* Sending and receiving handshake messages
* Processing stored transport and application state from a resumed
session and determining if it is valid to generate or accept 0-RTT
data
* Rekeying (both transmit and receive)
* Updating handshake state
So, given the above, the actual process that QUIC takes to encrypting the packet data isn't TLS at all, but is instead provided by QUIC.
I have started to look into WebRTC a bit and I am using it to build a simple peer to peer chat application using the data channel. I have the following questions:
Do I need to establish a RTCPeerConnection to each peer I want to talk to? So if there are three peers they each need 2 RTCPeerConnections (unless I use one of the peers as a sort of ad-hoc server).
If peer A sends out a candidate and sdp when creating a offer to peer B. Can peer B connect to peer A using that info and send its answer (with candidate and its sdp) over the RTCPeerConnection, i.e. using the RTCPeerConnection (before it's been completely established) as a signaling channel? I would assume that when the offer is created by peer A it starts to listen for connections on some port.
My understanding of WebRTC is a bit limited so if I've missunderstood some concept of WebRTC in my questions above please point them out!
Yes, as a direct P2P protocol everybody must be directly connected to everybody else if they want to communicate; unless you create some kind of mesh network in which one peer forwards messages to other peers.
No, the SDP offer and answer and ICE candidates all need to be exchanged through a signalling server; the connection cannot be established until both peers have actually agreed on a specific session configuration and ICE route to use, so you cannot send the SDP answer over a connection which isn't complete yet.
Especially for a simple text-only chat, going through a server is often easier than using P2P; the processing and bandwidth requirements are so minimal that the complications of P2P connections are probably not worth it. And you need a signalling server anyway. P2P only becomes really interesting once you start sending large files or audio/video streams.
In principle it is possible to establish a WebRTC connection without a signalling server, but that requires an out of band exchange of session tokens between the peers. I.e. the user would have to copy a token from the application, somehow send it to another user and the other user would have to paste it.
Additionally those tokens cannot be reused, so this procedure would have to be repeated every time peers want to establish a connection.
So while theoretically possible webrtc is not distributed in practical terms.
There is some noise about specifying support for incoming connections and reusable peer contacts, but the progress on that is unclear.
I saw that SCTP is going to be used for Data Channels starting in Chrome 31, and officially RTP based channels are going to be deprecated sometimes in February 2014 according to this google group thread:
https://groups.google.com/forum/#!topic/discuss-webrtc/y2A97iCByTU
Does this also mean that webrtc audio and video channels are also going to be transported over SCTP eventually(if not already in the works)?
How does RTP fit in the whole SCTP transport effort? Does that mean SRTP packets will flow over SCTP data channel? Or perhaps just the payload will be sent over SCTP transport protocol.
If I am reading info on SCTP, it combines best of TCP and UDP protocols; but it does not include encryption by default; so in mind the traffic flowing over should still be encrypted.
Any additional info would be helpful. Thanks!
The audio and video will keep going over RTP (actually SRTP which is the secure version or RTP) but the data channel will uses SCTP over DTLS over UDP. Both Firefox and Chrome are implementing this and you can find it described in the IETF draft specifications. For some types of NAT / Firewall traversal, the UDP packets may get tunneled in TURN over TCP.
Glad to provide you pointers to the draft specifications if that helps.
SCTP stands for Stream Control Transmission Protocol.
SCTP as a protocol can be seen as a hybrid of UDP and TCP.
At its core, SCTP holds the following characteristics:
Connection oriented. Similar to TCP, SCTP is connection oriented. It also offers a multi-homing capability that isn’t used by WebRTC
Optional reliability. Reliability is optional in SCTP and is up to the implementer using SCTP to decide if he needs this capability or not
Optional ordering. Ordering of packets sent via SCTP is optional and is left for the implementer to decide if this is necessary for him or not
Message oriented. SCTP makes sure that each message sent is properly parsed on the receiver end in the same manner in which it was sent
Flow control. Similar to TCP, SCTP provides a flow control mechanism that makes sure the network doesn’t get congested
SCTP is not implemented by all operating systems. In such cases, an application level implementation of SCTP will usually be used.
SCTP is used in WebRTC for the implementation and delivery of the Data Channel.
Google is experimenting with the QUIC protocol as a future replacement to SCTP
This is a question which I believe the RFC is silent about: https://www.rfc-editor.org/rfc/rfc5246
When an SSL connection is established, and application messages being exchanged between client and server, if at a pt of time a renegotiation is triggered, what should happen to those application messages that are sent while both ends are still negotiating.. ?
Are they discarded ?
Do they cause renegotiation to fail ?
Thanks !
They are not discarded and they do not cause renegotiation to fail. They are encrypted using the existing session key until the ChangeCipherSpec message has been sent, after which they are encrypted with the new key. That applies in each direction separately. The implication is that they can be interleaved with the handshake messages, although whether any of the existing APIs can actually provide a way to do that is another question.
What is the functional difference between TLS and DTLS?
How does application flow/negotiation differ while using TLS vs DTLS?
Basically DTLS is to construct TLS over datagram (UDP, DCCP, etc.)
DTLS is similar to TLS intentionally except that DTLS has to solve two problems: packet lost and reordering. DTLS implements
packet retransmission
assigning sequence number within the handshake
replay detection.
See RFC 6347 for details.
The idea is that DTLS is to TLS as UDP is to TCP, as much as possible.
See https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ which will likely obsolete RFC 6347 for details on the specification, as well as links to discussions thereof.
There are key differences between DTLS and the Transport Layer Security (TLS) protocol that the application programmer needs to be aware of that other answers miss/imply do not exist!
The DTLS protocol provides communications privacy for datagram protocols. Contrary to the extant top-rated answers as of this writing(archive), DTLS is not an implementation (or "construct") of TLS over UDP (or datagram protocols in general), and, replay detection is a required feature of TLS, but optional in DTLS. DTLS includes an implementation of a very TLS-like handshake, modified to work over datagram protocols. The implementation does handle the problems of packet reordering and loss, but only for the packets used for the DTLS handshake (and cipher selection). In other words, the "flights" that these packets deliver are delivered reliably. However, the DTLS packets containing payload (application data) may deliver their payload no more reliably than the DTLS packets (typically UDP) that encapsulate them.
Furthermore, while the DTLS protocol (v1.2) is derived from the TLS protocol (v1.2) and claims to "provide equivalent security guarantees", it does not.2 Back in 2013, researchers identified major security shortcomings in both DTLS implementations and in the DTLS protocol itself, that have since been rectified, at least in GnuTLS and OpenSSL implementations.2 In addition, DTLS does not guarantee non-replayability.
Finally, the OP asks how application flows differ while using TLS vs DTLS. TLS is intended to deliver a stream of data reliably and with authenticated encryption, end-to-end. DTLS is intended for the delivery of application data that is authenticated and encrypted end-to-end, but with lower latency than can be achieved when all application data delivery is guaranteed. This is why DTLS is used to secure streaming applications where losses are less important than latency, e.g. VoIP, live video feeds and MMO gaming.
PS: DTLS 1.3 is done/will probably have been published as an RFC by the time you read this.3
PPS: Oh, and if this was worth reading, don't miss RFC 7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)". I'm surprised DTLS 1.3 (the final draft anyway) doesn't refer to it (such as from its Security Considerations section) (Suggested) and neither does the TLS 1.3 spec!
DTLS is an implementation of TLS over UDP (a datagram protocol). per wikipedia, TLS uses TCP, and DTLS uses UDP, so all the classic differences apply. UDP communications exist as streams of packets with no ordering, delivery reliability, or flow control. applications that use datagram protocols need to make sure they can handle these concerns internally.
https://en.wikipedia.org/wiki/Transport_Layer_Security#Applications_and_adoption
http://www.diffen.com/difference/TCP_vs_UDP
One difference is that, due to being over UDP, stream ciphers are not allowed:
4.1.2.2. Null or Standard Stream Cipher
The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL
cipher.
The only stream cipher described in TLS 1.2 is RC4, which cannot be
randomly accessed. RC4 MUST NOT be used with DTLS.