At a hotel, the IP header protocol field on a captured packet says TCP, but a later analyst labels that same packet UDP after noticing the application is a VPN. What corrects the label?
Select an answer to reveal the explanation.
Short Explanation
The shipping label already names the carrier, and the logo on the box does not rewrite it. You read the IP protocol field, and on this packet that field says TCP. The trap is letting the VPN name, the port, or the MAC address overrule that field.
Full Explanation
The IP header protocol field states which transport this packet carries, and the analyst must classify the packet from that field. This capture already says TCP, so calling it UDP because the application is a VPN ignores the header in hand. The IP protocol field on this packet already identifies TCP, and the VPN application name does not replace that field. One candidate treats a product label as a header rewrite: The VPN product name replaces the protocol value carried in the IP header of this packet outright. A VPN can ride more than one transport, and that does not change the field on this packet. Another candidate confuses two header fields: The destination port replaces the protocol value carried in the IP header of this packet outright. The port names an application on a transport and does not overwrite the protocol field. A third candidate uses a link-layer address as the protocol: The source MAC address is the protocol value that should be read on this packet by the analyst. The MAC address is not the IP protocol field. On the exam, do not assume a VPN is UDP or TCP from the product name; use the protocol field on the packet you have. In operations, record the IP protocol value beside the application note so a later reader does not relabel the flow.