ng_ayiya - a SixXS IPv6 tunnel broker AYIYA Netgraph node
- Student: Peter Pentchev (roam@)
- Mentor: Bjoern A. Zeeb (bz+soc@)
Project description
Implement a netgraph node that connects to a netgraph kernel socket node and a netgraph interface node and understands enough of the AYIYA protocol to pass packets back and forth. Use a control connection to user space to handle all other signalling. Adjust the sixxs-aiccu implementation and add the netgraph implementation as an option for the FreeBSD port.
The goal of this project is to create a Netgraph node that acts as a link between a socket (TCP, UDP, SCTP, ...) connection to an AYIYA server (for a start, the SixXS POPs) and a local network interface (for a start, one that can route IPv6 traffic). The operation of the node should be controlled via a Netgraph socket (the usual way of letting a kernel Netgraph node communicate with a userland program) by higher-level tunnel negotiation software like SixXS's AICCU. The scope of the project also includes the necessary changes to SixXS's AICCU software to use the Netgraph framework instead of tunneling the packets by itself, as it does in its standard mode of operation.
The initial design of the Netgraph node is as follows:
- a "ayiya" hook to a ng_ksocket node for the "uplink" connection to the AYIYA POP of the tunnel broker
- an "inet6" hook to a ng_iface node
- a "control" hook to a ng_socket node for configuration from userland
- a "secrethash" control message to set the pre-hashed shared secret for the AYIYA protocol, so that the node need not know the actual secret
- possibly more control messages to set the node's mode of operation in additional ways (possibly reconnect to the AYIYA POP by itself, etc.)
- possibly two-way data communication with the userland utility through the control hook for e.g. responding to AYIYA queries, passing on the POP's message of the day, etc.
The hook names should either be the exact strings "ayiya", "control" and "secret" or strings that start with those tags followed by a slash ("/") and additional data that the node will ignore. This allows the administrator or the userland utility to keep more information for clarity, documentation and so on, without interfering with the operation of the node.
Approach to solving the problem
For the present the plan is to write a Netgraph node with the hooks listed above that communicates over these hooks.
Deliverables
Mid-term deliverable: the Netgraph node itself with support for the "ayiya", "inet6" and "control" hooks and the "secrethash" control message. This will allow it to be configured manually using e.g. the ngctl utility and already provide AYIYA tunnel service.
Final deliverable: the necessary modifications to the SixXS AICCU tool to set up the necessary Netgraph structure (also including the interface, ksocket and socket nodes), initialize the AYIYA node properly (using the "secrethash" control message) and possibly provide other functionality, e.g. MOTD or queries. These modifications will be added to the FreeBSD port of the AICCU tool and also submitted to the upstream developers of AICCU with the hope of including them in an official release. Also, if it turns out that it may not be advisable to include the Netgraph node's code into the FreeBSD base system, a FreeBSD port will be created for it for use by the modified AICCU port.
Milestones
- May 25: Start of coding
June 1: A basic Netgraph node skeleton with some degree of control over the hook connect requests. (done: SVN r286476)
- June 8: A basic Netgraph node that parses AYIYA packets and can build a packet with one of the simpler queries (e.g. "version"); also a shell script to configure it using ngctl
- June 15: Passing packets through the IPv6 interface, respond to more queries
- June 26: Testing and debugging the Netgraph node, automated testing of some kind, examining the AICCU tool to figure out how to modify it, communication with the AICCU upstream developers to get their opinion
- June 26-July 3: Mid-term Evaluations
- July 13: Initial support for Netgraph configuration in the AICCU tool.
- July 27: Submission of the changes needed to the AICCU tool to the upstream developers for possible inclusion there instead of in the FreeBSD port, research of the available means for crypto acceleration of the AYIYA packet hashing.
- August 17: Testing, debugging, other improvements as ideas pop up during the development process.
- August 17: End of coding (soft)
- August 21: End of coding (hard)
Test Plan
It may turn out to be advisable to create a simple AYIYA simulator for some automated testing. After that either some TAP tests or some tests in the FreeBSD regression testing framework format could be included in the code. TBD: flesh this part out with my mentor.
The Code
TBD: A Subversion repo link.