report from ietf meeting attendance 2005 -...

R&D N xx/2006

Marius Clemetsen, Geir Egeland, Paal E. Engelstad, Tor Hjalmar Johannessen, Frode Kileng

Report from IETF meeting attendance 2005

Company INTERNAL

http://www.unik.no/~paalee/research.htm

http://heim.ifi.uio.no/~paalee/

http://www.unik.no/~paalee/research.htm

http://heim.ifi.uio.no/~paalee

Company INTERNAL Report from IETF meeting attendance 2005

R&D Scientific Doc.

N xx/2006

Title Report from IETF meeting attendance 2005

ISBN ISSN Project No Program Security Gr. Company INTERNAL No. of pages Date 2006.01.25

Author(s) Marius Clemetsen, Geir Egeland, Paal E. Engelstad, Tor Hjalmar Johannessen, Frode Kileng

Subject headings IETF Meetings

Abstract This document presents the reports from attended IETF meetings1 for 2005. This work has been carried out as part of the standardization work in Telenor R&D.

1 The first meeting was held in Minneapolis, USA (IETF 59, March 6-11). The second meeting was held in Paris, France (IETF 63, July 31. to August 5.). The third meeting was held in Vancouver, Canada (IETF 64, November 6-11).

Telenor R&D N xx/2006

http://www.ietf.org/

Report from IETF meeting attendance 2005 Company INTERNAL

Telenor ASA 2006.01.25

All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher.



Contents

1 Introduction ................................................................................1

2 Relevance for Telenor & recommendations regarding Telenor participation..................................................................2

3 Highlights from 2005..................................................................3

4 Reports from plenary sessions.................................................5 4.1 Plenary sessions for IETF 64............................................................................. 5 4.1.1 IETF Operations and Administration Plenary (Frode Kileng) .......................... 5 4.1.2 Technical Plenary (Frode Kileng)...................................................................... 6 4.2 Plenary sessions for IETF 63............................................................................. 7 4.2.1 IETF Operations and Administration Plenary (Geir Egeland) .......................... 7 4.2.2 Technical Plenary (Paal E. Engelstad)............................................................... 8 4.3 Plenary sessions for IETF 62............................................................................. 9 4.3.1 IESG Plenary (Geir Egeland) ............................................................................ 9 4.3.2 IAB Plenary (Frode Kileng) .............................................................................. 9

5 Reports from selected IETF working groups.........................11 5.1 IPv6.................................................................................................................. 11 5.1.1 6LOWPAN (IPv6 over Low power WPAN) WG ........................................... 11 5.1.1.1 IETF 64 (Frode Kileng) .............................................................................. 11 5.1.1.2 IETF 63 (Paal E. Engelstad) ....................................................................... 12 5.1.2 IPv6 (IP version 6) WG ................................................................................... 12 5.1.2.1 IETF 64 (Frode Kileng) .............................................................................. 12 5.1.2.2 IETF 63 (Geir Egeland) .............................................................................. 13 5.1.2.3 IETF 62 (Frode Kileng) .............................................................................. 14 5.1.3 SHIM6 (Site Multihoming by IPv6 Intermediation) WG................................ 15 5.1.3.1 IETF 63 (Paal E. Engelstad) ....................................................................... 15 5.1.4 V6OPS (IPv6 operations) WG......................................................................... 16 5.1.4.1 IETF 64 (Frode Kileng) .............................................................................. 16 5.1.4.2 IETF 63 (Geir Egeland) .............................................................................. 17 5.1.4.3 IETF 62 (Geir Egeland) .............................................................................. 17 5.2 Mobility ........................................................................................................... 19 5.2.1 CAPWAP (Control And Provisioning of Wireless Access Points) WG ......... 19 5.2.1.1 IETF 63 (Paal E. Engelstad) ....................................................................... 19 5.2.2 DNA (Detecting Network Attachment) WG ................................................... 19 5.2.2.1 IETF 63 (Geir Egeland) .............................................................................. 19 5.2.2.2 IETF 62 (Geir Egeland) .............................................................................. 19 5.2.3 MANET (Mobile Ad-hoc Networks) WG....................................................... 20 5.2.3.1 IETF 64 (Frode Kileng) .............................................................................. 20 5.2.3.2 IETF 63 (Paal E. Engelstad) ....................................................................... 21 5.2.3.3 IETF 62 (Geir Egeland) .............................................................................. 21 5.2.4 MIP4 (Mobility for IPv4) WG......................................................................... 22 5.2.4.1 IETF 63 (Paal E. Engelstad) ....................................................................... 22 5.2.5 MIP6 (Mobility for IPv6) WG......................................................................... 22 5.2.5.1 IETF 62 (Geir Egeland) .............................................................................. 22 5.2.6 MOBIKE (IKEv2 Mobility and Multihoming) ............................................... 23



5.2.7 NEMO (Network Mobility) WG ..................................................................... 23 5.2.7.1 IETF 63 (Geir Egeland) .............................................................................. 23 5.3 Multicast Routing ............................................................................................ 24 5.3.1 MBONED (MBONE Deployment) WG.......................................................... 24 5.3.1.1 IETF 64 (Frode Kileng) .............................................................................. 24 5.3.1.2 IETF 62 (Frode Kileng) .............................................................................. 24 5.3.2 PIM (Protocol Independent Multicast) WG..................................................... 26 5.3.2.1 IETF 64 (Frode Kileng) .............................................................................. 26 5.3.2.2 IETF 62 (Frode Kileng) .............................................................................. 26 5.3.3 MSEC (Multicast Security).............................................................................. 26 5.4 Security ............................................................................................................ 27 5.4.1 ENROLL (Credential and Provisioning) WG.................................................. 27 5.4.1.1 IETF 62 (Tor Hjalmar Johannessen)........................................................... 27 5.4.1.2 IETF 62 (Tor Hjalmar Johannessen)........................................................... 27 5.4.2 ISMS (Integrated Security Model for SNMP) WG ......................................... 28 5.4.2.1 IETF 62 (Tor Hjalmar Johannessen)........................................................... 28 5.4.3 MOBIKE (IKEv2 Mobility and Multihoming) WG........................................ 28 5.4.3.1 IETF 63 (Paal E. Engelstad) ....................................................................... 28 5.4.3.2 IETF 62 (Tor Hjalmar Johannessen)........................................................... 28 5.4.4 MSEC (Multicast Security) WG...................................................................... 29 5.4.4.1 IETF 62 (Frode Kileng) .............................................................................. 29 5.4.5 PKIX (Public-Key Infrastructure) WG............................................................ 29 5.4.5.1 IETF 62 (Tor Hjalmar Johannessen)........................................................... 29 5.4.6 SAAG (Security Area Advisory Group).......................................................... 31 5.4.6.1 IETF 62 (Tor Hjalmar Johannessen)........................................................... 31 5.5 Other groups covered by watcher .................................................................... 33 5.5.1 DHC (Dynamic Host Configuration) WG ....................................................... 33 5.5.1.1 IETF 62 (Frode Kileng) .............................................................................. 33 5.5.2 DNSOP (Domain Name System Operations) WG .......................................... 33 5.5.2.1 IETF 64 (Frode Kileng) .............................................................................. 33 5.5.2.2 IETF 62 (Frode Kileng) .............................................................................. 34 5.5.3 ENUM (Telephone Number Mapping) WG .................................................... 35 5.5.3.1 IETF 64 (Frode Kileng) .............................................................................. 35 5.5.3.2 IETF 62 (Frode Kileng) .............................................................................. 35 5.5.4 GROW (Global Routing Operations) WG....................................................... 36 5.5.4.1 IETF 64 (Frode Kileng) .............................................................................. 36 5.5.5 Session Initiation Proposal Investigation (Sipping)......................................... 36 5.5.5.1 IETF 64 (Frode Kileng) .............................................................................. 36

6 Reports from Area Meetings ...................................................38 6.1 IETF 64 ............................................................................................................ 38 6.1.1 APPTSV (Applications/Transport Joint Session) Meeting (Frode Kileng) ..... 38 6.1.2 OPSAREA (Operations and Management Open Area) Meeting (Frode

Kileng) ............................................................................................................. 38

7 Reports from BoF sessions ....................................................40 7.1 IETF 64 ............................................................................................................ 40 7.1.1 16ng (IPv6 over IEEE 802.16(e) Networks) BOF (Frode Kileng) .................. 40 7.1.2 VOIPEER (VoIP Peering and Interconnect) BOF (Frode Kileng) .................. 41 7.2 IETF 63 ............................................................................................................ 41 7.2.1 AUTOCONF (Ad-Hoc Network Autoconfiguration) BoF (Paal E.

Engelstad) ........................................................................................................ 41



7.2.2 NETLMM (Network-based Localized Mobility Management) BOF (Paal E. Engelstad).................................................................................................... 42

7.2.3 MONAMI6 (Mobile Nodes and Multiple Interfaces in IPv6) BoF (Geir Egeland)........................................................................................................... 43

7.3 IETF 62............................................................................................................ 43 7.3.1 6LOWPAN (IPv6 over Low power WPAN) BOF (Frode Kileng) ................. 43 7.3.2 AUTOCONF (Ad-Hoc Network Autoconfiguration) BoF (Geir Egeland) ..... 45 7.3.3 BTNS (Better-Than-Nothing Security) BOF (Frode Kileng).......................... 45 7.3.4 TC (Tunneling Configuration) BoF (Geir Egeland) ........................................ 46



1 Introduction This document presents the reports from IETF meetings2 for 2005. The authors are: Marius Clemetsen (editor), Geir Egeland, Paal E. Engelstad, Tor Hjalmar Johannessen, and Frode Kileng. All are from the R&D department of Telenor.

Currently (per 15/12 2005) the IETF is divided in 8 areas: Applications Area (15 groups), General Area (2), Internet Area (27), Operations and Management Area (21), Real-Time Applications and Infrastructure Area (new area with no groups yet), Routing Area (15), Security Area (19) and Transport Area (26).

The main work in following up the IETF and providing input to this report is today carried out in Telenor R&D by a few people. This means that only a selected set of groups can be covered, and these fall into the following main technology categories:

• Authentication in access networks • IPv6 • Mobility and wireless • Multicast Routing • Security • Other groups covered (some groups that does not belong in any of the above

categories)

The content of the report is divided in the following main sections:

First the relevance of IETF for Telenor is briefly discussed, along with recommendations regarding Telenor participation (2).

Then a summary of important issues/discussions/decisions are covered in the section on “Highlights from 2005” (chapter 3).

In chapter 4 follow the reports from plenary sessions, and in chapter 5 the working group meetings (mapped into the above categories).

Chapter 6 covers 2 of the area meetings at IETF 64.

The last chapter (7) contains reports from attended BoF (Bird of a Feather) sessions. These sessions are held to check if there is sufficient interest in a new topic to create a new working group for it (and also to get feedback on the topic, and on the need for a new working group to cover it).

2 The first meeting was held in Minneapolis, USA (IETF 59, March 6-11). The second meeting was held in Paris, France (IETF 63, July 31. to August 5.). The third meeting was held in Vancouver, Canada (IETF 64, November 6-11).

Telenor R&D N xx/2006 - 1

http://www.ietf.org/


2 Relevance for Telenor & recommendations regarding Telenor participation

The work carried out in the IETF is of high importance to Telenor. IETF makes specifications/standards for the basic building blocks of the Internet communication infrastructure. First of all the IPv4 and accompanying protocols (like TCP/UDP, BGP, and OSPF) have been standardized in the IETF, and is under constant revision. Examples of protocols that have been produced in the IETF during the last decade are those related to IPv6, Mobile IP, IP Multicast, IP Quality of Service, SIP, layer 3 VPNs and MPLS (and there are many more). Some of these relatively new technologies are being used in the Telenor networks today, and some will be important in a short timeframe.

The IETF is working in areas that may directly influence future business models of Telenor. Examples are solutions for peering between VoIP providers, and new messaging solutions like SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). In other areas, IETF are working on solutions that will influence future service provisioning in Telenor, for example multicast distribution and provisioning for triple-play services. In addition, the work in the IETF influences standardization activities elsewhere (and visa versa, as other standardization organizations provide input to the IETF). An example is SIP, which has been adopted (and somewhat modified) by the 3GPP.

The effect of this is that many people in Telenor are interested in what goes on in the IETF. Fortunately the IETF has a very open policy when it comes to the availability of their specifications, and some have argued that this may also be one of the reasons for the success of the IETF. Still, getting to know what goes on in the IETF working groups at any given time requires some effort, and is hard to do without setting aside time for this, and attending IETF meetings. The investment may be very rewarding, as the engineering community of the IETF is highly competent. The IETF is also an arena where one may get in contact with experts from equipment vendors like Cisco, Nokia, etc.

Our participation in the IETF has a direct influence on other projects in R&D. Many examples exists where results from our participation in the IETF has been, and still are, used in both research projects and in joint activity projects with business units.

We recommend that the budget for the IETF is kept “as is”, as a higher degree of participation in IETF meetings will be difficult due to R&D travel restriction policies.

2 - Telenor R&D N xx/2006


3 Highlights from 2005 The IETF restructuring process continued in 2005 with the foundation of The IETF trust as one important event. The trust is a private legal construct established under the laws of Virginia/USA allowing assets (IPR and other property) to be held and administered for the benefit of the IETF and the Internet Standard Process. Harald Alvestrand stepped down as IETF chair and Brian Carpenter from IBM has taken on the job as new IETF chair.

The restructuring of many WGs was initiated by the decision to create a new working group area, the RAI (Real-time Applications and Infrastructure Area) Area. This is basically a split of the TSV (Transport) Area where the real-time related work is gathered in the new RAI Area.

A need for discussing larger Internet architectural issues was identified by IAB in 2005 and a new mailing list was set up for this purpose. The architecture-discuss list serves as a technical discussion forum for all members of the IETF community that are interested in larger architectural issues. It is meant to be an open discussion forum for all long and/or wide range architectural concerns related to the Internet Architecture. In particular, it may be used to discuss and bring forth different points of view on controversial architectural questions.

In 2005, it was decided to shut down the IPv6 WG. The reason for this is that all the major work items on the WG charter has been finalized, and since IPv6 issues is an item on the agenda for ”all“ IETF WGs, there is not a need for a dedicated group working on generic IPv6 protocol issues. The closing of the WG is considered as a sign of the maturity of IPv6 and there would be no problem handling new or unsolved IPv6 issues in the context of existing or new IETF WGs. It remains to be seen what the IETF view will be on the fact that ARIN has proposed to raise the HD ratio to 0.94 of IPv6 address utilization. Other RIRs (Regional Internet Registries) are discussing to do the same. The current RIR policy, and an IETF recommendation, is to use a HD ratio of 0.8 to measure address utilization of /48 to end sites. Some RIR are already allocating huge address blocks (/19), and some people are asking how much space do we really have.

