Incident Handling (INCH) WG Minutes IETF55 - Thursday 13.00-15.00 November 21, 2002, Atlanta Chair: Roman Danyliw ---[ Agenda ]----------------------------------------------------------- o Administrative (Roman Danyliw) o Data model requirements (Glenn Mansfield Keeni, Yuri Demchenko) - draft-glenn-inch-req-00 - draft-ietf-inch-iodef-rfc3067bis-requirements o Data Model (Jan Meijer) - draft-ietf-inch-iodef-00 o eCSIRT (Arne Helme) o Implementation experience with IODEF at the CERT/CC (Roman Danyliw) ---[ Administrative ]--------------------------------------------------- presenter: Roman Danyliw The meeting in Atlanta for IETF 55 was the first meeting since INCH was officially designated a working group (in August 2002). The status of the deliverables is as follows: o There are two drafts for the INCH data model requirements document. This said, there is quite a bit of similarity between these drafts since both are loosely based on RFC3067. - draft-glenn-inch-req-00 - draft-ietf-inch-iodef-rfc3067bis-requirements-00 The intent of the authors is to have a single draft by December 2002, and a WG last call no later than IETF 57 o The data model has been undergoing rapid change, and is intended to for a WG last call by IETF 57. o There has been little interest in the Implementation guide since the data model needed quite a few refinements. The target date for an initial draft is March 2003. ---[ Data Model ]------------------------------------------------------- presenter: Jan Meijer URL: http://www.andrew.cmu.edu/~rdanyliw/inch/ietf55/ietf55-inch-datamodel.ps Meijer presented a review of the open issues related to the current data model (draft-ietf-inch-iodef-00). Also presented was a radical redesign using recursive classes to solve may of these open issues. This proposed redesign will be further documented and sent to the list. Questions and Comments: o Based on the newly proposed data model, several issues were discussed: o The relative importance between simplicity of presentation (i.e., human readability) and the redundancy of data (e.g., duplicate contact information). o There were several concerns with the current implementation of the data model: o Demchenko volunteered to investigate using XML Schema instead of the current DTD implemented. o Based on complaints that it was very cumbersome to extract DTDs from the I-D, Meijer promised to maintain a separate DTD document for implementors as changes are made. o Concerns were voiced about the inconsistency of the current representation of contact information; too many classes to represent the same information. The proposed changes to the data model offer some solutions. o Some general questions about IODEF completeness were raised: o The need for representing routing information between the attacker and victim was brought up. The feeling of the group was that this information was important, but would not be standardized by the data model and would be relegated to the AdditionalData or Record classes. However, traceback information in the more general sense, that might enable a CSIRT to take IODEF documents from many constituencies to form a larger incident should be explicitly supported. o Inquires were made as to whether it was possible to associate contact information with an IP-address/host. The current data model supports this functionality. ---[ Requirements ]----------------------------------------------------- presenter: Glenn Mansfield Keeni and Yuri Demchenko URL: http://www.andrew.cmu.edu/~rdanyliw/inch/ietf55/ietf55-inch-requirements.ppt There were two RFC3067-based I-Ds submitted as the INCH requirements document. Keeni presented on draft-glenn-inch-req-00, and Demchenko spoke about draft-ietf-inch-iodef-rfc3067bis-requirements. The latter more strictly adheres to the original RFC3067, while the former is a bit more of a high level document. The authors (Keeni and Demchenko) have agreed to collaborate to form a single documents; any controversy found while merging to these drafts will be itemized for discussion on the list. Questions and Comments o glenn-inch-req-00 posits the need for ACLs on the document, and this spurred some debate as to the place of IODEF in the incident handling process. In the end, there was agreement that IODEF is essentially an exchange format. While it should provide mechanisms to indicate how the data will be used, this is the highest level of assurance that can be promised o Concern was raised about the use of the acronym IR in the document; in this case it was meant to be incident report. However, the term's pervasive use to also mean incident response seemed confusing. The term "IR" will be renamed in the future draft. o There was some discussion about the assumed mode of operation for a system using IODEF. Should it be push or pull? There was no agreement on this topic. ---[ Implementation: eCSIRT ]------------------------------------------- presenter: Arne Helme URL: http://www.andrew.cmu.edu/~rdanyliw/inch/ietf55/ietf55-inch-ecsirt.pdf Arne Helme gave a presentation on the eCSIRT project, a European-wide early warning system for security events, outlining how they plan on using the IODEF. ---[ Implementation: CERT/CC ]------------------------------------------ presenter: Roman Danyliw URL: http://www.andrew.cmu.edu/~rdanyliw/inch/ietf55/ietf55-inch-implementing-iodef.pdf Roman Danyliw gave a presentation on the implementation experiences of CERT/CC with IODEF for its incident reports.