Agenda - Agenda Bashing - Document Status - ADIF - Proxy Chaining and Policy - Phone Book Schema - End-to-End Security - Phone Book Update Protocol - Proxy Service Types - Roaming and IP Telephony Agenda Bashing: No new agenda items. Doc Status: 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. ADIF: ---- 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 useful feature. 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 accounting requirements. 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 instances. 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.