Editor's Note: These minutes have not been edited. 38th IETF, Memphis Roaming Operations Minutes Reported By: Pat Calhoun Wednesday April 9, 1997 1. Multimedia Services Affiliate Forum, Toon Vrins, AT&T MSAF Outline MSAF Global Intranet Access Committee MSAF - IETF relation A. Outline 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 members networks and services. It's 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 March of 1997. MSAF is interested in having a liaison with the IETF's roamops WG. The methods of liaisons are to exchange papers and to seek participation at meetings. There are 3 to 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. 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:which 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: - customer pricing - 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 - assign resources - support open standards The Milestones are: - June CSD - Sept Draft Interoperability Agreement - Sept Draft Operational Agreement - Dec 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. 2. Document Status All 6 drafts have been updated since the last meeting. The implementations draft is ready for last call, however a service provider stated that he may be interested in adding his roaming implementation. The chair decided that there will be a 30 day waiting period where 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. 3. Presentation on Multimedia Roaming Application, Reha Civanlar, AT&T Labs Mr. Reha initiated a Multimedia discussion about servers which can connect to a user's ISP in order to guarantee QOS. This is done by a client which 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. 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 discussions about whether this is something that even 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. 4. NAI Issues 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 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 the how many hours MAY be used for free, and John states that he has user's which 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 seems to be about the same number of people who are for and against this idea. Instead of the above paragraph, how about "There was no clear consensus in the WG as to the merit of this idea."? Thursday April 10, 1997 5. Authentication Issues 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 WG. It is still too early to know if it will be adopted by the RADIUS WG. The Authentication routing issues are Source route vs. 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. 6. Distributed RADIUS accounting Accounting and Reconciliation - 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 WG 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 (ie. 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. 7. Accounting Record Formats There is a presentation which shows a new format of Binary accounting record which 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. 8. Accounting Issues 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 WG is to define the format of the data, but not discuss the transfer of the data. It was noted that the WG can discuss the Proxy behavior of proxying the accounting data in pseudo-realtime. 9. Closing Discussion There is a proposal that John Vollbrecht submit a new internet-draft to the WG 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. A mail will be sent to the mailing list. End of meeting. --IMA.Boundary.960213168--