Net::Frame Review for CSCI 485b, Security

Basic Description of the Net::Frame package and sub packages.
http://search.cpan.org/dist/Net-Frame/

1. Introduction
----------------
Net::Frame is a fork of Net::Packet, and attempts to increase simplicity,
transparency, and modularity in the code base. Unfortunately, there is not
too much documentation, as the project is relatively new. The modularity that
is introduced into the project is both a blessing and a curse. The high
modularity allows for very configurable systems, and easily modified
programs. The modularity however, do increase the complexity in creating
packets, and sending and receiving those packets.

Net::Frame does not handle network connections in the same way that other
networking Perl packages that you might be familiar with, like IO::Socket, or
Anyevent::Socket, do. Both of these packages create TCP connections, which
you can then interact with. Instead Net::Frame allows for the construction
of single network packets. These packets can then be fired off, and in the
case of TCP, the returned packet can be read. No connection is made, as we
are interacting with the network on a very low level.

This document will cover some of the anecdotal experiences of installing, 
running, interpreting, and modifying Net::Frame and the example code on CPAN.

2. Installation
----------------
There are many CPAN libraries that must be installed. Additionally they
may require several nonstandard libraries be installed through the systems
package manager before the CPAN packages will compile. Dependency resolution
is not done well on this project, and so careful attention to error messages
is required when install the packages.

The following CPAN packages should be installed:
Net::Write
Net::Frame
Net::Frame::Simple
Net::Frame::Device
Net::Frame::Layer
Net::Frame::Dump
Net::Frame::Layer
Net::Frame::Layer::IPv4
Net::Frame::Layer::TCP
Net::Frame::Layer::UDP

In particular Net::Pcap may be problematic, and is a required dependency
to several other packages. The apt-get packages libdnet, libdnet-dev,
and libnet-libdnet-perl, as well as possibly libnet-pcap-perl, libpcap-dev
libnet-pcaputils-perl, and pcaputils, were required before I was able to
install Net::Pcan, and Net::Frame::Device on my local computer.

Net::Pcap is not be necessary to build Net::Frame, however the pcap library
are. It is recommended to install any and all pcap libraries on your virtual
machine if Net::Frame is not building properly.

An alternative to Net::Frame is Net::RawIp. This packages is more high level,
and is geared towards IP packets, not TCP packets. It may be useful later on
in the course, but is not necessarily now.

3. TCP
----------------
See the TCP State Diagram that was discussed in CSCI 460:
www.cs.hofstra.edu/~cscccl/c333/tcp.gif

TCP flags have many possible values. 
The ones we are interested in for this example are:
 0x02 -- SYN      -- CONNECT
 0x12 -- SYN+ACK
 0x14 -- RST+ACK  -- CLOSED

Following the example code on CPAN, I was able to successfully generate,
send, and look at the receipt of TCP packets fired at port 22.

These TCP packets were sent with a flag value of 0x02, SYN, and were returned
with flag value of 0x12, SYN+ACK. This represents step one and two of the
three way handshake required for a TCP connection, and is in accordance with
a port that is open.

When the same TCP packet is sent at a closed port, the flag 0x14, RST+ACK is
returned, indicating a closed port, not accepting TCP connections.

Finally, when a TCP packet is sent to a port that is filtered, no TCP
receipt will be returned, and the example code will timeout.

Using just this information, it will be possible to create a port scanner 
using this Packet Framework.

3.1 The Gory Details
--------------------
Please refer to the example code provided at
http://search.cpan.org/dist/Net-Frame/lib/Net/Frame.pm

4. UDP
----------------
While I had success sending TCP packets, I did not have much success sending
UDP packets in the limited time I spent playing with the framework. Net::Frame
is versatile enough to do almost all of what we could possibly want to do,
however it will take additional research, and understanding.

5. Conclusion
----------------
The Net::Frame framework as a whole it fairly complicated, and has several
challenges in installation, understanding, and complexity. It is however,
preferable to Net::Packet, as it is currently being developed. It would be
possible to use Net::Frame to implement a port scanner within a reasonable
amount of time. 

Other applications would also be possible to implement using Net::Frame,
although will represent a larger challenge.
