Washington DC, 7-12 November 1999
Piers O'Hanlon, University College London
This report provides a summary of discussions which took place during the 46th IETF meeting, held between 7th and 12th November 1999 in Washington DC. The contents of this document are based on personal notes taken during the meeting, and do not provide an official record of the meeting. The official proceedings are available from the IETF web site.
The opinions and interpretations expressed herein are those of the author, and do not necessarily represent those of the IETF, the working group chairs, or other persons mentioned herein. If this document differs in its record of events from the official proceedings of the meeting, then those proceedings should be considered accurate.
The remainder of this document is organised according to working group or BOF title.
There are number of problems to solved in this research group; The development of a scalable efficient re-keying architecture. The development of efficient source authentication techniques, amongst other things.
He described a policy model where there existed a variety of ‘roles’ which were defined by which ‘rights’ were held by that role. He listed 11 such rights, which were such things as rights to re-keying, key distribution, data security, etc. This work was in reference to the Antigone project: http://antigone.citi.umich.edu
Bob described a key distribution model where by the users pre-pay for their keys which have a specific lifetime. The keys exist in a hierarchy where at each node on the tree a quasi-random seed key exists which is used to generate the keys in the nodes below it. The key hierarchy allows efficient distribution of keys by just delivering a number of seed keys at the appropriate point in the hierarchy (though there were concerns raised regarding compromise of keys high up in the hierarchy). The key hierarchy is the same for all users so the system is independent of the number of users (though concerns were raised as to possible trading of keys between users).
A list of basic content of a security policy was outlined;
Policy ID
- Group ID
- Version
Access Control
- IP
- DN (Distinguished Name)
Crypto Specification
- Data Protection
- 3DES / HMAC ..
- DSS (Digital Signature Standard)
Remote Key Server Auth
- IP
- DN
Policy Auth Data
- Signature
- Public Key
He gave a breakdown as to how he saw the different group re-keying architectures:
- GKMP
- Hierarchic
o (LKH – logical Key Hierarchy)
o One-way function trees
o Extensions: LKH+, Chang et al
- Divide and Conquer
o Iolus
o Intra-domain GKMP
His Kronos system provides a re-keying architecture which attempts address the problem of scalability associated with large group re-keying. Kronos decouples frequency of re-keying from group size and membership dynamics by just doing periodic re-keying. The scheme is distributed by dividing the domain into ‘areas’ so there is a Domain Key Distributor and a number of Area Key Distributors. All the AKD re-key at the same time, being kept in sync by NTP, generating the same key. All AKD share two secrets K and R0. Using secret-key encryption algorithm E a sequence of group keys may be generated.
There followed some discussions on how the security associations break down for network layer security vs. application layer security. Then further talk on what management structures were required to provide a useful multicast security infrastructure.
The BGMP MIB was discussed
Brad Cain went into detail about inter-working issues with PIM-SM/MSDP and BGMP. kouvalas brought up a problem with a source specific tree and non-member senders – It wasn’t quite clear how it would be resolved.
Security issues were raised and Fenner mentioned that spoofing was a worse problem on bi-directional trees.
<draft-ietf-ipsec-ecn-01>
Last call on this – note it is affected by new diffserv terms.
<draft-ietf-ipsec-notifymsg-02.txt>
- New field added
- Should text messages have numeric prefix (cf. FTP)
- Question as to how currently defined notification data payload fits in DOI.
<draft-ietf-ipsec-monitor-mib-02.txt>
This MIB would provide read-only access for monitoring of the operation of IPSEC – With no configuration modes offered or access to keying material. It uses textual conventions from <draft-ietf-ipsec-doi-tc-mib-02.txt>. The MIB is designed to work with IPv6 and IPv4 – IPv4 addresses being stored by using the IPv6 “IPv4-mapped IPv6 address” 0::FFFF:<IPv4-addr> . It can deal with AH, ESP, IPcomp. There was some concern raised by the fact the packet counters were 32bit – possibly need raising. Although since it provides monitoring of current state and hold no history this may be less of a problem. The MIB makes use of ‘helper tables’ to assist lookup of data (e.g. SA, SPI). There were some concerns about the strength of the security in SNMPv3 as it is relatively weak.
This MIB seemed to have an overlap with the previous MIB though it does offer some history facilities and uses tables again for correlating information on flows.
<draft-bellovin-iapcbc-00.txt>
Integrity-Aware Plaintext-Ciphertext Block Chaining for IPsec getting over a separate Integrity check. This requires some changes to the behavior of IKE; it may also complicate some implementations of the ESP framework.
<draft-ietf-ipsec-pki-req-03.txt>
- Need Certificate and Certificate Request payloads
- Need to verify that something different to PKIX is required
- How to identify an Ipsec Certificate? New EKU
- Including keys in EKU can be limiting as EKU specifies where keys can (only) be used.
<draft-jenkins-ipsec-rekeying-02.txt>
Attempts to resolves issues regarding problems with re-keying between differing implementations – the IPsec spec’s do not specify the mechanisms closely enough. It suggests methods of performing both phase 1 and phase 2 re-keying for IPSec implementations in such a way as to minimise packet loss and to maximize compatibility.
The problem of dangling Phase 2 SA’s was brought up – They are SA’s for which no valid Phase 1 SA exists – which lead to problems with maintenance of such SA.
The meeting started with a description of the W3 recommendations Common Markup for micropayment per-fee-links: http://www.w3.org/TR/Micropayment-Markup
A model was described by John Ioannidis from AT&T. It consisted of a “provisioning agent”, which provided services for the vendor and buyer to trade, connected to a “clearing agent” which dealt with vendor and buyers banks in a non real-time fashion. This is possible because these are micropayments.
PhilipHallam-Baker from Verisign, who wrote the User Interface Requirements for Sale of Goods whilst at w3.org commented that they had found that the practical way to go about these systems was to design a three party system first as larger systems run into too many complications – given that’s the way banks usually operate; Having a buyer, vendor and a bank. Visa and MC have a kind of 4 party system though it is one of the only large scale systems. He also mentioned that Ross Anderson has 3 or 4 patents pending on 3 party systems.
This document describes a mechanism to allow for an arbitrary number of RPs per group in a single share-tree PIM-SM domain.
Policy based server balancing allowing the wide distribution of root Name Servers. The servers would have two interfaces – one being the shared unicast address (or anycast address) and the other being the AS-internal interface. The former is used for all name server requests, the latter is for all mesh co-ordination.
<draft-katabi-global-anycast-00.txt>
Provides a special routing protocol for handling of anycast addresses by extending BGP, adding two additional messages to it. It confines the complexity to the edge of the network by defining two route types – one low overhead which transit domains, and the other which is local and carries more information regarding specific anycast addresses.
A discussion involving how anycast should behave for TCP connections – At the moment the use of TCP is not recommended for use with anycast. There was talk about at which layer TCP connections might handle an anycast address (and a re-assignment) – It seemed to me that this decsion needed to made early on and determine how TCP might behave. No firm conclusion was reached.
Other discussion questioned what would happen regarding MTU discovery.
<draft-ietf-policy-core-info-model-02.txt>
This is work for using an object-oriented approach for representing policy information, currently under development as part of the Common Information Model (CIM) activity in the Distributed Management Task Force (www.DMTF.org). The CIM model has two hierarchies of object classes– structural ones which represent policy info and control of policies, and relationship classes which dictate how structural classes inter-relate.
There is a companion document <draft-ietf-policy-core-schema-05.txt> that defines how this information model maps to an LDAPv3 directory.
Describes an information model that describes the attributes common to the forwarding characteristics of Differentiated Services QoS and RSVP. Uses and extends the CIM network common model.
There is a joint W3 and IETF working group page at: http://www.w3.org/Signature/ . A spec is being developed to describe how to create an XML signature.
Ed Simon from Entrust spoke – they are using XML digital signatures.
Donald Eastlake (IBM) - They have a product that also uses them. He spoke about Canomicalisation of the XML containing the signature. He discussed using either the Document Object Model (DOM: http://www.w3.org/DOM), or Simple API for XML(SAX: http://www.megginson.com/SAX) - An event-driven parser API which reports parsing events to application via callbacks.
Provides mechanisms for unifying congestion control across appropriate “common destinations”. Information is shared within “macroflows” which encompass a number a flows using the same congestion management. The system provides separate mechanisms for determining available capacity, and for scheduling flows. The idea is that applications can access basic congestion information (e.g. cwnd, srtt, rttvar, loss rate), through the CM API, about their participation in a macroflow which then enables them to adapt to network conditions. The system provides three styles of data transmission control for apps:
- Buffered – a buffer is handed to the CM and delivered
- Callback based, where asynchronous apps use callback routines to send PMTU bytes of data.
- Synchronous-style where apps are informed of the flow rate and adapt their data delivery accordingly.
The system has also been designed so that it can be incorporated into a standard IP stack and then provide un-altered applications with CM services.
A rough draft spelling out the basic need for Congestion control and what correct CC actually constitutes. It also seeks to explore the IETF’s role in standardisation of such protocols.
The potential concerns were roughly outlined:
- Increasingly aggressive non-conformant TCP implementations
- Aggressive transport protocols
- Aggressive Web browsers
- Best Effort traffic without congestion control (eg UDP)
Recommendations on Queue Management and Congestion Avoidance in the Internet (rfc2309.txt) was discussed and for Sally to outline three main flow types:
- TCP-compliant flows
- Unresponsive to congestion control
- Responsive but not TCP-compliant flows
February 2000
- Informational RFC on CC principles
- Congestion Manager description (rfc2581)
- CM API for client, server, scheduler
May 2000
- Sample behaviour document
June 2000
- Decide on future of WG
This draft was discussed which proffers a solution of a router with a built-in “mini-DHCP” server which allocates addresses from the private address space, with external connection possible via a NAT or Realm Specific IP (RSIP: draft-ietf-nat-rsip-framework-02.txt)
There was some disagreement over whether private or globally unique address space should be used as system as likely to be connected to the global net at some stage.
It was noted that some “non-zero-conf” would most likely be required for security set up – either some shared secrets would be needed or some smart card system.
A point was raised about the fact that caching in routers of various information may affect hosts if zero-conf changes – A suggestion was made of a new ICMP message.
The situation wasn’t clear how multi-homed machines should be dealt with.
The provision of hostnames to machines wasn’t clear – a suggestion was to use some sort “claim and defend” approach (c.f. MASC).
Connections with the roamops WG should be explored.
Dave suggested running a mini-MAAS (using MADCAP) server and signal scope then only connect to it if known.
Definition of what “plugging in” needs to made clearer
Where nodes may be mobile the indication of the “home subnet” would be useful.
Provision of DNS forward and reverse entries for machines.
Brought up as relevant: <draft-ietf-ipngwg-router-renum-09.txt> ; Useful for renumbering routers/hosts as zeroconf network alters its role.
Service discovery in the should draw on svrloc WG; useful for:
- Clients to find services easily
- For bootstrapping
Though service discovery can be complex so needs to be re-considered in context of zeroconf.
It was mentioned 18 sub TLA’s have now been assigned.
The draft specifies modifications to the DNS to support renumberable and aggregatable IPv6 addressing. There is a new query type “A6”. During a query it is recommended clients should use “A6” first then “AAAA”.
The draft specifies an experimental, ICMPv6 based, protocol for asking IPv6 to supply certain network information, such as its fully qualified domain name.
- A fifth query type has been added for IPv4 (for dual stack machines)
- When subject of a query is a name - use wire format (for coping with internationalisation)
In reference to source address selection there was a discussion as to nature of multi-homing by Steve Deering. He concluded it is not well defined and should be broken down into;
- Multi-interface
- Multi-address
A suggestion was made to use Mobile IP for solving multi-homed problem.
A heuristic approach was suggested to select a source address:
- Prefer address that is similar type to destination
- Avoid depreciated address
- Prefer longer match (not always a good heuristic)
The two types of RPC were outlined:
- TI (Transport Independent)
- TS (Transport Socket)
The old PORTMAPPER is protocol dependent – requires a fallback mechanism whereby user attempts to probe for IPv6, which falls back to IPv4 upon failure.
The newer RPCBIND is protocol independent and can be extended to use IPv6
The TI-API doesn’t require modifications, unlike the TS-API which contains socket specific code.
TAHI Project is the joint effort formed by the three Japanese organizations with the objective of developing and providing the verification technology for IPv6. It is working closely with the WIDE (http://www.wide.ad.jp) and KAME (http://www.kame.net) projects.
They have a number of tools available for FreeBSD with the KAME stack:
- A packet analyser
- Traffic generator (Multicast tool, and a unicast tool)
- Routing Protocol Packet Analyser Tool (under construction)
They plan to work on more tools for analysing routing protocols, and IPSEC (though not mobile IP)
Based upon their Y2K code scrubber, it searches source files for IPv4 specific code using egrep. They have found it useful for picking out unnoticed code fragments.
For the tool see: www.sun.com/solaris/ipv6
Following day (IPNG continued).
The question of IPv6 AAA services was raised.
- Checksum can be handled by the application
- IPv6 mandates checking of checksum in UDP
This talk covered a new ICMP message that can instigate multiple replies from different machines on a route. It was presented in Tokyo as well. It was rejected because of a number of concerns about its usefulness and its ability to produce denial of service attacks.
<draft-ietf-ipngwg-scopedaddr-format-00.txt>
Since uniqueness of a scoped address is guaranteed only within the according scope, the semantics for a scoped address is ambiguous on a scope boundary. For example, when a user specifies to send a packet from a node to a link-local address of another node, the user must specify the link of the destination as well, if the node is attached to more than one link.
The proposal is to be able to specify a scope identifier on the command line:
<scoped_address><delimiter><scope_id>
where <scoped_address> is a literal IPv6 address, <scope_id> is a string to identify the scope of the address, and <delimiter> is a string to distinguish between <scoped_address> and <scope_id>.
The scope name is only of local significance and supplied to the API as sin6_scope_id in the socket structure.
The KAME project has a working implementation using ‘@’ as the delimiter and using interface names as scope_id’s
There was discussion on Digital Rights definition language
GeldKarte from Giesecke & Devrient (www.gdm.de) Enables secure transactions over the network Network Payment System.
There were approx 2384 attendees. The internet connection was 2 DS-3 lines. The Hotel was wired up with 44 Frequency Hopping, 6 Direct Sequence, and 6 Wavelan Base stations. Total of 500 FH users; 250 average users day time, 50 at night.
The was a talk on the name “Internet”, which was claimed by Internet Inc, now owned by Star Systems who have tentatively agreed to hand the name over for public after much wrangling with ISOC.
There were two talks on Web behaviour:
PRO-COW: Protocol Compliance on the Web
http://www.research.att.com/~bala/papers
Web Performance Characteristics.
http://www.research.att.com/~anja/feldmann/papers.html
Mark Prior from www.connect.com.au who will be hosting the next IETF in Adelaide. He gave a short invitation talk and video on Australia.
Bruce Davie (bsd@cisco.com) gave a talk on “Networking Health: Prescriptions for the Internet” (www.nas.edu). The talk centred around a report that is under development regarding how Health systems could benefit from the Internet – and gave some specific requirements such as very large image transfer, security roles.
The wiretap issue was introduced by Jeff Schieller and a slightly indefinite question was posed to room regarding whether Wiretap protocols should be the business of the IETF. There seemed to a large proportion against inclusion of wiretap, though when the abstainers were counted they were of a similar number. The number for wiretap were significantly less. The discussions centred around the US CALEA regulations regarding wiretap in existing hardware, and how it might apply to the Internet.
<draft-ietf-mobileip-mn-nai-05.txt>
A proposal to define a way for the mobile node to identify itself, to AAA servers, by including the Network Access Identifier (NAI) along with the Mobile IP Registration Request.
<draft-ietf-mobileip-vendor-ext-04.txt>
The draft provides facilities for research and experimentation by providing a way to include organization/vendor-specific information in the Mobile IP messages. Two messages are defined:
- CVSE – Critical Vendor Specific Extensions
- NVSE – Normal Vendor Specific Extensions
The basic difference between the Critical and Normal Extensions are that when the Critical extension is encountered but not recognized, the message containing the extension MUST be silently discarded, whereas when a Normal Vendor/Organization Specific Extension is encountered but not recognized, the extension is ignored, but the rest of the Extensions and message data MUST still be processed.
<draft-ietf-mobileip-aaa-key-00.txt>
Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering a care-of address to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to distribute such security information to the mobile node.
The MN doesn’t directly need to use the AAA server
<draft-perkins-sdp-scoping-00.txt>
Use MZAP scope ID’s to provide global scope information. But issues about the stability of MZAP zone ID was in question.
SIP/SDP set up for T.38 Annex D
Support for MMR and JBIG image types.
A Message Bus for Conferencing Systems
<draft-ott-mmusic-mbus-transport-00.txt>
- Added unicast optimisation
The Message Bus: Messages and Procedures
<draft-ott-mmusic-mbus-semantics-00.txt>
- Cleaned up API – made “more obvious”
- Common element for SIP/H.323/ISDN
- Protocol specific extensions
- Suitable for use in gateways (though not intended as competitor to MEGACO)
Application scenarios
- Modular client/gateway/proxy
- Make GUI aware of call protocol
- Simple browser plugin
- Example – Comms between workstation and phone
o Remote control of phone
o Simple means to provide CTI
Future
- MMUSIC work item
- Type RFC
- Specific call control for SIP
- Specific call control for H.323
- New capability syntax
- Command set for tools; video, audio, shared apps
SDP originally for session announcements
- Not designed for Capability Negotiation
- Other approaches emerge in SIP context (SIP caller prefs)
- Compare with [heavyweight] ITU: H.245 T.124
- SDP becomes problematic as a description language
Negotiation requirements
- Simple - Capability Negotiation
- Multiparty – dynamic membership
- General – should work without knowledge of semantics
- User prefences
- Simultaneous capabilities (or limiting combinations)?
- Policies
- Minimise Negotiation round trip requirement (Rosenberg: “Need to keep Number of round trips to <= 1.5”)
- Expressiveness
- Efficiency
- Extensible – naming and re-use of profiles
- Net friendly – compact description, copes with firewalls.