INDEX
~~~~~

  Proposal #1 (A descriptive interface for ARS)
  Proposal #2 (Reply parameters auto detection)
  Proposal #3 (IP header offset auto detection)

Proposal #1	A descriptive interface for ARS		<antirez@invece.org>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  MOTIVATIONS

  The ARS library for packet assembly already offers an high level interface
  to build TCP/IP packets. This proposal describe the implementation of a
  very high level interface (VHLI) to build packets using a descriptive
  interface.

  The goal of this interface is to provide the equivalent of the bpf
  filters for packets assembly, so you can directly export the interface
  to the user. The tcpdump(8) network analyzer allow you to specify
  a filter, however the filters are directly interpreted by the libpcap
  library. A packet assembly equivalent can be suitable to write
  applications like hping(8) with an intuitive and powerful user
  interface with little efforts.

  REQUIREMENTS

  To reach the goal a grammar for packet description is needed.
  The requirements of such grammar should meet the following requirements:

	o Should be able to describe all the common TCP/IP packets.
	o Should be able to describe broken and malformed TCP/IP packets.
	o Simple to parse.
	o Quite user-friedly, since it may be exported to user applications.
	o Should reflect the TCP/IP layered nature.

  PROPOSED FORMAT

  The proposed format, while simple, seems to meet all the requirements.
  Every line is defined as the following (note: the '\' means that the
  line virtually continue from the next line).

  protocol1{option1=vaule,option2=value,...,optionN=value}len

  The 'protocol' is a mnemonic for the protocol name, for example
  "ip, ipopt, icmp, tcp, tcpopt, data" and so on. The "len" layer
  is optional and is used to trucate the packet at the given len.
  Example of IP layer:

  ip{id=10,src=192.168.1.2,dst=192.168.1.3}

  If the packet is composed of more layers they are combined using
  the + character.

  ip{dst=192.168.1.2}+udp{sport=2000,dport=53}+data{bytes=00FFA4}

  Every field of every layer type as a well defined default, that
  should be the most used. A way to define differents default values
  may be given using some dot file in the user home directory.
  The value of every files can be in some field-specific format,
  hoever as a general rule a numerical value should be accepted
  in decimal, octal and hex format.

  The following additionally special values must be recognized:

  *	Random value that must meet all the possible values for the field.
  $ip   The IP address of the interface that will be used to send the packet.

Proposal #2	Reply parameters auto detection <antirez@invece.org>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  MOTIVATIONS

  The first target of the ARS library is to provide a flexible packet
  assembly layer for the hping(8) program. hping send different kinds
  of TCP/IP packets and display the reply in a human readable format.
  To do this hping needs to filter all the packets that can't be
  generated in reply to the sent packet: for every packet sent
  it enable a special filter to do this selection.
  The ARS library may provide a facility to create the rules needed to get
  valid responses accordly to the packet sent. The filter may be
  generated as an usable bpf filter or in some special format.

  WORK IN PROGRESS
