TCP / IP Suite

AH

RFC1826 http://www.cis.ohio-state.edu/htbin/rfc/rfc1826.html
This RFC has been replaced by RFC 2402.
The information on this page will be updated to suit the new RFC in the near future.
RFC1827 http://www.cis.ohio-state.edu/htbin/rfc/rfc1827.html

The IP Authentication Header seeks to provide security by adding
authentication information to an IP datagram. This authentication
information is calculated using all of the fields in the IP datagram
(including not only the IP Header but also other headers and the user
data) which do not change in transit. Fields or options which need
to change in transit (e.g., hop count, time to live, ident, fragment offset, or routing pointer, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms bases upon RTP. ) are considered to be zero
for the calculation of the authentication data. This provides
significantly more security than is currently present in IPv4 and
might be sufficient for the needs of many users.

When used with IPv6, the Authentication Header normally appears after the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options. When used with IPv4, the Authentication Header normally follows the main IPv4 header.
The format of AH is shown in the following illustration:

Interested in more details about testing this protocol?

ESP

RFC1826 http://www.cis.ohio-state.edu/htbin/rfc/rfc1826.html
RFC1827 http://www.cis.ohio-state.edu/htbin/rfc/rfc1827.html
This RFC has been replaced by RFC 2406.
The information on this page will be updated to suit the new RFC in the near future.

The IP Encapsulating Security Payload (ESP) seeks to provide confidentiality and integrity by encrypting data to be protected and placing the encrypted data in the data portion of the IP ESP. Depending on the user's security requirements, this mechanism may be used to encrypt either a transport-layer segment (e.g., TCP, UDP, ICMP, IGMP) or an entire IP datagram. Encapsulating the protected data is necessary to provide confidentiality for the entire original datagram.

ESP may appear anywhere after the IP header and before the final transport-layer protocol. The Internet Assigned Numbers Authority has assigned Protocol Number 50 to ESP. The header immediately preceding an ESP header will always contain the value 50 in its Next Header (IPv6) or Protocol (IPv4) field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IP datagram or an upper-layer protocol frame (e.g., TCP or UDP).

Security association identifier
The SPI is a 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of the SPI field is 0x00000000. An SPI is similar to the SAID used in other security protocols. The name has been changed because the semantics used here are not exactly the same as those used in other security protocols.

Interested in more details about testing this protocol?

TLS

ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt

The primary goal of the TLS (Transport Layer Security) Protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:

• Privacy - symmetric cryptography is used for data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can also be used without encryption.
• Reliability - message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters.

The TLS Record Protocol is used for encapsulation of various higher level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security that has three basic properties:

• The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers.
• The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection.
• The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication.

One advantage of TLS is that it is application protocol independent.
Higher level protocols can layer on top of the TLS Protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS.

Header
Fragmentation

struct {
    uint8 major, minor;
} ProtocolVersion;

enum {
   change_cipher_spec(20), alert(21), handshake(22),
   application_data(23), (255)
} ContentType;

struct {
   ContentType type;
   ProtocolVersion version;
   uint16 length;
   opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

Record compression and decompression

struct {
   ContentType type; /* same as TLSPlaintext.type */
   ProtocolVersion version;/* same as TLSPlaintext.version */
   uint16 length;
   opaque fragment[TLSCompressed.length];
} TLSCompressed;

Record payload protection

struct {
   ContentType type;
   ProtocolVersion version;
   uint16 length;
   select (CipherSpec.cipher_type) {
      case stream: GenericStreamCipher;
      case block: GenericBlockCipher;
   } fragment;
} TLSCiphertext;

Interested in more details about testing this protocol?

BGP-4

RFC1654: http://www.cis.ohio-state.edu/htbin/rfc/rfc1654.html
This RFC has been replaced by RFC 1771.
The information on this page will be updated to suit the new RFC in the near future.

The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. BGP-4 provides a new set of mechanisms for supporting classes interdomain routing.
(Compliant with IETF RFC1654.)

The format of the header is shown in the following illustration:

Marker
A 16-byte message containing a value predictable by the receiver of the message.

Length
The length of the message including the header.

Type
The message type. Possible messages are:
Open, Update, Notification, KeepAlive.

Enlarge	More Details

Interested in more details about testing this protocol?

