|
Extended Incident Handling (INCH) WG Minutes
Interim Meeting Sunday, 12:00 - 16:00, June 13, 2004 Budapest, Hungary Chair: Roman Danyliw <rdd@cert.org> Security Area Adviser: Steven Bellovin <smb@research.att.com> ---[ Agenda ]----------------------------------------------------------- 12:00 - 13:30 SESSION 1 o Agenda Bashing; WG Background; WG Issues (http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-agenda.pdf) o Requirements o Real-time Inter-network Defense (RID) (http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-rid.pdf) o Data Model (http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-dm.pdf) 13:30 - 14:00 Coffee Break 14:00 - 15:30 SESSION 2 o Data Model (continued) o Related Work - Vulnerabilities and Exploits Description Exchange Format (VEDEF) (http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-vedef.pdf) - IODEF experience in JPCERT/CC (http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-jpcert.pdf) ---[ Administrative ]--------------------------------------------------- presentation: <http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-agenda.pdf> Roman Danyliw presented a summary of the INCH working group. o Updates to the schedule were made to reflect a slight slippage in the delivery dates (WG last-call) of the WG drafts. ] done Initial I-D of the implementation guidelines document ] AUG 04 Submit requirements I-D to the IESG as Informational o The I-D editor has a list of the remaining concerns with the draft ] SEP 04 Submit incident data language specification I-D to the IESG as Proposed Standard ] SEP 04 Submit distributed denial of service extension specification I-D to the IESG as Proposed Standard ] OCT 04 Submit implementation guidelines I-D to the IESG as Informational o Blocking on the finalization of the IODEF Comments and Discussion: Q: What method will there be to extend IODEF after INCH has ceased to exist? A: Extending the IODEF can occur in a number of ways: o updating IANA registered enumerated types o independent draft submitted to the IETF o ad hoc standardization in the closed community using the IODEF ---[ Requirements ]----------------------------------------------------- document: draft-ietf-inch-requirements-03 A few issues remain with the requirements draft: <http://listserv.surfnet.nl/scripts/wa.exe?A2=ind04&L=inch&O=D&P=11122> ---[ Data Model ]------------------------------------------------------- document: draft-ietf-inch-iodef-02 presentation: <http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-dm.pdf> Roman Danyliw presented a review of the open issues related to the current data model. Comments and Discussion: (Note: Comments are organized according to the specific issue to which they relate) #472 Data model is too complex <https://rt.psg.com/Ticket/Display.html?id=372> o Widespread agreement that there was too much complexity, and simplicity is desirable o The following feedback was provided for the proposed simplifications: - OK to remove the following: - Layer 7 (application) protocols fields - Running process information at end-points - Filesystem information at end-points (e.g., inodes) - Explicit netmask of an IP address (deal in CIDR blocks, IPs) - Keep the following information - Layer-2 and non-IP Layer-3 address information #360 Supporting flow information <https://rt.psg.com/Ticket/Display.html?id=360> o Widespread agreement that there was a desire for this functionality o Concern not to over-engineer the representation. Feedback was to only include approaches currently envisioned now. #356 Standardizing the extension classes <https://rt.psg.com/Ticket/Display.html?id=356> o Wait on schema migration to resolve the issue #357 Assigning IncidentIDs <https://rt.psg.com/Ticket/Display.html?id=357> o Use policy to solve the problem #359 Supporting AS Numbers <https://rt.psg.com/Ticket/Display.html?id=359> o Wait on "simplification" of the data model to make this change #362 Unifying the type attribute of the extension classes <https://rt.psg.com/Ticket/Display.html?id=362> o If these are semantically different, then the attributes should be different. #363 Naming timezones in the time classes <https://rt.psg.com/Ticket/Display.html?id=363> o UTC is sufficient. IODEF is not meant for human-consumptions. Technology can easily transform UTC into a more human readable format. ---[ RID draft ]-------------------------------------------------------- document: draft-ietf-inch-rid-00 presentation: <http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-rid.pdf> Kathleen Moriarty presented (through a recorded presentation and email) on the current status of the RID protocol. Comments and Discussion: Q: Are there any restrictions on what is defined as a consortium? Is there only one? A: There would be multiple consortiums. They might be formed based on location or type of network. Internet2 may be a good example since they already have a PKI based on a federation model and the trust relationships have been formed. The consortium would be used to set up policy and use guidelines as well as provide trust relationships between NPs in the same consortium as well as NPs in different consortiums by the relationships established between various consortiums. Q: Is RID targeted at devices? Humans? Talk about what will be done when crossing ISP boundaries? A: No, RID is more a communication system to transport security incident handling messages and then to coordinate that with various components of the network (IDS for detection, traceback across a network, and devices for mitigating the effects of an attack). A network that initiates the trace or relay request and sends this to the next upstream NP in the path of the trace (determined either from a trace across the network or from routing if the address was not spoofed). The NP receiving the request can decide if they will continue the trace or take action on the relay request based on the trust relationship and rules of the consortium or region, the current resource status on their network, and other factors included in the draft. The response can be automated or if certain conditions (determined by the NP) are reached, they may want to involve a human for the approval of a trace continuance. Another reference for this question would be the draft itself or slides from previous meetings that contained a more detailed introduction to the work rather than a status update. Q: What kind of policy needs to exist to support RID? A: An agreed upon use and abuse guideline policy must exist so that NPs will continue each other's traces. The trust relationships are also important so that these issues can be worked out and agreed upon within a consortium which may give the trace more 'weight' than if it were to just come from one NP to another. The policy extension will include information on the type of trace being requested as well and the policy would describe what would be acceptable traces to continue within a consortium or when requesting a trace into a neighboring consortium. The security section of the draft outlines the concerns of the protocol and why the policy is important. ---[ New Work ]---------------------------------------------------------- presentation: <http://www.cert.org/ietf/inch/interim04/ietf-interim2004-inch-vedef.pdf> Ian Bryant presented on the Vulnerabilities and Exploits Description Exchange Format (VEDEF). This presentation suggested interest in standardizing vulnerability collaboration in the WG. Additional discussion of this area is required in the INCH community. It will represent new work, and require re-chartering. ---[ Implementation Experience ]----------------------------------------- Three implementation were discussed: - <http://www.cert.org/ietf/inch/ietf59/ietf59-inch-rid-implementation.pdf> by Yozo Toda - KrCERT/CC by Arnold Yoon - ecsirt.net by Klaus-Peter Kossakowski |