To deliver a message to the correct application on a host which of the following addresses is used

SMTP

The simple mail transfer protocol (SMTP) is defined in RFC 821, and is used for simple e-mail transmission; SMTP can only be used to transmit mail. A different protocol, post office protocol 3 (POP3) is required for more advanced operations such as receiving, deleting, enumerating and managing mail items. Most ISPs provide both SMTP and POP3 hosting services on their dial-up lines.

In order to use e-mail with an ISP, a client must have an e-mail account with the ISP arranged. During a dial-up session, the PPP protocol is used to authenticate the client (by sending its password and user number), and for the server to allocate an IP number to the client, which is valid for the duration of the session. Once the IP connection to the ISP is established, the client opens a TCP connection on port 25, the nominal port allocated to SMTP. Once the TCP link on this port is established, all subsequent two-way communication on the line is via standard NVT-ASCII characters.

Operation follows the standard client–server model, where the client originates a response from the server. Requests are made in the form of SMTP Commands. All commands follow a simple character format structure known as the 822-header format (after the RFC standard that defines it, RFC 822). This format uses standard NVT-ASCII characters delimited by normal carriage return – line feed character pair sequences <CR-LF>. This ‘standard’ text header format is also used in various other Internet application layer protocols. An SMTP transaction is straightforward, and easily implemented on a small micro. The general sequence of operations is as follows:

The caller establishes a TCP connection on port 25 with the host (the caller itself may use for response any port it wishes). The host (ISP) may reply with a welcome text message as follows (note the first three digit number or response code):

220 Sat, 28 Jan 2002 MYISP.COM Mail server. Welcome

2.

The client logs onto the SMTP server by sending the following text string:

HELO myname <CR><LF>

Note the single ‘L’ in ‘HELO’ This is followed by your registered e-mail ‘id’, followed by a single carriage return – line feed pair. Some hosts will require just the id, some others will want your full e-mail address, and some others may just accept the HELO string without a senders address at all, that is:

HELO <CR><LF>

3. The client now needs to wait for a reply. The reply from the server will also be in ASCII form and typically will contain the following message:

250 post – welcome [email protected]

The three-digit number is a unique reply code. The text following it contains the corresponding plain text explanation for human consumption. Client software only needs to check the three digits against a list (full details in the RFC). Code 250 for example is a general OK response. This indicates that the server has accepted the command and that the client can proceed to the next stage. Simple client end software could just respond to 250 codes and ignore the rest, aborting the session otherwise. In any case, the client must wait for a reply before proceeding to the next stage. Not waiting for a response from the server may cause it to ignore the rest of the commands.

4.

On receipt of the correct error code, the client can now send the e-mail message envelope (which contains the sender and recipient addresses). The information in this envelope is required by the server in order to route the message to the final recipient. A typical envelope transaction is as follows:

Note that the server acknowledges every line sent individually (returned lines are shown here indented for clarity). The client must wait for every reply before proceeding to the next command. Multiple RCPT TO headers have been used here to show how the same e-mail can be sent to more than one recipient in one session. In a real message, at least one recipient address is required. Note how the server checks every address entry as it arrives, and notifies the sender whether it can or cannot recognise the destination. Many other envelope commands are available, please refer to the RFC for more information. The last line of the envelope contains the command DATA on its own. This tells the server that any text following this command will be the body of the text message.

5.

The client can now send the text of the message. It is common practice to add a message header at the beginning of the message body. Message headers are used by receivers and browsers to classify message received and for displaying to remote users. They are not strictly necessary, and they do not need to be present for a message to reach its destination.

