Protocol Messages Packet Types

PacketTyp es: Abstract Sp eci cation of Network Proto col Messages Peter J. McCann and Satish Chandra Bell Lab oratories Packet Types: Abstract Specification of Network 263 Shuman Blvd. Protocol Messages Nap erville, IL 60566 fmccap, [email protected] Peter J. McCann and Satish Chandra Bell Laboratories 263 Shuman Blvd., Naperville, IL 60566 {mccap, chandra}@research.bell-labs.com Abstract ip_fw_chk(struct iphdr *ip) f struct tcphdr *tcp = (struct tcphdr *)((__u32 *)ip + ip->ihl); In writing networking co de, one is often faced with the task int offset = of interpreting a raw bu er according to a standardized ntohs(ip->frag_off) & IP_OFFSET; packet format. This is needed, for example, when moni- ... toring network trac for sp eci c kinds of packets, or when switch (ip->protocol) f unmarshaling an incoming packet for proto col pro cessing. case IPPROTO_TCP: In such cases, a programmer typically writes C co de that if (!offset) f understands the grammar of a packet and that also per- src_port = ntohs(tcp->source); forms any necessary byte-order and alignment adjustments. dst_port = ntohs(tcp->dst); Because of the complexity of certain proto col formats, and ... b ecause of the low-level of programming involved, writing such co de is usually a cumb ersome and error-prone pro cess. Furthermore, co de written in this style loses the domain- Figure 1: Excerpt from the rewall co de in Linux (v2.0.32). sp eci c information, viz. the packet format, in its details, making it dicult to maintain. Motivated by this problem, signi cant research e ort has re- We prop ose to use the idea of types to eliminate the need for cently b een put into systematic software architectures and writing suchlow-level co de manually. Unfortunately,typ es languages suited for constructing networking software. These in programming languages, such as C, are not well-suited e orts usually address a sp eci c asp ect of the complexityof for the purp ose of describing packet formats. Therefore, networking co de. Some approaches try to b etter express the wehave designed PacketTypes, a small packet sp eci ca- mo dular structure and comp osition of proto col layers (e.g., tion language that serves as a typ e system for packet for- x-kernel [11 ], Foxnet [6 ]). Others try to b etter express the mats. PacketTypes conveniently expresses features com- reactivecontrol within eachlayer (e.g., Esterel [5 ]). Yet oth- monly found in proto col formats, including layering of pro- ers emphasize the veri cation asp ect (e.g., Promela++ [3 ]), to cols by encapsulation, variable-sized elds, and optional or fo cus on an ob ject-oriented implementation (e.g., Mor- elds. A compiler for this language generates ecientcode pheus [1 ], Prolac [14 ]). These e orts demonstrate that an for typ e checking a packet, i.e., matching a packet against a implementation metho dology or language more suited to the typ e. In this pap er, we describ e the design, implementation, task at hand can help build cleaner and more robust im- and some uses of this language. plementations and can do so without exacting p erformance p enalties. 1 Intro duction One asp ect of the complexity of writing networking co de arises from the fact that the wire format of a network packet is xed by standards. Packet formats are indep endent of Networking software is dicult to construct. Networking any given machine's architecture to allow interop erability, co de in a system must interface with bare hardware in a net- and generally pack data as tightly as p ossible to minimize work device, and at the same time implement complicated the header overhead p er unit of actual content. Tointerpret real-time algorithms. Furthermore, b oth the low-level data a bu er containing a \raw" network packet, a programmer manipulation and the emphasis on high p erformance have must write low-level co de that understands the packet for- (barring few exceptions) limited the choice of an implemen- mat and that also p erforms any necessary byte-order and tation language to C. As a result, development, testing, and alignment adjustments as p er host requirements. We illus- deployment of new proto cols is a slow and exp ensive pro cess. trate suchlow-level co de by means of an example. Permission to make digital or hard copies of all or part of this work for Figure 1 shows an abstracted form of the rewall co de in the p ersonal or classro om use is granted without fee provided that copies Linux networking mo dule (net/ipv4). The co de rst com- are not made or distributed for pro t or commercial advantage and that copies b ear this notice and the full citation on the rst page. To putes the starting address of an IP packet's payload into the copy otherwise, or republish, to p ost on servers or to redistribute to variable tcp,by adding the size of the header ( eld ihl)to lists, requires prior sp eci c p ermission and/or a fee. the start of the packet. It then computes the o set of the SIGCOMM'00,Stockholm, Sweden. Copyright2000ACM 1-58113-224-7/00/0008...$5.00. 321 1 present IP fragment into the variable offset; the macro case (#payload ip) of ntohs converts a network byte order representation to the TCP fsource, dst, ...g => host byte order representation for a 16-bit quantity. If the if ((#offset ip) = 0) then proto col in the payload is TCP and o set is zero ( rst frag- ... ment), it extracts the source and destination p ort numbers from the TCP header. Later co de (not shown) implements sp eci c rewall p olicies based on this and other information. Figure 2: An ML-style description. The syntax #field var is eld selection from a record. The term on the left of => The style of programming involved here is not complicated, is a pattern, here matching the datatyp e TCP. but do es have some undesirable prop erties. A programmer must explicitly enco de the layout of an IP packet using pointer arithmetic and bit op erations. He must en- p ossible typ es of payload a given packet may b e asked co de the correlation between the protocol eld's value of to carry. Thus, this solution is not easily extensible. TCP and the payload b eing a TCP packet. He must IPPROTO Another problem with C unions is that one must still also remember to convert anymulti-byte numeric quantities test the discriminating eld and cho ose the interpre- between the network byte order and the host byte order at tation consistently. For example, if we representanIP 2 all appropriate places. While the TCP/IP suite do es not payload as a union of TCP and UDP typ es, wemust have a complicated packet format, other proto cols do, and still make the rightchoice based on the value of the writing co de that interprets a packet b elonging to one of protocol eld. those proto cols can require a lot of cumb ersome programming. For example, the Q.931 proto col [12 ] de nes the for- 3. Finally, b ecause of p ossible alignment and byte order mat of ISDN signaling messages as rather complex hierar- mismatches b etween a host machine and the network chical packets. A C implementation that parses a Q.931 format, applications may still need to do adjustments message can run into thousands of lines of co de, and it is b efore using a numeric value as a primitivetyp e. easytointro duce co ding errors in o sets, sizes, conditionals, or endianness. What ab out data typ es in higher-level programming languages, such as Standard ML? In Standard ML, one might The capabilitytointerpret a network packet is key to many express the logic in Figure 1 using the co de fragmentshown imp ortantnetworking applications, in addition to proto col in Figure 2. UnlikeinFigure1, the programmer do es not pro cessing. These applications include network monitoring, need to explicitly interpret the wire format. accounting, and security services. The only software architecture in the literature that addresses such applications is a There are go o d reasons why proto col co de is not written packet lter. However, lter sp eci cations essentially parse in this way. First, unmarshaling from the wire format to a packet in muchthestyle of Figure 1, and are written in the high-level data typ e could b e exp ensive, b ecause ML's byte co de (except for some higher-level expression languages representation of data typ es is not as close to machine rep- available for TCP/IP). The need for a mechanism to build resentation as that of C. Second, de ning layered packets such applications quickly and correctly,even for complicated in an extensible wayis still dicult. Although Foxnet [6] formats, has b een our primary motivation. implements TCP/IP in Standard ML, packets are exp osed as C-likebyte arrays. The co de uses low-level marshaling At rst blush, the concern for parsing a packet may not ap- and unmarshaling into SML records to access elds that are p ear to b e a problem at all|one might b e able to simply needed for proto col pro cessing. overlaya raw bu er with an appropriately de ned C struct or union, and read o the values from the elds of the struc- In this pap er we show that the idea of typ es can nevertheless ture.

Load more