TOS


Because the Internet by itself has no direct knowledge of optimizing the path for a particular application or user, the IP protocol provides a facility for upper layer protocols to convey hints to the Internet Layer about how the tradeoffs should be made for a particular packet.  This facility is the "Type of Service" facility, abbreviated as the "TOS facility".

 

The TOS facility is one of the features of the Type of Service octet  in the IP datagram header. The Type of Service octet consists of  three fields. The first 3 bits ( 0,1,2) are for the first field, labeled "Precedence" , intended to denote  the importance or priority of the datagram. The second field, labeled "TOS" , denotes how the network should make tradeoffs between throughput, delay, reliability, and cost.The last field, labeled "MBZ" ( for "must be zero" ) above, is  currently unused. The originator of a datagram sets this field to zero (unless participating in an Internet protocol experiment which makes use of that bit).  Routers and recipients of datagrams ignore  the value of this field.This field is copied on fragmentation.

 

Specification of the TOS Field

 

The semantics of the TOS field values (expressed as binary numbers):


      1000 minimize delay
       0100 maximize throughput
       0010 maximize reliability
       0001 minimize monetary cost
       0000 normal service


              
The values used in the TOS field are referred to as "TOS  values", and the value of the TOS field of an IP packet is referred  to as the "requested TOS".  The TOS field value 0000 is  referred to "default TOS." Because this specification redefines TOS values to be integers rather than sets of bits, computing the logical OR of two TOS values is no  longer meaningful.  For example, it would be a serious error for a  router to choose a low delay path for a packet whose requested TOS  was 1110 simply because the router noted that the former "delay bit"  was set.

Although the semantics of values other than the five listed above are  not defined , they are perfectly legal TOS values, and  hosts and routers must not preclude their use in any way. Only the default TOS is in any way special. A host or router need not make any distinction between TOS values

For  example, setting the TOS field to 1000 (minimize delay) does not  guarantee that the path taken by the datagram will have a delay that  the user considers "low".  The network will attempt to choose the  lowest delay path available, based on its (often imperfect)  information about path delay.  The network will not discard the  datagram simply because it believes that the delay of the available  paths is "too high" (actually, the network manager can override this  behavior through creative use of routing metrics, but this is  strongly discouraged: setting the TOS field is intended to give  better service when it is available, rather than to deny service when  it is not).

 

Use of the TOS Field in Routing

Both hosts and routers should consider the value of the TOS field of a datagram when choosing an appropriate path to get the datagram to its destination.The mechanisms for doing so are discussed in this section.

Whether a packet's TOS value actually affects the path it takes inside a particular routing domain, is a choice made by the routing domain's network manager.  In many routing domains the paths are sufficiently homogeneous in nature that there is no reason for routers to choose different paths based up the TOS field in a
datagram. Inside such a routing domain, the network manager may choose to limit the size of the routing database and of routing protocol updates by only defining routes for the default (0000) TOS.


Neither hosts nor routers should need to have any explicit knowledge of whether TOS affects routing in the local routing domain.

 

Inherent Limitations:

 

The most important of all the inherent limitations is that the TOS facility is strictly an advisory mechanism. It is not an appropriate mechanism for requesting service guarantees.There are two reasons why this is so:

 

  • Not all networks will consider the value of the TOS field when deciding how to handle and route packets.Partly this is a transition issue: there will be a (probably lengthy) period when some networks will use equipment that predates this specification.  Even long term, many networks  will not be able to provide better service by considering the value of the TOS field.  For example, the best path through a network composed of a homogeneous collection of
    interconnected LANs is probably the same for any possible TOS  value.  Inside such a network, it would make little sense to require routers and routing protocols to do the extra work needed to consider the value of the TOS field when forwarding packets.
  • The TOS mechanism is not powerful enough to allow an application to quantify the level of service it desires. For  example, an application may use the TOS field to request that the network choose a path which maximizes throughput, but cannot use that mechanism to say that it needs or wants a particular number of kilobytes or megabytes per second. Because the network cannot know what the application requires, it would be inappropriate for the network to decide
    to discard a packet which requested maximal throughput because no "high throughput" path was available.

 

 

TCP Flags


 

 

There are 6 flags - the Urgent Pointer flag, ACK( acknowledgement) flag, Push flag, RST(reset flag), SYN(synchronisation) flag & the FIN(finished) flag.

 

 

The Urgent Pointer flag identifies the incoming data as 'urgent'. The identified segments are processed immediately by being assigned high priority without waiting till all queued data is processed. The ACKnowledgement flag can be used to acknowledge the successful receipt of packet(s) - either the acknowledgement can be made for every packet received or for every n-th packet received. The Push flag can be used to assign the data the desired priority and is processed either at the Source or Destination. In using the push flag attention need to be paid to the fact that correct data segment handling is done. Also the appropriate priority needs to be set at the two ends of a connection.

 

When a segment that is not intended for the current connection has arrived the reset flag( RST) can be set . For instance if a remote system were to send a packet to a host to establish connection, and if that service is not supported by the host then the host can reject the request and then set the RST flag indicating that the host has reset the connection.

 

 

                  SYN

Host 1 ---------------------> Host 2

               SYN,ACK

Host 1 <--------------------- Host 2

                   ACK

Host 1 ----------------------> Host 2

 

 Connection is Established

 

 

                

 

The fifth flag in the TCP Flag options- the SYN flag is a highly used flag in TCP communication - the SYN flag is initialy sent when establishing the typical 3-way handshake between two hosts as shown above The Host 1 needs to establish contact with Host B using TCP as the protocol. In the course of the 3-way handshake there are 2 SYN flags transmitted . As the connection is set and data is transmitted between the two hosts more SYN flags will be sent and received.

 

 

The sixth & final flag available is the FIN flag which appears when the last packets are exchanged between a connection. When a host sends a FIN flag to close a connection, it may continue to receive data until the remote host has also closed the connection. A typical disconnection is shown below. TCP is a Full Duplex connection so there are two directions of data flow.

  

              FIN,ACK

Host 1 --------------------> Host 2

                 ACK

Host 1 <-------------------- Host 2

              FIN,ACK

Host 1 ---------------------->Host 2

                 ACK

Host 1 --------------------->Host 2

 

            Data Transfer

          

 

         

After the data transfer is completed the Host 1 sends a packet with the FIN, ACK flags set to Host 2. By this action Host 1 has acknowledged the previous data stream while simultaneously has initiated a TCP closing action to end this connection. After this Host 1's application will not receive any more data and the connection will be closed. Also Host 2 in response to Host 1's request to end the connection sends an acknowledgement back, After this is completed , the Host 2 sends its own FIN, ACK flags to end the connection. Finally Host 1 acknowledges the request Host 2 made earlier and this way the connection is closed

 

TCP & Worms :

 

Typically worm sources don't pool the whole network , but randomly try to open from time to time a single host connection.  One can use TCP flags and ICMP tracking. When the attacker tries to open the TCP connection to an unused destination IP address the TCP SYN flag is set. If the connection is successful there will be cumulative TCP flags SYN and ACK, if the connection is unsuccessful only flows with SYN flag will be there. Based on the count of the unsuccessful connections for every source IP address outside the network and source, the attacker can be tracked - the one with the most number of connection attempts. If attacker is using UDP protocol and pools the whole network, an excessive number of ICMP messages will then be generated.

 

 

 

 

 


Copyright © 2004-2010 ZOHO Corp , Inc. All Rights Reserved.