What are the 4 parts of a packet?

Exercises

Packet structures and Medium Access Control:

The International Organization for Contention’s (IOC) STAR (Slothful-Tag-And-Reader) Protocol requires that the tag transmit fifty ‘0’ bits and a twelve-symbol preamble prior to sending its 96-bit identification code. A parity check bit is embedded after each 8-bit byte of the ID code. The ID code is followed by a 16-bit CRC. What percentage of the tag message is devoted to formatting and error checking instead of sending data?

___________ %

The IOC is organized into working groups. Working group RPD-1 (Rate Performance Disparagement) has tabled a proposal for providing tags with the option of replying with only the preamble, ID, and CRC, also eliminating the parity check digits. The working group is now stuck, since the British members believe that tabling refers to bringing a measure up for consideration, whereas the American members understand the term to mean that the proposal has been abandoned, the European members are on vacation for 36 weeks, and the Asian members are too busy making products to attend the meetings. Let’s help them out. If the reader command causing a tag to reply with its ID requires 48 bits and is transmitted at half the rate of the tag reply, and a four-reader-bit gap is specified between reader command and tag reply and prior to another command, how much can throughput be improved by the tabled proposal?

___________ %

Is this improvement worth calling the European members back from the Mediterranean beaches?

YES ___________ NO ___________

It’s winter, they’re in the Alps ___________

To the consternation of visually-impaired2 Committee Chair Toulouse Track, all the 124 voting members have shown up at the meeting to vote on whether “tabling” should be interpreted according to the British, American, or Icelandic conventions3. Dr. Track decides to allocate the right to speak based on a slotted Aloha approach. He will ask each participant to choose a random number between 1 and 100 and write it down on the tablet of paper next to their glass of ice water. He will then flip a coin to decide whether to count up from 0 or down from 100, and call out numbers in the resulting sequence for each participant to speak. Each member will then have 1 minute to state their case favoring or opposing the resolution. If no one speaks for10 seconds after a number is called, Dr. Track will go on to the next number. In the event that two or more members have chosen the same number, they will all speak simultaneously. Dr. Track will record that a collision occurred, draft a memo regretting the fact to be delivered to the IOC Intellectual Property Manager, Pat N. Pending, and go on to the next slot.

What is the likelihood that there will be no collisions?

100%___________ 10% ___________ 5% ___________ 0% ___________

If there are ten 2-person collisions, three 3-person collisions, and one each with eleven people (the number ‘1’) and nine people (the number ‘100’), how long does it take for Dr. Track to get through all the allocated slots, assuming a 5-second inter-slot gap for Dr. Track to call out the next number?

___________ minutes

Would it have been more efficient to hold the meeting underwater using American Sign Language, or would that choice have a prejudicial impact on the result of deliberations?

YES ___________ PROBABLY ___________ WHAT? ___________

First-Generation Standards:

In Singapore, unlicensed RFID operation is allowed in the band 923–925 MHz. Is it possible to choose a 500-kHz channel in this band for reader transmission to ensure that Class 0 tag signals are also in the band?

YES ___________ NO ___________

A Class 0 reader using a symbol time of 25 microseconds and ID2 to singulate tags is counting tags with 128-bit IDs. How long does it take for the reader to receive a complete tag ID and error check?

___________ microseconds

A Class 0 reader monitors a conveyor. Tagged boxes on the conveyor are within the read zone for 1 second; on average, boxes are spaced apart by 3 meters and move at 1 meter per second. The reader continuously reads at full speed as in problem 4 above, simply discarding reads whose CRC and ID do not agree, and stopping every 100 milliseconds to issue a RESET and calibration sequence for new-entering tags. If the reader 24 hours per day, and assuming no actual metaphysical intervention, how many ghost tags will it detect in a week?

___________ tags

A Class 1 reader monitors the same conveyor, in Global Scroll mode. To save time, no mask bits are used in the reader command. Production worker Amon Breick carelessly leaves an extra tag on the table close to the reader antenna, so that this tag replies to every ScrollAllID command and its backscatter signal is much larger than that of tags on the conveyor. How many conveyor tags will be read under these conditions?

