The original protocol stack has not proceeded without both extension and damage.

1. IP's Secret Layer.
   
   1. Transport Layer Security (TLS), previously Secure Socket Layer (SSL).
   2. Many applications, such as HTTPS (secure web sites) use TLS.
   3. Not officially a layer in the protocol.
      1. Operates as sort of a subdivision of the Application Layer.
      2. Behaves like an additional layer, following the rules described above.
      3. This is a fairly clean extension of the stack.
   4. Generally provided by a library, not the O/S kernel.
   5. Increasingly used by application protocols.
   6. Encrypts the data on the line to frustrate snooping.
   7. Increases confidence that the server is identifying itself honestly via the “chain of trust”
      1. Each server has a public/private key pair (PUBx and PRIx in the diagram.)
      2. Sends a “certificate” giving its name and public key, signed using the associated private key.
      3. That certificate is accompanied by a another, which verifies the the server certificate and is signed by a “certificate authority”.
      4. Client key may be vouched for by additional signing keys, creating a chain back to a CA.
         Server Certificate

         I am www.example.com, and my public key is PUB1.

         

         Signed with PRI2.

         Signer Certificate

         I am www.signer.com, and my public key is PUB2. I confirm that PUB1 belongs to www.example.com. I am allowed to sign server certificates.

         

         Signed, PRI3.

         Authority Certificate

         I am www.ca.com, and my public key is PUB3. I confirm that PUB2 belongs to www.signer.com. I am a certificate authority (CA).

         Signed, PRI3.
      5. Upon connection, the server sends all these certificates to the client.
      6. A client (browser, etc.) contains a list of trusted CA public keys. The browser trusts PUB3 simply because it is in its list of trusted CA keys.
      7. The browser uses PUB3 to verify the CA certificate.
      8. It then uses PUB2 to verify the signer certificate.
      9. It then uses PUB1 to verify the server certificate.
      10. The client now believes the contents of the server certificate on the authority of CA, and the assumption that no one along the way has leaked or misused their private key.
2. New transport protocols.
   1. Originally, the Transport layer contained two different transport protocols, UDP and TCP, which are still the mainstays. (We'll study these later.)
   2. UDP is basically a pass-through, mostly taking each message from above, and forwarding it to the Internet layer.
   3. The IP stack is very flexible, since any number of new protocols may be added at the transport layer. Several have been standardized.
   4. No one uses the new transport protocols.
      1. Transport is usually implemented in the OS kernel.
         1. Kernels must be changed very carefully (slowly) because of their security importance.
         2. Not practical to just distribute kernel mods with optional software, for similar reasons.
      2. Some routers are specialized to the existing protocols, for optimization or security. These can't be changed en masse.
      3. Security firewalls tend to allow only what they understand, and they don't understand anything new. (And don't want to.)
      4. This is known as “Protocol Ossification.”
   5. New transport protocols wind up being implemented at the application layer.
      1. HTTP/2.0. Implements transport features in the application layer and uses TCP, usually with TLS, for transport.
         1. Provides multiple streams by packetizing them and sending over a single TCP connection.
         2. The stream is then re-divided by TCP itself.
         3. Other HTTP/2.0 features more reasonably belong in the app layer.
      2. QUIC protocol.
         1. A TCP replacement which works better with HTTP than TCP does. (TCP doesn't work efficiently with HTTP. Never has.)
         2. Does transport work at application, and sends packets through UDP.
         3. Implements multiple streams, and uses HTTP-friendly loss and flow control.
         4. Provides security similar to TLS, since TLS doesn't work over UDP.
         5. And it does speed up web pages. But it's in the wrong place.
         6. But for ossification, we could use the Stream Control Protocol (SCTP), which provides similar facilities at the transport layer.
      3. Real-time Transport Protocol (RTP), for media streams.
         1. TCP does not handle media streams very well. Lost packets must be resent, causing delay.
         2. So UDP is traditionally used, but it lacks some things.
         3. RTP at the app layer takes care of
            1. Connections like TCP.
            2. Flow control, so the sender doesn't overrun the receiver.
            3. Deals with jitter, packet loss, and reording as directed by user endpoints.
            4. Sending packets over UDP.
         4. But for ossification, we could use the Datagram Congestion Control Protocol (DCCP) at the transport layer.