Personal Impressions of IETF 49, San Diego,10-14 Dec 2000
Peter T. Kirstein et al.
1. Introduction 2
2. General Issues............... 2
2.1. Plenaries 2
2.2. NGI.. 2
2.3. Policies 2
3. Security... 3
3.1. IPSEC and IKE........ 3
3.2. Multicast Security BOF (MSEC) 3
3.3. PKI... 4
3.4. Authentication, Authorisation and Accounting (AAA) 4
4. Transport 4
4.1. Transport Area Routing Area Joint Meeting 4
4.2. MPLS 4
4.3. SIP... 5
4.4. Policy Framework... 5
4.5. RAP Differentiated Services (DIFFSERV WG) 5
4.6. Forwarding and Control Separation (FORCES)..... 5
4.7. Single Source Multicast (SSM WG)... 6
4.8. Reliable Multicast Transport (RMT WG)... 6
4.9. Seamless Mobility (SEA-MOBY) 6
4.10. Middle Box BOF... 6
4.11. Provider Provisioned VPN (PPVPN) BOF 6
4.12. Intermediate System to Intermediate System (IS IS) 7
4.13. FORCES 7
4.14. Audio/Video Transport Working Group 7
5. Gateways. 7
5.1. MEGACO 7
6. Applications 8
6.1. Applications Open Area and other general Subjects....... 8
6.2. IP Storage WG. 8
6.3. TEWG 8
6.4. Service Level Specification (SLS BOF).... 8
6.5. mboned 8
6.6. Real Time Flow Measurement (RTFM2 BOF) 8
6.7. Mobile trial. 9
6.8. ROHC WG 9
The IETF is growing ever larger particularly if it is in a pleasant part of the US. This time there were over 3000 people. The size makes it increasingly difficult to judge the numbers who may want to go to specific meetings. One BOF had twice as many wanting to come than could be accommodated on the floors and standing in the open doors! Others had huge rooms a quarter full. This note is provided for Scimitar, whose co-funding of my attendance is acknowledged gratefully. In fact it is based on the personal impressions of a number of people at UCL: Jon Crowcroft, Ken Carlsberg, Panos Gevros and myself. I have also tried to avoid duplicating activities described by Jacob Palme and David Chadwick, which also were co-funded by Scimitar.
Each of the UCL people attending really had different missions. I was concerned with furthering some of the IPv6 and mobility issues; Ken was particularly concerned with transport and routing issues, Panos with QoS issues, and Jon with his more general IAB hat. These notes are, however, only snapshots of the areas covered.
The organisation of this report is to consider some general issues in Section 2, and the work on security in Section 3. The longest single section is on all the things I associate with Transport in Section 4. Section 5, on gateways, only considers the MEGAGO and SIP activity, while a number of sessions are grouped under Applications in Section 6. I have not looked at whether this grouping is in accordance with the actual IETF Area divisions; I do not really consider this relevant!
This note is a very personal one; it represents some of the 100 groups and many hundred sessions that interested us. It makes no attempt to be all embracing.
The IAB presented several key problems in the plenary - particularly to the point were Randy Bush's slides on the DNS debacle, Tony Hain on NAT and Geoff Huston on the Routing (BGP) Table problem. There are some crises more than lurking here in stability and so on.
The IAB/IESG stated that there were several critical issues around apart from the MPLS group being basically closed down for lack of architecture, and turned into the new "Volume Area". Several people predicted the imminent death of the Internet at the DNS and BGP junctions!
There is an undercurrent of IPv6 positive attitude emerging. For example, the "How Should We Multihome In IPv6 BOF (multi6)" was full of people talking detail and deployment rather than the past emphasis on "if". Most of the work was concerned with transition planning. Clearly the question of the whole of the IP4/IPv6 issue is particularly concerned with questions such as multi-homing, forms of addressing, resource discovery of where to do the encapsulation, MIBs. The multi-homing BOF was particularly full; the main question there was whether to include solutions that did only IPv6, or ones, which had to work also with IPv4. In the end they decided that they would concentrate on the IPv6 versions, but would consider whether any solutions could apply also to IPv4.
Clearly things like IPSECv6 and MOBILEIPv6 are now nearly complete.
In the Policy Framework section, there is a strong attempt to rationalise policies having constant mechanisms of use of policies. There was discussion of PCIM extension, policy groups, repository re-use, PHB modelling. There are action/queue classes and modelling of Diffserv. They show how it maps well.
In the PKIX area, there is a suggestion for a fresh start for a native XML PKI model, using XML encryption, signatures, SOAP, etc., i.e., a PKI that is deeply entwined in the XML environment. This is pursued further in Section 3.3, but is related to the need to formulate policies for the PKI and the use of certificate that is much broader than envisaged originally.
The VPNs, considered further in Section 4.11, reflect also this concern with policies; that is why the ANDROID project is defining these in XML.
Mobile IP needs review from IPSEC group. Kent discussed move to 10 Gbps implementations. There are problems on number space, sequence numbers. Want to grow 32 to 48 bit. They will use AES. They need a parallelisable speedy algorithm.
They are interested in a new end-end security protocol good for NAT, security, QoS ICMP and NAT. Want to allow NAT to modify IP packet. Can change IP header, but allows extra data, and then can change IP information. Is supposed to be nearly as good as IPsec. However there were arguments whether NAT would be used and if so friendly NAT boxes. There are problems also for QoS. It is unacceptable because it would need change in every Host.
There is a discussion of NAT traversal draft. It does not enclose IPv6 for now. SSH Communications Security Corp will allow free use of NAT traversal technology. There will be additional 12 bytes bad for wireless.
ESP encapsulation in UDP is being discussed. There is a new encapsulation mode. It is believed that IPv4 IPv6 transition with NAT will not break ESP.
Ericsson may use IKE for 3GPP for MAP security. It runs over SS7 and is used for mobility and AAA. It is important for legacy purposes.
There is an interesting new activity in secure multicast. The Multicast Security BOF became a WG at once - it basically summarised the SMUG work to date (SMUG is the IRTF group for multicast security) - this is mostly taxonomical to date, though there are some key distribution protocols emerging. The main emphasis is on limiting access of group communication: long term secrecy, ephemeral access restriction. Large groups, 100K 1M is the sort of size envisaged, with very few sources. Authentication, Anonymity, Availability against DoS attacks, Protection against illegal redistribution are all vital. There are important trust issues in the centralised group controller, and concern with performance parameters of security solutions. Important parameters are the time to verify and decrypt data, and the time to authenticate. There are two outstanding problems: Source authentication (verify integrity authenticity) and Group membership management (maintain a common group key).
In the current protocol draft, one still has Security Associations (SAs), but this time they may be Group SAs. One of these is a Group Security Association. There are three categories of SAs. Category 1 is unicast; these are needed as one per recipient. The Category 2 ones are Group SAs, and are sent by multicast from one place to many; they are used for instructing each of the members of the group. The Category 3 are for the data itself, and have the key management done by the Category 2. GSAKMP is the mechanism for group key management. This includes group membership and key maintenance GS & KM). There is one set of dialogues between the Sender and a Group Controller and Key server (GS & KM) dialogue; this is unicast. Then there is a Category 2 between the GS & KM and the receivers. Finally the material goes by Category 3. There are a number of GSAKMP drafts.
Another approach is a Group ISAKMP with Domains of Interpretation (DOI). This requires a Phase 1 with secure channel, and a Phase 2 negotiates secure channel policy. This does the same a Category 1 and then a Category 2 one. There is the usual set of nonce messages. There has been some Proof of Concept has been done with Isakmp.
There are a lot of fairly ordinary comments on PKI ASN1 versus XML, persistent names, CAs, David Chadwick has done a fair amount on this; I will not repeat it. There were lots of routine items such as the Qualified Certificates Profile, Attribute Certificate Profile, Data Validation and Certification Server, Time Stamp Protocols (TSP), Permanent Identifier, Technical Non-Repudiation, Delegated Path Validation and Discovery Services, Certificate Management Protocol (CMP), Certificate and CRL Profile revisions, Public Key Algorithms and Identifiers. There have been interoperability tests on CMP/CRMF Interoperability Results - Bob Moskowitz (ICSA Labs) has been organising interoperability testing for CRMF/CMP Implementations. This testing will support the progression of CMP and CRMF to Draft standard. This has resulted in the need for clarification in the Certificate Request Message Format (CRMF).
There has been renewed discussion whether OCSP needs a v2; the general feeling is that it does though there is still argument about how much advance is needed.
The above is so far-reaching, that there is need for a PKIX Roadmap and a Certificate Policy and Certification Practices Framework. Finally, there has been discussion on whether PKIX should fully embrace XML. Mere re-encoding of certificates in XML does not seem to be a valuable exercise. A second approach might be to re-encode and change some semantics at the same time, but this too is not very attractive. Instead, there was a suggestion for a fresh start for a native XML PKI model, using XML encryption, signatures, SOAP, etc., i.e., a PKI that is deeply entwined in the XML environment. Several observations are made about why PKI deployment has not been as successful as we would all hope, e.g., applications that are not compliant with standards. XML key management services (XKMS) is an attempt to provide an interface, not an infrastructure, which will yield a very small footprint implementation (because of delegated validation), thus removing an impediment from deployment. "Trust services" form the core of this scheme, using delegated validation in various structural schema, e.g., completely centralised, DNS-tree structure, PGP-web, X.509 cross certification, etc. It is not clear in which context this work should proceed; e.g., it may be more appropriate in W3C vs. the IETF.
A key aspect of many new services is AAA and it has its ramifications for proxies, IPv6 and wireless. High reliability is a concern, hence the consideration of the use of TCP, SCTP and UCP.
conservation of packets applied to AAA (fallover/failback). The amount of control volume, and the time to get authorisation are vital. In view of the large installed base, interworking with Kerberos v5 is essential. There is need of AAA-Proxies, an AAA-Server, conservation of packets applied to AAA (fallover/failback), and AAA-Server. IPv6 ramifications have not really been considered.
This meeting discussed plans to radically alter the structure of this Area within the IETF. Specifically, the discussion centred on possibly migrating some existing groups and BOFs (such as Traffic Engineering, MPLS, Provider Provisional VPN, and IP over Optics) to the General Area, currently headed by Fred Baker. The IESG is currently unsure which groups would migrate, or if there would be an additional area. No AD has been agreed upon, nor has any charter been agreed upon which reflects the new responsibilities of the new/altered area. One new working group that may be formed in the new area is Common Control and Measurements Protocol (CCAMP).
The Transport Directorate acknowledged that many feel that changing TCP is better than using SCTP. However, the Directorate continues to feel that the opposite is true.
Work continues in the area of "Diff-serv aware Traffic Engineering". There are currently 2 working group drafts focusing on requirements and protocol extensions for MPLS, and 2 individual drafts dealing with set up requirements to support QoS. Part of the motivation of this work is to add Class Types to represents different Classes of Service. A new draft clarifies pre-emption across class types. Feedback from the meeting was that this effort might be overkill with respect to distinguishing and treating packets.
There is also a Query Draft, which is meant to find out about the edge-to-edge resources of a network. The Recovery Draft (similar to crankback in the telephony world) will probably go to last call soon).
Finally, there is a group of drafts focusing on Shared Backup of LSPs. Chair feels that this group is a good candidate for the new Areas described in the Transport Area meeting.
This was a rapid-fire meeting that very quickly went over issues related to various drafts. Of note, there was an extended discussion related to Record Route for SIP. Agreement was reached in allowing a proxy to modify RR to help deal with NATs and different address spaces. There was also disagreement about Call-ID in that it was unclear as to how one ties in different existing calls.
The group discussed several drafts: QoS Device Information Model (QDIM), QoS Policy Information Model (QPIM), and QDIM & Diff-serv. The QDIM discussion was quite contentious. It focused on different associations between schedulers and queues and they should be represented and modelled. The QPIM draft presents models on Int-serv (accomplished through COPS), and diff-serv accomplished though a PIB & MIB). The newest draft removed LDAP and storage dependent modelling. It also added Role and Compound polices. An IMPORTANT note is that policies can exist that lack actions as triggers.
The first DIFF-SERV meeting was mostly about the MIB needed. The Building Differentiated Services Research Group (BUDS) met for 3 hours. It included nice presentation from Bruce Davie of CISCO suggesting some compromise proposals e.g. on EF, Christophe Diot from SPRINT about their measurement work; and Tiziana Ferrari on Dante's DIFF-SERV measurement work/results.
The EF debate rumbles on there are several misunderstandings here - whether the service wanted is delay bound (with over-engineering) or rate based (with possible unknown delay bound). In the end the Davie/Charny compromise won out according to the consensus of the room: (Note that the WG decides consensus on the list.). There was no support for the option of doing nothing. The preference was for accepting 2 PHBs over opposing 2 PHBs was slight. Assuming only one PHB, support for the EF resolve definition was weak, while opposition to EF resolve, as the only replacement PHB was strong. Support for the "compromise" as the only replacement PHB was strong. When the question of 2 PHBs was restated as preference rather than acceptance, support was strongly for having only one replacement PHB.
Last call has been completed on Framework PIB. Error codes have been added to RSVP to modify Sender behaviour. This involves an explicit notification to the Sender aimed at UDP/multimedia traffic.
This involves separating the fast path forwarding from the control plane of routers so that a common standard architecture can be agreed upon. An ideal output of this effort would be to have different vendors produce different boards (forwarding and control) that could be integrated on the same backplane. For example, integrate the control plane engine (routing protocols) of Juniper with the forwarding engine of Cisco onto the same router. Our personal opinion is that while this is an intellectually interesting effort, it is its just not going to be done by the major vendors.
This was a simple but vital WG to oversee the simplest form of multicast. There is a straightforward architecture draft. There are addressing and security issues; partly because IPv6 will have to be considered, one must avoid addresses that can be over-written. Routing issues need further work. PIM-SSM and IGMPv3 need to be both fully defined and deployed. One needs to tackle simple redirect mechanism in the router to avoid the case of large fan-out, and allow for anycast.
The Reliable Multicast Transport met twice - The first session had presentations on various building blocks - e.g. ALC and norm etc. The second session was mainly about the various congestion control techniques, including a presentation from the Transport Services Group on TCP Friendly Rate Control (TFRC), and progress on ALC and PGMcc. TCP Friendly Rate Control (TFRC) compares favourably with AIMD; IETF approval may lead to wide-scale deployment of experimentation. For TCP Friendly Multicast Congestion Control (TFMCC), round trip time (RTT) measurement needs experimentation, filter design for measuring loss should be directly applicable. TFRC is ready for experimentation; TFMCC is not ready yet. Tree-based TFMCC is easier than NAK-based TFMCC. There is a question on minimum delay requirements for voice, and how does it fit with RTP.
This is a new working group that is really confused and in disarray. There is no problem statement, there is no charter, and yet it is a working group. The group is an outgrowth from Mobile IP and its focus is on micro-mobility -- mobility within a network (be it the Foreign or Home networks). Hence, a primary concern of the group is dealing with types of hand-overs between agents and in particular how to accomplish context handovers (i.e. switching existing QoS, policy, and/or security associations). Note: one of the presenters was Alan O Neil, formally of BT Labs, and the new start-up he's associated with (Flarion).
This BOF discussed the protocol/requirements in dealing with NATs, and to some degree, firewalls. The initial focus is to deal with SIP/H.323 communication, but all be able to act in a more generic manner with respect to other applications. A typical example would be to automatically punch a hole through a firewall/NAT box for a SIP or H.323 session. Hence, a communication protocol is the primary focus of the group. Not that discovery of boxes is outside the scope of the group.
Two framework documents have been introduced. These will be merged into one document. Part of the document will address the issue of auto-discovery of VPNs. Security will also play a role in this effort (e.g., adding VPN-ID to IKE phase 2 negotiation). It was noted that the ITU has a similar effort under SG13 -- producing a related document titled Y.1311. The ITU document is based on MPLS/BGP and the concept of virtual routers.
This area is very important to UCL. ANDROID, RADIOACTIVE and SCAMPI all involve VPNs, and so does the ICB VPN activity. There is a framework document discussing Requirements (e.g. Components), Customer Interface (Service & Protocols), VPN Establishment and maintenance. The ITU also has an activity here.
Many technical solutions were considered including IP VPNs over MPLS. IPSEC tunnelling was a major topic; this included site-to-site IPsec tunnels and voluntary IPsec tunnelling. This work must liase closely with other current IPsec WGs: IPSEC and IPSP (allow configuration of IPsec policy for hosts, security gateways and discovery of security gateways). Other problems include: IPsec Remote Access (IPSRA) and extended IPsec Requirements solicited; some possibilities here are: VPN-ID to IKE phase-2 negotiation, run routing protocols over an IPsec tunnel, possible issue of wildcard QM client IDS), more flexible Diffserv marking rules. For MPLS-based VPNs, there are questions about the impact of the Provider networks, label stacking, IP signalling, and use of RSVP and LDP. All are concerned with establishing VPNs, key signalling, and route signalling.
Finally, Provider Edge Routers (PE) introduces a new address family ("VPN IPv6"); "BGP-next-hop" is an IPv4-compatible IPv6 address. This raises many questions on the uniformity of enterprise solutions, and the use of routing.
This working group dealt with resolving issues of existing drafts. It will also include MPLS-interarea Traffic Engineering drafts as a working group item. Specifically, these drafts involve architecture and protocol extensions, including a summarisation of metrics.
The Forwarding and Control Element Separation BOF met this is an attempt to basically do the equivalent of gsmp for IP switches.
The most important task for AVT is to progress the RTP spec to Draft Standard. This requires two interoperable and independent implementations of each feature and function. This is complete for
most features but not all. There will be revised versions of the RTP spec and A/V profile issued with the incomplete features and Codecs removed. Several new payload formats were presented in addition to updates on five already in development. Considerable discussion ensued on an alternative proposal for AMR payload format, but in a post-session discussion the authors agreed to work towards a compromise solution. There are two proposals for meta-payload formats for unequal error protection; the authors are to write performance comparisons to allow selection of one. In place of two payload formats for MPEG-4 systems payload formats going for experimental status, we now have a single proposal under development by the MPEG committee, which will be completed and submitted for standards track. For one new payload format, for EVRC speech, the two proposals have already been merged, but it was brought to our attention that ITU may have already defined a conflicting payload format without our knowledge. This is to be investigated further.
Significant progress was made toward a profile for low-delay RTCP backchannel information. There are two drafts to be merged to complete that profile, then one or more payload formats that will make use of it, e.g., for retransmission on unicast streams. The major new topic for this meeting was security for RTCP. A requirements document and two proposals were presented. The two proposals have a lot in common, and the authors have agreed that they can select among the differences to produce a single proposal. The "hum" consensus of the room was that the security task and the new payload format proposals should be accepted as working group tasks.
The gateway control protocol MEGACO was particularly active for newer networks - with emphasis on wireless. MEGACO is an ITU gateway control, and it is hard to move this style of activity over to a real grounding in Internet those of us who attended found the session particularly tedious. It is the wireless community, which is particularly interested. The activities are particularly concerned with the relay to communications such as Frame Relay, ISDN, ATM and cellular. There was a huge discussion around things like operational MIBs, tones etc. They care about network terminations and signalling and are very ITU type. This included also activities such as credit card verification.
Clearly both finding the gateways was a keen concern. Organising, monitoring and aggregating of individual terminations were very important. A considerable work has been done on monitoring but not using SNMP.
They described an interoperability test, which had been very successful. Most versions were able to interwork successfully with some dozen independent implementations.
The Applications Open Area meeting just outlined the actions at this IETF - nothing startling was raised. There was considerable interest in the set of Content Distribution Network Protocols and their related BOFs. There was some attempt to put these into a framework this may get somewhere at the next IETF! The future directions of MMUSIC were discussed; in particular, it has been suggested that it should close?
They are providing an introduction framework document, describing the environment of IP storage (LAN, MAN, WAN and public nets. This will provide background on networks for storage professionals and storage background for networking professionals (SCSI, FC standards). It will survey various proposals and co-ordinate with the name discovery team. It will also consider what storage expects from TRANSPORT (need contributors).
A presentation by Randy Haagens (HP) & Allyn Romanow (CISCO) looked at TCP/ULP message framing and iSCSI framing. The problem of conserving host memory bandwidth could be solved by direct data placement. With the wrong message boundaries, there might be low (less than 10 Mbps) limits. With some re-assembly for re-ordering out-of-order data, 1Gbit/s possible but expensive (FiberChannel) but. 10Gbit/s was impossible. Many other tips are provided there is an awkward problem with when to use Message Boundary support at the transport level versus application-level support.
The Traffic Engineering Working Group was dominated by MPLS. Outside the formal meetings, BANDWIZ (a competitor for Digital Fountain) gave us a demonstration of their system and also talked about requirements for zero-th hop removal of requirement for sender to send when the first hop router knows there are no receivers. We have put some input into the IDMR group informally on how to enhance IGMP to do this. There is considerable work on a Framework PIB for Accounting Usage; this needs to be extensible and re-usable. The next step will be to look at DiffServ QoS accounting PIB to prove our framework of accounting PIB and classification of multiple usage instances.
The Service Level Specification and Usage BOF met - this is interesting for us as UCL are involved in the Tequila IST project, which kicked this off. There was a fair degree of interest though some kickback implied that it was possibly a bit early (not a lot - perhaps 2 IETFs) to work on this). There was quite a lot of support for doing the work.
One major ramification is that in the Transport Provider Domain, Diffserv is enabled. This needs to agree on a service, provide a flow contract template and negotiation protocol.
One needs a Framework Document, Info Model, Protocol Requirements, and a range of services, of tools (DiffServ, IntServ signalling, Dynamic Routing) . We must understand management protocols and deployment issues. The role of the customer, provider and end-end services must be provided. It is necessary to define traffic envelopes and conformance, how the stream should look like, conformance testing (in, out profile) and Performance Guarantees and Excess Treatment.
In the session on MBONE deployment, there was a rather half-hearted discussion on documenting tools used for debugging etc. Of course, UCL will maintain the mbone applications web site as long as we can.
This BOF includes Marcello Pias from UCL as a co-chair and is about trying to move on from where RTFM (Development of the Real-time Traffic Flow Measurement Architecture BOF (rtfm2)) had got to the idea is to have smarter meter architecture. Its goals are 4 IDs: Implementing new Attributes, high level interfaces for RTFM, remote packet capture. A number of packet format extensions are under study. There is a RTFM overview: meter, meter-readers, managers - flows are defined by a set of attribute values, see RFCs: RFC2720 and RFC2724 (RFC2721 is the applicability statement).
There is a draft RTFM architecture Problems and Application Scenarios, Requirements, Approach, Interface Description. The interface METER MIB is powerful but not easy to use (difficult to write rule sets, meter delivers traffic data in pull mode only). Several management applications require less functionality and would benefit from a simple interface.
There are typically two kinds of apps: plain (standalone) and those with integrated traffic measurement. The policy Server decides on measurement terminology. The PEP (Policy Enforcement Point) and PDP (Policy Decision Point) are the i/face descriptor style appropriate attribute masks. The Flow Attribute Flow Description describe the set of flow attributes; there is one reader per flow description, and a description of how to implement the specification MIB module, meter MIB extension, a new protocol, an API. As a commercial example CISCO NetFLow ``PUSH is much easier.
There was a very cute MANET ad hoc routing trial in the hallway lots of folks with base stations and laptops just built a net and ran one of the protocols.
K.Borman (Univ.Bremen) discussed the validity of the TCP formula, flow separation and how to implement them. This will become very relevant in 6WINIT, when we get to wireless networks.