Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/roamops/roamops-minutes-97apr.txt

Text File | 1997-05-29 | 13KB | 337 lines

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--