After a couple of BOFs in 2005 on SIP peering and interconnection between carriers/providers/”managed domains“, it was decided to found a new WG on this subject. The WG is named SPEERMINT (Session PEERing for Multimedia INTerconnect). Another new potential WG is the 16ng to address IPv6 over WiMAX, or IEEE 802.16(e) Networks that was the subject for a BOF at the IETF64. Further on, 2005 was the first year with an official WG meeting of the 6LOWPAN working on the mapping of IPv6 over IEEE 802.15.4. The group has produced a lot of drafts and the first implementation was also announced in 2005.

The MBONED (Multicast BackBone Deployment) WG was under consideration to be shut down in 2005. The WG chair was retreating and the AD, who stated that the 10-year-old WG could not be described as ”very successful“ due to the low degree of operational MBONE deployment, wanted the WG to consider a closure. There was a consensus to continue the work and the new chair will probably come from an operator. In 2005 there has been a lot of work in MBONED on issues like access control, admission control and accounting, i.e. mechanisms necessary to meet the requirements of commercial multicast.

During 2005, the working groups developing technology important for the wireless Internet has consisted of 13 working groups covering areas such as Application, Internet, Operations and Management, Routing and Security. There have also been several BOFs on mobility-related topics during 2005: One of the most interesting is the MONAMI6 working



group, which recently was formed. It will come up with a problem statement associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support.



4 Reports from plenary sessions

4.1 Plenary sessions for IETF 64

4.1.1 IETF Operations and Administration Plenary (Frode Kileng) In the RFC Editor report, Joyce Reynolds reported that there still are problems with a queue backlog. But 1/3 of the backlog is in the "Await author state" when input from author is required. She also presented a procedure on how to handle normative references to unpublished drafts that has been a major problem for a long time. Documents with such normative references can be submitted to the RFC editors but will be given the state "MISSREF" until all their normative references also has been submitted.

Barbara Roseman, operations manager of IANA reported on the strategy on how IANA will deal with the problem of a long request processing time. IANA has increased the staff to 7 and will engage more people if/when needed. The current processing time is now below 30 days.

Lucy Lunch, chair of the IAOC (IETF Administrative Oversight Committee), gave the general report at this plenary. She informed about the foundation of the IETF trust that is responsible for handling all IPR (Intellectual Property Rights) of IETF. The IETF trust is a private legal construct established under the laws of Virginia/USA allowing assets (IPR and other property) to be held and administered for the benefit of the IETF and the Internet Standard Process. Information about the trust will be sent to the mailing list to gain consensus. IAOC is currently negotiating a service agreement with NeuStar covering secretariat and meeting services for IETF. The negotiation of this agreement will soon be finished. In the discussion at the end of the plenary, Margaret Wasserman complained about the secrecy covering this negotiation. Lynch answered that full openness was impossible due to the business nature of this negotiation. Anyhow, Lynch agreed to send out available information to the IETF-mailing list to reach a consensus for this process.

Brian Carpenter gave the IETF Chair report. IETF64 had 1291 registered attendees (vs. 1309 in Washington at IETF61 one year earlier) from 40 countries (26 in Washington). Brian speculated if the increase in number of countries was due to easier Visa rules for attending the USA and requested feedback from people who had this experience. Also, at this meeting, the number of participants from China has increased and was this time identified as a separate country on the pie chart dividing the number of participants per country. Brian informed about the publication of "narrative minutes" from IESG teleconferences that will be available at http://www.ietf.org/IESG/iesg-narrative.html. There is also a new web page describing active IESG projects available at http://unreason.com/jfp/iesg-projects.html. Brian also presented the PESCI (Process Evaluation Committee of the IETF), a committee working on IETF process changes that has produced a first draft identifying a list of principle for the change process. He ended his speech by informing that Vint Cerf and Bob Kahn was not present this evening since they where receiving the "US Presidential Medal of Freedom" for "designing the software code that is used to transmit data over the Internet"....

In addition to the discussion about the lack of transparency of the IAOC negotiations with NeuStar, the Open Meeting part of this Plenary, only a couple of discussion items worth mentioning. In addition to someone who complained that the web pages of IETF look like "crap", Haner was concerned that different routines is used in the different WG to decide on what will become WG work items and that this influences the standardization effort. One of


http://www.ietf.org/IESG/iesg-narrative.html

http://unreason.com/jfp/iesg-projects.html


the IESG members answered that it is just a matter of fact that groups do their work in different ways and that this should not be standardized, but if there is unfairness in the process this is a problem that must be handled by going through the appeal process. Another participant raised his concern that many work groups adapt work items that is not covered by its charter.

4.1.2 Technical Plenary (Frode Kileng) Aron Falk started the meeting by giving the IRTF (Internet Research Task force) report. Two new research groups (RG) have been initiated. "The Internet Congestion Control research group" is one of them and is expected to work on a roadmap extending congestion control. The status of some of the other RGs are as follows: The Anti-Spam RG is developing a draft on using the DNS to distribute blacklists and white lists. The Crypto-Forum RG is working on an alternative algorithm to the broken SHA-1 hash function. The Network Management RG is working with P2P approaches to network management.

The IRTF technical presentation was given by David McGrew from the Crypto Forum Research Group on the subject "Problems and progress with crypto hash functions". The goal of the Crypto Forum RG is to advice the Internet community on crypto technology, to bridge between theory and practice, bringing new cryptographic techniques to the Internet community and to promote an understanding of these mechanisms via informational RFCs. The goal of crypto hashes is to find a function that is collision resistance, but crypto hash functions is commonly treated as the "crypto hammer"; commonly used and misused. After the recent break of the NIST SHA1 (Secure Hash Algorithm 1), the algorithm is considered to be so bad that laptop computers can break it. The goal of SHA1 was to give 280 combinations that would be suitable until 1 of January 2011 but the break of SHA1 shows that it actually only gives 263. Status of the other crypto hash algorithms are: SHA-2224 algorithm gives 2112 combinations and is intended to last until 2031 and SHA-256, with 2128 is intended to be used after 2030. Since a strategy to improve SHA1, i.e. with the goal of 280, will only make it usable for 4 more years, a shift to SHA256 is instead considered as the best step forward.

The break of SHA1 makes it unusable for Third Party Digital Signatures and also the raw SHA-1 is considered broken for message authentication. Although it still is usable for the authentication of entities/peers of digital signatures (entity authentication), for HMAC-SHA1 based message authentication and key derivation mechanisms, NIST (National Institute of Standards and Technology) wants to deprecate SHA-1 for all usage.

The deprecation of SHA-1 has a lot of consequences for IETF since a lot of references and specification of use of SHA-1 makes a revision of a large number of RFCs necessary. SHA-1 is referenced in 151 RFCs (101 standards, 40 informational and 19 obsoleted RFCs), HMAC-SHA1 has 121 references (84 standards, 33 informational and 22 obsoleted), SHA2 has 5 references (4 standards and 1 informational) and MD5 360 references in RFCs! (190 standards, 33 informational and 22 obsoleted).

The Crypto Forum RG has the following recommendation related to crypto hash techniques: Replace SHA-1 and MD5 in specifications now and for "Message Authentication Code" (MAC) use AES-based MAC or authenticated encryption mode and for other applications, use SHA-256 or carefully analyze security needs. Also, expect more changes in the future and build in algorithm agility.

The next item on the agenda was an update from IAB (Internet Architecture Board) given by Leslie Daigle. In 2005, IAB has had 3 focus areas: IPv6, Internet Architecture and "Bad net traffic". For IPv6, the IAB held an IPv6 multihoming BoF at NANOG (North American Network Operators' Group). Regarding the Internet Architecture, IAB has initiated a new



mailing list as an arena for discussing architecture related issues. In addition IAB is finishing the IDN (Internationalized Domain Names) ad-hoc group final report. Also, the draft "TLD (Top Level Domain) considerations" ("what's in a name"), has been approved and submitted to the RFC editor queue. On the IAB Bad net traffic activities, a revised document relating to "DoS Attacks" has been submitted.

The last item on the agenda was the "Town Hall Meeting" that was introduced at IETF63 in Paris. One participant raised his concern that IAB should be more involved in the initiation and creation of new BoFs, not just participate. Another followed up this issue and stated that there is a problem that new BoFs discusses to create new protocols when existing protocols could be utilized and that IAB should contribute to steer this. Another subject was a request for developing mechanisms for "running anything over anything" (running x over y, not only over UDP/TCP). One IAB member said that the complexity is too high and makes things to complicated and that we should not invite to do this. Another participant stated that it would just be a "mess" due to congestion control mechanisms in the net that must work over the "mapping layer". The last item worth mentioning was a complaint from a Japanese participant that the Routing WG has rejected a proposed work item on hierarchical routing, an area of work that is a hot subject in Japanese communities, since the WG chair did not wish to take up more work. One IAB member answered that IAB has for a long time worked in this area and considers hierarchical routing to be "bad". The authentication of delegations of sub layers in the routing hierarchy is difficult, but in some Asian countries it is simpler due to a strict hierarchical configuration of the network, often due to strict control by the governments.


4.2.1 IETF Operations and Administration Plenary (Geir Egeland) At the plenary it was reported that there are 1454 participants at the Paris meeting. People from 36 countries attended the meeting.

A new administrative unit was presented, the IAOC (IETF Administrative Oversight Committee). The IAOC's role is to provide appropriate direction to the IAD (IETF Administrative Director), to review the IAD's regular reports, and to oversee the IASA (IETF Administrative Support Activity) functions to ensure that the administrative needs of the IETF community are being properly met. The IAOC's mission is not to be engaged in the day-to-day administrative work of IASA, but rather to provide appropriate direction, oversight and approval. The IAOC's role is to direct and review, not to perform the work of the IAD and IASA. The role of the IAOC is presented in RFC 4071.

The Tools team has been active for one year, and some of the results can been seen at http://tools.ietf.org.

The chair of the IETF, Brian Carpenter, presented the next steps for the IETF. He presented some of the ongoing work within the IETF and listed some of the things that still are open:

• Need to revisit the engineering practice of the WG to improve quality and timeliness of the WG output. Some of the works from the tools team can help to manage documents.

• Cross-area review of drafts needs to be improved. The IETF must find a better way to make sure that all the aspects of a draft is reviewed by all areas before being sent to the IESG.

• The throughput rate of the IESG is improved, but must still get better.


http://tools.ietf.org/


4.2.2 Technical Plenary (Paal E. Engelstad) Technical presentation:

Steve Bellovin gave a technical presentation on application security. A summary of this follows first:

The reason the security requirements in IETF have changed recently, is that the threats have changed. The world has changed. Hacking makes profit. Distributed password-guessing, sniffer-programs, protocol level attacks (instead of exploiting bugs), tailored worms and viruses, etc.

The main problems today are eavesdropping (e.g. wireless), monkey-in-the-middle, ARP-spoofing, Evil-twin access points and routing attacks. The reason for not seeing an attack is normally because easier attacks are available.

Due to changed threats, the following "solutions" don't work anymore:

• plaintext passwords • challenge/response based on passwords • crypto without bilateral authentication

A main question is: "Who is at the other end of the connection?"

• TCP, TLS-over-TCP (did you check the certificate?) • Fake URIs: Paypa1.com, for example. • Multi-party protocols make this much worse: BGP, SIP, AAA, p2p, etc...

Secure Application Protocol Design Identify different parties. How is identity and authorization established? Identify trust relationships between them.

Analysis must be made early on. Crypt and trust is very hard to add later, especially with multi-hop and/or multi-party communication.

IAB update: IAB has discussed:

• False assumptions about DNS names • Architectural implications of link-layer indications

IAB is working on:

• IPv6: pieces missing for successful uptake • Further documentation of Internet engineering principle to make "common

knowledge" IRTF report:

Internet Congestion Control Research group is expected to be formed. The AIMD (Additive Increase Multiplicative Decrease) algorithm of TCP has shortcomings. Explicit Congestion Protocol (XCP) was mentioned as an example.

Transport Models Research Group will also be formed. Charlie Perkins asked for an "objective" simulation environment to be used to evaluate protocols.



It was also discussed how to attract academics to solve the problems IETF wants to be addressed, and how to make their contributions useful (e.g. favor usefulness over for example originality which is favored in academic forums today).

Technical discussion

• How about focusing more on the end-user experience? o Solve user-related out-of-the-box zeroconf? o E.g. what should we have put into SIP to make a VoIP phone to configure

itself easily? o The easiest parameter to configure is the one you don't have.

Why not seek simplicity from the outset? o The people who design the end-user experience are not here at the IETF o Mandatory sections on user-experience is probably not a good idea to

address this • Protocol Models in RFC4101 are very useful. It should be disseminated • There is concern about the growing complexity and total number of protocols

o Also a problem that functions are re-invented in different layers o User expectations are increasing, which increases complexity. o Features vs. complexity - hard to "add" simplicity

• Put some layers on a diet? We must pull together to regain the original simplicity.


4.3.1 IESG Plenary (Geir Egeland) It was reported that a total of 1167 persons attended the 62nd IETF meeting.

The biggest news from the IESG plenary was that Harald Alvestrand steps down as IETF chair and Brian Carpenter from IBM takes on the job as new IETF chair.

He presented his goals for chairing the IETF as:

• Make the IESG able to steer. • Make the Admin Restructuring work • Focus on improving IETF Progress. • Focus on vital liaison relations.

The PROTO team reported that a new process for sending/getting feedback from the IESG has been implemented. From now, every document sent to the IESG for review, will get appointed a "shepherd" to it. This will makes things easier and give the WGs more control and information about the reviewing process.

4.3.2 IAB Plenary (Frode Kileng) The IAB chair started with highlights from the new IAB drafts. Examples are "What's in a Name: False Assumptions about DNS Names" (draft-iab-dns-assumptions-02), "Design Choices When Expanding DNS" (draft-iab-dns-choices-00.txt), "Considerations for Selection of Techniques for NAT Traversal" (draft-iab-nat-traversal-considerations-00.txt), "IAB Thoughts on the Role of the Internet Research Task Force (IRTF)" (draft-iab-irtf-00.txt). In the RFC editor queue for submission we can find the draft "Writing Protocol Models" (draft-iab-model-03.txt). An announcement of Aaron Falk as the new IRTF chair was also given. Nominated candidates for the ISOC board of trustees are Fred Baker, Scott



Bradner, John Klensin, Jordi Palet, Martinez, Marshall and Rose. The announcement will be given within two months.

Pekka Nikander from Ericsson Research Nomadic Lab gave a report from the HIP (Host Identity Protocol) research group. HIP is a proposal to separate the identifier and locator at the network layer of the network layer. The "HIP layer" is placed in the boundary between hop-to-hop and end-to-end, i.e. below IPSec and above the "fragmentation" sub-layer. The idea of HIP was briefly discussed at two IETF BOFs in 2001. After a period of "development in the corridors", a HIP WG was founded in 2004. The base protocols are more or less ready and 4 interoperating implementations exists. Further work is needed on issues as mobility, multi-homing, NAT traversal and infrastructure. It covers a new name space based on public keys and a protocol for discover and authenticate the bindings between the identifier and locator. The HIP WG has produced components for experimental deployment of the base protocols and services (DNS, registration, and rendezvous) and is preparing for real time experiments. Pekka ended his presentation by inviting anyone interested to try out one of the publicly available implementations.

The next item on the agenda was a technical presentation given by Boeing of their Internet-solutions that gives full wireless Internet connectivity ("real time", VPN support, NAT, multicast support, up to 10-500kbps) on their planes without the need for installing any client software and how they support handover between satellites/ground-stations. They stated that they couldn't build a solution based on current mobility standards since the existing ones focus on host mobility rather than network mobility and network mobility support is needed since a typical travel between Europe and Asia uses 3 different ground stations and 4 different satellites in geostationary orbit. The planes are equipped with one mechanical steered satellite antenna. Many eyebrows was raised when the revealed that the mobility handover support was based on BGP! Each plane has a /24 network and is connected through a satellite which further on is connected to a specific ground station. When the plane moves into the coverage of a new satellite, a BGP route update for the /24 is sent to the backbone routers to implement mobility through updating the global routing tables! Although this solution actual works, some future challenges exists. Since the number of BGP routes increases in the global default free zone, he expect to see that core routers start to filter out such small BGP route announcements. Although the handover time between ground stations is a few seconds, it does not seem to be a problem, especially since the handover typically happen only a couple of times on intercontinental flights. Anyway, the speaker challenges the IETF to develop solutions for "global mobility". He also announced that Singapore Airlines intends to distribute television over IP using this solution.

A participant was told that the reason he did not get his SIP phone to work was due to the well-known NAT problem.... During the IAB open plenary session, a participant challenged IETF to stop working on NAT-traversal solutions when the answer is IPv6 since this makes application developers work on NAT-traversal mechanisms instead of creating good applications. Another participant suggested starting to market IPv6 as a "NAT traversal solution". An IAB representative stated that we have to take the reality into consideration, i.e. that we live in an IPv4 world and that some application developers may rather tell IETF to stop wasting resources on IPv6 and work on NAT-traversal techniques instead.

Bob Kahn asked about opinions from IAB on what ITU is doing in the area of Internet standardization. An IAB representative asked if there exists a plan within IESG/IAB to discuss cooperation with ITU. A joint steering committee with ITU and IESG members exists that discuss these matters on a weekly basis.



5 Reports from selected IETF working groups

5.1 IPv6

5.1.1 6LOWPAN (IPv6 over Low power WPAN) WG 5.1.1.1 IETF 64 (Frode Kileng)

[At November 7, the referee arrived at 14:40 due to collision with another meeting.]

Security considerations for 6LOWPAN were one item on the agenda. The strategy forward was not clarified but there the following proposal to was presented: 1) Advocate the IEEE 802.15.4b security mechanisms, 2) Recharter the WG to work on document(s) focusing on key-management techniques, 3) to determine application/IP-layer security for 6LOWPAN and 4) write the security considerations into the problem statement document. A problem with this strategy is that the 802.15.4b is not publicly available.

