Internet Security College of Engineering & CS Wright State University Dayton, Ohio 45435-0001

MS Thesis Topics List #2   Prabhaker Mateti   Abstract: Venkat Pothamsetty, a former student of mine now working at Cisco suggests the following topics as being suitable topics for MS Theses: IP Stack Integrity Checker, Enhancements to ikegen tool, Generic packet generation/ sniffing tool, Libnet Enhancements.

Table of Contents

1. ISIC -- IP Stack Integrity Checker
2. Enhancements to ikegen tool
3. Generic packet generation/sniffing tool
4. Libnet Enhancements

ISIC -- IP Stack Integrity Checker

Source http://www.packetfactory.net/Projects/ISIC/

Next Generation ISIC Tool

ISIC (IP stack integrity checker) tool comes with four binaries ESIC (operates at link layer), ISIC (generates bad IP packets), TCPSIC (generates bad TCP packets), UDPSIC (generates bad UDP packets) and ICMPSIC (bad ICMP packets). The tool concentrates on IP/TCP options, fragmentation, version numbers, checksums and header lengths for generating bad IP/TCP/UDP packets. ISIC in its present form has the following drawbacks.

1. It puts random values onto the IP/TCP/UDP protocol headers, and there is no intelligent decision taken in selecting them (like putting zeros or maximum values).
2. If the target stack panics while parsing some bad packet, there is no easier way to learn which packet did the magic.
3. The tool just concentrates on fragmentation, options, version numbers and lengths. There is no way to control other header values, like sending a TCP SYN with IP fragmentation bit set in it.

Desired features:

1. Examine the past vulnerabilities and investigate possible header values that are most likely to cause problems to the stack.
2. Have the ability of the "value database", where the tester has the ability to add and delete values.
3. Have more control over the values that the tool puts onto the headers and control over what header(s) we want to play with.
4. Keep/implement/enhance the "good" features of the ISIC tool package like generating the packets at amazing speeds.
5. Enhance the tool so as to include all the header fields of the IP/TCP/UDP stack.

Enhancements to ikegen tool

Internet Key Exchange (IKE, RFC 2409) is a protocol that uses parts of ISAKMP and parts of Oakley key exchange protocols to provide management of keys and security associations for the IPSec AH, ESP protocols and ISAKMP. Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408) is a framework that defines the management of security associations and keys and the payloads for exchanging key generation and authentication data. This is a protocol-independent framework for remote entities authentication and key exchange. Oakley is a key determination/ exchange protocol that is used with the ISAKMP framework to exchange and update keying material for security associations.  Oakley describes a series of key exchanges, known as modes, and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication).  With each successful negotiation, the VPN servers regenerate the keys that protect a connection, thus making it more difficult for an attacker to capture information from the connection. Additionally, if you use perfect forward secrecy, attackers cannot derive future keys based on past keying information.

The objective of the IPSec set of protocols is to protect IP datagrams by defining a security architecture (RFC 2401) that provides a standard and extensible mechanism for ensuring security of IP and upper-layer protocols (e.g. UDP or TCP). IPSec provides protection of data on a packet-by-packet basis since IP packets have no inherent security. IPSec is a set of protocols that define various parameters, functions, and flow required for proper operation of security. The ESP (Encapsulating Security Payload/ RFC 2406) provides confidentiality, data integrity, data source authentication, and protection against replay. The IKE on the other hand, is a general purpose security exchange protocol and is used for establishing shared security parameters and keys, as well as establishing security associations (SA) between IPSec peers. For example, an SA identifies algorithm types, key lengths and lifetimes, participating parties, and encapsulation modes.

The major function of IKE is the "on-demand" establishment and then maintenance of Security Associations (SA), that contains all the information needed for further applying of IPsec protocol. IKE authenticates each peer in an IPsec transaction, negotiates security policy, and handles the exchange of session keys. IKE execution starts with a high-level application's demand for new IPsec connection that is called a "demand for new SA". The result of IKE execution and peer-to-peer negotiation is a new security association that contains entire data for IPsec applying to target connection. While IKE works, it requires support of Certificate Management system (Certification Authority) for peer authentication, and consults with Domain of Interpretation for SA parameters negotiation.

