By: Aaron Falk
Date: December 7, 2007
What follows are summaries of several updates on the Internet Research Groups (RGs), some of which were reported during the Technical Plenary at IETF 70.
Since the July 2007 IETF meeting, one new IRTF (Internet Research Task Force) RFC has been published: RFC 5050, “Bundle Protocol Specifications.” A document to formalise IRTF RFCs is currently being developed.
The IRTF has some new work items on its agenda. One is a proposal to follow up on the IAB’s work on unwanted traffic within the IRTF. Interest has also been expressed in forming a research group (RG) that would focus on network virtualisation and another one focused on developing a Quality of Service policy framework. In the IETF Transport area, an IRTF RG dedicated to cross-layer communication has been suggested.
At IETF 70, three RGs met: the Host Identity Protocol Research Group (hip), the IP Mobility Optimisation Research Group (mobopts), and the Routing Research Group (rrg). Additionally, subsequent to the IETF, the End-Middle-End RG has decided to close based on lack of energy.
We would like to use this opportunity to offer details about the achievements, current work items, and future plans of most of the IRTF RGs as well as updates of discussions from IETF 70, held in December 2007.
Crypto Forum Research Group (cfrg)
The CFRG serves as a bridge between theory and practice, bringing new cryptographic techniques to the Internet community and promoting an understanding of their use and applicability. It is a forum for discussing and analysing general cryptographic aspects of security protocols. IETF working groups (WGs) that are developing protocols that include cryptographic elements often find it useful to bring questions to the CFRG.
Members of the CFRG recently discussed message authentication code (MAC) requirements, in the contexts of both draft-irtf-cfrg-fast-mac-requirements and the TCP-AO (TCP-Authentication Option) currently under design in the TCPM (TCP Maintenance and Minor Extensions) WG. New work such as SHA-1 and MD5 that makes digital signatures less vulnerable to attacks against hash functions was presented in draft-irtf-cfrg-rhash-01.txt.
New work in the form of draft-dharkins-siv-aes-01 has been reviewed, discussed, and revised. The work presents a new method for authenticated encryption that is more robust against misuse than most other modes are. It is under consideration in the TLS (Transport Layer Security) WG and other areas.
The draft of “An Interface and Algorithms for Authenticated Encryption” was approved as an RFC. The work has been adopted by the TLS WG as the basis for its use of AES GCM (Advanced Encryption Standard Galois Counter Mode). It is being adopted for other IETF uses as well.
The RG expects that a discussion of MAC candidates will follow the discussion of MAC requirements. References to some candidates have been provided.
Delay-Tolerant Networking Research Group (dtnrg)
Members of the DTNRG are concerned with addressing the architectural and protocol design principles that arise from the need to provide interoperable communications with and among extreme and performance-challenged environments where continuous end-to-end connectivity cannot be assumed. In other words, is it possible to interconnect highly heterogeneous networks even if end-to-end connectivity may never be available? Examples of such environments are spacecraft, military and tactical programmes, certain forms of disaster response, underwater, and some forms of ad hoc sensor/actuator networks. Another example is Internet connectivity in places where performance may suffer, such as in parts of the world that are still developing.
In 2007, the RG published two RFCs:
- RFC 4838: Delay Tolerant Networking Architecture (Informational)
- RFC 5050: Bundle Protocol Specification (Experimental)
There are a few areas of current work that are fairly mature and are likely to be completed as RFCs in 2008:
- LTP (Licklider Transmission Protocol): a transport protocol for high-delay environments
- Security: authentication and privacy for the DTN (delay-tolerant networking) bundle protocol
– There was agreement at a meeting held in Dublin to favour counter-node crypto because of its length-preserving properties. This becomes important when fragmentation is performed.
A Few Noteworthy Technical Items
- Structure of the namespace
DTN uses URIs (Uniform Resource Identifiers) to identify endpoints, -which include a scheme. Ongoing discussion revolves around the semantics associated with such schemes and how applications make use of them.
- Bit-level reliability
The bundle protocol does not currently contain a checksum or CRC (cyclic redundancy check) on the data (or blocks, which are similar to headers). Some of the folks involved in the RG would like to add this capability. [The security protocol uses a mechanism to ensure that bundle contents do not get modified either intentionally or unintentionally in transit, but some feel this approach may be too heavyweight.]
Although this issue has received some attention in the past, not much activity has been seen recently. The interaction with multicast and custody transfer can be tricky, and it remains an area of investigation.
The DTNRG will meet at IETF 71 in March 2008 in Philadelphia.
Upcoming discussions are likely to include some of the aforementioned technical issues in addition to discussion of the future of one or more “reference implementations” (RIs) of the bundle protocol. At present, we have identified one RI, but there are now multiple implementations that were demonstrated to interoperate during a DTN interop held at IETF 67. Issues revolve around whether there should be more than one RI for different operating environments and what its real purpose or purposes may be, such as education, demonstration, and performance.
End-Middle-End Research Group (emerg)
The goal of the End-Middle-End Research Group is to evaluate the feasibility and desirability of an architectural change to the Internet that allows explicit interactions with middleboxes, such as firewalls. We have considered a higher-level DNS-based naming scheme, in the manner of URIs, coupled with signalling protocols that are used to initiate and modify transport-level connections, such as TCP, UDP, SCTP, or DCCP flows. The aim is to investigate possible designs for a straw man experimental protocol.
A joint meeting with the HIP RG took place at IETF 69 that was very successful. The EME NUTSS draft provides connectivity that keeps stakeholders in mind. NUTSS makes explicit policies of middles and ends. EME could help HIP with middlebox traversal because EME is a mechanism for relaying a policy request to the right box. Some people question whether EME should carry application semantics and whether modifications to the packets should be allowed. The complete minutes are available here.
The group published a draft (draft-irtf-eme-francis-nutss-design-00.txt), but recently there has been no activity. Disbanding the RG is under consideration.
End-to-End Research Group (e2erg)
The E2ERG focuses on issues related to the end-to-end nature of communication. Historically, the group has focused its energies on one or more topics that are of particular interest to its members before moving on to another topic. Although the group is closed, it is sometimes necessary to invite other participants to meetings when there is an area of mutual interest. Two recent and current interests are (1) a review of the current state of congestion control and (2) questions about the provision of end-to-endness in an increasingly heterogeneous networking environment, particularly as it relates to management, routing, and characteristics of delivery services across qualitatively different subregions of the network. Typically, the group meets two or three times a year for two days at a time – at times and locations other than the times and locations of IETF meetings in order to avoid time conflicts. Most of the meetings have been in the United States, but the most recent meeting was in London. The next meeting will be in Cambridge, Massachusetts, in February 2008.
Host Identity Protocol Research Group (hiprg)
The IRTF HIP research group (HIPRG) complements the IETF HIP working group. Its two main goals are:
- To provide a forum for discussion and development of aspects of the HIP architecture that are still in research phase and not ready for working-group-level standardisation
- To stimulate, coordinate, discuss, and summarise experiments on deploying HIP; to provide feedback at some later date to the IAB and the IESG regarding the consequences and effects of wide-scale adoption of HIP. For the latter goal, the RG had planned to produce an experiment report, which currently exists in draft form (draft-irtf-hip-experiment-03.txt).
To date, most of the energy of the RG has been devoted to the first goal. There have been and continue to be various drafts on such issues as privacy extensions for HIP; basic and advanced NAT traversal; the i3 architecture and HIP; DHT (distributed hash table) as a HIP lookup service; process migration using HIP; SIP (session initiation protocol) and HIP interactions; TCP piggybacking of HIP messages; middlebox interactions; HIP and multicast; and network operator concerns with HIP. The RG has also pushed documents into the rechartered HIP WG (NAT traversal, legacy application support, native API) and has published its own IRTF-track document: “draft-irtf-hiprg-nat-04.txt.” There has been clear, ongoing interest on the part of a wide range of individuals and groups in studying how to extend the HIP architecture.
It has been difficult, however, for the RG to make progress on goal number 2. The chairs observe that coordinating and conducting experiments – particularly those oriented toward answering deployment questions – are much more difficult tasks than originally thought, especially compared with extending HIP. Since 2006, the HIP RG chairs have encouraged additional collaborative experimentation and dissemination of results. The chairs believe that encouraging wider-scale experiments and collaborations for the purpose of answering specific deployment questions about HIP is a priority. There are three open-source implementations of HIP that continue to mature, which means that software availability will become less of a barrier over time.
The HIP RG met at IETF 70 in Vancouver, Canada, and the group plans to meet again at IETF 71 in Philadelphia in March 2008. At its last meeting, the session featured a presentation of a few new HIP ideas regarding multicast and Internet connection sharing, updates on HIP projects and deployments, and discussions regarding the potential use of HIP as part of the peer-to-peer SIP overlay solution.
Internet Congestion Control Research Group (iccrg)
Ever since congestion control got included as part of TCP in 1988, this function has helped the Internet survive by ensuring its stable operation. However, it has long been agreed that this mechanism is not ideal; in fact, it shows deficiencies in the face of heterogeneous link properties, such as high capacities, long delays, or noise.
Now, after almost two decades, it seems that the demand for more better-performing mechanisms has become so strong that people are beginning to use alternatives that do not adhere to the standard anymore. Because this can lead to adverse interactions among different mechanisms, it is a major goal of the ICCRG to move toward consensus regarding (1) which technologies are viable, long-term solutions for the Internet congestion control architecture and (2) what might be an appropriate cost/benefit trade-off.
As a starting point for designers of new mechanisms, the group is currently working on two documents: a survey of congestion-control-related RFCs (which should help avoid reinventing the wheel) and an overview of open issues in the field of congestion control.
A process for evaluating experimental congestion-control proposals has been crafted with the goal of arriving at a recommendation to the IETF regarding publication of such proposals as RFCs (this process is currently applied to two documents describing TCP variants – CUBIC and Compound TCP – and discussions are ongoing).
Network Management Research Group (nmrg)
The NMRG continues to study the behaviour of management protocols by using traces collected from operational networks. The number of traces available is steadily increasing, although we are still short of traces from enterprise networks where we expect a larger percentage of commercial management applications to be deployed.
On the technical side, the NMRG is working on exchange formats for SNMP (Simple Network Management Protocol) traces (currently in second last call) and a common framework (and associated tools) for data aggregation/separation of SNMP traces (under active development by a small group, to be posted as an ID in January 2008). Based on this common framework, people analyse the periodic behaviour of SNMP traffic or they identify basic data retrieval algorithms used by management stations. Another aspect is the development of suitable online visualisation tools.
The NMRG did hold a one-and-a-half-day-long meeting in November 2007, which was hosted by the University of Twente in the Netherlands. Another meeting was held last year in Prague. In October 2007, an IEEE Communications Magazine paper on research directions in network management was published that originated from a joint NMRG/EMANICS workshop held in October 2006. Several regular NMRG attendees also participated in a July 2007 seminar on autonomic management held at Dagstuhl in Germany.
The SNMP measurement format ID is under second last call and will likely enter the IRTF publication process in January. The initial ID on data aggregation/separation will be posted in January 2008. It will then go through the RG process, which may mean that it gets last called in the summer. If things go well, it could be ready for the IRTF publication process in the second half of 2008. Thus, there will likely be a discussion about future work items during summer 2008.
Scalable Adaptive Multicast Research Group (samrg)
The SAMRG was formed in June 2006 and is cochaired by John Buford of Avaya Labs Research and Jeremy Mineweaser of Massachusetts Institute of Technology’s Lincoln Laboratory. The scope of the RG is to research application layer multicast techniques that leverage native multicast and that can adapt to different application requirements.
The SAMRG held two meetings in 2007: one was an interim meeting, which was held in January 2007 in conjunction with the P2P Multicasting Workshop; the other was a meeting held at IETF 69 in Chicago.
The main result of the RG was development of the following drafts and publications related to work items in the charter of the RG:
- Problem statement and requirements
- Technology survey
H. Yu, J. Buford. Advanced Topics in Peer-to-Peer Overlay “Multicast.” Encyclopaedia of Wireless and Mobile Communications (ed. B. Fuhrt), CRC Press, forthcoming.
- Framework for the SAM design
A key part of the SAM framework involves leveraging the design of Automatic IP Multicast without Explicit Tunnels (AMT) (draft-ietf-mboned-auto-multicast-08) by extending it to permit ALM connection.
- Hybrid ALM protocol proposals, including:
Waelrich and Schmidt: The Hybrid Shared Tree Architecture
Lei, Fu, Yang, and Hogrefe: Dynamic Mesh-Based Overlay Multicast Protocol
- Test bed for SAM experimentation and demonstration
Participants from WIDE have developed and tested an XCAST router on a private PlanetLab. The work is discussed in draft-muramoto-irtf-sam-exp-testbed-00.The XCAST (multidestination multicast) router is an element of the SAM framework due to the synergy between overlay routing and multidestination routing in the underlay network, which has demonstrated message savings of 30 percent. The topic will be covered in an article to be published in Computer Communications Journal called “Exploiting Parallelism in the Design of Peer-to-Peer Overlays,” by John Buford, Alan Brown, and Mario Kolberg.
The next SAMRG meeting is scheduled for IETF 71 in Philadelphia in March 2008. Goals for further work include moving the XCAST router to the public PlanetLab for use by the entire RG and integrating this with the extended version of AMT described in the SAM framework specification. For more information.
Routing Research Group (rrg)
The RRG is chartered to research routing and addressing technology that is not yet ready for engineering efforts. For the moment, the RRG has elected to focus on the problem of finding a scalable routing and addressing architecture for the Internet. In the current architecture, a multihomed site either injects one or multiple provider-independent address prefixes into the routing system from multiple locations or otherwise injects one or more prefixes it received from one provider into the routing system through other providers. Either case necessitates global scope for the address prefixes, and it results in a scalability issue. Locally scoped address prefixes are not sufficient, because legacy transport (TCP and UDP) connections use a specific prefix for connection identification, thereby tying the connection to a specific access link and creating a single point of failure. The primary thrust of most of the proposals currently before the group involves decoupling the location semantics from the identification semantics.
Since rechartering in early 2007, the RRG has met three times and has heard approximately 20 different technical proposals or updates to proposals. The group continues to receive new proposals and to refine a number of existing proposals. The mailing list has been reasonably active.
Currently, the goal is to drive the group to overall rough consensus through debate and comparison of proposals. The group plans to start the explicit windowing process in its next meeting (tentatively planned to coincide with IETF 71). The process is expected to take a year. During that time, new proposals are encouraged, and existing proposals are open for revision, potentially incorporating useful ideas from individual efforts and from the group’s feedback. The group is interested in devising by the end of the meeting a single, scalable routing architecture that it can recommend to the IETF for further development.
Transport Modelling Research Group (tmrg)
The Transport Modelling Research Group is chartered to produce a series of documents on models for the evaluation of transport protocols. The documents will include a survey of models used in simulations, analysis, and experiments for the evaluation of transport protocols. The output of the group will also include a broad set of simulation test suites and a set of recommendations for test suites for experiments in test beds. The group’s goal is to improve its methodologies for evaluating transport protocols.
Recent accomplishments include the following:
- The first document from the TMRG, Metrics for the Evaluation of Congestion Control Mechanisms (draft-irtf-tmrg-metrics-11), is in the final stages of review by the Internet Research Steering Group.
- Gang Wang, Yong Xia, and David Harrison have produced an Internet-Draft on an NS2 TCP Evaluation Tool Suite (draft-irtf-tmrg-ns2-tcp-tool-00.txt), along with a Web page with simulation scripts. The document describes a tool for use in the ns-2 simulator for generating scenarios with typical topologies and traffic models and for evaluation of the results via a range of metrics.
- Lachlan Andrew organised a workshop in November at California Institute of Technology called the TCP Evaluation Suite Round Table, where scenarios for evaluating congestion control mechanisms were discussed. As a result of the workshop, a short paper titled “Towards a Common TCP Evaluation Suite” was written and submitted to PFLDnet2008 (the yearly workshop on Protocols for Fast Long-Distance Networks).
Future plans include the further development of best-current-practice scenarios for the evaluation of congestion control mechanisms in simulators and test beds and building on the paper “Towards a Common TCP Evaluation Suite.” Plans also include completion of the Internet-Draft on Tools for the Evaluation of Simulation and Testbed Scenarios (draft-irtf-tmrg-tools-04). For more information about the IRTF.