___________ %

To avoid catastrophic failure when Amon is not on break, the reader software is modified to issue a Quiet command to each tag that is successfully read, so that another tag can participate. If the reader issues a Quiet command, with the 96-bit ID of the tag included in the mask, each time it successfully reads a tag, and the remainder of the command (other than the mask bits) takes 1 millisecond to send, what is the impact on the peak read rate? Assume the reader transmits at 60 kbps.

______ reads per second with Quiet vs. ______ reads per second without

Gen 2 Protocol:

How big does a memory bank have to be before an EBV requires a second byte?

___________ words

Here is the baseband signal a Gen 2 tag receives. The top shows a closeup of the preamble; the bottom shows the complete command except for the CRC-5 error check bits.

Based on this packet signal:

What is Tari?

___________ microseconds

What is the average reader data rate, assuming an equal mix of 1’s and 0’s?

___________ bits per second

What command is being sent?

___________

What session flag does the command apply to?

___________ (0 to 3)

What tag backscatter link frequency should be used to respond (estimates are ok)? What is the tag-to-reader data rate?

BLF:___________ kHzdata rate: ___________ bits per second

If this is your reader, and you know that between 1 and 3 tags are in the field of view of the reader at any given time, what is wrong with the parameters of this command?

Active Tags:

If you were a sensing device, would you want to associate with a PAN named Bluetooth? Is Zigbee any better? Shouldn’t the IEEE get real about these names?

YES ___________

NO, WHY? ____________

WHICH QUESTION AM I ANSWERING? ____________

Assume a Wi-Fi device sends a packet with 1000 bits in it at 2 Mbps. The radio transmitter produces 10 mW of RF power and is 30% efficient: that is, the RF output is 0.3 (DC power in).

How much energy does the transmitter use to actually send the signal?

_______________________________ mJ

If a 3.7-V AA battery can provide 2000 mA-h, how many packets can be sent before the battery is exhausted, if the above were the only energy needed for operating the node?

___________________________________ packets

At one packet per minute, how many years is that?

_____________________________________ years

Review the discussion of an active tag in chapter 5 (Figure 5.32 and text). How does the energy usage above compare to the values cited there? What can we conclude about the actual energy used in data transmission as a fraction of the total energy used by the device?

3.3.1 Packet Structure

The basic packet structure supported over the wireless link is an extension of the IPbus packet format, shown in Fig. 6. The minimum overhead added by the wireless link is the single-byte pad alias, which is an address equivalent. Optionally, sequence number, packet length, and CRC fields may also be added. The inclusion of sequence numbers is a Pad-specific configuration parameter. The other optional fields are type-specific, giving a very fine granularity on how the link protocols treat particular classes of data, supporting our goal of providing lightweight, type-specific communications protocols.

2.3.2 RTP Packet Format

Table I shows the RTP packet structure. The first 12 bytes are mandatory in every RTP packet, and the following optional part (e.g., the list of contributing source (CSRC) identifiers) is present only when inserted by a mixer. Some important fields are as follows:

Table I. RTP Header Format

Version (V): 2 bits. This field identifies the version of RTP. The version defined by RFC 3550 is two (2).

Payload type (PT): 7 bits. The PT field identifies the format of the RTP payload.

Sequence number: 16 bits. The sequence number increases by one for each RTP data packet sent. The sequence number allows the receiver to detect packet loss and restore the original packet sequence even if the RTP packets are received out-of-order.

Timestamp: 32 bits. The timestamp is the sampling instant of the first byte in the RTP data packet.

SSRC: 32 bits. The SSRC field identifies the synchronization source, which is chosen randomly such that no two synchronization sources within the same RTP session will have the same SSRC identifier.

Figure 4 shows an example of RTP packet.

4.2.1.6 Packet structure and time on air

Fig. 4–4 shows the packet structure used by LoRa. LoRa offers a maximum packet size of 256 bytes. More details on the LoRa packet structure can be found in [5]. For the purpose of this chapter, the main part of interest is the preamble that is a sequence of constant upchirps, two downchirps, and a quarter of upchirp.

