The opinions and interpretations expressed herein are those of the authors, 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.
How to simplify multicast? Firstly, support a multi-sender group with a single bidirectional tree, optimising for single-sender multicast, which is assumed to be the most-common case. Second, identify the group address by the pair (core, group), eliminating the need for routers to map from the group address to the core; include both the core and group address in joins and data.
The claimed advantages of these suggestions are as follows:
Documents...
Connection establishement and QoS negotiation is a major feature here, which is used to select from various existing (and novel) transport protocols. The network is assumed to support multicast, likely IP based.
So do we want encryption at all? Use authentication to determinne who can make the announcement, and a symmetric encryption algorithm?
Suggestion: remove public key encryption completely?
Colin Perkins presented a number of other proposals for updates to SAP. These included support for IPv6, the addition of a content type field to allow payloads other than SDP, and a URL scheme. There was opposition to the inclusion of a content-type field, since proliferation of multiple session description formats will cause interoperability problems.
Progress on the Session Initiation Protocol was summaried. The changes since the last meeting, mostly as a result of the last call process, are as follows:
Jonathan Rosenberg discussed SIP provisional response reliability. The problem is that provisional SIP responses are not sent reliably, which can cause problems when trying to interwork with hard state telephony protocols. The proposed solution is a SIP extension (org.ietf.sip.100rel) which provides reliability and ordering of SIP provisional responses and doesn't affect the base specification for those application which don't care about such reliability. There are still a number of issues to be resolved:
Jörg Ott presented update on progress with the message bus since the last meeting. In general there was agreement that this work is of interest, although it's scope (local conference coordiation) clearly needs to be better defined since this caused some confusion. The status of this work within the IETF is still undecided, but a further update will be presented at the next meeting, after which a BOF may be held to setup a new group in this area.
In PIM-SM/MSDP can put the policy in the RP, doesn't work in bidirectional trees. Source access lists are harder to implement when bidrect trees are used, since sources may be forwarded onto the tree at any point.
The other possibility is to put some information in the G-RIB to specify a 1-to-many group. This lets us restrict a group to senders in the root domain only, but we'd need to add optional uni-directional trees for BGMP.
Where should we send the message? Relay across local scopes inside the overlap, like ZAMs are... So, could we modify the ZAM message to convey this information? Yes, but it's a pain because of the way ZAM messages work, and is easier to create a new message ("not inside message", NIM) which is transported in a similar manner. Open issues:
Basically: abandon inter-domain shared trees; just use inter-domain source trees which reduces the problem to locating active sources. Use standard PIM source tree join mechanism inter-domain.
MSDP concepts:
Gradually move to a peer-to-peer mesh model, rather than a star model centered on the first top level. Eventually the initial top-level domain may disappear. The other must cooperate to ensure that the entire range is still announced.
Expecting an alpha-release of the MASC-daemon before the next IETF.
Address space has been requested, will likely be 225.x.x.x
Van Jacobson made a presentation on IP Multicast Technology, starting with a brief history lesson:
...brief discussion of how multicast works, for beginners...
There are two possible forms a multicast tree may take: source based (unidirectional, only root can send) and group (or core) based (bidirectional, anyone can send). PIM has both, Express is source based, "simple" multicast is core based with "additional weirdness".
...discussion of simple multicast, express, and "yesterdays ideas" hanging on to the push for inter-domain multicast routing...
BGMP (inter-domain multicast) core based using "group prefixes" (structure in multicast addresses) to get appropriate control and scalability.
...brief discussion of BGMP and the multicast address allocation model, and how it maps onto the concepts CIDR brought to unicast address allocation and routing; and how it brings policy routing to multicast...
Summary: BGMP is good, but we need help and input from the ISPs to make sure it fits their needs!
Following this, Mark Handley presented a summary of the work done in the reliable multicast research group and Brian Moore, chair ITU-T SG 13, discussed collaboration between the IETF and ITU-T.
A research group (IRTF) concentrating on the security aspects of multicasting data. The main aim of the group is to clearly identify the security requirements of multicast applications. The group can be considered as a "spin-off" from IPSec.
Chairs: D.Harkins (dharkins@cisco.com) and Ran Canetti (IBM)
WWW page: www.ipmulticast.com/community/smug
It is a document intended to be a roadmap for IP multicast applications developers.
The goal is to prevent: reinventing the wheel, spinning wheels and roughsod over IP nets
The focus is on applications and the assumptions are that multicast capable networks exist and the developers are aware of the mechanics (refer to draft-mboned-intro-multicast-03.txt).
Multicast applications can be split in 3 categories:
1-to-many (analogous to the broadcast model)
Many-to-Many (e.g. multimedia conferencing, shared editing)
Many-to-1 (resource discovery, auctions, polling)
Other issues involved include: heterogeneous receivers, reliable data delivery
Data security: receivers and senders don't trust each other. The challenges here are authentication and key distribution. There are many strategies for this but no standards. The aim of Smug is to define the problem. More than one protocol will be required.
There are 3 main types of fairness: local, resource and path fairness. The main consideration is which types of fairness to use in a reliable multicast protocol.
A description and the potential uses of IP multicast were presented concentrating on the business models (subscription to channels, package distribution, time). Multicast conditional access can be achieved through content management and user/client management. An important issue here is user/client authentication and data encryption.
Software protection may seem adequate but it subject to attacks. Instead, hardware tokens are tamper resistant, can't be easily replicated and are a distributable and portable solution. Smart cards provide: physical security, portability, secure storage of keys, secure processing (cryptofunctions) and non-repudiation.
The security requirements were identified (secrecy via encryption of multicast data with group key, group data authentication, source authentication and non-repudiation).
The design goals of the architecture are simplicity, flexibility and easy incorporation. The general guidelines are: closely mimic IPSec architecture, independence from routing/reliability mechanisms, reuse of existing components, minimal modifications in OS kernels and a flexible choice of key management schemes.
e) Hugh Harney (Sparta)
Presented an overview of 3 papers emphasizing real-world and security requirements.
f) Thomas Hardjono (Nortel)
Presented a key distribution mechanism where the domain is divided into a number of administratively scoped areas. The data group and the control group are not the same and each area has a number of control groups. A member in an area also joins one control group. A special control group consists of all key distributors. New set of keys gets distributed every time there are group membership changes.
Some thoughts about Secure Multicast with and without IPSec.
Main issue was how to set the SPI. There should be a different SPI for each sender. Consider single sender for now without worrying about many-to-many applications.
The requirements for key management applications were defined (Harkins):
Sensitivity to key piracy
Is the join secured ? Does it have to be ?
Must the group be re-keyed when a member joins or leaves ?
Are key distributors precluded ? i.e. is end-to-end security necessary
Is a particular underlying multicast routing protocol necessary ? is one preferred ?
Can the cost of (re)keying be amortised over the life of the key ?
Is delivery time sensitive or can data be buffered ?
Is anti-replay protection necessary ?
Co-Chair: Andrew Smith (Extreme Networks)
Objective: This group aims to design a protocol for scalable policy control.
Agenda:1) RAP Framework Updates - Raj Yavatkar
A new draft is out (draft-ietf-rap-framework-02.txt) with a number of revisions:
a) Architectural elements (described external arrows)
b) the role of LDAD
c) Added section on general requirements for the C-Ser (PEP-PDP) protocol
d) Evaluation of existing protocol (section on SNMP)
e) Removed the discussion on Priority Preemption (rap-priority-00.txt)
f) Removed the discussion on Global Agreements
g) A few other minor changes
Ready to issue last call ?
2) Common Open Policy Service - COPS 03 Overview (draft-ietf-rap-cops-03.txt)
Ready to go to last call
An overview of this protocol was presented (a client-server protocol with support for signaled and provisioned QOS) highlighting the request-decision sequence.
General characteristics: stateful model, fault tolerant (runs over TCP sending periodic keep-alives), securable (utilising TCP security mechanisms or IPSEC), extensible and protocol independent
Changes from COPS 02:
a) A single decision message can contain many decisions
b) The in interface identifies the interface on which the signaled message arrives and from where
c) The Out interface identifies the interface from which the signaled message is sent to and where
Open issues:
a) Keep alive messages ?
b) Client type administration (IANA ?)
c) Multiple LDP decisions/requests
d) PEPID string (what it is and who sets it)
An issue was raised whether to use TCP or an alternative.
There were no major objections to the use of TCP.
3) COPS Usage for RSVP
Updates from previous (00) version:
a) Multiple context flags for optimization and context event ordering
b) Decision flags and object encapsulation (bound to a preceding context object)
c) New Unicast and Multicast examples
d) Wording clean-up
4) RSVP Extensions for Policy Admission Control
Describes the format of POLICY_DATA objects (similar to RSVP objects)
An observation was made here about potential security loopholes
Describes PIN processing rules
5) Preemption priority for RSVP
Characteristics:
a) Arbitration between competing flows
b) Offset importance of reservation ordering
c) Simple - performed by network nodes
d) Generated by PDPs
e) Interpreted, processed and enforced by PEPs
The main issue here is multicast merging (how) of priority elements
Problems: denial of service, free riders, instability
Merging strategies discussed:
Take the highest priority (the lowest is very bad)
Who is participating
Determined by the PE itself
Preemption and Defending priority (motivation here is stability)
6)
The new name for the draft is: draft-ietf-rap-rsvp-identity-00.txt
Features:
a) authenticates user making an RSVP request
b) identifies the application
c) supports multiple authentication methods (Simple, Kerberos, Public Key)
d) facilitates admission control based on user policies
e) supports the RAP and COPS framework
f) does not define new RSVP objects (extends the POLICY_DATA object)
g) works with MD5 (RSVP Cryptographic authentication) to avoid duplication
The format of the Identity Policy Element was also presented.
There are implementations from Microsoft and Intel
Open issues:
Leave the subtypes number assignment to IANA ?
Last call ?
7) General discussion and decisions
Expand the charter of the Working group ?
This was raised because of an additional draft whose scope is ambiguous. There are a few editorial issues to be discussed on the mailing list so the charter should not be expanded at present.
Status of documents
The framework' document should proceed as an informational RFC
Some documents can be coupled and then proposed for last call:
framework & rap-cops
cops-rsvp - ext - rap priority
rsvp identity
Two new working groups (focus on ISP support)
MSDP and IS-IS
BOF - GSMP
Documents:
RIPv2 (Scott Bradner)
IAB Routing Workshop document (iab-rtr-workshop-00.txt)
An update on the status of the groups followed.
The aim is to try to coordinate the interaction between IP multicast networks, hosts and multicast applications
Not active
OSPF (Open Shortest Path First)
Status of documents:
OSPF for IPv6
Reuses all IPv4 mechanisms, rearranges LSA formats,
Uses IPv6 AH & ESP, runs per link - not per subnet
NSSA Option - ready for last call
MOSPF has been revised and has been proposed for last call
QOS routing for OSPF - Experimental RFC
ARA
MOSPF prunes
Immediate issues:
MIB definition, MD5 Authentication, IS-IS in IPv4,
Dynamic symbolic router Ids, more than 255 circuits
Other issues: MPLS extensions
There is now a real plan to define IPv6 extension
Main issues: Scaling axes for IP Multicast
Spinoff smaller working groups to be more focused e.g. pim
This relatively "young group" tries to standardise the Protocol Independent Multicast protocol as a scalable solution for multicast routing.
Current work focuses on 3 documents to be proposed as standards:
Pimv2 dense mode, pimv2 sparse mode, MIB definitions
Amongst current issues are scalable timers and there is work in the MPLS area
They hope to move on quickly and the aim is to standardise a protocol to tie shared trees.
Current issues include: how to do data encapsulation for bursty sources, security
The implementation is now available (WIDE and INRIA)
The group has reached consensus to move draft.
Future work:
Interoperability test (for single/multiple feed cases, deployment in France)
Report on experiments (especially multicast)
RFC 2338 - Provides router redundancy on LAN for hosts
Status: finalizing VRRP MIB
Collecting implementation info (9 implementations) to include in draft
Interoperability testing
IPv6 specification send to IESG to move to Proposed Standard
There are 5 implementations of mobile IPv6
There is interest for Mobile IP for wireless cellular data
Issues that may be addressed:
AAA interactions, fast local/regional handoffs
Will wait for significant deployment before moving mobile IPv4 to Draft St.
There are 3 guidance drafts and a number of routing protocol drafts
Currently evaluating the simulation models and the progress of the tools
Problems:
Need to reach an agreement on addressing/architecture framework
Need to use a common signalling/support protocol e.g. IMGP
This BOF's purpose is to determine why many unicast protocol designers have opted for custom UDP based transport protocols rather than using TCP. The desired outcome is a document on "how to use TCP" and to gauge the utility of the new transport protocols being developed.
Presentations were made by on the design trade-offs that went into a number of protocols. These are summarized below.
COPS is a means of outsourcing policy decisions to a separate server, the policy decision point. Routers, the policy enforcement point, use COPS to determine the policies to be enforced. COPS is client/server protocol using a query and response mechanism to obtain policies. The server is stateful and the communication between the client and the server needs to be dynamic.
The COPS group decided to use TCP as it was close enough to their requirements:
The RADIUS protocol is described in RFC2138, it is an authenication mechanism for dial up users linked to the internet through a modem pool. It is a stateless challenge and response protocol. The decision was made to use UDP because:
L2TP is designed to allow ISPs to offer services other than registered IP address services to dial up users. It is a tunneling protocol for PPP that has two channels: a control channel and a data channel. The control channel requires sequenced delivery and reliability. It is mostly idle, but wants to be aggressive when is use. For the data channel there is a desire for sequential devilery, though not in all cases, but no desire for reliability since higher level protocols should handle this.
L2TP uses UDP based on the issues of scalability, fast fallover response, low idle overhead, and the ease of encapsulating ATM and Frame relay cells.
HTTP/1.x uses TCP as the transport protocol, though it makes poor use of it due to implementation issues and some inappropriate uses of TCP.
= Unfortunate issues with TCP and the web include:
SIP is an application layer signalling protocol for initiating, modifying, and terminating sessions between two or more parties. SIP is designed to look like HTTP: it has request and request interactions, it is textual, and is designed to make extensive use of proxies. The default protocol used by SIP is UDP, although TCP can be used by clients that explicitly request it and by proxies. The bases for using UDP by default are:
The original NFS was developed for LAN access of file stores and used UDP as it was assumed that LANs did not need congestion control. Since version 2 NFS has supported TCP because of the desire of remote network access and congestion over links. Using TCP simplifies implementations as end systems no longer have to worry about fragmentation, reassembly, and reliability mechanisms.
The NFSv4 wishlist is:
The transport mechanism used in telephony should respect protocol data units, should include the unit length, and should provide sequential delivery. Transactions in telephony systems are short and bursty with tight timing constraints. TCP is not suitable because:
David was one of the implementors IDRP (routing protocol) using UDP datagrams with retransmissions for reliability. This made the implementation considerably more complex, and David argued the choice of TCP or UDP for routing protocols is a second-order effect. For BGP they used TCP as the transport protocol and David presented a single slide showing the mapping of the protocol requirements to the transport protocol feature:
BGP Property | Transport Property |
| Big messages | Segmentation |
| Startup and shutdown mechanisms | Connections |
| Long term associations | Connections |
| Liveness checking | Keep alives |
| Rate limited updates (prevents route flapping) | Flow contr= ol |
| Bursty updates | Congestion and rece= iver sensitivity |
| Smooth utility scaling with b/w | TCP is acceptable <= /td> |
| Self describing updates | Sequential delivery=
not essential Duplicate detection not needed |
| Multiple receivers (IBGP) | Multicast useful an= d cleaner than "kludges" with reflectors |
Joerg is involved with the ITU's H323 group and the IETF MMUSIC and AVT groups. The main activities of H323 is for call initiation, remote control, and reporting. Requirements for H323 are end-to-end reliability, robustness against denial of service attacks, and tunable parameters on a per connection and/or per datagram basis. The current solution uses mixed PDU timeouts with backoff and uses ACKs for reliability.
Three-way handshakes are helpful because of the acknowledgement of essentially random data (see rfc793). This makes sequence guessing attacks harder, though not impossible. Better to use authentication, or encryption, only adds a few bytes and cost of computation. Servers need state to handle replay attacks and so TCP is a good match.
Why do people not want to use TCP?
David Meyer highlighted to IP Multicast Initiative (IPMI) and told people to look at the website (www.ipmulticast.com). There are now quite a few whitepapers on deployment issues relating to multicast.
The author, Ross Finlayson, was not present. It was agreed that this draft (draft-ietf-mboned-firewall-02.txt) should go to last call and be c= lassified as informational.
The purpose of this document is to offer advice to authors of multicast applications. The intended readership is application developers who are familiar with network programming. It covers only applications; not infrastructure or mechanics. These are dealt with in the "Introduction to IP multicast routing" by Semeria and Maufer.
It is envisaged that there are three groups of applications:
Heterogeneity implies the need for adaptation of bandwidth (or layers). T= here are no standards for these strategies.
Relaible delivery is still a research area. The TCP model has no equivalent mapping for multicast. Two widely extolled strategies are the application of forward error correction (FEC) and the use of negative acknowledgement based schemes (NAKs). There are no standards here either, but there is a research group in the IRTF (Reliable Multicast Research Group Homepage).
= Security is also an unresolved issue. The Secure Multicast Group (SMuG) in the IRTF examining the problem (Secure Multicast = Group Homepage). The challenges lie in authentication and key distribution.
There are many open issues in multicast application development and although this document does not provide direct advice it does provide awareness of the issues and highlight applications. It will be decided on the mailing list whether this should become an informational RFC.
This protocol is a strawman candidate for finding suitably scoped addresses in an administratively scoped multicast internet. It is intended for use in conjuction with the Multicast Address Allocation Architecture (MAAA). Administrative scoping makes localization easier and better and address can be heirarchically scoped to improve scaleability. The intended application area is reliable multicast.
In the current Mbone applications typically use an expanding TTL search to find peers. This has issues with TTL thresholds and may cause flooding in sparse sessions. In this new scenario applications perform an expanding zone search. To do this effectively, applications need to be able to determine which zones are involved in the zone hierarchy for a particular session and what addresses are to be used for communicating with other session members within the zones in the hierarchy. The complicating factor is that different zones with the same scope may have different addresses.
The idea behind SADP is to have servers located within each scope and for applications to use a single multicast group within the scope [SADP-RELATIVE-GROUP] to find out the address relations.
A suggested packet format is presented in the draft. There was little interest in the group, although this is probably the wrong forum to discuss this protocol. Dave Thaler pointed to some problems and solutions in Roger's assumptions and they agreed to work on them offline.
Steve Shultz of NASA AMES Multicast Exchange (ARC-MIX) gave a short talk on the Multicast Exchange. The objective of the exchange is to have a multicast friendly network and to support scaleable inter-domain multicast routing exchange.
The components for MIX include a protocol for inter-domain route exchange (MBGP/BGP4+), a protocol for multicast forwarding and a method for identifying active sources. Connection to the MIX network is via FDDI concentrators as this provides ample bandwidth, and is easy to use and configure.
The routing (BGP4+) uses standard route exchange mechanisms (RFC2283) and like BGP4 includes unicast and multicast forwarding options. Multicast is using PIM-DM and PIM-SM with active source identification is correspondly performed by dense mode flooding and MSDP.
Peter Lothberg of SPRINT gave a short talk saying they are doing something similar to MIX and have a connection to MIX. They have two experimental networks and are currently working on getting PIM-SM working in conjunction with MSDP. A second person (not identified) stated their organisation was also doing this.
Chair: John Linn <jlinn@securitydynamics.com>
Agenda: (a) IESG Activities on WG Documents
(b) PKINIT/PKCROSS Last Call Discussion
(c) Status of revised/pending revision documents
(d) GAA/XGSS Comparison
(e) GAA Updates
(f) Kerberos passwords revision
(g) Kerberos-extra-tgt, pk-recovery
(h) PGP-Ticket
IESG Action: SNEGO moved to Proposed IESG Action: IDUP moved to Informational
In addition, a GSSV2 misalignment had been found and this had been discussed on the mailing list. This misalignment has been resolved in advance of IESG submission.
Russ Housley: CMS is in WG last call and should be in IETF last call by Xmas. There are a few remaining issues which should be resolved this week and there are no indications of problems with the IESG. The main change with the new version of CMS is the envelopedData structure. TLS (Transport Layer Security) and PKIX should be ready for last call in March.
Jeff Schiller: The drafts must be in last call for at least two weeks. Microsoft already has a CMS implementation but it should be checked that this is compatible with the current CMS version. There may be problems with TLS due to some unresolved patent issues. He suggested that this draft should refer to CMS by reference and, if there are any problems later on, change this to a reference by value. A final determination will be made no later than the March 1999 IETF meeting.
There were some other issues which need to be addressed, namely the use of Diffie-Hellman without a public key infrastructure as well as some other situations which PKINIT doesn't address. There was a consensus to remove the digital signature section, the key storage on KDC (Key Distribution Centre) and encryption key section from the base draft. The document would then be submitted to the WG for last call.
PKCROSS - it was felt that there were enough issues which needed to be dealt with in the PKINIT draft so PKCROSS wasn't discussed.
(i) krbgss-mech2-01 - a few small issues (eg name types) need to be resolved
(ii) kerberos-revisions - a new draft is planned by mid-January, identifying deltas relative to RFC-1510 (Kerberos Network Authentication Service V5) and also addressing outstanding discussion re ticket extensions and ASN.1 encoding.
Denis compared the GAA (Generic Authorisation and Access Control) and XGSS (Extended Generic Security Service) documents and seemed to find that the approaches were complimentary.
POSIX ACLs are fine for stand alone systems but not for distributed systems. Both LDAP and AAA BoF are doing ACL work and we should liaise with them to see how they are addressing the issue of ACLs
There are a few minor issues which need to be addressed but should be ready to move forward by the next IETF.
kerberos-extra-tgt (Extension to Kerberos V5 For Additional Initial Encryption)
This allows a pre-authentication field in the AS_REQ message to carry a ticket granting ticket (tgt). The session key from this ticket granting ticket is used to cryptographically strengthen the initial exchange in either the conventional Kerberos V5 case or in the case the user stores their encrypted private key on the KDC. There was much discussion around this document with the general feeling being that there were a number of weaknesses and not much gain in security. The discussion was taken off-line.
pk-recovery (Public Key Cryptography for KDC Recovery in Kerberos V5)
This allows the recovery of a compromised Kerberos V5 KDC using public key cryptography.
"draft-moscaritolo-mione-pgpticket-01.txt" covers methods of extending open-PGP's message formats to support an authorisation system. Basically, public key cryptography is used to authenticate a user to a server and establish the user's access permissions. The concept is that the user acquires a ticket signed by some issuer that specifies what they are entitled to do. That ticket is then submitted to a server. The server uses a challenge/response method to verify that the holder really has the matching private key. The server then allows the access specified. This draft was presented to inform the CAT WG of its presence and to see if anyone was interested in its advancement within th CAT WG. It is based on RFC2440 v4 standalone signature packets and some of the uses mentioned could be:
Agenda: (a) LDAP and PGP
(b) RFC 2440
(c) PGP MIME
(a) LDAP and PGP - (Roland Hedberg - Catalogix)
This was originally proposed in 1995 and it now seems that the time may be more appropriate.
The motivation is: to have one database holding all the users information; LDAP is an IETF standard and; it simplifies client and application construction.
There are several assumptions: there should be no or limited pre/post processing for clients and so a rewrite of the LDAP client software shouldn't be necessary; searches on userID and/or keyID and/or key fingerprints should be allowed; it should be possible to store several keys per user/application.
There are two proposed solutions: split the information for each key into several attributes (eg userID, keyID) but this would lose the connection between the attributes and will cause problems if have several keys in one place; use a URL pointing to a storage area.
This is the stage that was reached 3 years ago - it was proposed that a new draft be worked on and Ed Rees (Novell) and Roland Hedberg (Catalogix) volunteered to do this.
(b) RFC 2440 - Open PGP
This draft was discussed and there were several issues:
There is a web site with the status and comments on the Open PGP draft. This is
http://www-ns.rutgers.edu/~mione/openpgp
Issues which may be addressed:
(c) PGP-MIME RFC 2015 (Ken Yamamoto - Internet Initiative Inc ?)
PGP-MIME (RFC 2015) is based on v2 PGP (RFC 1991) and was written in Oct 96. A similar Open PGP-MIME draft should be written and synchronised with PGP-MIME. It was felt very important that backwards compatibility with the original PGP-MIME document.
Thomas Roessler (MUTT?) and Kazu Yamamoto (MEW?) volunteered to put together a first draft of this document.
(b) Revs for IKE (D.Harkins - Cisco)
IKE is "The Internet Key Exchange" (draft-ietf-ipsec-isakmp-oakley-xx.txt) There are lots of issues to be dealt with.
ISAKMP - do we need both major and minor version numbers ?
(c) Revisions for DOI (Tim Jenkins - Timestep Corp.)
DOI is "The Internet IP Security Domain of Interpretation for ISAKMP" (draft-ietf-ipsec-ipsec-doi-xx.txt)
(d) Re-Keying Issues
There were a number of re-keying issues which could be broken down into:-
(i) Phase 2 issues - the drafts are not very explicit and use unacknowledged messages over a lossy channel (UDP). The "commit bit" is not protected for authentication and the "delete notification" has problems and implementations vary.
(ii) Phase 1 issues - the use of initial contact is optional, as is the use of delete notification.
The recommendations were: reduce the need for the commit bit and specify the behaviour of rekeying to guarantee continuously available SAs (Security Associations) without gaps.
The recommendations for IPSecond were: add the required SA deletion mechanism; delete request notification; delete acknowledgement; standard timeout/retries apply to exchange; apply to both Phase 1 and Phase 2 SAs.
(e) Rechartering
Jeff Schiller asked the question "What do we do next?" The milestones in the charter have been reached and the IPSec documents were RFC'd at Thanksgiving. The Working Group has been in existence for 6 years and the documents are at proposed standard with several interworking implementations. It is recommended that we concentrate on deploying what we have and make further changes in such a way that they are backwards compatible. Enhancements should be based on real needs.
There are a number of areas which may be explored:
(f) MIBs (Tim Jenkins - Timestep Corp.)
The objective is the monitoring of IPSec only. There are a number of issues which need to be resolved.
(g) Transport Friendly ESP (Steve Bellorin - AT&T)
A possible ESP variant was suggested for discussion and not yet for RFC. Some people don't like ESP as it hides a lot of things such as port numbers, and causes firewall problems. In addition IPSec is NAT unfriendly. It should be possible to specify what part of the IP and TCP headers may be available in the clear with the exposure completely under the control of the endpoints. It may even be desirable to exclude the first few bytes from the authentication and so allow modifiable fields.
What shall we do with the Diffie-Hellman and OCDP drafts ?
B) Established Projects
Ba) KEA and ECDSA (Status update - T. Polk)
There is nothing to discuss here.
Bb) CMC (Jeff Weinstein - Netscape)
Certificate Management Messages over CMS (draft-ietf-pkix-cmc-02.txt). The protocol has been designed with the following requirements:
Bc) CMC Comments (Carlo from Entrust)
The first incarnation was in July 97 and the second in November 98. This was a lot better but there are still two concerns:-
(i) security - it is possible for someone to get their name and someone else's key into a certificate
(ii) interoperability - the text is unclear in parts which may give rise to interoperability issues.
There was a misunderstanding due to a typo in the emailed agenda which said that CMC was in WG last call - it isn't and there is a list of changes which still need to be addressed.
Bd) Diffie-Hellman Signing Algorithm (Jim Schaad - Microsoft)
<draft-schaad-dhsign-00.txt> describes a method for producing a signature from a Diffie-Hellman key pair. This behaviour is needed for such operations as creating a signature of a PKCS #10 certification request. This document describes two different flavours of the signature algorithm, one using a D-H key from a CA and the other using a temporary key created by the signer.
This is a standalone draft from the enrolment drafts and has 2 algorithms:
Be) PKIX Roadmap document (A. Arsenault)
The next draft will be in January/February.
Bf) PKIX CP/CPS Framework Revision (W. Ford)
There will be a new draft around February
Bg) X.509 PDAM (T.Polk - NIST)
The ISO group is doing more X.509 work with new extensions and would like comments from the IETF/PKIX.
There are some revocation related extensions:
(i) CRL Scope Extension - applies to public key and attributes CRLs
(ii) Status Referral Extension
(iii) Freshest CRL Extension
There is also a new annex containing CRL processing rules, clarification to the delta CRL text and proposed reorganisation.
The ballot closes on March 7th 1998 and the PDAM is downloadable from:
ftp://ftp.bull.com/pub/OSIdirectory/BeijingVancouver98Output/
The files are: CertificateExtensionsPDAM.doc
CertificateExtensionsPDAM.pdf
C) New Topics
Ca) Qualified Certs (draft-ietf-santesson-qc-01.txt) (S. Santesson)
This is concerned with the European legal system and these certificates can be identified as Qualified Certificates. This identifies their liability and policy and they are only applicable to non-repudiation. It identifies a person and NOT a company.
Cb) ETSI Report (D. Pinkas)
This is a report on the electronic signature standard and is available from:
http://www.etsi.org/SEC/ESRep042.pdf
It is concerned with the need for non-repudiation of signatures so they can be used for electronic contracts.
ETSI is the "European Telecommunications Standards Institute"
The meeting was continued at 1pm on Wednesday - see later
6) IP Security 2
Agenda:
(a) PKI Requirements R. Thayer
(b) MS Kerberos auth B. Swander
(c) Xauth/CFG R. Pereira
(d) Hybrid auth T. Zegman
(e) Policy Issues R. Pereira
(f) Security Policy M. Cordell
(g) Policy engine L. Sanchez
(h) Core Schema E. Ellesson
(i) Trust Management M. Blaze
(j) NAT Issues G. Montenegro
(k) More NAT Issues P. Srisvresh
(l) SA Mobility J. Ionnidis
(a) PKI Requirements (R. Thayer - Internet Devices)
The current draft is available from:
http://www2.internetdevices.com/arch-lab/ietf/draft-ietf-ipsec-pki-req-02e.txt
There is also a survey available on the web, covering at least 70 vendors at
http://www2.internetdevices.com/arch-lab/ietf/ipsec-survey.html
(it seems to be just a test as I write theses notes ?)
(b) MS Kerberos Authentication (B. Swander - Microsoft)
There are some issues: GSS AcceptSecContext may return Continue_Needed. So you need an extra round trip for the KDC - GSS supports arbitrary round trips and IKE must do this also. This has all been fully implemented at Microsoft and works okay. Win2000 beta 3 has is as in the current documents (vendorID=GSSAPI, IKEauth=65001, IKE payloadID=129, GSSAPI ID Name Class Value=32001)
The Win2000 KDC has been tested and has also been used as a member of other MIT based domains.
In order to try this yourself you need:
Win2000 beta 3 Domain controller KDC Win2000 platform as a domain member
For win9x, NT 3/4 you must use a 3rd party implementation as there is no Microsoft s/w available yet.
For non-windows platforms you should use MIT kerberos libraries.
Information can be found at:
http://ntbeta.microsoft.com/documentation/Walkthrough.asp
http://www.microsoft.com/ntserver
http://www.microsoft.com/security
http://www.cybersafe.com/ <- has info on Kerberos implementations
Note that Microsoft allows an extra round trip but no other implementations do.
(c) XAUTH/CFG status (Pereira - Timestep Corp.)
(i) The ISAKMP Configuration Method <draft-ietf-ipsec-isakmp-mode-cfg-04.txt>
This describes a new ISAKMP method that allows configuration items to be exchanged securely by using both push/acknowledge or request/reply paradigms.
There have been no changes since the last IETF. Real world functionality is being done with a lot of peer-peer requests and replies. There are a number of things which need addressing: call management; keep alives and; policy discovery/distribution but these can all be added quite quickly.
(ii) Extended Authentication Within ISAKMP/Oakley
<draft-ietf-ipsec-isakmp-xauth-03.txt>
This describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol.
The only modification since the last IETF was the addition of a fourth message (acknowledgement) to acknowledge the status response from the gateway.
A number of companies are interested - Timestep, Checkpoint, SSH, Xedia and IRE for example - but there are no products yet.
(d) Hybrid auth (T. Zegman - Checkpoint ?)
There is a need to support the use of IPSec for remote users where there are old legacy authentication systems but no fully deployed PKI. Can do a Phase 1 exchange followed by xauth.
Some comments from the floor were made:
(e) Policy Issues (R. Pereira - Timestep)
There is a mailing list for these issues at ipsec-policy@mail.timestep.com
There are two documents:
(i) IPSec Policy Data Model <draft-ietf-ipsec-policy-model-00.txt>
(ii) An LDAP Schema for Configuration and Administration of IPSec based
Virtual Private Networks (VPNs) <draft-ipsec-vpn-policy-schema-00.txt>
There are also a number of other policy documents:
It would be nice to create a document roadmap for IPSec policy so that all the documents could use the same terminology, allow different models for policy distribution, discovery and storage and work with other groups.
The goals would be: to have a core policy; to have a core management specification so that any management system can communicate with any IPSec device and; to have a better understanding of IP Security topologies and models.
(f) Security Policy (M. Cordell - BBN/GTEI)
The draft discussed was:
"Security Policy Specification Language" <draft-ietf-ipsec-spsl-00.txt>
which describes the Security Policy Specification Language (SPSL), a language designed to express security policies, security domains, and the entities that manage the policies and domains. The syntax and semantics of the language are presented here. SPSL currently supports policies for packet filtering, IP Security (IPSec), and ISAKMP exchanges, however, it may easily be extended to express other types of policies.
This is consequently a vendor-independent language for specifying policies and is based on a class structure. it has the format:
(a) attribute:value eg dst:192.1.98.168 (b) single/multi valued
There are 3 types:
(i) Management (either maintainer or certificate) (ii) Network (either node, node-set (group of nodes), gateway, gateway-set) (iii) Policies
There is a parser available written in Bison/Flex and information can be found at:
http://www.net-tech.bbn.com/pbsm/pbsm-index.html
(g) Policy engine (L. Sanchez - BBN/GTEI)
Document: "Security Policy System" <draft-ietf-ipsec-sps-00.txt>
Problems: - discovery of security gateways
Requirements: - support for complex topologies
The code was released on November 20th. The document is available from:
http://www.net-tech.bbn.com/pbsm/SPS-design
(h) Core Schema (Policy) E. Ellesson
Ed Ellesson is the Policy Framework Working Group Co-Chair. The objectives of this group are to:
Their target is to have this done by June '99.
The deliverables will be ready in a few weeks and are:
as well as some other documents I think.
There is a mailing list at policy@raleigh.com
(i) Trust Management for IPSec Policy Configuration (M. Blaze AT&T)
There are two IPSec policy layers:
The Trust Management approach allows you to use certificate distribution systems to distribute policy. It is unclear how to do all this or even exactly what is needed but an Informational RFC draft will be issued called something like "draft .... trustmgt-blaze". The keynote language may be sued which is a trust management language similar to PolicyMaker and allows applications to form queries. Keynote determines if the actions etc are allowed based on the credentials. There is a free implementation available of Keynote.
(j) NAT Issues (G. Montenegro - SUN)
NAT is Network Address Translator
There are a lot of NAT issues which are being addressed elsewhere:
One problem is that we are not looking at NAT and IPSec but IPSec across NAT.
One solution is to use packet de-multiplexing based on negotiated mappings.
We must be careful to:
(k) More NAT Issues (P. Srisvresh)
There is a draft:
"Security for IP Network Address Translator (NAT) Domains" <draft-ietf-nat-security-00.txt>
NATs provide transparent routing to end hosts trying to communicate from disparate routing realms, by modifying IP and transport headers en-route. This solution works best when the end user identifier (such as host name) is different from the address used to locate end user.
End-to-end transport level payload security can be provided for applications that do not embed realm-specific information that is meaningless to one of the end-users. Applications that do embed realm-specific information will require an application level gateway (ALG) to make the payload meaningful in both realms. However, applications that require assistance of an ALG en-route cannot pursue end-to-end transport level security.
All applications traversing a NAT device, irrespective of whether they require assistance of an ALG or not, can benefit from IPsec tunnel-mode security, when NAT device acts as the IPsec tunnel end point.
(l) SA Mobility (J. Ionnidis - AT&T)
JI gave a short presentation about mobility of Security Associations.
Agenda: (a) Timestamp (draft-ietf-pkix-time-stamp-00.txt)
(b) Data Certification Server (draft-ietf-pkix-dcs-00.txt)
(c) Atomic certs (draft-raghu-atomic-certificates-00.txt)
(d) Interoperability Testing
(e) Secure Network Time BOF
(f) Availability of IBM PKIX Software
(a) Timestamp (draft-ietf-pkix-time-stamp-00.txt)
This document is stable, close to completion and should progress to last call after the next draft.
(b) Data Certification Server (draft-ietf-pkix-dcs-00.txt)
This is a "notary" service which can certify the correctness of certificates or signatures submitted to it. There have been no major changes since the last draft.
Denis Pinkas: There are a number of issues which need to be addressed.
There was some discussion about whether to combine the timestamp and DCS documents as DCS has the option of not checking everything and so can be used as a basic timestamp facility. Denis and a few others said they were against this combination.
There was also a question about patents around timestamping - apparently it is an issue and some patent issues are mentioned in the document. Any users or implementors will need to look into this issues themselves. There are many patents and patent holders so a royalty free agreement with the IETF, which has happened in the past, will not be possible in this case.
Another question was regarding whether the timestamp protocol should be able to handle decryption as a number of people feel it is undesirable to send documents in the clear - I think the current situation is that just the hash is sent to the server ?
There was a poll which agreed that the timestamp document should go to WG last call after the next draft.
(c) Atomic certs (draft-raghu-atomic-certificates-00.txt)
No talk was given on this.
(d) Interoperability Testing
PKIX - CMP interoperability testing ccan be done at Entrust. If you want to be involved then email "chris.voice@entrust.com"
(e) Secure Network Time BOF
Tim Polk just mentioned that there will be a meeting of a "Secure Network Time BOF" tomorrow (Thursday). This is concerned with a secure time infrastructure and compliments the timestamp and DCS documents.
(f) Availability of IBM PKIX Software
Mark Davis (IBM) said that PKIX software is available from the MIT web. It is available as binary and source code but is currently only available for WinNT with Solaris becoming available at the end of the month. They are actually further ahead with the AIX code but this won't be available. Note that due to Crypto Export regulations this is only downloadable in the US. IBM didn't write the encryption software themselves but use the "Cylink" and "RSA Bsafe" toolkits. Consequently it should be possible to just export the source code minus the encryption and plug in your own security toolkits overseas.
Paul Hoffman (IMC) has a pointer to the software on his site and said that if someone was to give him a pointer to a non-US site holding the software then he would put this on his site also.
Tim Polk (NIST) said that NIST are also doing a reference implementation but this is delayed at the moment. This should be available outside the US.
Chair: Russ Housley <housley@spyrus.com>
Agenda:
(a) CMS Draft Discussion Russ Housley
(b) X9.42 Draft Discussion Eric Rescorla
(c) MSG Draft Discussion Paul Hoffman
(d) CERT Draft Discussion Paul Hoffman
(e) ESS Draft Discussion Paul Hoffman
(f) CERTDIST Draft Discussion Jim Schaad
(g) DOMSEC Draft Discussion Bill Ottaway
(h) Request CEK Key Management Frank Siebenlist
(i) Wrap Up Russ Housley
(j) New CMS Examples Document Paul Hoffman
(a) CMS (Cryptographic Message Syntax) Draft (Russ Housley - Spyrus)
All sections are complete and the document is in WG last call. The current draft is 09 and the comments received have been incorporated into "10" which is pending. The completion depends on the X9.42 (Diffie-Hellman Key management) document.
The key wrapping algorithm issue is still unresolved. It has only been looked at for Triple DES in CBC mode and RC2 in CBC mode. It has weaknesses in other modes. The section has been changed to specify that it must be used in the above way.
There are three parts to the key wrapping algorithm: key checksum; key wrapping and; key unwrapping. The checksum is 16 bits now but it was suggested that this should be 32 bits. It was also suggested that it would be better to use a hash rather than a checksum but if we are only using 16 bits you don't gain anything by using a hash (SHA).
The consensus was that CMS draft 10 should go into a 4 week long Working Group last call.
There was a suggestion that the signedData should have a signing key identifier (SKI) rather than just having the issuer and serial number. SKI is a CHOICE field - it is NOT used in S/MIME, S/MIME MUST use the issuer and serial number.
(b) X9.42 (Diffie-Hellman Key Agreement Method) Draft (Eric Rescorla - RTFM Inc)
This draft standardises one particular Diffie-Hellman variant, based on the ANSI X9.42 standard, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The D-H variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair.
There is a brand new draft available with the following changes:-
(c) MSG (S/MIME Version 3 Message Specification) Draft (Paul Hoffman - IMC)
There has been some new wording and the Triple DES reference is now X9.52 which is the ANSI standard.
(d) CERT (S/MIME Version 3 Certificate Handling) Draft (Paul Hoffman - IMC)
The only real change is that Section 3.2 (required name attributes) as it is redundant with PKIX Part I.
(e) ESS (Enhanced Security Services for S/MIME) Draft (Paul Hoffman - IMC)
There have been a few small editorial changes in moving from "09" to "10"
(f) CERTDIST (Certificate Distribution Spec.) Draft (Jim Schaad - Microsoft)
There have been no changes since the last meeting. The only thing left is to write the security considerations section and then it will be ready for WG last call.
There was a suggestion from the floor to add a n example of a hash of zero bytes so implementor would get this right. There were also a few changes in the text needed as a few of the necessary steps had inadvertently been left out.
(g) DOMSEC (Domain Security Services using S/MIME) (Bill Ottaway - DERA)
The signature application has been clarified and there are multiple types per signature. There were no comments or additional changes requested. Work has started on an implementation and they are looking at embedding it in a firewall.
There was a question as to whether this should be looking to progress to "Informational" or "Standard".
Comments from the floor:
If you don't use encapsulation then security can be breached because someone can take your signature and use it themselves
Paul Hoffman (IMC) - DERA are the only people working on this so he felt that it should be "Experimental" at the moment and then move it over to "standards" track when other people are working on it.
There was a straw poll with most people agreeing that it should be "experimental"
(h) Request CEK Key Management (Frank Siebenlist - DASCOM)
This is CMS agreement for shared (content) encryption key. It is similar to a Key encryption key agreement and uses CMS for session based message exchanges. It is the standardisation message format for GSSAPI and facilitates SASL implementation.
In summary you want to use CMS for more than PKIX and S/MIME and the addition of a "Content Encryption Key Agreement" to the CMS draft is relatively innocent.
Comments from the floor:
Eric Rescorla - don't like this at all
Others - If it isn't a good idea then it shouldn't be in the IETF and this
doesn't seem like a good idea. It could be open to abuse if you
don't understand it fully.
Russ Housley - Frank and John should chat to see if they can come up with a
new draft.
(j) Wrap Up (Russ Housley - Spyrus)
The charter says that we should try to be compatible with OpenPGP. There was a comment that PGP has been written so that it can use X.509 style keys so a similar mechanism would be nice in S/MIME drafts.
Paul Hoffman - there are a lot of issues to deal with so it may be an idea to
have a separate draft which explains what to do if you want to
be compatible with both OpenPGP and S/MIME.
(j) New CMS Examples Document (Paul Hoffman - IMC)
Paul Hoffman (IMC) has volunteered to write a document containing CMS examples. There were a number of helpful suggestions from the floor and he would like people with examples or suggestions to get in touch with him.
Agenda:
(a) Open PGP Jon Callas
(b) CAT (Common Authentication Technology)
(c) IPSec Ted
(d) PKIX
(e) Others
(f) Wrap Up
(a) Open PGP WG Jon Callas
Jon ran through what has been happening in the OpenPGP group eg PGP MIME document is tor replace RC2015 (the old PGP MIME document)
See my notes on the OpenPGP meeting earlier fro details.
(b) CAT (Common Authentication Technology) WG
For more details on the CAT meeting see my earlier notes.
(c) IPSec WG (Ted)
In the IPSec meetings:
The document set has finally been approved. There are a number of items in the IPSec WG which will get moved to clearly focussed WGs eg SNMP MIB.
Some time was spent in the WG meeting checking that we are aligned with PKIX regarding X.509.
JI talked about SA mobility.
For full details see my earlier notes.
(d) PKIX WG
In the PKIX meeting:
For full details see my earlier notes.
(e) Others
(i) TLS (Transport Layer Security)
(ii) DNSSec (Domain Name System Security)
AFT (Authenticated Firewall Traversal)
OTP
SecSH (Secure Shell)
SPKI (Simple Public Key Infrastructure)
WTS (Web Transaction Standards)
- None of the above met at this IETF.
- SecSH is just about finished
- SPKI is just about finished and probably won't meet again. The
documents will be "Experimental".
- WTS has not met for a long time and probably won't meet again.
(iii) New WGs / BOFs
There are a few new WGs/BOFs:-
(f) Wrap Up (Jeff Schiller - MIT)
There was much discussion about the "Wassenaar Arrangement". This is to do with other countries also regulating weapons technology etc including encryption. Details of this can be found at:
People should let the public know what a bad idea this is and there were calls for the IESG to make a public announcement. The IESG have/will put out a statement reaffirming RFC 1984 "IAB and IESG Statement on Cryptographic Technology and the Internet" (Aug 96). Many people thought this was not enough as the public have no idea who the IAB and IESG/IETF are.
There was also mention of an IAB Security Mechanism document which outlines all the security stuff in the IETF. This is "Security Mechanisms for the Internet" (draft-iab-sechmech-00.txt).
Agenda:
(a) Document Status R. Hinden
(b) IPv6 Code Points R. Hinden
(c) IPv6 REN Status and Plans R. Fink
(d) Mobile IPv6 D. Johnson
(e) IPv6 over IPv4 without Tunnels B. Carpenter
(f) DNS Extensions to Support IPv6 M. Crawford
(g) Router Renumbering B. Carpenter
(h) Jumbograms S. Deering
(i) Multicast Listener Discovery Protocol S. Deering
(j) Separating Identifiers/Locators in Addresses L. Zhang
(k) Site Preferences in Neighbour Discovery
(a) Document Status (R. Hinden - NOKIA)
Most of the documents have been published as RFCs except:
(i) IP Header Compression document - we are waiting for a new draft
(ii) IPv6 Over ARCnet Networks - we are waiting for a new draft
(iii) Router Renumbering for IPv6 - waiting for IESG comments
(iv) IPv6 Router alert option - IESG wants to reconcile this with IPv4 router alert
(v) Reserved IPv6 subnet anycast address - gone to IESG
(vi) DNS extensions to support IPv6 - gone to IESG
(vii) IPv6 jumbo payload option - WG last call for proposed std
(viii) IPv6 over IPv4 without explicit Tunnels - WG last call for proposed std
(ix) Basic Socket Interface Extensions - WG last call for Informational
(x) Initial IPv6 sub TLA ID Assignments - WG last call for Informational
(xi) Name Lookups Through ICMP - WG last call for Experimental
Steve Deering (Cisco) said that INRIA, NRL and KAME all have (BSD) implementations and are going to merge their code.
(b) IPv6 Code Points (R. Hinden - NOKIA)
IANA registration has been done and is available at: http://www.iana.org/numbers.html
There are two addressing documents and it is time these were moved to draft standard.
There were no objections.
(c) IPv6 REN Status and Plans (R. Fink - LBNL)
REN is "Research and Educational Networks"
Microsoft IPv6 may be 2-3 years away and it may take another 3-5 years to deploy it. It would be good if we could drive this a bit faster by starting to deploy our own IPv6 implementations. ESnet has established native IPv6 with CAIRN, vBNS etc
There is a website: http://www.6ren.net
or email: rlfink@lbl.gov
(d) Mobile IPv6 (D. Johnson - Carnegie Mellon University)
Dave had to be in a different meeting but was hoping to make it to this one before the end.
(e) IPv6 over IPv4 without Tunnels (B. Carpenter - IBM)
This document has been through WG last call and will probably be resubmitted without Section 7 (this as to do with IPv6 over IPv4 without multicast).
(f) DNS Extensions to Support IPv6 (M. Crawford - Fermilab)
We are waiting on a few DNS documents (EDNS0 which is waiting for IANA considerations section)
Concerning implementations: BIND9 will have IPv6 DNS stuff and will be released in about 12 months. BIND 8.2 will have it in sooner but this will just be for experimentation.
(g) Router Renumbering (B. Carpenter - IBM)
There were a few comments from the IESG and a new draft will be released soon
(h) Jumbograms (S. Deering - Cisco Systems)
This was the part which was removed from the IPv6 draft so that the rest of the specification could go through.
(i) Multicast Listener Discovery Protocol (S. Deering - Cisco Systems)
Steve forgot to release this. He will make a few modifications and send out a new draft. There was some question about a Denial of Service attack as a response time of 0 is allowed.
(j) Separating Identifiers/Locators in Addresses (L. Zhang - UCLA)
This is an analysis of the GSE Proposal for IPv6. We want to move it to WG last call in order to go to Informational RFC.