TCP Acknowledgments and Digital Certificate Verification
Understanding TCP Acknowledgments
(A) Why is acknowledgment 701 sent when the segment with sequence 801-900 is received? Because in TCP, acknowledgments are cumulative, which means that the acknowledgment number refers to the next expected byte, indicating that all previous bytes have been successfully received and are in order.
The sender sends segments with sequence numbers 501-600, 601-700, and 701-800. The segment with sequence number 701-800 is lost. The receiver successfully receives segments 501-600 and 601-700, so it sends an acknowledgment with ACK = 701, indicating that it has received up to byte 700 and is expecting byte 701 next. When the sender sends the segment with sequence number 801-900, the receiver still expects to receive segment 701-800 before it can move forward. Since the segment 701-800 has not been received, the receiver sends another acknowledgment with ACK = 701, indicating that it is still waiting for byte 701.
(B) Why is acknowledgment 901 sent when the segment with sequence 701-800 is received?
After the segment with sequence number 701-800 is retransmitted and successfully received, the receiver now has a continuous sequence of bytes from 501 to 900. The receiver sends an acknowledgment with ACK = 901, indicating that it has received up to byte 900 and is now expecting the next byte, which starts with sequence number 901. This is reflected in the figure where the segment 701-800 is resent and received successfully. The receiver updates its acknowledgment to ACK = 901, indicating that all bytes up to 900 have been received in order.
Acknowledgment 701 is sent after receiving segment 801-900 because the receiver is still waiting for the missing segment 701-800. Acknowledgment 901 is sent after the retransmission and successful reception of segment 701-800, indicating that all bytes up to 900 have been received.
Digital Certificate Verification Process
Bob Requests a Certificate: Bob applies for a certificate from a Trusted Certificate Authority (CA), which will verify Bob’s identity.
CA Issues the Certificate: After verifying Bob’s identity, the CA issues a digital certificate. This certificate includes Bob’s public key and the CA’s digital signature.
Bob Publishes the Certificate: Bob posts this certificate on his website. The certificate is now publicly accessible to anyone visiting Bob’s website.
Sue Verifies the Certificate: When Sue accesses Bob’s website, she retrieves Bob’s certificate.
Sue needs to verify the authenticity of Bob’s certificate using the following steps:
- Retrieve CA’s Public Key: Sue must have the CA’s public key, which is usually pre-installed in her browser or available from the CA’s website.
- Check CA’s Signature: Sue uses the CA’s public key to decrypt the CA’s digital signature on Bob’s certificate. If the decryption is successful and matches the certificate details, it confirms that the certificate was indeed issued by the trusted CA and has not been tampered with.
- Verify Bob’s Public Key: Once Sue confirms the certificate’s authenticity, she can trust the public key contained in Bob’s certificate.
- Establish Secure Connection: Sue can now use Bob’s public key to establish a secure communication channel (e.g., using SSL/TLS) with Bob’s server.
Explanation: When Sue wants to communicate with Bob securely, she relies on the certificate issued by the Trusted Certificate Authority. By verifying the CA’s signature on the certificate, Sue ensures that Bob’s public key is valid and that Bob is indeed who he claims to be. This process prevents man-in-the-middle attacks and ensures the integrity and confidentiality of the communication between Sue and Bob.