Another interesting item on the agenda was a discussion related to interoperability between ZigBee and 6LOWPAN. Geoff Mulligan introduced the discussion by identifying two potential areas of conflicts: 1) the network frame format with ZigBee's network frame vs. 6LOWPAN adaptation layer. Due to IPR, Mulligan was not allowed to reveal details about the ZigBee frame format. 2) The Beacon payload defined within ZigBee but currently undefined in 6LOWPAN. 6LOWPAN is "beacon-less" but uses the beacon in the PAN binding process. The beacon response message contains an opaque beacon payload that ZigBee uses to identify network profile type (home controls, commercial, IPv6, cluster tree). Mulligan felt that 6LOWPAN needs to clarify if 6LOWPAN should use the payload for the exchange of additional information. During the discussion, there seemed to be objections that ZigBee interoperability was an area of concern for 6LOWPAN since interoperability is not needed since ZigBee and 6LOWPAN is separate islands. But there seemed to be an interest in utilizing the beacon payload format for the exchange of extra information.

[The scheduled 6LOWPAN meeting ended at Monday with many items still left on the agenda. Due to this, it was arranged an ad-hoc meeting the next morning with the focus on routing issues].

A comparison of LOAD and AODV was the first item on the agenda at the ad-hoc meeting. LOAD is a simplification of AODV where the main differences are that LOAD does not support destination sequence numbers, that only the destination is allowed to answer routing requests (RRREQ and that LOAD doesn't use local repairs on link failures but instead requires a node to report the link failure back to the originator.

LOAD also supports to utilize link quality (LQI) of the 802.15.4 physical layer. There was also given a comparison of the DYMO-Low vs. the DYMO routing protocol. DYMO-Low is a simplification with properties that makes it a better solution for use in a .15.4 environment.

Another interesting item on the agenda was issues related to interoperability with Internet. I.e. how to route traffic between 6LOWPAN and other IPv6 networks. The speaker stated that to use different IPv6 prefixes to separate WPANs is not enough for identifying outbound traffic to external IPv6 network. One proposal is to use a default GW (gateway) mechanism and use a flag-bit in the adaptation layer frame format to flag outbound traffic to external IPv6 networks.



The meeting ended with a report on a 6LowPAN implementation results. A Korean group has implemented 6LOWPAN solutions on a CC2420DBK board from Chipcon. They have implemented the protocol stack, including the adaptation layer, the LOAD, DYMO-Low and HiLow routing protocols and also the SSLP for 6LOWPAN. They are studying different topologies performing delivery ratio measurements. Beside actual measurements, they have built a simulation framework for LOAD on NS-2. Data from both the measurements and the simulation is available in the proceedings of IETF64. 5.1.1.2 IETF 63 (Paal E. Engelstad)

(See also earlier BoF-sessions on 6LOWPAN - IETF 61 and IETF 62).

Right now the 6LOWPAN (IPv6 over Low power WPAN) WG focus on the core problem, and is not chartered to address wider problems. This means that at the moment it is most important for the WG to get the problem statement and adaptation layer documents finalized. Other work, such as Neighbor discovery, service discovery etc, might be addressed later after having re-chartered. The problem statement document is soon ready for last call. It was discussed to which extent application assumptions shall be made. Some commented that the problem document - and also the format document - limits the use of 6LOWPAN, and does not fit to a number of applications they are currently developing for 6LOWPAN. The chair claimed that application assumptions must be made.

Apart from some bit and field length changes in the format, there are mostly editorial changes to the format document.

There are 6 other submissions that are currently out of scope. However, the WG discussed them in the meeting to clarify how these works-in-progress might affect on the current core documents:

Neighbor discovery draft was discussed. Christian H. pointed out that this document is needed to provide a full understanding of how the format document works/might work. Without this document, the format document can be misunderstood. Charlie P. pointed out that there are overlap between ND in 6LOWPAN and that in MANET.

Is the mechanism in the Interoperability document really only a NAT? It was also asked whether the WG should address the use the optional 16-bit MAC addresses mentioned in the document. It was concluded that this is interesting work but it does not affect the core documents.

In relation to the MOBOPTS documents it was questioned if 6LOWPAN is a PAN or is it an Internet of PANs. It is important to clarify this, because it affects on mobility.

In summary, this was an efficient meeting that clarified a large number of details required for the WG to move forward, but few new and interesting issues came up.

5.1.2 IPv6 (IP version 6) WG 5.1.2.1 IETF 64 (Frode Kileng)

Ralph Droms from Cisco presented the draft "Considerations on M and O Flags of IPv6 Router Advertisement" (draft-ietf-ipv6-ra-mo-flags-01.txt) discussing issues related to stateless auto configuration. A host can get IPv6 addresses from several sources: from routers in RA (Routing Advertisement), DHCPv6 servers, and the host using the address privacy extension (RFC3401). The challenge is how to combine them on the host, i.e. the rules for combining, how the ISP/IT department can tell hosts which address configuration


http://portal.telenor.no/servlet/ShowResource?id=147353&view=view_resource

http://portal.telenor.no/servlet/ShowResource?id=161425&view=view_resource


source it should use and how an ISP/IT department can enforce that those rules are followed.

Kurt Erik Lindqvist presented the status report of the "IPv6 AdHoc Group". This ad-hoc group was initiated to give RIRs (RIPE, ARIN, etc) input on how to deal with allocation requests on big IPv6 address blocks. The group has released the draft "Considerations on the IPv6 Host density Metric" (draft-huston-hd-metric-01.txt), the "RFC4147 Proposed changes to the format of the IANA IPv6 registry" and the "RFC4159 Deprecation of ip6.int". Currently, the group is working on the issues related to the administration of the IANA special purpose address block (2001::/23), like guidelines for allocation from the block and assignments of "protocol specific addresses". This work is on the agenda for IAB at the IETF64.

Bob Hinden imitated a discussion of the process of advancing core IPv6 specifications to standards. It was proposed at the IETF63 in Paris to request IESG to grant Internet Standard status on the core protocols. The issue here was to discuss how to meet the requirements to this status change like demonstrating that significant implementations and successful operational experience has been obtained and that the standards has a high degree of technical maturity. Margaret Wasserman, the Area Director, stated that she had checked this and that it actually was no other formal requirement than that the WG agreed and that the IESG agreed in this status update. Each document must be put forward in this process independently and Margaret proposed to start with some of the core protocols. In the discussion, the chair proposed that the WG should write an IPv6 status report as a step in this status change process. Several attendees felt that this was not necessary and that such IPv6 status reports could be located everywhere. There was also a discussion on how to handle problems/bugs in the standards. Pekka Savola stated that there is not a requirement that a document/standard is flawless to go through this final step in the standardization process and that this could be solved by releasing new drafts into the standardization process. Jordi Palet proposed to set a deadline for fixing flaws in the standards and then just proceed with the process.

The final item on the agenda, and also on the IPv6 WG agenda ever, was a discussion about the future of the IPv6 WG. Brian Haberman, chair of the WG, initiated the discussion by concluding that all work on the WG charter has been done and only a few minor items still remain. The future for IPv6 is also a change from one specific WG on IPv6 to address IPv6 considerations in "all" IETF WGs, a change that has been ongoing for years already. Brian Haberman proposed that IETF64 should be the last face-to-face meeting for the WG but that the mailing list would still be active for a long time as a place for general IPv6 discussion. There were only a few objections in the discussion afterwards due to uncertainty on how to handle specific existing and upcoming IPv6 issues. Margareth Wasserman, the AD, reassured that the closure of the WG is a sign of IPv6 maturity and that there is no problem handling new/existing IPv6 issues in the context of IETF and compared this to how things get settled in IPv4 without anyone calling for an "IPv4 WG. IPv6 issues will be solved where they belong, i.e. application specific issues in APP-area WGs, routing issues in RTG-area, etc. Another sign of the maturity was the message from the KAME this week that the KAME-project will be shut down in the beginning of the next year. After going through a long list of people to thank, Bob Hinden officially declared the IPv6 WG to be dead.

IPv6 WG is dead - Long live IPv6! 5.1.2.2 IETF 63 (Geir Egeland)

The draft that caused the most discussion was draft-narten-ipv6-3177bis-48boundary-00.txt.



The reason behind the draft is that some RIRs want to allocate /56 rather than /48s. The draft discusses whether it makes sense to revisit/revise current addressing policies based on experience gained since 1998. The current addressing architecture is that the /64 boundary is architectural, and very costly to change, but the space to left of /64 is policy managed. The /48 is a policy boundary. The current RIR policy is to use a HD ratio of 0.8 to measure address utilization of /48 to end sites. Some RIR are already allocating huge address blocks (/19), and some people are asking how much space do we really have. Should we plan address space for 100 years? In 2050, /48 per person means that 1/128 of the aIPv6 address space used. ARIN has already proposed to raise the HD ratio to 0.94. We may also see a proposal to change /48 to /56 for Small Office/Home Office (SOHO) at the next ARIN meeting. The other RIRs are also discussing to do the same. There was consensus to make this a working group document, and the work should include all implication of changing the /48 policy to /56. This topic was discussed in the July edition of the ISP column: (http://ispcolumn.isoc.org/2005-07/ipv6size.html).

Next Steps for the IPv6 WG was presented since the working group is scheduled to close by the end of 2005. Since 1994 the WG have published 61 RFCs, and the core protocols went to Draft Standard in 1998. The IPv6 chairs recommend that the core protocols go to Full Standard and already meet the requirements as specified in RFC 2026.

The proposed list of core protocols:

• IPv6 • Address Architecture • ICMPv6 • Neighbor Discovery • Stateless Autoconfiguration • Path MTU Discovery

5.1.2.3 IETF 62 (Frode Kileng)

Bob Hinden presented issues raised during the WG Last Call of the "IP Version 6 Addressing Architecture" (draft-ietf-ipv6-addr-arch-v4-01.txt). One item discussed was a suggestion from Pekka Savola to deprecate IPv4 mapped IPv6 addresses. This has been discussed on the mailing list but no consensus has been made. The meeting showed a consensus to deprecate them.

Dave Thaler presented the "Bridge-like Neighbor Discovery Proxies (ND Proxy)" (draft-ietf-ipv6-ndproxy-01.txt) which addresses the problem of bridging several subnets when a level-2 bridge does not support no promiscuous mode or when there doesn't exists heterogeneous level-2 addresses. The ND Proxy solution is similar to what is found in IPv4 ARP Proxies available today. A typically application for this is for bridging support in 802 wireless networks. The ND proxy was accepted as a WG work item in 2003 and was just sent through a WG last call. Loop prevention was a major issue raised during the LC and several solutions to this problem was discussed at this meeting.

One of the main agenda items was a presentation of the IAB IPv6 ad-hoc committee by Thomas Narten (IBM). This is the first time this committee was presented. The background for the committee is that RIRs are now receiving requests for very big allocations of address space (>/23. RIRs then went to IANA for advice on how to handle these requests. IANA wanted advice on how to handle this and also some other IPv6 issues. IAB then founded this ad-hoc committee that consists of Narten, Hinden, Haberman, Lindquist, Huston and Wilson). The committee specifies a clarifying documentation (in RFC) about how IANA manages v6 space: (draft-huston-ip6-iana-registry-05.txt and IANA pages). Current focus of this is to define IANA and RIRs policies for allocations of large address


http://ispcolumn.isoc.org/2005-07/ipv6size.html


spaces. How big should the IANA-to-RIR allocations be? Currently this is /23 but in future /12 or /16? When a RIR is allowed to ask for more space, i.e. the question of reserving space vs. utilization. Normally adjacent blocks are held off to allow for new requests. The question is then how long such blocks should be reserved?

Another work item of the ad-hoc committee is the deprecation time for the ipv6.int DNS tree, i.e. the time when everyone should have moved to the ipv6.arpa. The draft-huston-ip6-int-01.txt states that this date is 1. June 2005. A participant asked if there where any statistics on the number of requests for ipv6.int? Georg Michalsen has some statistics collected through a period of 2 year. Although the numbers are not complete, they tell that the number of requests is low but not insignificant (estimated 1/100 between .int vs. .arpa) and queries typically should come from public networks and home networks with old equipments. Michalsen and a participant from Japan volunteered to collect better statistics on this issue.

5.1.3 SHIM6 (Site Multihoming by IPv6 Intermediation) WG 5.1.3.1 IETF 63 (Paal E. Engelstad)

The SHIM6 (Site Multihoming by IPv6 Intermediation) WG is tasked to continuing the work of the multi6 WG. (The reason that multi6 is not closed down yet is that it has still items waiting in the editor queue.) The WG will first produce and finalize documents on architecture, protocol, crypto-locators, triggers and applicability.

First, the WG is still in the state were a lot of people trying to understand what the WG is going to do. A lot of discussions are initiated to clarify issues.

Important issues clarified about the architecture:

• The generic questions are: How is a session/equivalence state established? Upper layer does not know about the change of addresses etc. What is the upper and lower layer split, the initial packet exchange and the capability negotiation? Are re-homing triggers set by session or by host? How do you know when the state is obsolete? The shim layer is just below the IP endpoint sub-layer. Maintaining the state is challenging, e.g. how to detect network failure, what are the locator failure triggers etc.

• Important issues clarified about the protocol: o Assumption about DNS. DNS can be used for load balancing. Thus, must

negotiate the addresses directly with the selected host and not rely on DNS. o Context establishment: Initial contact, deciding to set up SHIM6 context

state, and re-homing after connection failure. The context established exchange is a four-way handshake similar to that of HIP.

• Important points clarified about crypto Locators and triggers were: o Providing triggers for reachability is hard to do efficiently (i.e. more than

simple pings). This can be very complex. o If there is rich cross-layer information from higher layers, shim should use

it, but will have to use polling or something similar if such information is not available

Second, a lot of principal questions were raised. For example:

• How do you define when a link is down or only very degraded (e.g. 30% packet loss)?

• To what extent should decisions be taken in the IP layer, Transport layers and in Applications? Pushing the logic down means a "one-size-fits-all" solution that



might not meet the specific requirements of higher layers. One can either use a rich API to the IP layer, or to keep the API simple, and allow upper layers to make decisions about the locators.

When using both Shim6 and MIPv6 should the node use CoA or HoA as locator? Perhaps we need to express to the shim that there are different types of addresses, e.g. temporary and stable. Actually, it is not clarified yet if SHIM6 should use MIPv6 or the opposite. However, SHIM6 should work independent of MIP6.

5.1.4 V6OPS (IPv6 operations) WG 5.1.4.1 IETF 64 (Frode Kileng)

The meeting showed consensus for sending the "IPv6 Network Architecture Protection" draft (draft-ietf-v6ops-nap-02.txt) off to IESG. This work gives an interesting analysis for strategies for securing IPv6 networks where a NAT is redundant and how to gain a protection level in IPv6 networks using techniques that are known collectively as NAP (Network Address Protection). I.e. the draft should give some relief for people concerned about how to survive in an IPv6 world without NAT.

Another document that was voted over for sending it off to the IESG was the "ISP IPv6 Deployment Scenarios in Broadband Access Networks" (draft-ietf-v6ops-bb-deployment-scenarios-04.txt). Jim Bound spoke for this and declared that he knew about several operators that used this already but that he was unable to reveal them due to nondisclosure agreements. The meeting showed consensus for sending it off to IESG.

The work on "IPv6 Enterprise Network Analysis" (draft-ietf-v6ops-ent-analysis-03.txt) now at last seems to come to an end. Jim Bound, one of the editors, complained about the slow progress putting this forward to IESG. Pekka Savola argued that there are real technical objections against it, especially the parts on DSTM that has been an item for discussion on several meetings and on the list. Pekka stated that there are alternatives to the DSTM. The WG chair requested for a quick update on the document and another round on the mailing list before it is sent out for last call.

The WG was asked to take up a security related draft as a new work item. Stig Venaas presented the draft "IPv6 Implications for TCP/UDP Port Scanning" (draft-chown-v6ops-port-scanning-implications-02) written by Tim Chown. It discusses implications for port-scanning techniques in IPv6 due to the large address room. Pekka Savola stated that it is an interesting subject but objected against taking this up as a new work item due to the big number of items already on the list for v6ops and that we should focus on them. Dave Thaler supported this as a WG item but that this document is actually about issues related to address scanning, not port scanning. The meeting showed consensus for taking this up as a WG item.

There is some confusion around the overlapping terminology related to tunneling and other IPv6 migration techniques. Jordi Palet presented the draft "6in4 versus 6over4 terminology" (draft-palet-v6ops-6in4-vs-6over4-00.txt) discussing terms like 6in4 and 6over4. The draft proposes the term "in", like 6in4, to cover IP-in-IP tunneling mechanisms and "over" to cover translation mechanisms. Jordi revealed that one of the motivations behind this draft is that he had discussed the misuse of these terms in marketing departments that stated that they would only change the wording on the basis of the existence of a draft clearly defining these terms... The presentation triggered a lot of discussion against taking this up as a WG item and one stated that this belongs in Wikipedia, not IETF. A voting, although conductive, showed the lack of consensus for taking this as a new work item.



Fred Templin presented some ideas of another possible WG item related to requirements on MTU assurance in IP-in-IP tunneling. It raises issues due to fragmentation on IPv4 links when tunneling IPv6, issues that have negative impact on performance due to the lack of mechanisms for determining the MTU of the decapsulators. Templin concludes that there is a need for Tunnel MTU assurance mechanisms that spans NATs and Firewalls. In the discussion, both Dave Thaler and Pekka Savola objected to taking this up as a new item since this belongs in other WGs and more especially in the PMTU WG. 5.1.4.2 IETF 63 (Geir Egeland)

The v6ops WG has processed a set of documents through WG last call, and these are about to be sent for AD review and eventual IESG movement. A set of documents that was presented at the meeting will be last-called after the meeting. These are:

• draft-ietf-v6ops-ipsec-tunnels • draft-ietf-v6ops-ent-analysis • draft-ietf-v6ops-nap • draft-ietf-v6ops-security-overview

There was a presentation of a couple of new draft that was accepted by the WG. These are:

• draft-davies-v6ops-icmpv6-filtering-bcp • draft-vives-v6ops-distributed-security-framework

There was a presentation by Cisco and people from the 6NET project on a renumbering project that they did. There will be some follow-on work, including a document publication sometime next year. The upshot of that is a variety of documents from Cisco and 6NET, and some specific recommendations to be posted to the mailing list. The draft draft-chown-v6ops-renumber-thinkabout will be updated, and there may be specific recommendations concerning renumbering. 5.1.4.3 IETF 62 (Geir Egeland)

The status of the work of the WG can now be found at (http://tools.ietf.org/wg/v6ops).

The two Finnish chairs now resign from their position and Fred Baker from Cisco takes over as chair.

The WG has updated its charter and tries to emphasis that the time to market is getting crucial for the work done in v6ops.

The work on moving NAT-PT to experimental is to go to WG last call shortly. In short, this draft says that protocol translator alternatives must be done elsewhere.

Jim Bound from HP presented the Enterprise analysis draft. This draft now contains a matrix of the most common user cases for IPv6 in the next 18 months. The IPv6 alternative is now removed, since this most likely will only be a scenario beyond 18 months. This work has lacked in progress much due to the fact that the WG has been slow to provide feedback to the authors. This work must move forward, so a document can be presented. The Japanese IPv6 promotion council has already documents out on how to deploy IPv6, and the v6ops WG should be able to reuse some of this.

IPv6 Fix is a new activity of the WIDE project. Its main focus is to fix problems obstructing IPv6 deployment. As of now, they have analyzed d host implementations, DNS misbehavior and IPv6 network quality (using PING). More work will follow.

A new draft called IPv6 Network Architecture Protection was presented. This draft compare the seemingly benefits from NAT and IPv4 with IPv6 solutions. The draft was accepted as a WG document.


http://tools.ietf.org/wg/v6ops


Other WG documents that was presented where:

• Things to think about when renumbering • IPv6 Security overview • Use of VLAN for IPv4/IPv6 coexistence



5.2 Mobility

5.2.1 CAPWAP (Control And Provisioning of Wireless Access Points) WG

5.2.1.1 IETF 63 (Paal E. Engelstad)

There has been some progress over the last year. First, the terminology is now well established, although a better definition of the Local\Split MA. Probably a new Work Item will be established to address this. Furthermore, one has reached good consensus on the CAPWAP objective (- there were few comments and only minor changes after the IEEE).

Most important is that four different protocols exist, namely SLAPP, LWAPP, WICoP and CTP. The evaluation team has already undertaken the evaluation work, and an evaluation draft will now be the priority for the WG. It will be submitted shortly after the meeting. It will contain a protocol recommendation that will form a basis for the election of the CAPWAP protocol.

The objectives of the evaluation of proposed protocols are:

• configurable QoS, according to 802.11e

• configuration consistency (using a key, token, or serial number)

• security considerations

• NAT traversal: Only looking for obvious constraints of IP carried in payload

• Firmware trigger should be received at any time in the state machine to be fully CAPWAP compliant.

The LWAPP and SLAPP protocols seem to be evaluated as better than WICoP and CTP. The latter two have for example shortcomings in terms of security and do not address QoS mappings. LWAPP has limitations in terms of the 8-bit length Message type ID and should instead use standard-based security and authentication mechanisms. SLAPP is recommended to define a spit MAC mode for local of bridging of user data. It should also accommodate the use of multiple FQDNs and IP addresses in each of its discovery modes.

Although the evaluation team would not reveal their final recommendation before after a separate conference call has been held, it seems that probably LWAPP or possibly SLAPP will be recommended as a basis for the final CAPWAP protocol.

5.2.2 DNA (Detecting Network Attachment) WG 5.2.2.1 IETF 63 (Geir Egeland)

The working group only met for a 2-hour meeting. The main topic for the WG was the two documents returned by the design team. The working group needs to choose between the two candidates, LinkID and Complete RA. There was a rather long discussion on which one to choose, even though most agreed that there are only small differences between them. There was no consensus, and the discussion is to be continued on the mailing list. 5.2.2.2 IETF 62 (Geir Egeland)

Report from the IEEE802.21 chair

The chair of the IEEE 802.21 group gave a presentation of their goals and current work for Media Independent Handover Services and Interoperability

IEEE 802.21 considers handovers between the following technologies:

• Between 802.xx and 802.yy



• Between 802.xx and Cellular (3GPP, 3GPP2)

• Between 802.11 ESS

Where x,y = 3, 11, 15, 16.

Comments from the WG was that IEEE has not the power to define a L3 transport, and that the solution for the MIH signaling should be done in the IETF. It was agreed that IEEE and IETF need to closer co-operate with respect to 802.21.

Report from design team

The design team has identified a large number of options, and the goal of the second session was to eliminate some of these options.

The design team suggests that the following is removed:

• Link detection: o Explicit link ID random

o Explicit link ID prefix hash

o Priority landmark

• Fast advertisement o Simple fast RA

o Deterministic Fast RA

This leaves:

• Link detection

o Explicit link ID agreed prefix

o Complete RA

o Requested landmark

o Hybrid landmark

• Fast advertisement o Fast router discovery

o Hash ordered fast RA

o Probabilistic fast RA

Although some of this was a topic for discussion, the WG agreed with the design team to move forward with the suggested mechanisms.

5.2.3 MANET (Mobile Ad-hoc Networks) WG 5.2.3.1 IETF 64 (Frode Kileng)

The chairs gave an overall WG progress report: The reactive routing mechanism is specified in the DYMO-03 draft, the proactive routing algorithm in the OLSRv2-00 draft and multicast forwarding in the SMF-01 draft.

Clausen presented the "The Optimized Link-State Routing Protocol version 2" (draft-ietf-manet-olsrv2-00.txt), i.e. the OLSRv2. There has been a lot of work this week and features covered now are: improved extensibility, address compression, unified message format for simple parsing of logic and some general cleaning (fragmentation and improving implementability). It is still based on the same algorithms and information exchanges as specified in RFC3636. Further work is necessary on issues related to the fragmentation of protocol messages and extensions for supporting new link metrics. Currently 4 independent OLSRv2 implementations are under development.



Adamson presented plans and initiated a discussion on "Simplified Multicast Forwarding" (SMF) for MANET based on the draft "draft-ietf-manet-smf-01.txt". The draft covers basic multicast packet forwarding functionality including a "all nodes receives", native IPv4 and IPv6 multi-hop forwarding support, support for dynamic optimized set of algorithms, Internet connectivity and interoperability, and supporting a mix of "neighborhood aware" and "unaware" SMF nodes. Adamson also presented some output of simulation trials of SMF.

Tom Henderson gave an update from the OSPF MANET design team. The initial problem statement has decided on OSPFv3 instead of OSPFv2, to have compatibility with non-wireless OSPFv3 nodes, and that the goal is to make it scale up to 50-100 nodes. The group has no consensus on the use of source independent vs. source dependent technique, on the use of HELLOs or LSAs for dissemination for two-hop neighborhood information, and on differential (incremental) HELLO implementations. They have done a lot of simulation and the results shows that using MDRs with bi-connected paths gives good scaling and minimal overhead. Henderson concluded by telling that the design team is not making any further progress at the moment and do not know how to solve the problem of selecting between the two viable approaches. 5.2.3.2 IETF 63 (Paal E. Engelstad)

The WG is currently working on a new reactive protocol, DYMO, and version 2 of OLSR.

There has been much progress in the specification of DYMO. Some technical issues still need to be clarified. There are now a number of implementations of DYMO in Linux and in simulators, such as OPNET. Implementations works well and are stable. Simulations, however, show that there are tradeoffs between DYMO and AODV. The main difference is the path accumulation of DYMO that reduce the number of RREQs, but may produce lots of RERRs. More performance analyses are required before one can draw definite conclusions.

A design team is developing OLSRv2. They are aiming at getting v2 as a standard track proactive protocol from MANET. Version 2 fixes minor nits and improves the extensibility of the protocol. It is now possible to cancel prefix advertisements (by using a sequence number). IPv4 and IPv6 addresses are treated uniformly and are now represented more efficiently. Internal extensibility of messages is included to reduce complexity. There are ongoing implementations. Interoperability testing will be arranged in the coming months.

Experience from 2nd OLSR Workshop was presented. 10 implementations were tested. A majority of these were also IPv6 capable. All implementations inter-operated and no routing-related problems were identified. A general problem is that 802.11 is not particularly appropriate for ad hoc networking.

SMF, MPRP and SMURF were also discussed, and it was informed about the work in the AUTOCONF BOF.

A design team is working on OSPF-MANET but there were hardly any time left to discuss this. Generally, the design team is struggling to reach consensus on a single recommended approach. 5.2.3.3 IETF 62 (Geir Egeland)

There was a presentation of the updated charter that is basically just to insure that the protocols are design to connect to the Internet.

A new protocol called DYMO was presented. This looks very similar to AODV, but the protocol is simpler in the design and caters for both IPV4 and IPv6. There were several comments about MANETcast address. In summary, 255.255.255.255 or ff02::X addresses are not the address that should be used to transmit control messages to all MANET nodes.



A new multicast address should be allocated from IANA. There were also several comments about RATE_LIMIT on DYMO packets. It was agreed a more complex method of limiting traffic (such as an exponential backoff) might be beneficial.

There was a short presentation about the results from AUTOCONF BOF. It was claimed that the BOF was a success, since there was a considerable amount of interest for the topic.

It was informed from the chair that the OSPF MANET design team has released two drafts to extend OSPFv3 to the wireless domain, which the WG might find interesting.

There will be an OLSR interop in Paris the weekend before the next IETF-meeting. This will focus on IPv6.

5.2.4 MIP4 (Mobility for IPv4) WG 5.2.4.1 IETF 63 (Paal E. Engelstad)

The chairs are working on a new charter proposal.

FMIPv4 drafts, Generic Strings and RADIUS attributes for MIPv4 will probably be accepted as Working Group Items.

It was decided that MIPv4 extension for configuration information should be proposed as a working group item. The information might be exchanged between the MN and a network entity. The network entity can for example be the FA or the HA. The information is included in short and skippable options in the Registration Requests and Registration Replies. The configuration could for example include information about the primary DNS server or the secondary DNS server. The proposal is particularly of interest to 3GPP to be used as a link-layer agnostic method when DHCP is not applicable. The method should accommodate to incorporate regular DHCP message, in order to "not re-invent the wheel".

For enterprise connectivity it was proposed to use MOBIKE when supported, instead of the MIP4-VPN mobility solution. For this use, MOBIKE requires 3 access modes; FA-CoA, CCoA, and mobile-enhanced VPN with VPN_TIA as CCoA. For NAT traversal MIPv4 NAT traversal and/or IPSec NAT traversal can be used. The chairs presented an obvious drawback of this proposal; MOBIKE is not optimized for mobility at the same level as MIPv4.

The use of multiple CoAs was also discussed. This topic will probably also be addressed by the MONAMI BOF/WG.

5.2.5 MIP6 (Mobility for IPv6) WG 5.2.5.1 IETF 62 (Geir Egeland)

There has been a lot of discussion about bootstrapping on the ML. The design team will present a solution on the next IETF, and they will most likely close shortly after the solution has been presented.

There was a presentation about MIP6 bootstrapping by J. Kempf where the basic idea is for the MN to ask for DNS SRV records to get the HA address. Then IKEv2 is used to establish MN-HA keying. Replay protection is provided by Message identity code in DNS (RFC1035) and data integrity and origin authentication is provided by DNSSEC.

There was a presentation about Location privacy in MIP6. The problem is that the HoA is visible in all packets the MN uses in home or visited network and the COA is visible at visited network. The HoA could be profiled for activity and the COA reveals roaming of a mobile node when HoA is used. There was a show of hands that indicated that the WG wants to work on location privacy.



5.2.6 MOBIKE (IKEv2 Mobility and Multihoming) See Security section

5.2.7 NEMO (Network Mobility) WG 5.2.7.1 IETF 63 (Geir Egeland)

NEMO has been implemented for BSD* and Linux operating systems. There was a presentation of the status and the features of the implementation SHISA for BSD, which is implemented by the KAME project, and NEPL for Linux that is implemented by the nautilus6 project. They both support the Home Agent and the Mobile Router and have been tested against the TAHI test suite (http://www.tahi.org/mipv6/).

There was also a presentation on IPv4/IPv6 transition issues, which raised the question that if this is important, why isn’t the WG designing IPv4 mobile routers.

There was a presentation of an analysis of multihoming in Network Mobility. This has raised the following issues that the WG will have to comment on:

• Fault Tolerance • Ingress Filtering • Media Detection • HA synchronization • Prefix Delegation • Loop prevention in nested NEMOs

The NEMO working group has been working on route optimization and the result from the previous IETF meeting was to split the work into two separate documents:

• Route Optimization problem statement draft: This draft has been released and is pretty much what the WG expected.

• Solution Space analysis draft: This draft will be released by the end of August. The working group is going to recharter, but there was no more time to discuss this in the meeting. This will be continued on the mailing list.


http://www.tahi.org/mipv6/


5.3 Multicast Routing

5.3.1 MBONED (MBONE3 Deployment) WG 5.3.1.1 IETF 64 (Frode Kileng)

The meeting got a status update on the very interesting and Telenor relevant draft specifying the automatic setup of multicast tunnels, i.e. "draft-ietf-mboned-auto-multicast-04.txt". The authors hope to finish this in a few weeks and the draft will then be sent to a Last Call on the WG mailing list. We also were told about one implementation of this but the authors requested information on others. Dave Thaler went to the microphone and told about one they are working on.

The trend with working on solutions to give administrative control and management support of multicast continues. Sato gave a short presentation of the draft "AAA Framework for Multicasting" (draft-sato-multiaaa-framework-00.txt). The plan is to ask the group on the mailing list if this should be a WG item. Dave Thaler stated that he thinks this belong in another group since MBONED is a WG dealing with operational matters. John Maylor said that there is some specific properties related to management of multicast that this group should identify and specify. The group should first study a framework for this and then, if AAA is a possible solution, the work could be moved to another WG.

Williamson presented a lightweight mechanism for Multicast Address Discovery. The lack of a simple mechanism has resulted in applications hard coding addresses and in using globally scoped addresses when local zone addresses is enough. He proposes a lightweight multicast address discovery protocol (MADP) that assumes no supporting infrastructure other than IP Multicast support and that runs entirely in application clients and servers. There was a lot of controversy about MADP. Several participants felt that DNS should be used. Other stated that SLP or SAP could be used. Dave Thaler stated that he felt this was a good idea but only solves the problem of address discovery, not multicast address allocation.

At the end of the meeting, the Area Director informed that the MBONED chair David Meyer wants to retreat from his position as WG chair. The Area Director asked the meeting if MBONED WG should be closed or eventually re-chartered and a new chair selected. For the last option, he wanted to select a new chair from an operator who has deployed multicast. In the discussion, there was a clear consensus that the participants wanted MBONED to continue. The AD state that the WG is 10 years old and it could not be described as "very successful" due to the low degree of operational MBONE deployment. A participant disagreed and stated that there have never been so much multicast enabled networks as today. The AD summarized the discussion that there seemed to be a consensus that the WG should continue and that he wants suggestions for candidates for the position as WG chair. During the discussion, a poll was taken to se how many of the participants represented an operator. The high number surprised both the referee and many others. 5.3.1.2 IETF 62 (Frode Kileng)

Pekka Savola presented the draft-ietf-mboned-addrarch-01.txt describing a BCP of multicast addressing architecture. In the 10 year long history of IP multicast, documentation of multicast addressing and allocation has been available in numerous drafts and RFCs. This draft tries to summarize and give up-do-date information on the multicast addressing architecture. There have not been too much feedback on this draft yet and Pekka invited reviews since it soon will be shipped to a WG last call.

3 Multicast BackBONE



The problem of multicast address discovery has been discussed several times. IANA is requested often for static assignment even for applications that do not require global assignment. Pekka presented a proposed WG item, the "Lightweight Multicast Address Discovery" draft (draft-savola-mboned-address-discovery-problems-00.txt) that tries to define the problem and solution space. During the discussion, MADCAP was mentioned as a possible solution to the discovery problem. Others objected that MADCAP was a component in a bigger architecture that was never deployed and that there seems to be some problems with MADCAP. No one could remember exactly what this was and it was proposed to try to investigate this. This draft was accepted as a WG item.

Pekka also presented another proposed work item the "Overview of the Internet Multicast Routing Architecture" (draft-savola-mboned-routingarch-01.txt) which has the save motivation as the previously mentioned draft-ietf-mboned-addrarch-01.txt, i.e. to give an up-to-date summarize of the multicast routing architecture. The discussion mainly was related to the classifying of MOSPF as historic. Several attendees felt that the term "historic" is somewhat biased and although few implementations of MOSPF exists and that we should not encourage its usage we may should find another way to state this. The meeting was in favor of accepting the draft as a work item.

Multicast VPN (Multicast support within MPLS VPN) was also an important item at this IETF meeting. Yiqun Cai gave an update on this issue that was added to the WG charter in IETF-59 in Seoul (March 2004). After IETF-61 in Washington, work was initiated to migrate the presented (potential) drafts to an upcoming draft "draft-to-become-l3vpn-2547bis-mcast-00.txt". Several vendors have implemented multicast VPN, mostly based on the revisions of the draft-rosen-vpn-mcast, e.g. Cisco -07 and Juniper -06.

At day 2, Mar 8, T. Hayashi presented a candidate WG item named "Accounting, Authentication and Authorization issues in well managed IP multicasting services" (draft-hayashi-maccnt-02.txt). This draft describes the problem area and solution requirements and assumes that a solution can be implemented in the edges of a network using IGMP and MLD. Except a suggestion for changing the title of the draft (Pekka Savola: opposite of "well managed" is eh. "bad managed"), there where no objections to taking this draft as a WG work item. Next step is an applicability study of existing solutions and to study solutions that will meet the requirements.

Hayashi presented an applicability study of existing solutions to the AAA/Multicast issue in the draft "Issues Related to Receiver Access Control in the Current Multicast Protocols" (draft-hayashi-rac-issues-00.txt). He states that the purpose of this proposed WG item is to come to a common understanding and start a discussion how to meet the requirements of commercial multicast. Goal is to achieve same capabilities such as access control, admission control & accounting, as in unicast content delivery. Based on his experience, currently many issues raised in the I-D are NOT perfectly covered by existing standards. There was a consensus to take this draft as a WG item but it was agreed to coordinate this work with the work item mentioned above to avoid overlaps.

Marshall Eubanks then presented issues related to using SIP for multicast source discovery. He started by presenting the history of SAP as the original source discovery mechanism in MBONE before presenting an analysis of using SIP that was initially created for MBONE. He concludes that there is not much to gain over using SAP and that SIP will not solve the lightweight source discovery problem, basically because it is not "light" and that there is no way to enforce its usage.



5.3.2 PIM (Protocol Independent Multicast) WG 5.3.2.1 IETF 64 (Frode Kileng)

The only draft worth mentioning in this 1 hour WG meeting was the "Improved Assert in PIM-SM" (draft-hemige-pim-improved-assert-00.txt) draft presented by Venu Hemige. The purpose of the proposed mechanism is to remove the control plane dependency on the data-plane to detect duplicate traffic, and it is a simple extension with minimal changes to the current PIM-SM mechanism. It is fully compliant with PIM-SM version 2. 5.3.2.2 IETF 62 (Frode Kileng)

The charter of PIM will now be updated to address PIM enhancements required to support multipoint switching in MPLS.

James Lingard presented an update on the “Bootstrap Router Mechanism for PIM” (draft-ietf-pim-sm-bsr-05 - James Lingard) that is an update of RFC2362. Work on this draft has been ongoing since 2001 but new authors have volunteered to finish this work. A major change from the RFC is the support for administratively scoped zones. It is a goal of this work to preserve backward compatibility with RFC2362 but not with previous revisions of this draft. The draft still needs further work on finalizing the mechanism for implicit vs. explicit withdrawal and “bootstrap BSM semantic fragmentation”. Last call is planned shortly after IETF63.

Pekka Savola presented the proposed work item “Last-hop Threats to Protocol Independent Multicast (PIM)” (draft-savola-pim-lasthop-threats-01.txt). An analysis of threats to infrastructure is available in the draft-ietf-mroutesec but no analysis of threats to the last-hop has been done. The analysis covers last-hop PIM vulnerabilities as nodes that send unauthorized register messages, nodes that become an unauthorized PIM neighbor, routers that accept PIM messages from non-neighbors and unauthorized nodes that get elected as a PIM asserted forwarder. It also covers DoS attacks on the link. On-link threats covered are DoS attack on the link, DoS attacks on outside nodes and confidentiality, integrity and authorization violations. A main threat is related to the need to secure the communication with IPSec between multiple valid PIM routers on a link.

The last item on the agenda was a report from the team that has a goal of increasing the scalability of PIM. Existing BGP implementations supports more than a million simultaneous routes but state-of-the-art PIM implementations supports less than 50% of this. The reason to this is the processing overhead related to “join” & “prune” refresh PIM messages. The team suggests introducing “ack-ing” to achieve reliable delivery of join and prune messages. Also suggested are adding sequence numbering to achieve order delivery and some other minor feature to improve the message handling. The presenter did not consider the usage of TCP as an alternative.

5.3.3 MSEC (Multicast Security) See security section



5.4 Security

5.4.1 ENROLL (Credential and Provisioning) WG 5.4.1.1 IETF 62 (Tor Hjalmar Johannessen)

There are many cases where a service consumer needs to contact a service provider to get credentials that the consumer can use when accessing the service; part of this initial contact may involve the consumer and the provider mutually validating the other's identity. This working group will look at some of the cases where cryptography is used to provide authentication.

Main focus: The establishment of user identities is fundamental for most security systems, and some good examples are: PKI, EAP type protocols, SIPPING-CERT3GPP Generic Authentication Various MIPV6 Kerberos. The progression in the working group is slow despite that the issues are important. This indicates that this is difficult to standardize (too context specific?).

Detailed minutes can be found at: (http://www3.ietf.org/proceedings/05mar/minutes/enroll.html) 5.4.1.2 IETF 62 (Tor Hjalmar Johannessen)

(There was no meeting for this working group at IETF 62. It seems as most milestones have been reached.)

Status March:

Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress.

The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them.

The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups.

Current internet-Drafts:

• Intrusion Detection Message Exchange Requirements: http://www.ietf.org/internet-drafts/draft-ietf-idwg-requirements-10.txt

• The Intrusion Detection Message Exchange Format: http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-14.txt

• The Intrusion Detection Exchange Protocol (IDXP): http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-07.txt

Request For Comments: The TUNNEL Profile (RFC 3620): http://www.ietf.org/rfc/rfc3620.txt.


http://www3.ietf.org/proceedings/05mar/minutes/enroll.html

http://www.ietf.org/internet-drafts/draft-ietf-idwg-requirements-10.txt

http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-14.txt

http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-07.txt

http://www.ietf.org/rfc/rfc3620.txt


5.4.2 ISMS (Integrated Security Model for SNMP) WG 5.4.2.1 IETF 62 (Tor Hjalmar Johannessen)

Version 3 of the Simple Network Management Protocol (SNMPv3) was elevated to Internet Standard in late 2002 and added security to the previous versions of the protocol. Although the enhanced protocol is secure, operators and administrators find that deploying it can be problematic in large distributions. This is due primarily to two synchronization problems. The first is the addition of yet another authentication system specific to SNMPv3 that needs to be maintained across all networking devices. Most of these devices already contain local accounts and/or the ability to negotiate with authentication servers (e.g. RADIUS servers). However, SNMPv3 does not make use of these authentication mechanisms, and this causes additional synchronization burdens. The second issue found with deploying SNMPv3 is that distributing and maintaining View-based Access Control Model (VACM) rules is also difficult in large-scale environments.

Comparison of Proposals for Integrated Security Models for SNMP:

draft-ietf-isms-proposal-comparison-00: Basic statement: no clear winner

Recommendation: The EUSM architecture would be the right direction for the ISMS WG. However, a number of aspects of the EUSM design need moderate to substantial revision.

RFC 3748: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. The EUSM proposal violates this recommendation

5.4.3 MOBIKE (IKEv2 Mobility and Multihoming) WG 5.4.3.1 IETF 63 (Paal E. Engelstad)

Much of the basic work has already been resolved in May. For example:

• The design issues have been resolved and now one is only editing the document. • The protocol is also now constructed according to the main decision in May, and

the document is now going through revision. However, there is still much additional work in the pipeline.

This meeting focused mainly on presenting what is in the protocol today, and discussing what should be in there. Protocol design was also discussed.

The basic protocol principle is that the responder sends a list of addresses, while the initiator decides which to choose. There are a number of additional features, such as

• NAT traversal, • Responder address changes (although it does not fully work with NAT traversal), • Path testing (to be able to fail-over between paths) and • Return routability test. • Issue 34 on path testing and changes in NAT mappings were discussed.

5.4.3.2 IETF 62 (Tor Hjalmar Johannessen)

There was a detailed discussion on problems related to NAT (for IPv4) - see http://www3.ietf.org/proceedings/05mar/minutes/mobike.html.


http://www3.ietf.org/proceedings/05mar/minutes/mobike.html


5.4.4 MSEC (Multicast Security) WG 5.4.4.1 IETF 62 (Frode Kileng)

Russ Housley gave a presentation of multicast issues related to IPSec (RFC2401bis). The background for this work is coordination with the IPSec WG to ensure that ESPv3 and AHv3 in rfc2401bis could accommodate multicast. The RFC 20401bis has completed the WG last call but it the changes to in ESPv3 and AHv3 is not sufficient and the current SPD structure does not support multicast. It is suggested to let the RFC2401bis proceed and get published as a proposed standard as it is and then close the IPSec WG. The MSEC WG would then develop an update to this to address the multicast shortcomings.

Another item on the agenda was a presentation of a proposed WG item specifying an additional mode of key distribution in the MIKEY protocol (draft-ignjatic-msec-mikey-rsa-r-00). The motivation is to support scenarios like when a VoIP initiator does not have available the public key of the responder. The proposed solution specifies a mechanism where the initiator request the public key of the receiver by sending a signed message to the receiver, which then returns its public key to the initiator.

There were few items on the agenda and the session ended after less than an hour.

5.4.5 PKIX (Public-Key Infrastructure) WG 5.4.5.1 IETF 62 (Tor Hjalmar Johannessen)

New work Items:

• Production of a requirements RFC for delegated path discovery and path validation protocols (DPD/DPV) and subsequent production of RFCs for protocols that satisfy the requirements

• Development of a logotype extension for certificates

• Development of a proxy certificate extension and associated processing rules

• Development of an informational document on PKI disaster recovery

Document status: Five documents in RFC Editor's queue. One document just approved by IESG, several more in the IESG queue for review & approval. Several documents stalled.

PKIX WG Document Presentations:

Simple Certificate Validation Protocol (SCVP) - David Cooper (NIST): Significant progress has been made towards rough consensus through the two drafts submitted since the last meeting. These drafts represent been submitted with significant enhancements.

3280bis - David Cooper (NIST): A design team met in January to develop a -00 draft from a list of issues complied from PKIX mail messages and mail to the RFC 3280 editors. To first order, this document addresses matching rules only for name comparisons relative to path validation, e.g., for certificate chaining and for applications of name constraints.

UTF8String Deployment and Migration - Akira Kanaoka (Secom/JNSA PKI Challenge Project): This presentation reported on feedback received from a questionnaire on UTF8String deployment in Asia, i.e., to determine the extent to which CAs in Asia followed the RFC 3280 guidance on this topic, guidance that was rescinded in 3280bis!

CRL Signer Certificates and AIA - Stefan Santesson (Microsoft): Draft -00 of this new PKIX document was published after the last meeting. There has been moderate discussion on the list about this draft. About 5 major issues were identified. Responses have been proposed for each issue and, where appropriate, will be reflected in the next draft. One



issue (choice of recommended referral methods) still remains, and will be addressed on the list.

Update on CRMF, CMC documents - Jim Schaad (Soaring Hawk): This presentation reviewed the state of several related drafts and highlights the controversies that remain.

Related Specifications & Liaison Presentations:

LDAP schema definitions - Kurt Zeilenga (OpenLDAP): The author of this individual submission has requested that the WG review and comment upon this draft.

OCSP Data Interchange Format - John Hines (Tumbleweed): The presenter will be submitting an individual draft defining a data interchange format for OCSP servers. The presentation described the problems that inspired this draft and invites WG participation, even though the document will not be a PKIX document. The goal is to eventually make this a standard, and Russ Housley explained the procedure for doing this via the individual submission path.



5.4.6 SAAG (Security Area Advisory Group) 5.4.6.1 IETF 62 (Tor Hjalmar Johannessen)

This working group is an umbrella for all groups working on security.

AVISPA:

Alessandro Armando, from AI-Lab, DIST - University of Genova, Italy, gave a presentation on Automated Validation of Internet Security Protocols and Applications (AVISPA). It is a project funded by the EU. He covered:

• The development of security protocols is out-pacing human ability to analyze them.

• Tools are needed to support the analysis of these protocols.

• Some protocol analyzers exist, but they do not support large protocols and each one has a unique language and user interface.

• Want to develop a rich specification language, advanced techniques, integrated developer tools, and standard AVISPA Library.

• Want to assess the practicality using AVISPA Tool.

• There are four "backends" to do checks on protocols.

• The High Level Protocol Specification Language (HLPSL) is role-based language.

• Tool can be accessed at www.avispa-project.org/web-interface.

• AVISPA Library tested against a set of security problems with protocols that have been recently standardized by the IETF, uncovering 112 problems in 33 protocols.

• There are four universities working together on the development

MD5 and SHA-1 Status (Ref: http://www3.ietf.org/proceedings/05mar/slides/saag-3.pdf):

Eric Rescorla, from Network Resonance, gave a presentation on MD5 and SHA-1 and the recent attacks against them. He covered:

• Terminology:

o Collision: Find M, M' such that H(M) = H(M')

o 1st preimage: Given X, find M such that H(M) = X

o 2nd preimage: Given M, find M' such that H(M') = H(M)

• MD5 collision (practical).

• SHA-1 in 269 operations (theory); when it should be 280 operations.

• Certificates - Lenstra et al. demonstrate a pair of certificates with different public keys but the same hash.

• None of these attacks allow you to compute preimage.

• The collisions are not totally controllable; where the changed bits will be located depends on current hash state.

• DO NOT panic!

• These attacks do not affect key derivation functions (PRF), peer authentication protocols with non-repudiation (SSL, IPSec, SSH), message authentication (HMAC), challenge-response.

• These attacks do affect non-repudiation, certificate issuance (only in special instances), and timestamps (maybe).

• Since the CA has control over some of the fields in the certificate there are ways to thwart attacks based on these hash collision attacks.

• DO NOT Panic, but we do need to create a plan for the future:

o SHA-224, something new?

o New randomized hash algorithms; in ASN.1 protocols one need a random value in the algorithm identifier parameter.


http://www.avispa-project.org/web-interface

http://www3.ietf.org/proceedings/05mar/slides/saag-3.pdf


o As a stop gap measure, randomize certificate serial numbers (or dates in the validity period).

OATH:

The One Time Password algorithm from OATH (the initiative for Open AuTHentication), ref www.openauthentication.org <http://www.openauthentication.org>.

David M'Raihi, from Verisign, gave a presentation on the OATH one-time password algorithm <http://www3.ietf.org/proceedings/05mar/slides/saag-2/sld1.htm>.

He covered:

• Why? One-time passwords (OTP) are more secure than static passwords. OTP is easy, like two-factor authentication.

• Several algorithms exist, but they are proprietary, so information is not available for peer review.

• An open algorithm makes it possible for anyone to analyze. There is a freely available description and a reference implementation.

• Requirements: usable, secure, implementation flexible, and economic. • Algorithm uses HMAC and SHA-1, which are both open and public. • Algorithm description: HOTP (Counter, Key) = Truncate (HMAC-SHA-1

(Counter, Key)) • The recently announced SHA-1 attacks cause no concerns in this algorithm. • About ten companies have implemented the algorithm, including software tokens,

hardware tokens, and SIM cards. • Next Step: an open standard.


http://www.openauthentication.org/

http://www3.ietf.org/proceedings/05mar/slides/saag-2/sld1.htm


5.5 Other groups covered by watcher

5.5.1 DHC (Dynamic Host Configuration) WG 5.5.1.1 IETF 62 (Frode Kileng)

(Note: This meeting was not fully covered due to collision with MSEC meeting.)

It was a pleasure to see a Norwegian as the new co-chair for the DHC WG. Stig Venaas currently has a position at the University of Southampton, and is on leave from his position at Uninett.

Takeshi Ogawa presented a proposed work item specifying DHCPv6 Options for Fast Handovers (draft-ogawa-fhopt-00.txt). The motivation for this work is the need for fast handover support on the IP-layer to support real-time applications. The draft introduces a new DHCPv6 option that makes it possible to give a node information that it will use after the handover, before the actual handover takes place. One problem with the existing "Fast Handovers for Mobile IP" (FMIP) is that it requires upgrade of existing equipment and that a DHCP solution would be better for plain IP-nodes since they already depends heavily on stateful addresses. Takeshi proposes that the DHCP-server sends the "fast handover option" to a mobile node before handover. The option includes the essential information from FMIP. This means that fewer equipments (than FMIP) needs to be upgraded, a unified handling of stateful addresses due to the usage of DHCP and a reduced handover time since information is sent before the actual handover. An example of this is to send the WLAN channel number the new AP to a Mobile Node so that the node does not have to search for the channel itself.

Chown presented "IPv4 and IPv6 Dual-Stack Issues" (draft-ietf-dhc-dual-stack-02.txt). The draft gives a recommendation on the general strategy on how to handle issues related to potential problem when processing configuration information received from both DHCPv4 and DHCPv6 servers. He concludes that DHCPv4 support is required in dual-stack nodes, that IPv4 configuration information and/or address options to DHCPv6, that DHCP information between v4 and v6 should be consistent (possible from a single asset database) and that the process of merging v6 and v4 information is not trivial. It was a consensus at the meeting to take the draft to a WG last call.

5.5.2 DNSOP (Domain Name System Operations) WG 5.5.2.1 IETF 64 (Frode Kileng)

The chair started with a deep sigh complaining on the lack of feedback on drafts. Pekka Savola suggested that to submit a draft, the writers must at a minimum have commented 5 other drafts. Another participant stated that the WG takes up to many drafts on potentially interesting subjects but not that is really that interesting for people.

Mark Andrews presented a potential new WG work item, the draft "Configuration Issues Facing Full Service DNS Resolvers In The Presence of Private Network Addressing" (draft-andrews-full-service-resolvers-01.txt). The motivation for this is the high overload on in-addr.arpa name servers due to unnecessary reverse lookup on "IPv4 private addresses" (192.168/10./etc). The AS112-servers, i.e. the volunteers for the private addresses like 10.in-addr.arpa, are very overloaded, and this costs real money to maintain. The draft proposes that the ISP specific DNS servers and local caching names servers returns NXDOMAIN directly on lookup requests on private addresses. I.e. no protocol change, just a new procedure. In the discussion, one participant raised concern about who should be



responsible for managing the "list of addresses". Another said that it would be better if the servers returned a textual representation of the address instead of NXDOMAIN since this would stop further lookups. There was consensus at the meeting to adopt this as a new work item.

Fältstrøm, chair of ENUM, gave a short presentation of the ENUM draft "ENUM Requirement for EDNS0 Support" (draft-conroy-enum-edns0-01.txt), to ask if this draft makes any sense. The goal of the draft is to specify that ENDS0 (~"large DNS reply packet support") is required for ENUM-implementations. One participant answered that such a document is necessary but maybe just to clarify the consequences of not supporting EDNS0. It seemed to be a consensus that the draft was sensible.

As a side note, Hankins, one of the as112 volunteers, went to the microphone and told that as112 on a daily basis get phone calls from people who think they get attacked due to traffic on port 53. I.e. network operators/managers that don’t understand a basic mechanism as DNS.... 5.5.2.2 IETF 62 (Frode Kileng)

Alain Durand presented a potential WG item with the rather pretentious title "To publish, or not to publish, that is the question" (draft-durand-dnsop-dont-publish-00.txt). It basically describes some guidelines for what to publish in the DNS. Of specific interests for Telenor are the guidelines related to when to publish in IPv6 addresses during a transition phase. The recommendation concerning this is that when publishing several addresses for a DNS label, one must take care not to publish at the same time addresses that are designed to be globally unique and reachable and addresses that are not. During the discussion, Bill Manning stated that he wants to decide by himself what to publish and that no one should tell him this, but several others (Pekka Savola and Rob Austein) stated that people needs to get told what to do because of lack of competence. It seemed to be enough interest to take the draft as a WG work item.

Pekka Savola presented the DNS-related parts of the "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", i.e. section 3.2 of draft-palet-v6ops-tun-auto-disc-03.txt. This draft is an agenda item at the TC BOF and the intention here is just to present issues related to DNS and to get input from the "DNS-people" on which solution to select. Basically the draft proposes two different tunnel end-point discovery (TEP) mechanisms based on DNS: "Forward" and "Backward" DNS lookup. The forward mechanism uses the forward DNS search path (possibly learned through DHCPv4) and a "well-known-TEP-name" to lookup the TEP. An example is _v6tc.local.example.com. Only an A-record needs to be added but there may be a challenge related to have NAT-boxes w/DHCP to pass through the search path and that the forward path doesn't necessarily map well to the actual network topology. Also, queries may end up at the root servers. The backward DNS lookup approach uses a new "TEP"-record and clients looks up this based on their own IP address (ex. 1.2.3.4.in-addr.arpa IN TEP _v6tc.example.com). This method maps well to the actual network topology but it requires a pre-population of the whole IP address space in DNS. As expected during the discussion, Keith More stated his concern about using DNS for yet another service-discovery purpose.

Peter Koch presented the "The DNS Phase In Problem". Basically this addresses the generic problem of when a new record type is introduced and how the lack of a value in DNS should be interpreted. Does the absence of a v value deliberately say "no" or "do not yet know or care"? What is the generic solution to this? Especially during the deployment of new services/features this will be an issue. Several attendees stated that this is an application-level problem and not something that DNS should/could help with.



5.5.3 ENUM (Telephone Number Mapping) WG 5.5.3.1 IETF 64 (Frode Kileng)

The chairs stated their intention to advance RFC3761, i.e. "the ENUM standard" to draft standard. There is a need to look at the experience drafts from implementations first to see if it would be required to first go to proposed standard.

Patric Fältstrøm, Chair of ENUM, informed about the feedback from DNSOP when presenting the draft "ENUM Requirement for EDNS0 Support” (draft-conroy-enum-edns0-01.txt). He proposes to instead having a separate ENUM specific operational requirement/recommendation draft, that the ENUM specific issues is taken out of the draft and sent to person in DNSOP that will work on a more generic DNSOP requirement/recommendation draft. He suggests postponing any further update on the draft until DNSOP has taken a decision on this matter. There were some objections to this strategy from someone who felt that this also should be an ENUM WG document.

Alexander Mayrhofer presented a potential new WG draft, the "IANA Registration for Enumservice vCard" (draft-mayrhofer-enum-vcard-00.txt). The draft proposes an URI scheme for registering vCard as an ENUM service, a service that essentially just returns a URL to the vCard. The vCard is an "electronic business card", a transport independent format able to represent a set of key/value pairs of information. The motivation for this draft is a request from two ENUM service operators on how such information can be implemented in ENUM. In the discussion, Patrick Fãltstrøm raised concern about privacy issues in this and felt that IRIS may be better to use than HTTP. He wants more text on privacy and security. On a direct question, Patric answered yes when asked if he wanted a granularity on which information that should be available dependent on whom requests the information. Another participant stated that it is necessary to study how vCard is handled in XMPP. But another participant said that information should not be put in the vCard if the information should not be published.

Issues related to Carrier/Infrastructure have been a big item for discussion on the mailing list the last months. After a presentation of the draft "Carrier/Infrastructure ENUM Requirements" (draft-lind-infrastructure-enum-reqs-01.txt) there was a discussion about terminology, i.e. if it should be referenced as "carrier ENUM" or "infrastructure ENUM". The participants were asked about this and although it for this referee seemed to be no consensus (humming), it was judged that "infrastructure ENUM" won. 5.5.3.2 IETF 62 (Frode Kileng)

Yoshiro Yoneya reported from the APEET/ENUM trial at Apricot 2005 in Kyoto. APEET (Asia Pacific ENUM Engineering Team) was started in 2004 as an informal forum for project engineers from CNNIC, JPRS, KRNIC, SGNIC and some other organizations. The objective of this live trial was to get ENUM/SIP experience for all participants at APRICOT 2005, experience with ENUM info registration and number solution and SIP voice communication between participants. The trial showed the applicability of ENUM for SIP routing. Some incompatibilities with the interpretation of regular expressions were found. The results from the trial will be documented in an Internet Draft. It was also announced the plans for a big trial at the IETF-64 in Vancouver/Canada in the autumn of 2005 where 500-2000 handsets will be tested.

Alan Johnsen presented the draft "IANA Registration for ENUM services conf-web and conf-uri" (draft-johnston-enum-conf-service-00.txt). The draft specifies discovery mechanism for "web conferences". The presentation resulted in a long discussion about the need for defining a specific "web-conference" URI when a generic URI-reference already exists. There was also disagreement over the semantics of a "web conference" since this was not specified and could be "anything". Is the concept of "web conference" important enough and clearly defined to justify a separate ENUM-service? The Chairs failed to draw



any consensus and the discussion touches the generic issue of what is an ENUM-service and what is not.

The Chair presented a suggestion to specify a SOAP binding for EPP (Extensible Provisioning Protocol) for the management and provisioning of E.164 numbers. The response to this challenge was not exactly overwhelming but there where someone supporting this to help the provisioning of ENUM.

Bernie Hoeneisen followed up his presentation at the previous IETF meeting of an EPP extension framework for an ENUM validation mechanism. The draft "ENUM Validation Information Mapping for the Extensible Provisioning Protocol” (draft-hoeneisen-enum-validation-epp-01.txt) specifies a validation mechanism that will ensure that a holder of an ENUM domain name corresponds to the holder of the E.164 number. It was a consensus at the meeting to accept this as a WG work item. Implementation experience is needed to get forward with this work.

5.5.4 GROW (Global Routing Operations) WG 5.5.4.1 IETF 64 (Frode Kileng)

[This referee arrived one hour after meeting start due to collision with another meeting.]

One item on the agenda was a presentation of the "IPv4 Address Report", which reports the current status on the allocations of IPv4 addresses and analysis the rate of consumption giving an estimate for exhaustion of the IPv4 address pool. The exhaustion analysis concludes with the date 7/5-2012 for the exhaustion of IPv4 addresses from the IANA address pool and 20/5-2013 for the RIR pool. The IPv4 address report is available at (http://ipv4.potaroo.net).

5.5.5 Session Initiation Proposal Investigation (Sipping) 5.5.5.1 IETF 64 (Frode Kileng)

Dan Petrie presented work on a configuration framework and data sets for SIP. This was based on the drafts "A Framework for Session Initiation Protocol User Agent Profile Delivery" (draft-ietf-sipping-config-framework-07.txt), "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets (draft-petrie-sipping-profile-datasets-03.txt) and "The Core Session Initiation Protocol User Agent Profile Data Set" (draft-petrie-sipping-sip-dataset-01.txt). The objective for this is to establish a minimal set of vendor independent properties required for deploying a SIP VoIP service. Important now is to identify any missing obligatory properties and to set criteria for the selection of profile data sets that should be WG items.

Volker Hilt presented a set of drafts related to session policies for SIP: "A Framework for Session Initiation Protocol (SIP) Session Policies " (draft-hilt-sipping-session-policy-framework-00.txt), "A User Agent Profile Data Set for Media Policy" (draft-ietf-sipping-media-policy-dataset-00.txt) and "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies" (draft-hilt-sipping-policy-package-00.txt). The establishment of session policies is done between the UA and a "policy server". There are still several open issues with this solution, like deciding about the subscription/notification mechanism, the format used in the policy decision (SDP? Patch to SDP? XML Policy format?), and a security model to prevent submissions of illegal policies to the UA, which prevents illegal policy downloads from the policy server and that supports mutual authentication mechanisms.



Vijay Gubriani presented a couple of drafts concerning IPv6 and SIP. The drafts were "IPv6 Transition in the Session Initiation Protocol (SIP)" (draft-ietf-sipping-v6-transition-01.txt) and "Recommendations on the use of IPv6 in the Session Initiation Protocol" (draft-gurbani-sipping-ipv6-sip-01.txt). That IPv6 is becoming an issue in WGs like SIP is yet another sign of the maturity of IPv6.

Markus Isomakin presented a potential new WG item "Requirements and Possible Mechanisms for File Transfer Services Within the Context of SIP Based Communication" (draft-isomaki-sipping-file-transfer-00.txt). It describes a user-to-user file transfer mechanism in the SIP framework, i.e. in addition to what already exists there like Instant Messaging, presence, conferencing, etc. Isomakin told that implementations already exist and there are issues related to interoperability that this draft would solve. The solutions support ad-hoc mode file transfers (one-to-one, one-to-many) and session related (one-to-one session within the context of the session/conference and conference transfer). The discussion showed that there were some objections against this work item. One argument was that file transfer is just one of many potential mechanisms that are interesting to integrate in the SIP framework and that there is a need for generic mechanisms for supporting add-ons to SIP-sessions. The Chair felt that this work belonged in the SIMPLE WG.

Rocky Wang presented the "Calling Party Category" draft (draft-rocky-sipping-calling-party-category-01.txt). This describes a solution for the classification of the calling party with the purpose of performing peer specific call handling. One possible application for this is a "Do Not Disturb" (DND) supplementary service to make the network automatically reject incoming calls dependent of the category of the calling party. Another potential service is an "Anonymous Call Rejection" (ACR) service. During the discussion, several attendees raise objections against this and declared that this belonged somewhere else.

The last draft worth mentioning was presented by Hannes Tschofenig, The "Payment for Services in SIP" (draft-jennings-sipping-pay-03.txt) can be described as "postage stamps for SIP" that will be used to prevent spam-calls by telling the caller "I don't know you, please show your good intentions by donating 1 cent to my favorite charity and show me your receipt"! The dependency on a well functioning micro payment infrastructure was one of the objections against taking this up as w WG item.



6 Reports from Area Meetings

6.1 IETF 64

6.1.1 APPTSV (Applications/Transport Joint Session) Meeting (Frode Kileng)

The meeting, that was a joint meeting between the Application Area (APP) and the Transport Area (TSV) in IETF, started with a report of current status of IETF work in the APP area since IETF63. There are some concerns about the work going on in the area of Mobile E-Mail in OMA, i.e. the OMA MEM MWG. The IETF LEMONADE WG ("Enhancements to Internet email to support diverse service environments") has had a workshop together with OMA MEM MWG on this issue. In general, there is a lot of work on external relations and the chairs urged the participants to follow this work more closely.

Continuing on the APP area status update, the WIDEX WG ("Widget Description Exchange Service") has been formally started, a WG addressing issues related to remote user interfaces. A BOF on this subject was held in Paris at IETF63. At IETF64, a XML-Patch-Ops BOF was held on the subject of issues related to XML resource manipulation, a BOF that was not intended to initiate a new WG but to review work on this issue from the SIMPLE WG and evaluate if this work is duplication on existing work, a useful addition or a replacement of existing work. Another BOF to be held at IETF64 was the IEE BOF ("Internationalized E-mail and extensions"). The chair also identified relevant BOFs from other areas besides APP or TSV like the SEC area DKIM BOF ("Domain Keys Identified Mail") and the OPS area CALLHOME BOF ("Reversing Traditional Client/Server Connection Model").

The TSV area director then gave a similar passage through the status of the TSV area since IETF63. Worth mentioning was the VOIPEER BOF that will initiate a WG to "develop a 'big picture' architecture for how service providers of VoIP interconnect". A separate report of this BOF is available as a separate report. Another interesting BOF was the FECFRAME (Forward Error Correction over Transport Framework) addressing error correction techniques for unreliable transport protocols, a work with the area of real-time applications like RTP/RTCP in mind.

On the agenda was also a presentation and discussion of the split of the TSV area and the collection of real-time related work as a new separate area called RAI (Real-time Applications and Infrastructure). TSV will still address transport protocols, i.e. services offered to upper layers although some of them are somehow related to real-time issues. Examples are SCTP, RSVP and DIFFSERV.

The meeting ended with a discussion related to new topics for the TSV area like transport specific issues related to overlay networks like peer-to-peer networks including overlay multicast network.

6.1.2 OPSAREA (Operations and Management Open Area) Meeting (Frode Kileng)

Christian Jacqenet from France Telecom presented issues related to the provisioning of Internet-wide VPN services. The background for this work is the emerging triple-play services where some applications are QoS demanding (TV broadcasting, VoIP) and others



require traffic isolation (vconf etc.). There is a need for contractual commitments for the provisioning of QoS-based VPN services and the need for exchanging QoS information between domains. Another issue is the need for automation for reducing cost of operations, for dynamic provisioning of network resources and for the dynamic enforcement of a set of VPN-specific policies. The approach proposed by Jaqenet is to write a requirement draft detailing issues in the provisioning of QoS-based inter-domain VPN services and then to address this in a BoF at IETF65 in Dallas in February. The area director had already refused a request for a BOF on this at IETF64 due to the lack of drafts and mailing list. Ross Calloni stated that this is a complex area and there is a need for clarifying the work that must and should be done and also where it belongs. Calloni thinks that it is an interesting subject but that there is no need for a new WG on this since the work could be done in existing WGs. A potential area for a new WG is related to work on inter-AS-QoS. Another attendee disagreed and stated the need for a dedicated WG working on addressing the "whole picture" on an area that is a real problem for operators. The Area Director concluded that there is a need for focusing this work before a BoF can be held and the foundation of a new WG.

Kathleen Nichols presented the draft "A Strawman Architecture for Diffserv Control Plane Elements" (draft-nichols-dcpel-strawman-arch-00.txt) (DCPEl) related to the generic end-to-end service provisioning as the subject for a new WG. DiffServ focused on mechanisms for how a router should behave in case of too much traffic but leaved out issues related to administration and management of the router, i.e. the "Control Plane" part of the proposal. One attendee objected to this item stating that it is irrelevant since DiffServ turned out to have scaling problems and that this proposal comes two years to late. Hannes Tschofenic presented NSIS, a potential candidate for the control plane. The NSIS protocol suit is a generic signaling solution well suited for a number of environments and usage scenarios. There was a discussion about the NSIS usage in ITU-T and ETSI-TISPAN. During the discussion, several attendees stated that this work is important and also raised the need for coordinating this with ITU. Hannes stated that there is a need for a problem description and this draft is just discussing specific solution and its implementation. The Area Director asked the meeting if this work should be taken up by IETF in some way or another. Objections to this question from the audience stopped a consensus call. Several attendees indicated the need for a clarification of the area of work before a vote was taken or else the consensus call would just kill the discussion on this item.



7 Reports from BoF sessions

7.1 IETF 64

7.1.1 16ng (IPv6 over IEEE 802.16(e) Networks) BOF (Frode Kileng) This BOF is the first time WiMAX, or IEEE 802.16(e), is an item on an IETF agenda.

The first part of the meeting was used for presentations describing the IEEE 802.16(e) technology. Hannes Tschoefenic gave the initial generic introduction, Parviz Yegani gave an overview of the work in the WiMAX forum Network Working Group and James Kempf from the DoComo Labs in USA gave a presentation on using network based localized mobility management for WiMAX.

Ye-Seon Kim from Korea Telecom presented the status and plans of WiBro, i.e. 802.16 deployment project in South Korea. Currently, WiBro is using IPv4 but will support IPv6 in the near future. Kim stated that one of the advantages of IPv6 over WiBro is the enhanced mobility support and the support for an increasing number of devices (due to the address room). The migration plan is divided in 3 phases: Phase 1 is the current IPv4 only, phase 2 with dual-stack IPv4/IPv4 together with IPv4 only and phase 3 supporting IPv6 only together with dual-stack and IPv4 only. Kim was unable to answer any technical questions since she, by her own words, "was not a technician".

Gabriel Montenegro had the pleasure to present the first draft ever on WiMAX in IETF. The draft "Transport of IP over 802.16" (draft-mandin-ip-over-80216-ethcs-00.txt) is written by Jeff Mandin, who could not be present due to a collision with a WiMax meeting. Fundamental issue for IP transport over 802.16 is the determination of the IP sub-network model, the selection of which 802.16 convergence sub layer type to be used and to specify how to set up classifier tables in the convergence sub layer. The Ethernet convergence sub-layer is an obvious choice for the IP transport since it is clean and simple and out-of-the-box compatible with host and routes. Montenegro was asked why there is a need for any further work on this if the Ethernet sub-layer could be used as it is? His answer was that it looks like Ethernet but it is not, for example that it only supports multicast on "the air".

Myung-Ki Shin from ETRI presented the draft "Scenarios and Considerations of IPv6 in IEEE 802.16 Networks" (draft-shin-ipv6-ieee802.16-01.txt). The characteristics of 802.16 networks (links) influence how to adapt IPv6 and the considerations discussed is classified into protocol issues, implementation issues and operational issues. Issues discussed are the basic mapping of IPv6 onto 802.16 (ND, transmission of IPv6 packets, IPv6 addressing/sub-net model), mobility ("plain" Mobile IPv6 or Mobile IPv6 with fast handover), multicast (e.g. Multicast Listener Discovery (MLD)) and security considerations.

The final item on the agenda was a presentation and discussion of the proposed charter. The chairs stated that there now is a limited window of opportunity to work together with WiBro and WiMax. The Area Director asked the meeting a direct question if IETF should have a WG working on this. A large majority of the participants answered yes and when asked, there seemed to be a lot of people who wanted to contribute that also work in WiMAX and WiBro. The majority also felt that the charter needs more work.



7.1.2 VOIPEER (VoIP Peering and Interconnect) BOF (Frode Kileng) The subject of this BOF was SIP peering and interconnection between providers/"managed domains" and the intention was to discuss the charter and focus of a new WG. It was the second BOF to be held on this subject, the first one was at IETF63 in Paris. The meeting agreed to start to use the term "managed domains" instead of "providers" or "carrier".

The first item on the agenda was a discussion about the charter. The charter will cover specification of a call-routing architecture for delay-sensitive (real-time) communication using the SIP protocol, specification of various types of packet flows in such networks, requirements on feedback for operational conditions and best current practice (BCP) regarding the exchange of calls among VoIP providers. The division of labor with the ENUM WG was set by the formulations: "ENUM WG is primarily concerned with the structure of data for the translation of E.164 numbers into SIP URIs and the VOIPEER WG is concerned with the use of that data for use in signaling an routing real-time sessions.

In the discussion, the question was raised if accounting and billing should be covered by the WG Charter. David Meyer, the chair, said no, since this is an area where lot of work has been done and several solutions exists. There were some objections from people feeling that this belongs to VOIPEER. The meeting showed consensus to include work on Caller ID in the charter. It was also a consensus to leave the charter as it was proposed and in the future maybe change it to include the interaction between layer 3 and layer 5.

The meeting ended in a discussion of the name of the WG. Several names have been proposed and were discussed. But when SIPPAIRING was proposed, the meeting supported a shortening of this. The new name of the WG was at the meeting decided to be SPEER WG (for SIP Peering). After the meeting the name was changed to SPEERMINT (Session PEERing for Multimedia INTerconnect).

7.2 IETF 63

7.2.1 AUTOCONF (Ad-Hoc Network Autoconfiguration) BoF (Paal E. Engelstad)

This BOF is preceded by a BOF in Minneapolis (IETF62), and an earlier bar-BOF in San Diego (IETF61). The background for the BOF is that autoconfiguration is not a charter of the MANET WG, which is in the Routing Area of the IETF. This BOF, on the contrary, relates more to other Internet-area related work, such as ZEROCONF for on-link autoconfiguration, IPv6 stateless autoconfiguration and the use of DHCP as a network administrative tool.

The WG looks at multi-hop packet forwarding. The network can be infrastructure-less (i.e. continue to work without infrastructure), and accommodate random mobility. It should be noted that an ad-hoc node has a concept of a link that is different from that of a node on the fixed Internet. Network mergers are particularly relevant, and might require separate duplicate address detection. IPv6 is first priority, while IPv4 might be tackled later. DNS discovery and naming is out of scope of the WG. The WG will mainly make modification to existing solutions (e.g. make IPv6 stateless or stateful autoconfiguration work in a MANET environment).

The main milestones of a WG will comprise:

• Terminology and problem statements.



• A stateless IPv6 solution with unique local and global addresses will be submitted, hopefully reusing existing specifications (e.g. IPv6 autoconfiguration).

• A stateful IPv6 solution will be submitted, acknowledging that DHCP-hacks are already being deployed on MANETs today, hopefully reusing the existing specifications (e.g. DHCPv6).

• Configured address uniqueness maintenance. This will be a specification that needs particular development within the WG, since it will probably not be an extension of other specifications.

7.2.2 NETLMM (Network-based Localized Mobility Management) BOF (Paal E. Engelstad)

The NETLMM (Network-based Localized Mobility Management) BOF targets local IP mobility over a restricted geographical, administrative and IP-topology domain. Localized mobility management normally means to reduce the amount of latency and host signaling - while the Mobile IP binding update and route optimization is completing. Location privacy is also important.

The existing protocols feature extensive host involvement in localized mobility management, and a tight coupling with Mobile IP; for example, HMIP, FMIP and LLMIPv4. These are experimental protocols, but there has been no real progress.

Need for non-MIP related localized mobility management is needed, because:

• New non-MIP global related global mobility protocols have emerged, such as HIP and MOBIKE.

• WLAN switches have taken over, and no MN protocol stack changes are required for local mobility management. Customers prefer this approach.

Problems with existing localized mobility management:

• Can't be used by any host • Designed to MIPv6 • Security associations are required and virus can expose the host's location.

The solution that this group will seek:

• Is a "routing-style" service, • Does not require authorization in addition to the network access authorization, • Minimizes changes in the host stack, • Improves handover performance, and • Supports heterogeneous wireless.

Relevance to some other standardization efforts:

• 3GPP: It was pointed out by Katsutoshi Nisida, DoCoMo YRP, that the Localized Mobility Management developed in this WG is anticipated to be very important for 3GPP in terms of All IP Networks (AIPN).

• WIMAX: IEEE 802.16e access might benefit from network-based localized mobility management for IP developed in this group.

The solution will target IPv6 first, but must also be able to carry IPv4 traffic. A tunneling approach will first be explored and not the use of host-routes.



There seemed to be enough interest to form a working group. However, according to comments during the meeting, the proposed charter first needs a number of changes and modifications.

7.2.3 MONAMI6 (Mobile Nodes and Multiple Interfaces in IPv6) BoF (Geir Egeland)

Issues regarding the support and the simultaneous use of multiple interfaces on mobile nodes operating Mobile IPv6 or NEMO Basic Support were discussed occasionally in various IETF Working Groups, particularly in MIP6. Several solutions already exist, each addressing a different part of the entire problem. In addition, some of the identified issues are not specific to mobility, whereas mobility specific issues apply to both Mobile IPv6 and NEMO Basic Support. The motivation for the BOF is the creation of a new working group in order to focus on the mobility-specific issues independently from existing IETF Working Groups (presumably MIP6, MIPSHOP, IPv6, NEMO, V6OPS, and SHIM6). The goal of the new working group would be to provide a clear problem statement and the associated solutions. More information about the BOF can be found at http://www.nautilus6.org/ietf.

The comments from the people attending the BOF was divided into two groups; those who said it was to early to start anything before SHIM6 has provided any output, and those who meant that this could be done in parallel. Some people also commented that this work also could be done in some of the other WG, but this could again be difficult since these WGs already are overloaded with work. There was no consensus in the room whether a WG could be set up based on the proposed charter, - which led to the conclusion that the people behind the BOF need to work on the charter and present this topic again.

7.3 IETF 62

7.3.1 6LOWPAN (IPv6 over Low power WPAN) BOF (Frode Kileng) The 6LOWPAN was officially established as a WG a few days before the meeting. Compared to last BOF (IETF61 in Washington DC) there were more high-profile IETF-attendees attending.

Nandakishore Kushalnagar from Intel presented the problem statement of the WG described in draft-kushialnagar-lowpan-goals-assumptions-00. Basically, 6LOWPAN addresses IPv6 over a MAC layer based on IEEE 802.15.4-2003 standard. Typical 6LoWPAN characteristics are: small packet size, 16-bit short or IEEE 64-bit extended media access control addresses, low bandwidth (250/40/20 kbps), star and mesh-topologies, low power (typically battery operated), relatively low cost, networks are ad hoc &devices have limited accessibility and user interfaces and devices are inherently unreliable due to nature of devices in the wireless medium. The problem statement defines the assumptions that: Devices conform to IEEE 803.15.4-2003, that they typically send small amounts of data and that they are typically constrained devices.

There are several challenges: In worst case, an 802.15.4 PDU will have 81 octets and IPv6 MTU requirements are 1280 octets. Stacking IP and above layers "as is" may not fit within one 802.15.4 frame (IPv6=40 octets, TCP=20 octets, UDP=8 octets + other layers (security, routing, etc) leaving few bytes for data. Not all ad-hoc routing protocols may be immediately suitable for 6LOWPAN (DSR may not fit within a packet, AODV needs more memory, etc). Existing service discovery methods may be to "bulky" for 6LOWPAN (primarily XCML based that needs computing, more memory, etc). Support for limited


http://www.nautilus6.org/ietf


configuration and management are necessary. Security or multi hop needs also to be considered.

WG Goals of 6LOWPAN are:

• To define adaptation (fragmentation/reassembly) layer to match v6 MTU requirements.

• To specify methods to do IPv6 stateless address autoconfiguration. • To specify (or usage of existing) header compression schemes. • To specify implementation considerations and best methods of an IPv6 stack. • To define methods for meshing in 6LOWPAN below IP.

Other goals that are currently not in the charter are:

• To use/adapt network management technologies for 6LOWPANS. • To specify encoding/decoding (or perhaps new protocols) for device discovery

mechanisms. • To document 6LOWPAN security threats.

During the discussion, it was stated that the scope is to try to use existing mechanisms and not to invent everything from scratch. Several attendees raised a concerned that security issues must be addressed by the WG and not do depend that some-security-WG will do this.

Gabriel Montenegro from Sun presented the first "real work" draft from the WG. The draft "Transmission of IPv6 packets over IEEE 802.15.42” (draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt) defines how IPv6 is mapped over 802.15.4. The progress plan is to do a WG last call of this in May 2005 and send this to IESG as a proposed standard in July 2005. The draft specifies the 15.4 mode for IP, MTU, frame format and adaptation layer, stateless address auto configuration, v6 link-local addresses, unicast address mapping, header compression, packet delivery in a mesh, etc.

The selected 802.15.4 mode for IP is to pack IP packets in data frames. The use of non-beacon enabled network is selected (No beacons for sync but certainly for device discovery), contention based channels access (CSMA/CA), no guaranteed time service (GTS). The addressing mode both source and destination address is included (PAN IDs also possible). Two types of MAC addresses (64 bit extended addresses, 16 bit short addresses are possible (TO BE DONE). PAN ID (16 bits) <-> IPv6link (i.e. IPv6 prefix). Current assumption is that a given PAN ID maps to a given IPv6 link but it is not specified how to do the mapping. One possibility is that /48+16bits of PAN ID gives the IPv6 prefix.

The IPv6 MTU mapping states that IPv6 MTU over 802.15.4 SHALL BE 1280 (i.e. the minimum IPv6 MTU). The 802.15.4 MTU is only 102 octets without security and only 81 octets with (AES in max CCM mode). This means that there is a need for an adoption layer. Also needed is header compression for IP (not a luxury).

The 6LOWPAN service layer consists of the MAC adaptation layer that allows larger (than 802.15.4) packets to be sent, allows packet delivery in a mesh and allows protocol multiplexing via protocol type (current protocol types are: IPv6 (prot_type=1), IPv6 compressed headers (prot_type=2), AODV for 15.4 (prot_type=4), other protocols, some applications themselves)

Three types of frame format is defined, one for un-fragmented packets and two for fragmented. LF bit identifies fame format (00=un-fragmented, 01=first fragment, 10=last fragment, 11=interior fragment). Also, the m-bit in header is an indication that there is a mesh routing (destination is coded in header).



The draft also defines stateless address auto configuration based on EUI-64 for 802.15.4. The Interface Identifier (IIF) obtained via IPv6 over Ethernet (RFC 2464). Prefix must be 64 bits. Mapping to 16-bit short addresses possible (work to be done). Link-local addresses as usual: FE80::11F.

7.3.2 AUTOCONF (Ad-Hoc Network Autoconfiguration) BoF (Geir Egeland)

This BOF discussed the need for a WG to be set up for designing protocols for autoconfiguration of MANETs, i.e. Address configuration, DNS, etc. Autoconfiguration has been a topic of much discussion in the MANET WG, but this has now ended, as the MANET charter now specifically state that only routing protocols should be the topic of WG discussion. The goal of the AUTOCONF BOF was to work on solutions for both IPv4 and IPv6 network. The solution should cater for both partitioning and merging of ad hoc network. It should also cater for node mobility within a network, and for random nodes joining and/or leaving network.

The AD commented that such a solution should not be especially different from IP-network. The audience felt that this was important and this has to work and be interoperable and is an important step towards getting MANETs out there and working.

7.3.3 BTNS (Better-Than-Nothing Security) BOF (Frode Kileng) The goal for this BOF was to determine if there was sufficient interest within the IETF community to work on this, i.e. to start a WG with this as a theme. The motivation for BTNS is that some network security is better than nothing and that existing network security protocols are complex and not widely used. One explanation is the requirement for a hard-to-deploy-and-manage key infrastructure. BTNS was first discussed in a BOF at IETF-61 in Washington Nov 2004.

BTNS will protect an ongoing connection by ensuring that the endpoint is the same throughout an association. It doesn't support any guarantees of the endpoint IDs but will protect against association thefts. This is similar to the SSL used for client side authentication for HTTPS. BTNS should not be used when network identity matters and when this is not validated at higher layers. The intention is to develop extensions to IPSec and IKE for this infrastructure-free security mechanism.

The main item of the agenda was a discussion of the proposed WG charter. The discussion of the charter mainly concerned issues if it is possible to state in the charter that IPSec/IKE should be changed and if this should be specified in the list of WG work items. Also discussed were the milestones, or more correctly, the deliverable dates. The intention is to have initial drafts of WG documents finished within 2 months. The BTNS framework specification will be delivered to IESG within 5 months. The applicability statement document is expected to be published soon after this. A document describing IKE extensions to the SPD and PAD for supporting anonymous keying for IPSec and cryptographic channel bindings for IPSec will be sent to IESG within 9 months. Within 6-8 months an informational document on the usage of IPSec in securing higher-level protocols will be sent to IESG.

There seemed to be a general interest in the BTNS work but there also seemed to be few volunteers to participate and to do the actual work.



7.3.4 TC (Tunneling Configuration) BoF (Geir Egeland) The main goal for this WG was to design a mechanism for automatic to set up an IPv6 tunnel over IPv4 between a home site and the core. The meeting had as goal to agree on some tunnel properties such as:

• Authentication, • MTU, • encapsulation, • and if a Tunneling End Point (TEP) discovery mechanism was needed.

One of the concerns of some of the people in the WG was how does tunnel endpoint scale at the ISP side. If UDP ports are used to discriminate between tunnels, only 64k tunnels can be set up. Another concern was how easy is it to remove such a service when it is no longer necessary. Some people also felt that such a mechanism might even not be useful, and an important comment from Japan Telecom was that native IPv6 is cheaper than tunneling.

After a show of hands for ISP supporting a TEP mechanism, a majority of ISPs meant that this type of feature is not useful. Most ISP feels that TSP is sufficient if this is moved forward as an RFC. ISPs want to have control over the network, and do not want to deploy any mechanism which reduces this kind of control. All ISP knows how to access and configure services in the network, and thus do not need a protocol for discovering services. This type of information/setup can be deployed on setup-CDs which most ISPs already ship to customers.

TEP discovery is not really useful from an ISP point of view. A roaming user will connect to his well-known TEP as usual, and it is not big deal if the path is not optimum in this case. This is what Tunneling Broker users are experiencing for a while, and what we actually do when connecting to our enterprise network through a secured VPN.