The FROM command is followed by the common name and the e-mail address of the sender. They could be anything you like; they are only used for display purposes as the host will simply pass them on without processing. The second header command TO, takes the common name and the e-mail address of the recipient. Again, this information is used by the recipient's browser or e-mail manager, and not processed by the mail system. The SUBJECT line can be used to carry optional header information, which may be of use to a recipient browsing through a long list of incoming mail messages. Information on headers can be very confusing and misleading as every computer in the chain may append its own piece of text to the header. This is done so that a recipient can track the sequence of events back to the sender. Unfortunately, misleading information can be added to headers by spammers to confuse the recipient as to who the original sender was. The body text follows the headers next. It is common practice to send text in plain 7-bit ASCII. It is also possible to encode sections of text in different character formats by using MIME type encoding. This allows the inclusion of characters in non-standard character sets, special punctuation marks and special symbols. Computer or graphics files can also be sent as attachments, where text or binary files are converted using compression and other encoding algorithms into character sets compatible with NVI-ASCII, without including characters that may upset transmission. RFC 1522 specifies one way of sending non-ASCII characters in RFC 822 message headers. The main use of this is to allow additional characters in the sender and receiver names, and in the subject lines. With this method, encoded characters are sent as multiple-character encoded sequences, for example, the sequence =?ISO-8859-1?Q?Andr=E9? = results in the text André (note the addition of an accent in the last letter). The text after the first question mark ISO-8859-1 specifies one of many character sets to be used (valid values are ‘us-ascii’ and ‘iso-8859-X’ where X is a single digit, as in ISO-8859-1), Q denotes ‘quoted printable’ that is, characters are sent as the combination of the character ‘=’ followed by two hexadecimal digits corresponding to the wanted character position in the relevant table. For example, the character é (accented e), corresponding to the 8-bit character 0xE9, is sent as the sequence ‘=E9’ Spaces can be sent as an underscore or the three character sequence ‘=20’. The British pound currency sign is sent as ‘=A3’ An alternative to Q is B, which means base-64 encoding. In base-64 encoding, three consecutive bytes of original text (24 bits) are encoded as four 6-bit values. The 6-bit values are mapped to a standard ASCII table of numbers and upper/lower case letters. In this way, text and data composed of 8-bit characters can be sent as a limited character set.

Multipurpose Internet mail extensions (MIME) encoding is covered in RFC 1521. This applies mainly to the body of the text (as opposed to the headers). The purpose of MIME is to add extensions, in the form of command lines, to the body of a mail message to add some form of structure to it. In practice, MIME just adds some new RFC-822 style headers to the text, telling the recipient the structure of the body to follow. RFC-1522 encoding is normally applied to ensure the body is transmitted using plain ASCII (NVT ASCII) characters in case some of the original material contains 8-bit data (i.e. binary files or images). A typical set of MIME headers are:

More information on character and graphic encoding can be found in the respective RFCs. The last item of body text must have a full stop (period) character in a line of its own. That is, the termination sequence <CR><LF><.><CR><LF> notifies the server that the message text is completed and message transmission is over.

6.

The client now waits for the host to send an acknowledge message. The reply will usually contain a unique message number

250 submitted and queued (msg.12345678)

7.

The client can now close the e-mail session, close the TCP connection, or attempt to send another e-mail message if needed. The client does this by sending the QUIT command on a line of its own:

Tables 8-3 and 8-4 give a list of SMTP commands and reply codes, respectively.

Table 8-3. List of SMTP commands

Table 8-4. SMTP reply codes (please refer to RFC 821 for complete definitions)

Summary

Many application-layer protocols contain a variety of security issues due to the complexity and lack of security in their design. Some of these protocols (e.g., FTP and DNS) have been around for decades, and therefore have few security capabilities; however, they are still widely used on the Internet. Application-layer software, which is frequently exposed to network traffic from untrusted sources, is another common source of security vulnerabilities. To protect against these threats, it is necessary to utilize secure protocols, secure software, and secure configurations. Tools such as Nessus should be periodically run against systems to ensure that they do not contain any security issues.

Domain name system

Many application layer protocols require that users identify specific end systems. For example, to access Web documents using HTTP (see later), a user needs to specify the Web server from which a document needs to be retrieved. As discussed in Chapter 7, each network interface contains its own global interface address (unless it is shared using a NAT system). Thus, a user could provide the IP address of the server' network interface. However, memorizing IP addresses is difficult for humans. Instead, “domain names” are used to refer to networks (i.e., sets of IP addresses with matching prefix) and specific interfaces within them. Domain names typically use more intuitive names and thus are easier to remember (e.g., www.google.com or www.umass.edu). The Domain Name System (DNS) is an application layer system that provides mapping between domain names and the associated IP addresses. DNS is described in detail elsewhere [123, 124]. DNS is widely used in the Internet, as practically all Web addresses and email addresses contain domain names.