The establishment of SA between two peers takes place in two phases. In the first phase, two entities (e.g. ISAKMP servers) agree on how to protect further negotiation traffic between themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to protect the negotiations for the protocol-specific SA being requested. The second phase of negotiation is used to establish security associations for other security protocols (e.g., for IPsec protocols SA). These security associations can be then used by a security protocol to protect many message/data exchanges.

Ikegen is a IPSec packet generation tool written by Pothamsetty. Currently it concentrates on generating main mode proposal packets. Extend ikegen so that

1. We can tweak values for different headers
2. Does support generic aggressive mode packet generation.
3. Generates malformed and out of sequence payloads.
4. There should be some intelligent default values for the headers and the user should be able to overwrite each and every one of those values through command line arguments. 

Generic packet generation/sniffing tool

Most of the present packet generation tools (e.g., hping2) focus on IP/TCP/UDP header values. Some of the tools (e.g., sendip) let you specify the corresponding layer data, where in you have to give the whole hex string of the layer data as one of the arguments. With the release of Libnet, packet generation has become easy and still there are no tools which focus on application layer protocols headers (dhcp/ntp etc.). The tool desired can be described with an example.

./tool -s ip.src=a.b.c.d and  ip.frag =1  or ssl.packettype="servercertificate" \
 -g eth.mac=a.b.c.e.f.g and ip.dst=a.b.c.d and dhcp.mode="server"

If you see a fragmented packet or an ssl server certificate packet send a dhcp reply from a particular mac address.

Libnet in its present form has the IP/TCP/UDP packet generating functions. They take different header values as the arguments, build the appropriate layers of the packet and send the packet at the corresponding layer. It also has some application layer protocol generating functions like OSPF. For generating application packets using Libnet one needs to do the following:

1. A header like file, which has the structures corresponding to the protocol header
2. Packet building functions, which copy the user supplied values into the structures declared.

Both of these can be automated given the specification of the protocol header (feildname and size). The specification can be given using a well designed packet description language. For example if the user gives the the input through a file [Protocol: blah; Upper protocol: TCP; feild1 : size1, defvalue1; feild2: size2, defvalue2;] the header file and the packet building file can be automatically constructed using the input file. The tool should be able to build a blah packet filling in its headers with the default values given or supplied values through the function.

It should not be hard to do the same with packet sniffing also.

1. The tool should cover multiple layers.
2. As shown above, the packet filters should not only cover application layer protocol headers, but also data.
3. It should look for just those values mentioned in the command line and put in reasonable default values for values not mentioned while generating packets.
4. The corresponding packet to look for and the corresponding packet to send may span multiple packets.

Libnet Enhancements

Analyze Libnet source code (http://www.packetfactory.net ) with the goal of developing a methodology paper that details how new IP protocols can be added to the API. Write a script (say in Python or Perl) that will generate C source for new protocols based on a protocol specification file that describes the packet headers and payload. Example protocols: GRE, AH, ESP, IKE. Protocols can be done separately or by the larger group that the protocols belong to (VoIP, IPSec, etc).

Enhance LibNet by adding functionality that can be used to parse packets that are being sniffed off of the network. This capability would enable the creation of applications that need to read packets from the network, parse the information, and then generate replies based on that information.

Acknowledgements

Listed above are "problem" descriptions that I received from Venkat. I have edited them so that they are self-contained with references, etc. Venkat was an MS student of mine, and now works in a security group at Cisco. I would like us to work on these.

References

You can view these RFCs at http://www.rfc-editor.org.

1. IKE (Internet Key Exchange) Protocol,  RFC 2409.
2. ISAKMP RFC 2408
3. Ethereal source has packet-isakmp.c
4.