NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Glen Zorn <email@example.com>
Pat Calhoun <firstname.lastname@example.org>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <email@example.com>
Operations and Management Area Advisor:
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Michael O'Dell <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: include
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. In the near term, the goals of the group will be to produce an architectural document describing the basic mechanisms required to support user roaming. A repository for documentation describing current roaming implementations will also be maintained.
In addition, 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, 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 saag and cat) to identify issuesto which the roamops group should attend, as well as to assure 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:
Re-submit existing Internet-Drafts as work of the ROAMOPS Working Group
Submit Internet-Drafts to IESG for publication as RFCs
Review the charter for additional work required
Submit the roaming implementations review draft for publication as an Informational RFC.
Submit the roaming requirements and network authentication identifier drafts for publication as a Proposed Standard.
Submit Internet-Drafts on phone book attributes and format.
Submit the authentication draft for publication as a Proposed Standard.
Submit the accounting draft for publication as a Proposed Standard.
Request For Comments:
Review of Roaming Implementations
- Agenda Bashing
- Document Status
- Proxy Chaining and Policy
- Phone Book Schema
- End-to-End Security
- Phone Book Update Protocol
- Proxy Service Types
- Roaming and IP Telephony
No new agenda items.
Two documents are currently in last call:
- Roaming Requirements is in last call as an Informational RFC
- Network Access Identifier is in last call as a standards track RFC.
A comment made by Harald, the operations Area Director, was that the NAI draft
needed to specify that NAIs are unique, and how their uniqueness was guaranteed. The
Area Director also objected to the fact that the current thought behind the domain portion
of the NAI was in fact a domain name.
There are several other documents in progress.
Unfortunately, the author was not able to attend the IETF to discuss the draft.
The protocol attempts to create a standard way of defining accounting information,
independent of the transport. There was not rough consensus on whether this was a
A comment was made that this could be a good short-term solution. But another comment
was to wait and see the result of the AAA BOF on the Friday morning, which could address
Given that RADIUS accounting is an informational RFC, it was questioned whether
ROAMOPS should condone the use of the protocol. There were some objections that no
additional work should be done with RADIUS.
Currently, SNMP is the standard IETF accounting protocol, but experience has shown
that its use is very difficult in large networks. It is clear that a better standards-based
accounting protocol is necessary.
One interpretation of the draft was that the tags seem to be similar to attribute numbers.
So much so that the tags re-used RADIUS attribute numbers, which seemed to imply that
it did not provide transport independence. Glen commented that the reason for this was
simply that RADIUS accounting already existed, making it convenient to re-use the
same attribute numbers.
Someone noted that the draft did not specify a method of defining Vendor Specific
information. However, it could be done using the sub-attribute encoding scheme defined
in the draft.
Rough consensus was reached to wait until after the AAA BOF prior to taking any further
action on this matter. If the AAA BOF was interested in designing a standards-based
accounting protocol, the ADIF could become unnecessary.
Proxy Chaining and Policy:
John Vollbrecht presented the draft on proxy chaining and policy. Someone noted that the
draft seems to contradict itself since it implies that accounting proxies are long lived and
perform retransmission. This is not necessarily true since in most of today's implementations
the NAS (the originator of the accounting packet) is the system that performs the
retransmissions, not the proxies.
Someone noted that there is also a third method that exists, which is a combination of the
two schemes defined in the draft. In this third method, if an ACK was returned to the host,
the proxy server would then be responsible for the retransmission of the packet. This would
push the responsibility of ensuring the accounting packets were delivered to the proxy
server instead having to maintain them in the embedded NAS. Rough consensus was
reached that this latter scheme, which would be optional, was preferable.
A few people commented that changes to the RADIUS protocol were not appropriate within
the ROAMOPS WG, and should be taken to the RADIUS WG, or whoever is currently
carrying the RADIUS baton. The Area Director's response was that the IETF was in the
business of producing standards, not in running working groups. The AD noted that it
was perfectly reasonable for any RADIUS work to either be submitted as a ROAMOPS
work group item, or as an individual contribution.
An additional question was raised as to the proper procedure of requesting RADIUS
attribute numbers. The response was that it should not be done through the RADIUS
WG chair, but through the IANA which is the official numbering authority.
There was rough consensus that the ROAMOPS WG would take this work under its
wing and submit it on the standards track on September 30, 1998. However a comment
was made that since RADIUS is known to have many problems, would it not be desirable
to push it simply as a BCP. Rough consensus was not reached on this issue.
Phone Book Schema:
The author was looking for comments on the draft since very few had been received.
Someone stated that a comment that had not yet made it in the latest version was that
V.Fast needed to be changed to V.90. This will be added to the next release of the draft.
It was also noted that the Phone Book schema was not a phone book update protocol,
simply a schema.
A question was raised on whether this document was of interest to the WG. Some stated
that it was of interest, but possibly ahead of its time given that there are many other items
of higher importance to solve.
Glen stated that Microsoft's Directory is currently implementing the schema, which is
why Glen was hoping to receive more comments and be able to move the document ahead.
Rough consensus was barely reached that the schema was required as part of the WG items.
The Area Director noted that he had sent a request to some LDAP experts to take a look
at the draft. Once feedback is received from the experts, the document will be updated
and sent out for last call.
End to End Security:
Pat Calhoun presented the end-to-end security within RADIUS draft. Although many
people did think that the functionality was necessary, rough consensus was not reached
that the ROAMOPS WG should be adding this to the RADIUS protocol.
Many people openly stated that adding more functionality to RADIUS was not desirable,
and this feature should be added to a new protocol.
Phone Book Update Protocol:
Although the Phone Book Update Protocol does show up as a requirement in the roaming
requirements draft, there are currently no protocols proposed to solve this problem.
If the Working Group could agree that the phone book attributes should be in an LDAP
format, it would seem logical to dump them in a directory (or possibly a relational
database). The file could then be retrieved using HTTP.
A point was made about the security requirements of such a protocol. It would seem
necessary to secure the individual phone entries and not just the HTTP transfer. This
would be necessary because the information itself must be authenticated. One method
of doing this would be for each phone entry (or perhaps the whole file) to be signed by
the service provider. It seems that confidentiality may also be a requirement in some
Another possibility would be to make use of the Service Location Protocol Version 2,
which includes security. This is an area to be investigated.
John Vollbrecht and Mark Beadles volunteered to prepare a set of requirements for a
Phone Book exchange protocol. The LDAP synchronization BOF, which deals with
replication and duplication, at the Chicago IETF seemed to be a good place to start.
Proxy Service Types:
John Vollbrecht provided a presentation on what a proxy server is, and what it means
to various people.
In a scenario called "simple domains" there is a helper between a provider and an end-
server. The provider must know how to find an appropriate end-server (normally through
the use of the NAI). Another variation on this theme is where a NAS and a helper is
combined with various databases that can be access for various services (i.e. authentication,
accounting, etc.), and contact the end-server directly.
There is also the "full mesh" simple scenario, where each provide has a relationship with
all providers (N*2).
The "proxy forwarder" scenario is where a proxy is used to forward requests and replies.
It must be noted that it is also possible for proxies to convert some attributes (determined
by local policy). In this case there exists a relationship between the provider and the end-
user's organization (either a provider or corporate network).
The "brokered roaming" scenario is where a broker is responsible for the "business"
relationships between providers and corporate networks. This reduces the full mesh
complication raised earlier. A broker can also change attributes, and in certain cases can
even used different protocols on either side of the broker (i.e. in RADIUS, out TACACS+).
Rough consensus was reached that this information, although known to most, has never
been written down and should appear in an informational RFC. John Vollbrecht agreed
to document it.
Roaming and IP Telephony
Pat Calhoun contacted Jonathan Rosenberg, Chair of the IPTel WG, to find out if
IPTel was interested in solving the roaming IP Telephony problem. Jonathan
indicated that it was not part of the WG's charter, and probably never would be.
The question raised was whether the ROAMOPS WG thought it would be interested
in attempting to solve the roaming problem for IP Telephony. Rough consensus was
not reached, but many people believed that we should reconsider once we are done
with our more pressing issues.
go to list