Domain names are structured hierarchically with each domain name belonging to a top-level domain (e.g., “.edu” for educational institutions or “.de” for Germany). Continuing from the top-level domain, domain names replicate some of the hierarchical structure of IP prefix assignments. Domain names are structured by zones (e.g., “umass.edu” for the University of Massachusetts Amherst). Domain name zones can have subzones that manage part of the name space (e.g., ecs.umass.edu is a subzone of umass.edu). Within each zone or subzone a name server (“authoritative name server”) maintains the local mapping between IP addresses and names. The IP address of the name server is known to the next higher zone as well as all hosts within the zone.

To retrieve a DNS mapping for an application on an end system, the end-system DNS resolver (typically part of the operating system) initiates communication with name servers. Because the resolver does not know the address of the name server that maintains the IP addresses for the domain name in question, a step-wise process is necessary. The domain name can be resolved iteratively by parsing the domain name in reverse order and querying the corresponding name server. First, the top-level domain name server needs to be queried. To determine the IP address of the top-level domain name server, one of the root name servers is contacted. The root domain name server provides the IP address of the top-level domain name server, which is contacted next. The top-level domain name server provides the address of the name server of the next level domain. The resolver queries that name server and continues this process until it reaches the authoritative name server that manages the IP address of the domain name in question, where the IP address of the domain name can be retrieved.

To make the query process more efficient and to avoid an overload on name servers high up in the hierarchy, name servers can cache mappings. If a query for a mapping is received that can be answered from information in the cache, the name server responds with this information and no further queries are necessary. To implement this caching process effectively, the resolver typically does not directly contact the top-level domain server, etc., but has its local name server do it. Thus, the local name server can learn the DNS mapping and provide a cached response to repeat queries on the same domain name. (The end-system resolver also maintains a local cache to reduce DNS traffic.) Figure 9-1 illustrates the iterative query process when a domain cannot be resolved locally. It is also possible to use recursive queries, where a queried name server automatically sends more specific queries to other name servers before responding (not shown).

The DNS queries are sent as UDP packets, as a query can typically fit into a single packet. Also, the lossy operation of UDP has limited impact on DNS. If a query or response is lost, retransmission can be triggered by the application (or the resolver). The benefit of UDP is that no transport layer connection needs to be established and thus less delay is incurred. Numerous additions have been implemented for DNS, including security extensions (e.g., DNSSEC) and extensions to support email (e.g., Mail Exchanger record).

The DNS system plays a critical role in operation of the Internet. Without DNS, many application layer applications fail, as applications and users do not know the IP addresses of the systems they need to communicate with. Therefore, there is much concern about the protection of top-level name servers from denial of service attacks (see Chapter 10). Also, there is ongoing debate on which national or international organization should manage (and thus have control over) this critical component of Internet infrastructure.

Transport Layer Security

The last Application layer protocol that we’ll discuss troubleshooting is TLS. As we’ve already discussed, TLS is used to add a layer of encryption to a number of other Application layer protocols and requires that a secure communications channel be able to be established. Due to the complex nature of public-key encryption, it is sometimes difficult to establish this secure connection and some troubleshooting may be necessary to help identify where in the connection process the problem lies.

Corporate Memo…

We’ve already discussed how TLS works and how a working communications session is established. To troubleshoot this process, you need to gain access to the TLS layer directly rather than relying on any other Application layer protocol routing through it. One of the best methods for doing this is to use the OpenSSL tool to create a TLS session without involving the other Application layer protocols. OpenSSL is an open-source tool that is frequently utilized by applications to provide encryption services on their behalf. While some enterprise applications build in their own TLS services, others rely on external providers like OpenSSL.

To create a basic one-way TLS connection to a remote web server, you can use the following command with OpenSSL: openssl s_client -connect www.google.com:443. The results of this are shown in Figure 2.14. When this is run, OpenSSL will create a secure connection to TCP port 443 on the server www.google.com. You will then be left with an open channel where you can run other tests such as the manual HTTP test demonstrated previously.

You may notice in Figure 2.14 that there is a verification error early in the establishment of the secure communications channel. The text associated with this error is “verify error:num=20:unable to get local issuer certificate.” This error means that we didn’t specify a particular list of CAs for OpenSSL to trust. You can use the OpenSSL command “-CApath” to specify the path to a location for CA certificates that you wish for OpenSSL to trust.