The receiver uses the preamble to start synchronizing with the transmitter. The LoRa packet ToA can be defined as:

(4.13)Tair=Tpreamble+Tpayload

where Tpreamble is the preamble duration and Tpayload is the payload duration that also includes optional header and cyclic redundancy check (CRC) fields. Without going into the details of exact ToA computation, which can be found in [5], one can say that SF and BW have direct influence on the ToA of the LoRa packet, as these parameters typically define the symbol rate: higher SF increases ToA, while higher BW decreases ToA at the cost of lower receiver’s sensibility.

FLAG

In the original definition of the packet structure in RFC951 (September 1985), this field was labeled as unused, and was reserved for future enhancements. By the time that RFC 1542 (October 1993) was written, the working group was struggling with the problem of returning boot replies to a requesting client. Since the client would not know his IP address until AFTER receiving the packet, it was often necessary to broadcast the reply back to the client. With this in mind, RFC 1542 renamed this field and specified that the highest-order bit would be set by the client to indicate that a BROADCAST reply was required. The rest of the bits were reserved for future use, with a default setting of zero if unused.

Examining ARP Packet Structure

Using our knowledge of protocol analyzers, we examine the structure of an ARP packet. Open Ethereal and begin a pcap using the Filter string arp. If you’re using Windows, open a command-line prompt and issue the command ARP –d. Ping www.yahoo.com. This will allow you to manually delete the entries in your ARP cache and then force your system to ARP the local gateway to resolve the IP address needed to forward the ping to www.yahoo.com. ARP is a two-step process. First, there is the ARP request, which is sent to a broadcast address and then the ARP reply. This reply is sent back the initial requestor as a Unicast. Once you have collected an ARP packet, you’ll see something similar to the ARP request shown in Figure 3.10.

The first 2 bytes of the ARP data within the Ethernet flame identify the hardware type (in this case, Ethernet is represented by 0x0001). The next 2 bytes denote the address protocol ARP is attempting to resolve. In this case, we see an attempt to resolve an IP address that is denoted by 0x0800.

The next 2 bytes denote the length of a hardware address and a protocol address, respectively. MAC addresses have a length of 6 bytes and IP addresses have a length of 4 bytes.

Next is the Operation byte. This field is 0x01 for an ARP lookup request, and 0x02 for an ARP lookup reply. In this case, we are looking at an ARP request packet. Following the operation byte, we have 6 bytes denoting the Sending Hardware Address (SAP) (the sender’s MAC address). Following this, we have the Sending Protocol Address (the sender’s IP address).

Next is the meat of our request; 6 bytes all set to 0, indicating that we want to know what MAC address belongs to the following 4 bytes. Those final 4 bytes of the ARP packet indicate the IP address that we want to resolve to a MAC. The ARP reply is shown in Figure 3.11.

Note in the reply that the target hardware and protocol addresses and the sender hardware and protocol addresses have traded positions in the analogous packet structure. Also note that the formerly null value for the target hardware address has been replaced with the requested MAC address.

Tip

In addition to the preceding command, there are other useful commands for maintaining your ARP cache. By using the command arp –s < ip address > < MAC address >, you can permanently add an entry to the ARP cache. Add the string pub to the end of the command and your system will act as an ARP server, answering ARP requests even for IPs that aren’t yours. Finally, to view the full contents of your ARP cache, execute arp –a.

When ARP replies are received, they are added to the local host’s ARP cache. On most systems, ARP cache entries will time-out within a relatively short period of time (2 minutes on a Windows host) if no data is received from that host. Additionally, regardless of how much data is received, all entries will time-out after approximately 10 minutes on a Windows host.

The flowbits Option

The flowbits option was implemented to allow users to track state information across multiple packets within a single session. The state information is passed by adding a reference to a bitfield from the flow tracker into the packet structure. This is one of the extensions to the packet structure mentioned earlier in this chapter. The flowbits option works by assigning each unique state name a numerical index into the bitfield. Then each rule is allowed to set the value of the bit, read the value of the bit, or toggle the bit. In order for flowbits rules to function, the flow preprocessor must also be enabled.

