Before detailing our methodology, we place our solution in the context of the integrity and middlebox cooperation schemes described in Sections 3.1–3.3. Table 3.2 informally evaluates the degree to which these relevant prior works meet the corresponding design ob- jectives outlined in Section 3.5. Checksums are featured in the table due to their widespread use within the current protocols. The other three items in the table were chosen as the best exemplar from each of the three groupings under which we categorized the solutions space.
Scheme In-band Minimal
overhead Symm. feedback Incrm. depl. Impr. TCP Mdl. coop. End- to-end Granu- lar Checksums Tcpcrypt Tracebox SIMPLE HICCUPS
Table 3.2: Summary of Related Work
In Table 3.2, Harvey Balls [101] are used to represent the degree to which each integrity or middlebox cooperation scheme meets each of our design criteria. A full ball, , means the scheme fully met that criterion. An empty ball, , means that the scheme failed to meet that criterion. Other levels imply partial meeting of the criterion with possible caveats. Figure 3.5 presents the same information using graphical overlays. The following lists explain our informal reasoning behind each quantification:
Checksums:
• In-band: They are carried within both TCP and IP.
• Minimal overhead: The algorithm is lightweight, and only requires extra transmis- sions when it fails to match.
• Symmetric feedback: There is no feedback mechanism.
• Incrementally deployable: They are already deployed and boxes understand them. • Improves TCP: Does not help improve TCP under the presence of disruptive packet
header modifications.
• Middlebox cooperative: Middleboxes can make any changes as long as they recom- pute the checksum.
Figure 3.5: Visual representation of properties of related work. This gure depicts the same information as Table 3.2, and is included only to provide an additional means of perspective about the solution space.
• End-to-end: Must be overwritten if any packet header modifications are made. • Granular: No granularity to individual fields.
Tcpcrypt:
• In-band: Operates fully within TCP.
• Minimal overhead: Encrypts opportunistically but uses strong cryptography and uses a large portion of the options space.
• Symmetric feedback: Communicates through TCP options, but fails to give status in certain situations.
• Incrementally deployable: Hosts that do not understand tcpcrypt just ignore the option, but ossified network architecture must allow transmission of new TCP option type.
• Improves TCP: Prevents changes, but cannot help two endpoints optimize parame- ters for a disruptive path.
nection is encrypted.
• End-to-end: Will not work on all paths because it is susceptible to having its options stripped.
• Granular: No granularity to individual header fields.
Tracebox:
• In-band: Relies heavily on ICMP messages.
• Minimal overhead: Requires successively fractional RTTs similar to traceroute. • Symmetric feedback: Host being probed does not learn any information.
• Incrementally deployable: To function, routers need to support RFC 1812-style packet quoting.
• Improves TCP: Does not give any information to the TCP stack.
• Middlebox cooperative: Middleboxes can still make any changes, but only checks one path.
• End-to-end: Cannot determine modifications made by penultimate hop. • Granular: Gives granularity when router quotes full length of headers.
SIMPLE:
• In-band: Requires SDN infrastructure along the path in question, which may span multiple providers and networks.
• Minimal overhead: Requires testing for correctness of protocol behavior. • Symmetric feedback: Information is retained by the network operator.
• Incrementally deployable: All middleboxes along a path must be upgraded in order to realize benefits.
• Improves TCP: Correctness-testing in the SIMPLE architecture would help avoid problems.
• Middlebox cooperative: Uses dynamic learning module to work with any middle- boxes.
• End-to-end: Has no effect on middleboxes outside the owner’s administrative do- main.
TCP HICCUPS:
• In-band: Tests TCP and operates completely with TCP.
• Minimal overhead: Does not use computationally expensive cryptography. • Symmetric feedback: Each endpoint receives information about the path.
• Incrementally deployable: Uses no new options or redefined field semantics that would confuse inflexible middleboxes.
• Improves TCP: Can check protocol extensions for correctness and inform TCP. • Middlebox cooperative: Permits middleboxes to continue normal and expected op-
eration, but now endpoint TCP are informed of any packet header changes.
• End-to-end: Works on paths that do not modify two of: IPID, ISN, and TCP receive window. Detects any changes that happen anywhere along the path.
• Granular: Uses coverage sets to learn individual field modifications.
In the context of these existing and proposed integrity and middlebox cooperation schemes, we endeavor to demonstrate in the following chapters that our design meets our design criteria and represents a unique point in the design space.
CHAPTER 4:
Methods for transmitting integrity
Strive not to be a success, but rather to be of value.
Albert Einstein
In order to endow endpoints with the power to detect in-path modifications to their traffic, we must first address the fundamental design decision of how to communicate an integrity check of the packet header fields and any related status information. This chapter exam- ines various methods for transmitting integrity information and analyzes the implications involved with using each method. After targeting in-band TCP for our integrity transmis- sions, we examine issues and precedent for using various TCP header fields.
4.1
Integrity Properties
To implement an integrity check over the TCP and IP packet headers, based integrity check, the two systems communicating in a TCP session need to transmit to each other a represen- tation of the packet header states as each side sees them. To achieve symmetric notification, they must then be able to compare the state representation as they see it upon receipt with the representation seen by the sender. A primary issue will be to find which fields can be used to carry the integrity check.