Another useful trick with OpenSSL is to have it display the validity dates and other information associated with the server-side certificate. This is actually included in the response we received in Figure 2.14, but we can’t read it because it’s in the encoded certificate. We can use the following command to force OpenSSL to route any incoming data including the certificate through its x509 certificate translator: openssl s_client -connect www.google.com:443 | openssl x509 -text. Figure 2.15 shows the resulting certificate information displayed after using this altered command.

If you need to test two-way TLS communications, you can use the “-cert” option to specify a local client X.509 certificate. Keep in mind, however, that this will only be used if the server is set to use client certificates for client authentication. In addition, if you’d like to see all of the TLS connection process in a nice summarized format, you can use the following command: openssl s_client -state -nbio -connect www.google.com:443 | grep "^SSL". This should give you the summary shown in Figure 2.16.

In most cases, issues with TLS can be found using OpenSSL to troubleshoot a direct connection to the remote system. A very common problem with TLS is invalid certificates caused by the certificate being expired, issued by an untrusted CA, or a mismatch between the server configuration used to present the certificate versus that used to generate it. Another very common issue has to do with the certificate chain. Each host certificate tends to be signed by an intermediate server that, in turn, has its own certificate signed by either a primary CA or another intermediate server. If the client does not trust each intermediate server in this chain, then validation of the certificate path will fail. This generally means that you have to have a copy of each intermediate server’s certificate in your trusted certificate store.

II.C. Application Layer

SIP

SIP is an application layer protocol that bears a certain resemblance to HTTP, being based on a similar request/response model. However, it is designed with rather different sorts of applications in mind and thus provides quite different capabilities than HTTP. The capabilities provided by SIP can be grouped into five categories:

User location—Determining the correct device with which to communicate to reach a particular user

User availability—Determining if the user is willing or able to take part in a particular communication session

User capabilities—Determining such items as the choice of media and coding scheme to use

Session setup—Establishing session parameters such as port numbers to be used by the communicating parties

Session management—A range of functions including transferring sessions (e.g., to implement “call forwarding”) and modifying session parameters

Most of these functions are easy enough to understand, but the issue of location bears some further discussion. One important difference between SIP and, say, HTTP, is that SIP is primarily used for human-to-human communication. Thus, it is important to be able to locate individual users, not just machines. And, unlike email, it's not good enough just to locate a server that the user will be checking on at some later date and dump the message there—we need to know where the user is right now if we want to be able to communicate with him in real time. This is further complicated by the fact that a user might choose to communicate using a range of different devices, such as using his desktop PC when he's in the office and using a handheld device when traveling. Multiple devices might be active at the same time and might have widely different capabilities (e.g., an alphanumeric pager and a PC-based video “phone”). Ideally, it should be possible for other users to be able to locate and communicate with the appropriate device at any time. Furthermore, the user must be able to have control over when, where, and from whom he receives calls.

To enable a user to exercise the appropriate level of control over his calls, SIP introduces the notion of a proxy. A SIP proxy can be thought of as a point of contact for a user to which initial requests for communication with him are sent. Proxies also perform functions on behalf of callers. We can see how proxies work best through an example.

Consider the two users in Figure 9.8. The first thing to notice is that each user has a name in the format [email protected], very much like an email address. When user Bruce wants to initiate a session with Larry, he sends his initial SIP message to the local proxy for his domain, cisco.com. Among other things, this initial message contains a SIP URI —these are a form of uniform resource identifier which look like this:

SIP:[email protected]

A SIP URI provides complete identification of a user, but (unlike a URL) does not provide his location, since that may change over time. We will see shortly how the location of a user can be determined.

Upon receiving the initial message from Bruce, the cisco.com proxy looks at the SIP URI and deduces that this message should be sent to the princeton.edu proxy. For now, we assume that the princeton.edu proxy has access to some database that enables it to obtain a mapping from the name [email protected] to the IP address of one or more devices at which Larry currently wishes to receive messages. The proxy can therefore forward the message on to Larry's chosen device(s). Sending the message to more than one device is called forking and may be done either in parallel or in series (e.g., send it to his mobile phone if he doesn't answer the phone at his desk).

The initial message from Bruce to Larry is likely to be a SIP invite message, which looks something like the following:

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP bsd-pc.cisco.com;branch=z9hG4bK433yte4