The flowbits option is similar in spirit to the old activate/dynamic rules, but it is considerably more powerful because it allows for alerting in the secondary rules instead of only logging. However, where the dynamic rule would match against any packet that matched its rule header, flowbits-activated rules match only against other packets in the flow. Additionally, the first rule in the flowbits rule group does not have to alert on the packet where the activate rules always generated an alert. flowbits are tracked independently across each session in a data segment managed by the flow preprocessor. For TCP and UDP, each session is identified by the source IP, the destination IP, the IP itself, the source port, and the destination port. For other protocols, only the source IP, destination IP, and IP itself are used. Using the flowbits option it is possible to implement a simple protocol state machine using a handful of Snort rules. You can find the implementation of the flowbits option in src/detection-plugins/sp_flowbits.c.

Internet Protocol Packet Format

We will now consider the internals of the protocol and discuss its packet format and fields. IP uses 14 separate fields in the packet format. The fields fall into two basic categories. Header management fields handle the packet structure, version, data length, and protection of IP header. Packet flow fields, such as Type of Service, Fragmentation, and Time to Live, handle end-to-end delivery of packets. The fields of the IP packet shown in Fig. e73.3 are:

Version: 4 bits. the version of IP used

Header length: This 4-bit field defines the total length of the datagram header in 4-byte words. The length of the header is 20–60 bytes. With no Options, the header length is 20 bytes long

Differentiated Service (DS): 8 bits. This field was previously known as service type. Specifies how the upper-layer protocol wants the current datagram to be handled

Total length: 16 bits. The IP datagram length in bytes, including the IP header. Length of data = total length − header length

Identification: 16 bits. Contains an integer that identifies the current datagram

Flags: 3 bits. Consists of a 3-bit field, the first bit of which is reserved. The second bit set to 1 means that the datagram must not be fragmented, and if it cannot pass through any network, an ICMP error message is generated and the datagram is discarded. If the second bit is set to 0, the datagram may be fragmented. The third bit set to 1 means that there are more fragments to follow. If the value of the third bit is set to 0, it means that this is the last or only fragment.

Fragment offset: 13 bits. Indicates the position of the fragment's data relative to the beginning of the data in the original datagram. It is the offset of the data in the original datagram measured in units of 8 bytes. Fig. e73.4, Fragmentation Example, shows a datagram with data size of 4000 bytes fragmented into three fragments. The bytes in the original datagram are numbered 0–3999. The first fragment carries bytes 0–1399. The offset for this datagram is 0/8 = 0. The second fragment carries bytes 1400–2799; the offset value for this fragment is 1400/8 = 175. The third fragment carries bytes 2800–3999. The offset value for this fragment is 2800/8 = 350.

Protocol: 8 bits. The upper-layer protocol that is the source or destination of the data

Header Checksum: 16 bits. Calculated over the IP header to verify header's correctness. It does not calculate the checksum over any of the data because that is covered by the Layer 2 CRC

Source IP address: 32 bits. The IP address of the sending host

Destination IP address: 32 bits. The IP address of the receiving host

Options

Data: IP datagrams can be sent with several options enabled. They are rarely used because most routers and firewalls do not allow them

Fig. e73.5, IPv4 Captured Packet, displays the contents of an IP packet. The fields we discussed are all displayed in the lower-left panel under the IPv4 header. The header length is 20 bytes; thus there are no IP options. The data field is therefore 48 − 20 = 20 bytes long. The flags indicate not to fragment the datagram.

Snort Components

When discussing the internals of Snort, Figure 4.1 often helps to clarify the components at work and offers a high-level view of the Snort process.

The following are the four main components of Snort and the Snort process:

Packet capture/decoder engine First, traffic is acquired from the network link via the libpcap library. Packets are passed through the decode engine that first fills out the packet structure for the link-level protocols, which are then further decoded for higher-level protocols such as TCP and UDP ports.

Preprocessor plug-ins Packets are then sent through a set of preprocessors. Packets are examined and manipulated before being handed to the detection engine. Each preprocessor checks to see if this packet is something it should look at, alert on, or modify.

