NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 07-Jun-99
Chair(s):
Glen Zorn <gwz@acm.org>
Pat Calhoun <pcalhoun@eng.sun.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Technical Advisor(s):
Michael O'Dell <mo@uu.net>
Mailing Lists:
General Discussion:roamops@tdmx.rutgers.edu
To Subscribe: roamops-request@tdmx.rutgers.edu
In Body: subscribe
Archive: ftp://ftp-no.rutgers.edu/misc/IETF/roamops
Description of Working Group:
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. Thus far, the group has produced an architectural document describing the basic mechanisms required to support user roaming, a description of several existing roaming implementations and defined a standard username syntax to support roaming. A repository for documentation describing current roaming implementations is also maintained.
In the future, the group will 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, authentication and authorization mechanisms and exploring in in depth the security issues involved with roaming. This work is expected to consist mainly of new or revised procedures and application-layer protocols, in addition to recommendations for the fulfillment of the Internet roaming requirements.
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, saag and cat) to identify issues to which the roamops group should attend, as well as to assure that their work does not make roaming unnecessarily difficult or impossible.
The utmost goal of the group will to make sure, by any means necessary, that it produces documents of high quality that are useful to the IETF community.
Goals and Milestones:
Done |
|
Re-submit existing Internet-Drafts as work of the ROAMOPS Working Group |
Done |
|
Review the charter for additional work required |
Done |
|
Submit the roaming implementations review draft for publication as an Informational RFC. |
Done |
|
Submit the roaming requirements and network authentication identifier drafts for publication as a Proposed Standard. |
Done |
|
Submit Internet-Drafts on phone book attributes and format. |
Aug 98 |
|
Submit the authentication draft for publication as a Proposed Standard. |
Aug 98 |
|
Submit the accounting draft for publication as a Proposed Standard. |
Sep 98 |
|
Submit a BCP on roaming requirements fulfillment |
Internet-Drafts:
· The Accounting Data Interchange Format (ADIF)
· Secure Radius Server Operation Guidelines for Dial Roaming
· An LDAP Schema for Phone Books
Request For Comments:
RFC |
Status |
Title |
RFC2194 |
Review of Roaming Implementations | |
RFC2477 |
Criteria for Evaluating Roaming Protocols | |
RFC2486 |
PS |
The Network Access Identifier |
RFC2607 |
Proxy Chaining and Policy Implementation in Roaming | |
Roamops IETF Meeting
1. Agenda
- Agenda Bashing
- Document Status
- XML Phone Book
- Limiting Fraud in Roaming
- Charter Revision
2. Document Status
- draft-ietf-roamops-auth-10.txt in is the RFC Editor's queue
- The XML Phone Book is still in draft
- What do we want to do with the ADIF draft?
- Certificate Based Roaming - to be discussed
Pat Calhoun will send a list of expired drafts to Randy Bush and Internet-Drafts.
3. XML Phone Books (Max Riegel) Rev 02
The draft is draft-ietf-roamops-phonebook-xml-01.txt. The new draft includes the changes that were requested at the last IETF meeting.
- Element Definition for 'Phone Book' and POP
- Arrangement of element definitions and descriptions
- Additional format for 'providerIcon' (JPEG and GIF)
- XML Phonebook is a single file (no external references)
- Typing by notification for:
- Fully qualified domain name
- IP address
- Picture format (base 64 encoded JPEG/GIF)
- All other elements are pure '#PCDATA'
- Updated 'Complete XML DTD'
- Some security considerations added. There is a new W3C working group working on this, and we hope to use their output in a next version of our security consideration section.
- Some new values for 'modemProtocols' and 'isdnProtocols'
- Several editorial changes
The existing XML phone book entry makes use of cryptic bit masks for values. A proposal would be to change the document to make use of more readable labels (e.g. V90, ISDN, etc). There seems to be a preference for the latter, but since the xml phone book is not intended to be read by humans, it is not clear that it is useful to change the draft. We need to consider which one we would like to use.
- Refinement of number of occurrences of elements
- 'Attribute' declaration (e.g.)
Position Property
---------- -----------------------------
0x0001 Multilink
0x0002 Mobile-IP
0x0004 Multicast Reception
0x0008 Multicast Transmission
Issue: The IANA does register strings, but not XML attributes. How would the phonebook be extended in the future? This will be taken to the list.
Issue: Do we need strong typing for telephone numbers? Some definition of how a telephone number should look like, and how it means could be included. We could define the global reachable telephone number. We need to take this to the list. One recommendation is to define the telephone number to be in the format of <country> <blank> <area/city> <blank> <telephone number>. We will take this to the list.
Issues: The W3C is working on a first proposal for an XML schema. This is still early in the process. We would have to wait until the end of this year before a schema is ready for us to use. There are currently no tools available to create schemas, and none are planned by the end of the year. Therefore, we propose using the DTD.
4. Limiting Fraud in Roaming (Glen and Pat)
In the requirements RFC, it mentions that we should be able to limit, detect or eliminate the risk of fraud. The RADIUS protocol is not able to meet this requirement, so a new protocol by Glen and Pat was submitted after the last IETF.
The issue is that the RADIUS server, in a roaming environment, cannot send an unsolicited message. The draft, draft-ietf-roamops-fraud-limit-00.txt, talks about a way that an ISP, or home provider, can control the risk of fraud they are willing to accept, at the cost of CPU and bandwidth. This is done by enforcing that authentication is done between the PPP user, and the home DIAMETER Server. The DIAMETER Server generates the challenge, and validates the challenge when the response is received. The DIAMETER server also generates a signed token that includes the username, session-ids, timestamp, etc. This token must be present in the accounting messages. The DIAMETER server also returns a session lifetime in the reply.
The home DIAMETER Server initiates an authentication to the user before the session expires. A successful authentication creates a new signed object, which can be used in the Interim Accounting requests.
If a broker is present, it can either proxy the request to the home DIAMETER server, or return a referral messages back to the proxy DIAMETER server. The broker acts as a CA, issuing certificates to all roaming partners. This allows the roaming partners to sign their accounting messages, which is used for end-to-end security.
The proposal does not support fraud if accounting is based on traffic. There appears to be quite a bit of interest in the Working Group, we need to take this to the list as well.
5. Charter Revision
The Working Group has rough consensus that we will NOT wait for the AAA to finish, but will fulfill our own requirements by creating or adopting a protocol. Once a generic protocol is completed, and is useful to ROAMOPS, we will look into it.
The Working Group will move the ADIF draft to last call in 2 months.
We will talk about the certificate based roaming draft on the list.
We will add a work item to define a new protocol for roaming authentication, authorization and accounting. The Working Group had consensus that protocol developed will be DIAMETER base and extensions necessary to fulfill ROAMOPS requirements.
Pat Calhoun and Ken Peirce will develop the BCP to compare COPS and DIAMETER against the roaming protocol requirements.
None received.