To: Larry <sip:[email protected]>

From: Bruce <sip:[email protected]>;tag=55123

Call-ID: [email protected]

CSeq: 271828 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

The first line identifies the type of function to be performed (invite); the resource on which to perform it, the called party (sip:[email protected]); and the protocol version (2.0). The subsequent header lines probably look somewhat familiar because of their resemblance to the header lines in an email message. SIP defines a large number of header fields, only some of which we describe here. Note that the Via: header in this example identifies the device from which this message originated. The Content-Type: and Content-Length: headers describe the contents of the message following the header, just as in a MIME-encoded email message. In this case, the content is an SDP message. That message would describe such things as the type of media (audio, video, etc.) that Bruce would like to exchange with Larry and other properties of the session such as codec types that he supports. Note that the Content-Type: field in SIP provides the capability to use any protocol for this purpose, although SDP is the most common.

Returning to the example, when the invite message arrives at the cisco.com proxy, not only does the proxy forward the message on toward princeton.edu, but it also responds to the sender of the invite. Just as in HTTP, all responses have a response code, and the organization of codes is similar to that for HTTP, as shown in Table 9.2. In Figure 9.9 we can see a sequence of SIP messages and responses.

The first response message in this figure is the provisional response 100 trying, which indicates that the message was received without error by the caller's proxy. Once the invite is delivered to Larry's phone, it alerts Larry and responds with a 180 ringing message. The arrival of this message at Bruce's computer is a sign that it can generate a “ringtone.” Assuming Larry is willing and able to communicate with Bruce, he could pick up his phone, causing the message 200 OK to be sent. Bruce's computer responds with an ACK, and media (e.g., an RTP-encapsulated audio stream) can now begin to flow between the two parties. Note that at this point the parties know each others’ addresses, so the ACK can be sent directly, bypassing the proxies. The proxies are now no longer involved in the call. Note that the media will therefore typically take a different path through the network than the original signalling messages. Furthermore, even if one or both of the proxies were to crash at this point, the call could continue on normally. Finally, when one party wishes to end the session, it sends a BYE message, which elicits a 200 OK response under normal circumstances.

There are a few details that we have glossed over. One is the negotiation of session characteristics. Perhaps Bruce would have liked to communicate using both audio and video but Larry's phone only supports audio. Thus, Larry's phone would send an SDP message in its 200 OK describing the properties of the session that will be acceptable to Larry and the device, considering the options that were proposed in Bruce's invite. In this way, mutually acceptable session parameters are agreed to before the media flow starts.

The other big issue we have glossed over is that of locating the correct device for Larry. First, Bruce's computer had to send its invite to the cisco.com proxy. This could have been a configured piece of information in the computer, or it could have been learned by DHCP. Then the cisco.com proxy had to find the princeton.edu proxy. This could be done using a special sort of DNS lookup that would return the IP address of the SIP proxy for the princeton.edu domain. (We'll discuss how DNS can do this in Section 9.3.1.) Finally, the princeton.edu proxy had to find a device on which Larry could be contacted. Typically, a proxy server has access to a location database that can be populated in several ways. Manual configuration is one option, but a more flexible option is to use the registration capabilities of SIP.

A user can register with a location service by sending a SIP register message to the “registrar” for his domain. This message creates a binding between an “address of record” and a “contact address.” An “address of record” is likely to be a SIP URI that is the well-known address for the user (e.g., sip:[email protected]) and the “contact address” will be the address at which the user can currently be found (e.g., sip:[email protected]). This is exactly the binding that was needed by the princeton.edu proxy in our example.

Note that a user may register at several locations and that multiple users may register at a single device. For example, one can imagine a group of people walking into a conference room that is equipped with an IP phone and all of them registering on it so that they can receive calls on that phone.

SIP is a very rich and flexible protocol that can support a wide range of complex calling scenarios as well as applications that have little or nothing to do with telephony. For example, SIP supports operations that enable a call to be routed to a “music-on-hold” server or a voicemail server. It is also easy to see how it could be used for applications like instant messaging, and standardization of SIP extensions for such purposes is ongoing at the time of writing.

HyperText Transfer Protocol (HTTP)