Detection engine Packets are then sent through the detection engine. The detection engine checks each packet against the various options listed in the Snort rules files by performing single, simple tests on an aspect or field of the packet. The detection plug-ins provide additional detection functions on the packets. Each of the keyword options in the rule is linked to a detection plug-in that can perform additional tests.

Output plug-ins Snort then outputs the alerts from the detection engine, preprocessors or the decode engine.

Capturing Network Traffic

Snort needs a way to capture network traffic, and does so through two mechanisms:

▪

Setting the network card into promiscuous mode.

▪

Then grabbing the packets from the network card using the libpcap library.

We discuss promiscuous mode and the libpcap library later in the “Packet Sniffing” section. For now, let's take quick refresher on the OSI model and the TCP/IP protocol suite. It's important, as we will be referencing them both throughout this chapter.

The OSI and TCP/IP Models

The Open Systems Interconnection (OSI) model was originally designed to be a standard for developing network communication protocol suites. By strictly adhering to the OSI model, different network vendors could write code that would interoperate with other competing network vendors. Unfortunately, the network industry didn't fully comply with the OSI model, and the TCP/IP protocol suite was no exception.

The most powerful part of the OSI model is the “layering” concept. Each layer consists of a number of components, separated into seven layers. Each layer is responsible for a particular part of the communication process. During communication, the layers receive data formatted by the layers above, manipulate the data, and then send it down to the layer below. When receiving data, the layers receive the data from the layer below, unpack the data, and then pass it up one level.

The layering concept has the following advantages:

▪

Major code rewrites of a protocol are not necessary if a particular component needs to be changed. For example, if you want to change the IP component at Layer 3, it won't affect the other layers.

▪

It allows for the breakdown of complex network processes into more manageable sublayers.

▪

Industry-standard interfaces provide interoperability between different vendors. A vendor can write a piece of code for the network layer, for example, and other vendors can then use it seamlessly.

▪

Layering allows for easier troubleshooting, because the protocols are separated into layers. When troubleshooting, you don't have to tackle the complete protocol, only the layer with the problem.

In this chapter, we also talk about Snort decoding, and significant actions at the different layers of the OSI model. Figure 4.2 shows where Snort's activities lie in the OSI model.

Figure 4.2. The OSI Model and Snort

OINK!

The OSI model provides a useful method of describing how a protocol suite such as TCP/IP works. When learning about a new protocol or protocol suite, you will tend to refer back to the OSI model, as it helps us understand where a protocol fits in and what other protocols interoperate with it.

TCP/IP

Originally a governmentally funded research project, TCP/IP has grown to be the most popular protocol suite in the world. TCP/IP is a combination of suites of different protocols at different layers of the OSI model, as you will see later in the chapter. While Snort can decode other protocols, it is primarily focused on the TCP/IP suite. The TCP/IP suite doesn't exactly following the OSI model, and in some cases differs depending on the operating system. Therefore, using the OSI model as a blueprint, Figure 4.3 illustrates the TCP/IP protocol suite.

Figure 4.3. The TCP/IP Model and Snort

The five layers of TCP/IP are as follows:

▪

Application layer For example, Web-based HTTP protocol, e-mail SMTP-based protocol

▪

Transport layer For example, TCP and UDP

▪

Network layer For example, ICMP and IP

▪

Data Link layer For example, Ethernet, Token Ring, and ARP

▪

Physical layer For example, a network card or modem

OINK!

Further information on TCP/IP and OSI model can be found in the book TCP/IP Illustrated Volume 1 by W. Richard Stevens. Originally published in 1994, it is still relevant today and is an excellent resource on TCP/IP, one of our favorites.

Packet Sniffing

Snort needs a mechanism to get the traffic as it passes along the network. Figure 4.4 shows a sample design network, which we will be using as a reference throughout the chapter.

Figure 4.4. Sample Network

