CURRENT_MEETING_REPORT_ Reported by Cyndi Mills/BBN ACCT Minutes Agenda Review and Revise: Document o Internet Accounting Background Editor: Don Hirsh, hirsh@meridiantc.com o Internet Accounting Architecture Editor: Cyndi Mills, cmills@bbn.com o Internet Accounting Meter Services Editor: Mark Seger, seger@asds.enet.dec.com o Internet Accounting Collection Protocols Editor: Martin Dubetz, dubetz@wugate.wustl.edu Action Items: Changes during review and revision: 1. Distinguish between Internet (long-distance) and local-area accounting. Internet accounting does not use attributes or user-ids (this reduces overhead). Local area accounting may use attributes and user ids (these may be defined later). The same accounting record formats are used for both Internet and local area accounting, although different profiles define which fields are mandatory, optional, and prohibited for each type. 2. Refined ENTITY definition to be: oEnd-system network addresses. oIntermediate system network addresses. oAllow for different address types (IP address, NSAP address, etc.) oAll addresses are now absolute (no longer relative to meter loc). What about dynamically allocated network addresses (transients)? 1 At least the service provider must be identified, if not the individual host. Could service provider allocate IP address as unique subscriber identifier independent of transient address? Added a comment or unique id field which may be appended to the entity for use as an additional identifier. Local area accounting only, please. We need a mechanism to map transients tounique ids, but don't want to get involved in defining a directory service with real time propagation problems. Maybe we should simply provide an appropriate field for use in the accounting record without specifiying how mapping is obtained. This discussion should be continued on the mailing list. 3. VALUES - Counters don't reset to zero on reporting, so we are consistent with SNMP. Need to make sure this can work without too much additional memory from router. Don't want to copy too often or maintain multiple ``snapshots'' of accounting tables in routers. 4. In background document, need to explain: oMulticasting is collected as an address. No special consideration. Dropped packets are tough luck - they may be counted and we can't distinguish retransmits at the IP level. Treat as performance problem, not accounting problem. Network management should use other measures for dropped packets and guaranteed levels of service, etc. oExplain hierarchical collection better. Each network generally accounts for its immediate subscribers, which may be end-systems (hosts) or other networks (routers or broadcast media with a network number). Explain importance of recommending collection at internet entry and exit points (rather than at all routers) to minimize accounting overhead. oMake it even clearer that this group isn't recommending billing approaches. How administrations bill (flat fee, cap, minimum, guaranteed delivery rates, penalties) is far beyond the scope of what we're trying to accomplish - we're just looking for a reliable way to report on network-layer network usage! (express goals/non-goals more emphatically) 5. Distributed rewrites/comments/updates of Architecture, Meter Services, and Collection documents. 6. Collecton protocol discussion. Need help on deciding whether SNMP will be adequate - performance issues may be key. Certainly SNMP authentication is an issue. However, SNMP is the management protocol of choice, and is most widespread. 7. List of questions for Security Area, particularly regarding SNMP. Need help from Security Area. oPerformance of authenticated SNMP? Single-stream/multi-stream? oAuthentication: do we need to add signatures for our meter ids? Will SNMP ``just take care of this''? 2 oAuthorization: how do we tell our routers which management stations (plural) are authorized to collect information. (Access control). I suppose someone will have to think about who can get the information from the collection point. How do we resolve this in light of having one ``control'' station and multiple ``monitoring'' stations for each router. How do we transfer title to ``control'' station when the original control station crashes, gets isolated, etc. Does SNMP do access control? ACLs (access control lists)? oConfidentiality: We need encryption for sensitive traffic flow information. Will SNMP do this for us, and key management too? oIntegrity: Even if we don't need encrypted data, how about encrypted checksums? What will SNMP do for us here? oDenial of Service. What do we need to worry about here? oExport controls. Do we need to define multiple variants of encryption? Can we do this and still meet performance and other goals? oGoverment security requirements. How to ensure that this will meet both commerical and government requirements? Currrent Action Items: 1. Enlist security help. 2. Enumerate COLLECTION ISSUES (revisited) and post to list. 3. Explain how SNMP might work and ramifications. 4. Finish Updating Architecture document, distribute to list. 5. Revise Meter definition document and distribute to Working Group list. 6. Revise Background document and distribute to list. 7. Write MIB (add to Meter Services). 8. Estimate number of concurrent flows on backbone, e.g., NSFnet HTM. 9. Submit outrageous statements to email list if it's quiet for too long to provoke resumption of appropriate discussion. Overall Timetable: o Update current document set for storage in IETF-DRAFT ASAP. o Meet in January/February to expedite MIB definition. o Discuss collection issues on mailing list - after some discussion submit synopsis to ietf mailing list to solicit help from a wider audience. 3 Attendees Robert Collet /PN=ROBERT.D.COLLET/O=US.SPRINT/ADMD=TELEMAIL/C=US/@sprint.com Robert Cooney cooney@wnyose.nardac-dc.navy.mil Fred Engel Mike Erlinger mike@mti.com Brian Handspicker bd@vines.enet.dec.com Don Hirsh hirsh@meridian.uucp Ken Jones uunet!konkord!ksj William Kutz Kutz@dockmaster.ncsc.mil Cyndi Mills cmills@bbn.com Chris Myers chris@wugate.wustl.edu Fred Ostapik fred@nisc.sri.com Bill Rust wjr@ftp.com Mark Seger seger@asds.enet.dec.com Michael St. Johns stjohns@umd5.umd.edu Jesse Walker walker@eider.enet@decpa.dec.com Kathy Wilde wilde@decvax.dec.com David Wood dcmwood@spot.colorado.edu Lixia Zhang lixia@parc.xerox.com 4