HTTP is an application layer protocol used for transferring information between computers on the World Wide Web. HTTP is based on a request/response standard between a client; usually the host and a server, a web site. The client initiates a request for a particular resource via a user agent and establishes a TCP connection usually on port 80 with a server. The server responds to the request with a status line and additional information that should include the resource requested. Resources to be accessed by HTTP are identified by Universal Resource Identifier (URI), which functions as a pathname to the resource. A resource can include all forms of data such as text, images, or multimedia shared on the Internet.

Protocol Specifications

HTTP is defined in RFC 1945 (HTTP/1.0) and RFC 2068 (HTTP/1.1). The RFC related to a protocol provides information that is helpful for understanding related log files. Another protocol, called the File Transfer Protocol or FTP (defined in RFC 0959), enables individuals to transfer files from one computer to another over the Internet.

As an investigator, it is important to understand the basic structure of HTTP because web browsing can be used for any online communication. Although HTTP is usually configured on TCP port 80, the administrator can configure the web server on any port. Furthermore, HTTP traffic can be encrypted with HTTP over TLS (Transport Layer Security), also called Secure HTTP (HTTPS). HTTPS typically uses TCP port 443, and though HTTPS still follows the HTTP standards, all the contents of the messages are encrypted, making it difficult to analyze the network traffic.

When conducting log analysis, it is important to understand the request method used by the client and the corresponding status code sent by the server. HTTP defines eight methods indicating the desired action to be performed on the requested resource. Table 9.3 summarizes the different actions that can be performed on the resource requested.

Table 9.3. HTTP Request Methods

As an example of an HTTP request, Figure 9.8 shows a GET request for the snakeoil1.jpg image on the intranet server (10.10.10.50) from the intrusion investigation scenario.

The server status line is the initial line of the server response and it includes the HTTP version, the status code, and the status message. It is important to understand that the status code and status message indicates how the server is responding to the specific request. Table 9.4 summarizes the different categories of responses that the server might send.

Table 9.4(a). HTTP Response Status Codes

Table 9.4(b). Meaning of Common HTTP Request Codes

For instance, Figure 9.9 shows the HTTP success code (200) returned in response to the GET request for the snakeoil1.jpg image in Figure 9.8.

Each time a resource on a web server is accessed over the Internet, an entry is made in an access log on the server detailing which computer on the Internet was used to access which files at a certain time, as well as the HTTP return status code. Although the format of access log files depends on the web server and its configuration, they all resemble the Common Log Format (CLF) or extended CLF:

CLF: remote host, userID, date, time, request, status code, # bytes returned

Extended: remote host, userID, date, time, request, status code, # bytes returned, referring URL, browser

On Microsoft web services, these logs are generally located in %systemroot%\system32\logfiles\ in a subdirectory associated with the server in question (e.g., W3SVC, FTPSVC) and have a slightly different format from the CLF. The following IIS web server log associated with the request for the snakeoil1.jpg image in Figure 9.9 is shown here:

2009-04-03 22:38:10 W3SVC1 10.10.10.50 GET /images/snakeoil1.jpg - 80 - 192.168.1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+N T+5.1) 200 0 0

From the Case Files: Credit Card Theft

We were called in to investigate suspected theft of credit cards from an e-commerce site. Forensic examination of the MSSQL database server used to store the credit cards showed no signs of compromise. However, the primary web server used to fulfill e-commerce functions did contain evidence of intrusion. Specifically, the web server access logs showed repeated SQL injection attacks that enabled the intruder to bypass the e-commerce application on the web server and directly access records in the backend SQL database. The log entries resembled the following, showing the IP address used by the intruder (changed to 192.168.14.24 here for sanitization purposes) as well as the customer record and associated credit card number that was obtained by the intruder.