Taking as an example a user on the desktop machine pc-1 (IP address: 10.1.1.1), the user opens his Web browser and types http://10.1.1.220, which starts a connection to the Linux server. Within the TCP/IP stack of pc-1, the request travels down the five layers of the TCP/IP model, encapsulating along the way. When the request reaches Layer 3 (network layer), the desktop machine requires a mechanism to discover the hardware address of the Linux machine's network card (this is called the Media Access Control, or MAC, address). It does so using the Address Resolution Protocol (ARP). The desktop machine sends out an ARP request for the machine with the IP address 10.1.1.220, and the Linux machine will answer with its MAC address.

OINK!

A MAC address is in the format 00:10:A4:A2:09:88, and is a unique address burned into every network card. We can see the MAC address of our network card by running the command ifconfig -a in Linux, and ipconfig /all on Windows 2000.

Once the pc-1 machine has the MAC address of the Linux server (00:10:A4:A2:09:88), it will encapsulate the traffic into an Ethernet frame (Layer 2) and send the packet to the Linux machine. When the Linux server receives the packet, it will decode the packet through the different layers of the TCP/IP model. The Linux server will re-encapsulate its response back down the layers of the TCP/IP model, and the packets will travel back to the desktop machine.

While the desktop machine pc-1 is communicating with the Linux server, the traffic is seen by all of the network cards connected to the hub. Each network card then examines the destination MAC address of the Ethernet frame (00:10:A4:A2:09:88), sees if it matches against its MAC address, and ignores it if it doesn't.

OINK!

In Figure 4.4, all of the machines are connected using a hub. Hubs are a broadcast medium, where all of the traffic is broadcast out to each of the ports on the hub. In a switched environment, the switch will learn which ports have which MAC address, and will only send the traffic destined for those MAC address to the particular ports. Even if the Snort machine is in promiscuous mode, it still won't see all the traffic because the switch will not pass the traffic to it. Modern switches have a mechanism to mirror or span the traffic, which involves making a copy of the traffic and sending it to a special port. By plugging our Snort server into this port, we will be able to see all of the network traffic that travels across the switch.

A Network Card in Promiscuous Mode

The default behavior of a network card is to ignore traffic that is not destined for its particular MAC address. We need to change this behavior so that it doesn't check the destination MAC address. By placing the network card in promiscuous mode, we have a mechanism for seeing all of the traffic as it's placed on the hub.

Referring back to our previous example, the Snort server has a network card in promiscuous mode. When the packet from the desktop machine pc-1 to the Linux server (or for that matter, any packet on the network) is seen by our machine running Snort, the network card will make that packet available at the data link layer (refer to Figure 4.3 for the position of Layer 2 of the TCP/IP model). Snort then needs a mechanism to get packets from the network card at the data link layer and into its packet decoder. Snort does this using the libpcap library.

What Is the libpcap Library?

The libpcap library was written as part of a larger program called TCPDump. The libpcap library allowed developers to write code to receive link-layer packets (Layer 2 in the OSI model) on different flavors of UNIX operating systems without having to worry about the idiosyncrasy of different operating systems’ network cards and drivers. Essentially, the libpcap library grabs packets directly from the network cards, which allowed developers to write programs to decode, display, or log the packets. The TCPDump program did just that. A cross-platform sniffer, originally written by Van Jacobson, Craig Leres, and Steven McCanne at Lawrence Berkeley Labs to analyze TCP performance problems, TCPDump allowed you to capture packets and then decode and display them. One day, frustrated with the limitations and output formats of TCPDump, Marty Roesch wrote Snort as a replacement to TCPDump. The original version of Snort did not have preprocessors or fancy plug-ins; it was simply a better TCPDump.

Pieces of TCPDump have been borrowed by Snort. The following is the header of an early version of Snort's source code:

