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/
Company INTERNAL
R&D Scientific
Doc.
Title
ISBN
ISSN
Project No
Program
Security Gr.
No. of pages
Date
Report from IETF meeting attendance 2005
N xx/2006
Report from IETF meeting attendance 2005
Company INTERNAL
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
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.
Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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
4.1.1
4.1.2
4.2
4.2.1
4.2.2
4.3
4.3.1
4.3.2
Plenary sessions for IETF 64 ............................................................................. 5
IETF Operations and Administration Plenary (Frode Kileng) .......................... 5
Technical Plenary (Frode Kileng)...................................................................... 6
Plenary sessions for IETF 63 ............................................................................. 7
IETF Operations and Administration Plenary (Geir Egeland) .......................... 7
Technical Plenary (Paal E. Engelstad)............................................................... 8
Plenary sessions for IETF 62 ............................................................................. 9
IESG Plenary (Geir Egeland) ............................................................................ 9
IAB Plenary (Frode Kileng) .............................................................................. 9
5
Reports from selected IETF working groups .........................11
5.1
5.1.1
5.1.1.1
5.1.1.2
5.1.2
5.1.2.1
5.1.2.2
5.1.2.3
5.1.3
5.1.3.1
5.1.4
5.1.4.1
5.1.4.2
5.1.4.3
5.2
5.2.1
5.2.1.1
5.2.2
5.2.2.1
5.2.2.2
5.2.3
5.2.3.1
5.2.3.2
5.2.3.3
5.2.4
5.2.4.1
5.2.5
5.2.5.1
5.2.6
IPv6.................................................................................................................. 11
6LOWPAN (IPv6 over Low power WPAN) WG ........................................... 11
IETF 64 (Frode Kileng) .............................................................................. 11
IETF 63 (Paal E. Engelstad) ....................................................................... 12
IPv6 (IP version 6) WG ................................................................................... 12
IETF 64 (Frode Kileng) .............................................................................. 12
IETF 63 (Geir Egeland) .............................................................................. 13
IETF 62 (Frode Kileng) .............................................................................. 14
SHIM6 (Site Multihoming by IPv6 Intermediation) WG................................ 15
IETF 63 (Paal E. Engelstad) ....................................................................... 15
V6OPS (IPv6 operations) WG......................................................................... 16
IETF 64 (Frode Kileng) .............................................................................. 16
IETF 63 (Geir Egeland) .............................................................................. 17
IETF 62 (Geir Egeland) .............................................................................. 17
Mobility ........................................................................................................... 19
CAPWAP (Control And Provisioning of Wireless Access Points) WG ......... 19
IETF 63 (Paal E. Engelstad) ....................................................................... 19
DNA (Detecting Network Attachment) WG ................................................... 19
IETF 63 (Geir Egeland) .............................................................................. 19
IETF 62 (Geir Egeland) .............................................................................. 19
MANET (Mobile Ad-hoc Networks) WG....................................................... 20
IETF 64 (Frode Kileng) .............................................................................. 20
IETF 63 (Paal E. Engelstad) ....................................................................... 21
IETF 62 (Geir Egeland) .............................................................................. 21
MIP4 (Mobility for IPv4) WG......................................................................... 22
IETF 63 (Paal E. Engelstad) ....................................................................... 22
MIP6 (Mobility for IPv6) WG......................................................................... 22
IETF 62 (Geir Egeland) .............................................................................. 22
MOBIKE (IKEv2 Mobility and Multihoming) ............................................... 23
Telenor R&D N xx/2006
Report from IETF meeting attendance 2005
Company INTERNAL
5.2.7
5.2.7.1
5.3
5.3.1
5.3.1.1
5.3.1.2
5.3.2
5.3.2.1
5.3.2.2
5.3.3
5.4
5.4.1
5.4.1.1
5.4.1.2
5.4.2
5.4.2.1
5.4.3
5.4.3.1
5.4.3.2
5.4.4
5.4.4.1
5.4.5
5.4.5.1
5.4.6
5.4.6.1
5.5
5.5.1
5.5.1.1
5.5.2
5.5.2.1
5.5.2.2
5.5.3
5.5.3.1
5.5.3.2
5.5.4
5.5.4.1
5.5.5
5.5.5.1
NEMO (Network Mobility) WG ..................................................................... 23
IETF 63 (Geir Egeland) .............................................................................. 23
Multicast Routing ............................................................................................ 24
MBONED (MBONE Deployment) WG.......................................................... 24
IETF 64 (Frode Kileng) .............................................................................. 24
IETF 62 (Frode Kileng) .............................................................................. 24
PIM (Protocol Independent Multicast) WG..................................................... 26
IETF 64 (Frode Kileng) .............................................................................. 26
IETF 62 (Frode Kileng) .............................................................................. 26
MSEC (Multicast Security).............................................................................. 26
Security ............................................................................................................ 27
ENROLL (Credential and Provisioning) WG.................................................. 27
IETF 62 (Tor Hjalmar Johannessen)........................................................... 27
IETF 62 (Tor Hjalmar Johannessen)........................................................... 27
ISMS (Integrated Security Model for SNMP) WG ......................................... 28
IETF 62 (Tor Hjalmar Johannessen)........................................................... 28
MOBIKE (IKEv2 Mobility and Multihoming) WG ........................................ 28
IETF 63 (Paal E. Engelstad) ....................................................................... 28
IETF 62 (Tor Hjalmar Johannessen)........................................................... 28
MSEC (Multicast Security) WG...................................................................... 29
IETF 62 (Frode Kileng) .............................................................................. 29
PKIX (Public-Key Infrastructure) WG ............................................................ 29
IETF 62 (Tor Hjalmar Johannessen)........................................................... 29
SAAG (Security Area Advisory Group).......................................................... 31
IETF 62 (Tor Hjalmar Johannessen)........................................................... 31
Other groups covered by watcher .................................................................... 33
DHC (Dynamic Host Configuration) WG ....................................................... 33
IETF 62 (Frode Kileng) .............................................................................. 33
DNSOP (Domain Name System Operations) WG .......................................... 33
IETF 64 (Frode Kileng) .............................................................................. 33
IETF 62 (Frode Kileng) .............................................................................. 34
ENUM (Telephone Number Mapping) WG .................................................... 35
IETF 64 (Frode Kileng) .............................................................................. 35
IETF 62 (Frode Kileng) .............................................................................. 35
GROW (Global Routing Operations) WG....................................................... 36
IETF 64 (Frode Kileng) .............................................................................. 36
Session Initiation Proposal Investigation (Sipping)......................................... 36
IETF 64 (Frode Kileng) .............................................................................. 36
6
Reports from Area Meetings ...................................................38
6.1
6.1.1
6.1.2
IETF 64 ............................................................................................................ 38
APPTSV (Applications/Transport Joint Session) Meeting (Frode Kileng)..... 38
OPSAREA (Operations and Management Open Area) Meeting (Frode
Kileng) ............................................................................................................. 38
7
Reports from BoF sessions ....................................................40
7.1
7.1.1
7.1.2
7.2
7.2.1
IETF 64 ............................................................................................................ 40
16ng (IPv6 over IEEE 802.16(e) Networks) BOF (Frode Kileng) .................. 40
VOIPEER (VoIP Peering and Interconnect) BOF (Frode Kileng) .................. 41
IETF 63 ............................................................................................................ 41
AUTOCONF (Ad-Hoc Network Autoconfiguration) BoF (Paal E.
Engelstad) ........................................................................................................ 41
Telenor R&D N xx/2006
Company INTERNAL
7.2.2
7.2.3
7.3
7.3.1
7.3.2
7.3.3
7.3.4
Report from IETF meeting attendance 2005
NETLMM (Network-based Localized Mobility Management) BOF (Paal
E. Engelstad).................................................................................................... 42
MONAMI6 (Mobile Nodes and Multiple Interfaces in IPv6) BoF (Geir
Egeland)........................................................................................................... 43
IETF 62............................................................................................................ 43
6LOWPAN (IPv6 over Low power WPAN) BOF (Frode Kileng) ................. 43
AUTOCONF (Ad-Hoc Network Autoconfiguration) BoF (Geir Egeland) ..... 45
BTNS (Better-Than-Nothing Security) BOF (Frode Kileng).......................... 45
TC (Tunneling Configuration) BoF (Geir Egeland) ........................................ 46
Telenor R&D N xx/2006
Company INTERNAL
1
Report from IETF meeting attendance 2005
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
Report from IETF meeting attendance 2005
2
Company INTERNAL
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
Company INTERNAL
3
Report from IETF meeting attendance 2005
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
Telenor R&D N xx/2006 - 3
Report from IETF meeting attendance 2005
Company INTERNAL
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 - Telenor R&D N xx/2006
Company INTERNAL
4
Reports from plenary sessions
4.1
Plenary sessions for IETF 64
Report from IETF meeting attendance 2005
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
Telenor R&D N xx/2006 - 5
Report from IETF meeting attendance 2005
Company INTERNAL
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 CryptoForum 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: SHA2224 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 HMACSHA1 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. SHA1 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
6 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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
Plenary sessions for IETF 63
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.
Telenor R&D N xx/2006 - 7
Report from IETF meeting attendance 2005
Company INTERNAL
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, ARPspoofing, 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.
8 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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
•
•
•
•
4.3
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.
Plenary sessions for IETF 62
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-irtf00.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
Telenor R&D N xx/2006 - 9
Report from IETF meeting attendance 2005
Company INTERNAL
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 Internetsolutions 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.
10 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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.
Telenor R&D N xx/2006 - 11
Report from IETF meeting attendance 2005
Company INTERNAL
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
12 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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-48boundary00.txt.
Telenor R&D N xx/2006 - 13
Report from IETF meeting attendance 2005
Company INTERNAL
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:
•
•
•
•
•
•
5.1.2.3
IPv6
Address Architecture
ICMPv6
Neighbor Discovery
Stateless Autoconfiguration
Path MTU Discovery
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)" (draftietf-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
14 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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-ip6int-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 rehoming 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
Telenor R&D N xx/2006 - 15
Report from IETF meeting attendance 2005
Company INTERNAL
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-deploymentscenarios-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-v6opsport-scanning-implications-02) written by Tim Chown. It discusses implications for portscanning 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.
16 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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-chownv6ops-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.
Telenor R&D N xx/2006 - 17
Report from IETF meeting attendance 2005
Other WG documents that was presented where:
•
•
•
Things to think about when renumbering
IPv6 Security overview
Use of VLAN for IPv4/IPv6 coexistence
18 - Telenor R&D N xx/2006
Company INTERNAL
Company INTERNAL
5.2
Report from IETF meeting attendance 2005
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
Telenor R&D N xx/2006 - 19
Report from IETF meeting attendance 2005
•
•
Company INTERNAL
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:
Explicit link ID random
o
Explicit link ID prefix hash
o
o
Priority landmark
Fast advertisement
o
Simple fast RA
Deterministic Fast RA
o
This leaves:
•
•
Link detection
Explicit link ID agreed prefix
o
Complete RA
o
Requested landmark
o
o
Hybrid landmark
Fast advertisement
Fast router discovery
o
Hash ordered fast RA
o
Probabilistic fast RA
o
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-ietfmanet-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.
20 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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 nonwireless 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.
Telenor R&D N xx/2006 - 21
Report from IETF meeting attendance 2005
Company INTERNAL
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.
22 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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.
Telenor R&D N xx/2006 - 23
Report from IETF meeting attendance 2005
5.3
Company INTERNAL
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-multicast04.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
24 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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-l3vpn2547bis-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" (drafthayashi-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.
Telenor R&D N xx/2006 - 25
Report from IETF meeting attendance 2005
Company INTERNAL
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 dataplane 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” (draftietf-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 lasthop 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
26 - Telenor R&D N xx/2006
Company INTERNAL
5.4
Report from IETF meeting attendance 2005
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.
Telenor R&D N xx/2006 - 27
Report from IETF meeting attendance 2005
Company INTERNAL
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
•
•
•
•
•
5.4.3.2
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.
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.
28 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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-rsar-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
Telenor R&D N xx/2006 - 29
Report from IETF meeting attendance 2005
Company INTERNAL
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.
30 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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:
Collision: Find M, M' such that H(M) = H(M')
o
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:
SHA-224, something new?
o
New randomized hash algorithms; in ASN.1 protocols one need a random
o
value in the algorithm identifier parameter.
Telenor R&D N xx/2006 - 31
Report from IETF meeting attendance 2005
o
Company INTERNAL
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.
32 - Telenor R&D N xx/2006
Company INTERNAL
5.5
Report from IETF meeting attendance 2005
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
Telenor R&D N xx/2006 - 33
Report from IETF meeting attendance 2005
Company INTERNAL
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.inaddr.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.
34 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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-edns001.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
Telenor R&D N xx/2006 - 35
Report from IETF meeting attendance 2005
Company INTERNAL
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-enumvalidation-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-sippingprofile-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-policyframework-00.txt), "A User Agent Profile Data Set for Media Policy" (draft-ietf-sippingmedia-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.
36 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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-transition01.txt) and "Recommendations on the use of IPv6 in the Session Initiation Protocol" (draftgurbani-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-toone 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-callingparty-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.
Telenor R&D N xx/2006 - 37
Report from IETF meeting attendance 2005
6
Reports from Area Meetings
6.1
IETF 64
Company INTERNAL
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 XMLPatch-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
38 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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 endto-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.
Telenor R&D N xx/2006 - 39
Report from IETF meeting attendance 2005
7
Reports from BoF sessions
7.1
IETF 64
Company INTERNAL
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 sublayer is an obvious choice for the IP transport since it is clean and simple and out-of-thebox 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.
40 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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.
Telenor R&D N xx/2006 - 41
Report from IETF meeting attendance 2005
•
•
•
Company INTERNAL
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.
42 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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 IETFattendees 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
Telenor R&D N xx/2006 - 43
Report from IETF meeting attendance 2005
Company INTERNAL
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-over802.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 nonbeacon 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).
44 - Telenor R&D N xx/2006
Company INTERNAL
Report from IETF meeting attendance 2005
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 IPnetwork. 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.
Telenor R&D N xx/2006 - 45
Report from IETF meeting attendance 2005
Company INTERNAL
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.
46 - Telenor R&D N xx/2006