2009-03-07 04:22:51 W3SVC WWWSRV1 10.1.0.12 GET/ecommerce/purchase.aspItemID=35745’%20=convert(int,(select%20top%201%20convert(varchar,isnull(convert(varchar,CreditCardExpires),’NULL’))%2b’/’%2bconvert(varchar,isnull(convert(varchar,CreditCardName),’NULL’))%2b’/’%2bconvert(varchar,isnull(convert(varchar,CreditCardNumber),’NULL’))%2b’/’%2bconvert(varchar,isnull(convert(varchar,CreditCardType),’NULL’))%2b’/’%2bconvert(varchar,isnull(convert(varchar,CustomerID),’NULL’))%2b’/’%2bconvert(varchar,isnull(convert(varchar,payID),’NULL’))%20from%20EPayment%20where%20right(CreditCardExpires,2)%20not%20in%20(‘01’,’05’,’04’,’03’,’02’)%20and%20CreditCardExpires%20not%20in%20(‘01/2006’,’02/2006’,’03/2006’,’04/2006’,’05/2006’,’06/2006’,’07/2006’,’08/2006’)%20and%20CustomerID%3E’0000000’%20order%20by%20CustomerID))--sp_password½230½80040e07½Syntax_error_converting_the_varchar_value_’04/2010/Joe_Blow/1234567891011121314/1/20/27981’_to_a_column_of_data_type_int.80 - 192.168.14.24 HTTP/1.1Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.8.0.6)+Gecko/20060728+Firefox/1.5.0.6 - www.ecommerce1.com5000 0 2613 1341 312

Searching the web access logs further revealed the initial vulnerability scan the intruder launched against the system from a different IP address, and all subsequent exploration and unauthorized access events. The log entries showed that, over a period of days, the intruder was able to extract every credit card from the customer database.

3.3 Stability and Universality of the Architecture

We have been discussing how the application layer protocols and the underlying link layer mechanisms have allowed IP architecture to evolve. Although evolvability is important, because it shows that the protocols are not tied to one particular application use that may change in the future, stability of the foundations of the architecture is also important. For smart objects, such stability is very important because individual smart object systems are designed to have a long lifetime, often up to ten years. Such investments require the base technology to be stable enough to remain available toward the end of the system life cycle.

The IP architecture has existed for nearly 30 years. Although there is room in the IP architecture for evolving protocols both at the application layer and at the link layer, throughout the years the architecture as a whole has remained exceptionally stable. Standards have been updated several times over the 30 years, but its foundation as a packet-based communication technology has remained firm. The network layer, the core of the IP architecture, exists in two versions — version four (IPv4) and version six (IPv6). The major difference between the two is that IPv6 provides more addresses. There are, however, no major architectural differences between the two versions.

Because IP forms the basis of the public Internet, the IP architecture and its surrounding standards will continue to exist well into the future. The prevalence of the Internet not only implies that IP has a large installed user base regarding hardware and software that supports it, but there is also a large installed network infrastructure. IP networking equipment and IP network access are both readily available and will continue to be so as long as the Internet exists.

The stability and prevalence of the IP architecture also have implications on the knowledge and education of users and network administrators. IP architecture and its protocols are part of the core curriculum in courses and training material at all levels of the educational system ranging from day-long network training courses to multiyear university programs. Ever year, thousands of new engineers graduate with knowledge of IP protocols and the architecture.

The number of books and training material on IP architecture and its protocols is immense, continues to increase, and is available in many different languages. There is a vast amount of material freely available online both as text, recorded seminars, and animated videos. Again, material is available in many different languages and for different audiences.

2.3.1 RTP Overview

The RTP [5,6] is an application layer protocol for end-to-end delivery of real-time data such as interactive audio or video over multicast or unicast network services. While RTP normally runs on top of UDP, it may be used with other underlying transport protocols such as TCP. RTP supports data transfer to multiple destinations if the underlying network supports multicast.

RTP contains two complementing functionalities: real-time data transport and data transport monitoring and control, which are provided by the RTP and the RTP control protocol (RTCP), respectively. RTP itself, however, does not provide any guarantee on timely delivery or other quality-of-service. It relies on the underlying network services to do so. Specifically, RTP does not guarantee packet delivery or prevent out-of-order delivery. The RTP sequence number allows the receiver to detect out-of-order delivery and to reconstruct the original packet sequence.

13.9.4 IP Security Protocol (IPSec)

IPSec is a widely used protocol that can be employed with other application layer protocols (not just for web applications such as SSL). The operations of IPSec between A and B involve:

A and B generate and exchange two random keys using Internet key exchange (IKE).

A and B combine the two numbers to create an encryption key to be used between them.

A and B negotiate the encryption technique to be used such as DES or 3DES.

A and B then begin transmitting data using either the transport mode in which only the IP payload is encrypted or tunnel mode in which the entire IP packet is encrypted.