 EGP

The Exterior Gateway Protocol (EGP) exists in order to convey net-reachability information between neighboring gateways, possibly in different autonomous systems. The protocol includes mechanisms to acquire neighbors, monitor neighbor reachability and exchange net-reachability information in the form of Update messages. The protocol is based on periodic polling using Hello/I-Heard-You (I-H-U) message exchanges to monitor neighbor reachability and Poll commands to solicit Update responses.

The format of the header is shown in the following illustration:

EGP version
The version number. This version is version 2.

Type
Identifies the message type.

Code
Identifies the message code.

Status
Contains message-dependent status information.

Checksum
The EGP checksum is the 16-bit one's complement of the one's complement sum of the EGP message starting with the EGP version number field. When computing the checksum the checksum field itself should be zero.

Autonomous System Number
Assigned number identifying the particular autonomous system.

Sequence Number
Send state variable (commands) or receive state variable (responses and indications).

Interested in more details about testing this protocol?

EIGRP

EIGRP Enhanced Interior Gateway Routing Protocol (EIGRP) is an enhanced version of IGRP. IGRP is Cisco's Interior Gateway Routing Protocol used in TCP/IP and OSI internets. It is regarded as an interior gateway protocol (IGP) but has also been used extensively as an exterior gateway protocol for inter-domain routing. IGRP uses distance vector routing technology. The same distance vector technology found in IGRP is also used in EIGRP, and the underlying distance information remains unchanged. The convergence properties and the operating efficiency of this protocol have improved significantly.

The format of the EIGRP header is shown in the following illustration.

Version
The version of the protocol.

Opcode
1    Update.
2    Reserved.
3    Query.
4    Hello.
5    IPX-SAP.

Type
1    EIGRP Parameters.
2    Reserved.
3    Sequence.
4    Software version.
5    Next Multicast sequence.

Length
Length of the frame.

Interested in more details about testing this protocol?

GRE

RFC 1701: http://www.cis.ohio-state.edu/htbin/rfc/rfc1701.html
RFC 1702: http://www.cis.ohio-state.edu/htbin/rfc/rfc1702.html

The Generic Routing Encapsulation (GRE) protocol provides a mechanism for encapsulating arbitrary packets within an arbitrary transport protocol. In the most general case, a system has a packet that needs to be encapsulated and routed (the payload packet). The payload is first encapsulated in a GRE packet, which possibly also includes a route. The resulting GRE packet is then encapsulated in some other protocol and forwarded (the delivery protocol).

GRE is also used with IP, using IP as the delivery protocol or the payload protocol. The GRE header used in PPTP is enhanced slightly from that specified in the current GRE protocol specification.

The format of the header is shown in the following illustration:

Flags
The GRE flags are encoded in the first two octets.
Bit 0 is the most significant bit, bit 12 is the least significant bit.
Flags are as follows:
Checksum present (bit 0). When set to 1, the Checksum field is present and contains valid information.
Routing present (bit 1). When set to 1, the Offset and Routing fields are present and contain valid information.
Key present (bit 2). When set to 1, the Key field is present in the GRE header.
Sequence number present (bit 3). When set to 1, the Sequence number field is present.
Strict Source Route (bit 4). It is recommended that this bit only be set to 1 if all of the Routing Information consists of Strict Source Routes.
Recursion Control (bits 5-7). Contains a three bit unsigned integer which contains the number of additional encapsulations which are permissible.
Version Number (bits 13-15). Contains the value 0.

Protocol type
Contains the protocol type of the payload packet. In general, the value will be the Ethernet protocol type field for the packet.

Offset
Indicates the octet offset from the start of the Routing field to the first octet of the active Source Route Entry to be examined.

Checksum
Contains the IP (one’s complement) checksum of the GRE header and the payload packet.

Key
Contains a four octet number which was inserted by the encapsulator. It may be used by the receiver to authenticate the source of the packet.

Sequence number
Contains an unsigned 32 bit integer which is inserted by the encapsulator. It may be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver.

Routing
Contains data which may be used in routing this packet.

The format of the enhanced GRE header is as follows:

Flags
Flags are defined as follows:
C (bit 0). Checksum Present.
R (bit 1). Routing Present.
K (bit 2). Key Present.
S (bit 3). Sequence Number Present.
s (bit 4). Strict source route present.
Recur (bits 5-7). Recursion control.
A (bit 8). Acknowledgment sequence number present.
Flags (bits 9-12). Must be set to zero.
Ver (bits 13-15). Must contain 1 (enhanced GRE).

Protocol type
Set to hex 880B. Key Use of the Key field is up to the implementation.

Sequence number
Contains the sequence number of the payload.

Acknowledgment number
Contains the sequence number of the highest numbered GRE packet received by the sending peer for this user session.

Interested in more details about testing this protocol?

HSRP

RFC2281 http://www.cis.ohio-state.edu/htbin/rfc/rfc2281.html

The Cisco Hot Standby Router Protocol (HSRP) provides a mechanism which is designed to support non-disruptive failover of IP traffic in certain circumstances. In particular, the protocol protects against the failure of the first hop router when the source host cannot learn the IP address of the first hop router dynamically. The protocol is designed for use over multi-access, multicast or broadcast capable LANs (e.g., Ethernet). A large class of legacy host implementations that do not support dynamic discovery are capable of configuring a default router. HSRP provides failover services to those hosts.

HSRP runs on top of UDP, and uses port number 1985. Packets are sent to multicast address 224.0.0.2 with TTL 1. Routers use their actual IP address as the source address for protocol packets, not the virtual IP address. This is necessary so that the HSRP routers can identify each other. The format of the data portion of the UDP datagram is:

Version
HSRP version number, 0 for this version.

Op code
Type of message contained in the packet. Possible values are:
0 - Hello, sent to indicate that a router is running and is capable of becoming the active or standby router.
1 - Coup, sent when a router wishes to become the active router.
2 - Resign, sent when a router no longer wishes to be the active router.

State
Internally, each router in the standby group implements a state machine. The State field describes the current state of the router sending the message. Possible values are:
0    Initial
1    Learn
2    Listen
4    Speak
8    Standby
16   Active

Hellotime
Approximate period between the Hello messages that the router sends (for Hello messagesonly). The time is given in seconds. If the Hellotime is not configured on a router, then it may be learned from the Hello message from the active router. The Hellotime should only be learned if no Hellotime is configured and the Hello message is authenticated. A router that sends a Hello message must insert the Hellotime that it is using in the Hellotime field in the Hello message. If the Hellotime is not learned from a Hello message from the active router and it is not manually configured, a default value of 3 seconds is recommended.

Holdtime
The amount of time, in seconds, that the current Hello message should be considered valid. (For Hello messags only.)

Priority
Used to elect the active and standby routers. When comparing priorities of two different routers, the router with the numerically higher priority wins. In the case of routers with equal priority the router with the higher IP address wins.

Group
Identifies the standby group. For Token Ring, values between 0 and 2 inclusive are valid. For other media, values between 0 and 255 inclusive are valid.

Authentication data
(8 bytes) Clear-text 8 character reused password. If no authentication data is configured, the recommended default value is 0x63 0x69 0x73 0x63 0x6F 0x00 0x00 0x00.

Virtual IP address
(4 bytes) Virtual IP address used by this group. If the virtual IP address is not configured on a router, then it may be learned from the Hello message from the active router. An address should only be learned if no address was configured and the Hello message is authenticated.

Interested in more details about testing this protocol?

IGRP

The Interior Gateway Routing Protocol (IGRP) was developed by the Cisco company. It is used to transfer routing information between routers.
IGRP is sent using IP datagrams with IP 9 (IGP). The packet begins with a header which starts immediately after the IP header.

Version
Protocol version number (currently 1).

Opcode
Operation code indicating the message type:
1   Update.
2   Request.

Edition
Serial number which is incremented whenever there is a change in the routing table. The edition number allows gateways to avoid processing updates containing information that they have already seen.

ASystem
Autonomous system number. A gateway can participate in more than one autonomous system where each system runs its own IGRP. For each autonomous system, there are completely separate routing tables. This field allows the gateway to select which set of routing tables to use.
Ninterior, Nsystem, Nexterior
Indicate the number of entries in each of these three sections of update messages. The first entries (Ninterior) are taken to be interior, the next entries (Nsystem) as being system, and the final entries (Nexterior) as exterior.

Checksum
IP checksum which is computed using the same checksum algorithm as a UDP checksum. The checksum is computed on the IGRP header and any routing information that follows it. The checksum field is set to zero when computing the checksum. The checksum does not include the IP header and there is no virtual header as in UDP and TCP.
An IGRP request asks the recipient to send its routing table. The request message has only a header. Only the Version, Opcode and ASystem fields are used; all other fields are zero.
An IGRP update message contains a header, immediately followed by routing entries. As many routing entries as possible are included to fit into a 1500-byte datagram (including the IP header). With current structure declarations, this allows up to 104 entries. If more entries are needed, several update messages are sent.

Interested in more details about testing this protocol?

1 2 3 4 5 6 7 8 9

TCP/IP Family Protocol Information
AH | ATMP | ARP/RARP | BGMP | BGP-4 | COPS | DCAP | DHCP | Diameter | DIS | DNS | DVMRP | EGP | EIGRP | ESP | FANP | Finger | FTP | HSRP | HTTP | ICMP/ICMPv6 | IGMP | IGRP | IMAP4 | IMPPpre/IMPPmes | IPDC | IP | IPv6 | IRC | ISAKMP | ISAKMP/IKE | iSCSI | ISTP | ISP | LDAP | L2F | L2TP | MARS | Mobile IP | MZAP | NARP | NetBIOS/IP | NHRP | NTP | OSPF | PIM | POP3 | PPTP | Radius | RLOGIN | RIP2 | RIPng for IPv6 | RSVP | RTSP | RUDP | SCTP | S-HTTP | SLP | SMTP | SNMP | SOCKS | TACACS+ | TALI | TCP | TELNET | TFTP | TLS | TRIP | UDP | Van Jacobson | VRRP | WCCP | X-Window | XOT