NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Glenn Zorn <glennz@microsoft.com>
Pat Calhoun <pcalhoun@usr.com>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
Scott Bradner <sob@harvard.edu>
General Discussion:roamops@tdmx.rutgers.edu
To Subscribe: roamops-request@tdmx.rutgers.edu
In Body: include "subscribe"
Archive: ftp://ftp-no.rutgers.edu/misc/IETF/roamops
The purpose of this group is to develop or adopt procedures, mechanisms and protocols to support user roaming among groups of Internet service providers (ISPs). This is different from, but related to, the work of the IP Routing for Wireless/Mobile Hosts Working Group (mobileip) in that the roamops group is not concerned with the movement of hosts or subnets, but of users. In the near term, the goals of the group will be to produce an Informational RFC describing existing roaming implementations and an architectural document describing the basic mechanisms required to support user roaming. The group will use draft-zorn-dial-roam-req-01.txt as a starting point for the latter document. In addition, a repository for documentation describing current roaming implementations will be maintained.
In the longer term, the group may address interoperability among ISPs and roaming users by standardizing such items as network usage data exchange (including the content, format and protocols involved), phone book attributes and exchange/update protocols, inter-ISP authentication mechanisms and exploring in depth the security issues involved with roaming. This work is expected to consist mainly of new or revised procedures and application-layer protocols.
Any and all business issues regarding the operation of an ISP roaming network (such as settlement, business and billing methods) are specifically NOT in the scope of the roamops Working Group and will not be discussed.
The group will work closely with other IETF Working Groups (including mobileip, radius, nasreqng and cat) to identify issues to which the roamops group should attend, as well as to assure their work does not make roaming unnecessarily difficult or impossible.
Goals and Milestones:
|
Nov 96 |
Re-submit existing Internet-Drafts as work of the ROAMOPS Working Group |
|
|
Jan 97 |
Submit Internet-Drafts to IESG for publication as RFCs |
|
|
Jan 97 |
Review the charter for additional work required |
· Review of Roaming Implementations
· The Network Access Identifier
· The Roaming Relationship (REL) Resource Record in the DNS
· The Accounting Problem in Roaming
· The Authentication and Authorization Problem in Roaming
Minutes of the Roaming Operations (ROAMOPS) Working Group
I. Multimedia Services Affiliate Forum, Toon Vrins, AT&T
MSAF Global Intranet Access Committee MSAF - IETF relation
MSAF is a non-profit organization open to all committed to the advancement of interoperable multimedia services and applications. It facilitates global connectivity and interoperability among member networks and services. Its primary output is the framework for implementation agreements.
There are currently 48 members. The web address is www.msaf.org.
MSAF has a study group called Global Roaming, which had their first meeting in March of 1997. MSAF is interested in having a liaison with the IETF's ROAMOPS Working Group. The methods of liaisons are to exchange papers and to seek participation at meetings. There are 3-4 MSAF meetings per year.
B. Service Interoperability Committee
"... The ability to use a local analog or ISDN dial-in network to remotely access companies or service providers in other areas."
It started as a Global Roaming Study group. There currently are two documents pending: "Draft Common Service Description" and "Draft Terms of Reference."
The next meeting is in June in London, England.
C. Draft Common Service Description
The document describes the required, recommended and optional features and customer requirements. It has a product summary, billing and settlements and discusses customer care.
The current features that are described are:
· Secure Managed transport network (i.e., private networks) · Service level Guarantees · Access to POPs of interconnected service provider multi-protocol support · Address allocation is provided by the user's corporation · In-company authentication is needed · User is restricted to a single simultaneous login
The current Deliverables are:
· Interoperability agreement (contractual, legal and settlement issues) · Common Service Description (features and service levels) · Operational Agreement (interface specification)
The Options are:
· Tests and trials · Certification of service providers · MSAF demos, press releases
There is currently no work on:
· Marketing and selling
Brand name
The Interoperability issues being discussed are:
Authentication of the dial-in user across multiple service providers
· Security features such as IP tunneling and encryption
Maintaining the required service quality levels settlements between service providers
The Focus on companies is:
· Secure, high quality dial-in access to corporate networks · For business critical application · The work is based on ITU and IETF standards
The membership requirements for service providers are:
· Offer the service · Comply with CSD · Willing to interconnect · Assign resources
and for Technology providers they are:
· Provide portions of service
The Milestones are:
June CSDSept. Draft Interoperability Agreement Sept. Draft Operational AgreementDec. Test and Demo Dec. Approved deliverables
MSAF's global roaming study group is currently looking at the IETF for standards. They are interested in the following:
· Exchange results · Refer issues to each other · Service features · Business model · Reporting · Liaisons; participate in meetings
There was a general discussions regarding the usefulness (and not) of this Study Group. Mike O'Dell mentioned that it is permitted to discuss settlements, but not how businesses should run their business or perform the settlements.
All six drafts have been updated since the last meeting. The Implementations Draft is ready for last call; however, a service provider stated that he might be interested in adding his roaming implementation. The chair decided that there would be a 30-day waiting period in which service providers can send new text for the Implementations Draft, after which the Implementations Draft will be sent out for last call on the mailing list.
III. Presentation on Multimedia Roaming Application, Reha Civanlar, AT&T Labs
Mr. Reha initiated a Multimedia discussion about servers that can connect to a user's ISP in order to guarantee QOS. A client who contacts the server and requests that it initiates a direct connection with the user’s local ISP, which hopefully has high bandwidth on the local network, does this. Since the server cannot possibly have accounts with all ISPs in the world, this is a perfect application for roaming. Therefore, when the server dials into the ISP he is in fact a roaming client.
There are three components; the NoD Server, the ISP and the client. The interfaces are:
HTTP Server <-> NoD Server ISP telephone number determination Ask to establish a connection to the ISP NoD Server <-> ISP Roaming NoD Server <-> Client Connect/Disconnect Keep-alive Authentication
An implementation of this service is available at: http://www.perfectvideo.com/
The Roaming requirements are:
· How can a NoD server ask for QoS? · Determine the telephone numbers · Service attributes · RSVP · ?The Next Steps are:
· Test with interested roaming consortia · Formal definitions for the interfaces / protocols
This is followed by a general discussion about whether this is something that belongs in this working group. It appears as if it does since the NoD Server acts as the roaming user. We obviously do not want the NoD Server to have an account on each ISP across the world.
John Vollbrecht has a problem with the current proposal to have a single user name where the domain is looked up in the DNS. The proposal is to revive the "source route" which allows the full route of the authentication chain to be included in the name (i.e., John@Merit@MCI, where John's authentication would be sent to MCI, then to Merit).
John believes that supporting this would accelerate the deployment of roaming.
An example given is that an ISP could have blocks of free hours for roaming with certain ISPs and that they would like for the user to use this to their advantage. A source route would be the easiest way to implement this. Of course, the user has to know about how many hours MAY be used for free, and John states that he has user's that are sophisticated enough to know this.
There was a discussion on resource management and whether an intermediary Proxy can add resource management attributes such as session time in the access accept.
There was no clear consensus in the Working Group as to the merit of this idea.
Some objections were made in the IPSEC WG regarding multiple proxy chains for authentication.
Hierarchical authentication routing is needed for scalability with RADIUS proxying. Authentication routing demonstrates validity of roaming relationship path. Proxies only forward authentication if valid relationship path exists.
There is a problem with user passwords. This is mostly related to PAP since it is in the clear in all of the proxies in the chain. Maybe we should add to the specification that we SHOULD NOT use PAP for passwords in the clear. We will take it up on the list since there does not seem to have rough consensus.
There is also a problem with the lack of authentication of the Access-Request with CHAP. Therefore we SHOULD require the use of timestamp and signature attributes. The timestamp is a very new and possibly controversial attribute being proposed in the RADIUS Working Group. It is still too early to know if it will be adopted by the RADIUS Working Group.
The Authentication routing issues are Source Route versus the DNS scheme. With the Source Route, the packet MAY be modified along the way. The Digital signature would allow detection of this (possibly). Should a new attribute be created which records the route through each proxy? If each proxy in the chain were to add a signature attribute to the packet, would this be sufficient? We will take this up on the list.
The Non-repudiation of Access-Responses are very important for two reasons. One is to ensure that no one has modified the packet through the proxy chain and the other is to be able to prove that you were told that a user was authenticated.
John Vollbrecht does not agree that non-repudiation is very useful. We will take this up further in the mailing list.
VI. Distributed RADIUS Accounting
Hope to set context for discussion
Show example of what Merit does now
The Questions being asked are:
Is support for settlement procedures part of roamops? Is the proxying accounting protocol a good thing? If so, is RADIUS accounting satisfactory? Should accounting be on standards track, is it a should or a must?
It was noted that settlement is NOT part of the Working Group charter.
The proposal is that accounting records should be proxied all the way through the chain the same way that the authentication is done today. It was noted that this is problematic and that it would make sense to terminate the transaction at each hop, but to still send it all the way through the chain. There does not seem to be much support for the view remark.
There is a proposal which is to have the authenticating server add a class attribute to the access-accept, which would be used in the accounting record to match up and to ease reconciliation.
There is some demand to have the proxying of RADIUS accounting be a MUST in the document, but the chair feels that to have a document which calls for an informational protocol (RADIUS accounting, RFC2059) would hold up a document from going on the standards track. However, this document could be published as a BCP.
There is discussion that the idea of using RADIUS accounting and the proxying of it to do some form of resource management (i.e., restricting the number of sessions per user) should be part of the authentication protocol and not the accounting protocol. However the RADIUS WG does not deal with this since it believes that the RADIUS protocol is not a resource management protocol.
There are three vendors who believe that accounting and resource management are two different things. Accounting should be a standards track document and that resource management work is required.
VII. Accounting Record Formats
There is a presentation that shows a new format of Binary accounting record that has an AVP format, which is similar to the L2TP AVP format. This format has a max length of 8192, a vendor ID (vendor ID of 0 is IANA or RADIUS WG attributes) and a mandatory attribute.
This is essentially what is discussed in the accounting draft. This is very different from what John Vollbrecht is proposing.
The Accounting record proxying has the following benefits:
· Independent of accounting protocol · Provides non-repudiation, encryption in accounting transfer · Receipts provide robustness
The problem is that it is not well suited to support of real-time accounting capabilities, i.e., simultaneous login control.
There is a discussion on whether encryption is really necessary. Also there is objection to the use of non-repudiation since it does not provide anything to the service providers.
Simultaneous login control should NOT be considered to be part of the accounting protocol. There is rough consensus that Resource management is a separate issue from accounting and that the Working Group should attempt to address that issue as far as it addresses roaming.
It seems that non-repudiation and encryption are not useful. A rough consensus of the Working Group is to define the format of the data, but not discuss the transfer of the data.
It was noted that the Working Group can discuss the Proxy behavior of proxying the accounting data in pseudo-realtime.
There is a proposal that John Vollbrecht submit a new internet-draft to the Working Group which discussed an optional method of the NAI format (e.g., the
"source route" method). This will allow the current NAI document to move ahead.
There is no objection to pushing the current NAI draft to last call. An email will be sent to the mailing list.