/*

* Program: Snort

* Purpose: Check out the README file for info on what you can do with Snort.

*

* Author: Martin Roesch ([email protected])

*

* Comments:

* Ideas and code stolen liberally from Mike Borella's IP Grab program. Check out his stuff at http://www.borella.net. I also have ripped some

* util functions from TCPdump, plus Mike's prog is derived from it as well.

* All hail TCPdump.…

/*

How Does Snort Link into libpcap?

Looking inside the snort.c source code, when Snort starts up it checks a number of settings and configurations. It calls the libpcap library, which, among other things, checks the interface and puts it into promiscuous mode. When Snort calls the libpcap functions and initializes the interfaces, it enters what is called the primary execution loop, or pcap_loop.

In this endless loop, the pcap function waits until it has received packets from the network card device driver, and then calls the ProcessPacket() function. The ProcessPacket() function links into Data-Link layer decode routine decode.c. More information on this topic can be found in the section Decoding Packets later in this chapter.

So, why use libpcap? libpcap is a cross-platform library that works on all major UNIX systems and Windows, so there's no need to reinvent the wheel for decoding and packet capture. Writing your own sniffer is straightforward, and information on libpcap and writing libpcap code can be found at www.tcpdump.org/pcap.htm.

Snort is only one of many programs that use the libpcap library and components of TCPDump; a full list is at www.tcpdump.org/related.html. One of our personal favorites (besides Snort, of course) is Ethereal (www.ethereal.com). Ethereal is an excellent GUI-based open-source packet sniffer with a massive decode plug-in set that can decode over 335 different network protocols. It also reads pcap formatted log files, so looking through large outputs from Snort or TCPDump is easy.

The original TCPDump and libpcap versions were UNIX only. However, a research and development group in Italy have put together a Windows version of libpcap called winpcap, which can be found at http://netgroup-serv.polito.it/winpcap. Like the UNIX libpcap, winpcap is used by a number of Windows-based sniffer programs, including Snort and Ethereal. Versions of these programs can be found on the accompanying CD-ROM in the Chapter 3 and Chapter 5 directories, respectively.

OINK!

Snort requires that the libpcap or WinPcap libraries be installed before Snort is installed; the libpcap libraries are a separate entity to Snort. For more information on this topic, please refer to Chapter 3 “Installing Snort.”

11.6.3 Intelligent Medical Computers

In the intelligent and integrated medical facilities, numerous MPUs and knowledge banks are linked via a high-speed backbone network as depicted in Figure 11.5. Isolated packets of information arrive at the knowledge banks from numerous medical centers and hospitals. Optimal protocol design and packet structure for medical functions need to be evolved for this type of medical environment, even though the existing TCP/IP will suffice. The addressing of the distant knowledge banks is done via a subject matter identifier allocated to the distant knowledge banks. Content and address map of the entire network are housed in specialized medical service “control point” that facilitates4 the high-speed backbone network to quickly access the information for real-time or emergency conditions.

This identifier of the knowledge bank is consistent with the information stored in that particular bank, thus reducing the switching time to these massive information stores. In such systems, the instruction to the knowledge bank is followed by a burst of input data via the packet switching network. The maintenance of the MDBs (Figure 11.5) is provided by expert teams who update and track any innovations/changes in the profession. These specialized services are provided by the team of knowledge maintenance systems specialists (see KMS-1 and KMS-2 in Figure 11.5). Maintenance and authenticating the medical knowledge become the responsibility of the KMS staff and IT specialists in intelligent medical network (IMS). Patient and physician databases are monitored and they remain behind firewalls for data, network, and patient security. Access to outside medical service providers (MSPs) may be provided by a specialized secure vendor services network or by a secure Internet transactions. Such secure transaction is now carried by banking and financial networks. Much like the designs of MANs and WANs, IMNs can be tailored to suit the need of any medical profession, any specialty, and any community to serve patients and doctors, anywhere and anytime.

Every subprocedure is executed via an individual packet command (like the SS7, X.25 packet commands in the backbone network embedded in the intelligent networks). The net result of the procedure is conveyed to the users (or their application programs, APs) by a series of packet transactions. Such transactions between a single intelligent medical system and multiple knowledge banks are systematically processed, and the output is accumulated from subprocedures, procedures, and runs. The entire usage of the network-based intelligent medical systems is as orderly and systematic as job processing in distributed computer environments. Debugging of this type of intelligent medical systems function becomes easy as the study of packet contents of any given procedure.