Wednesday Afternoon Session II 15:50-17:20 - Karlin III Chairing: Alexey Melnikov and Takeshi Takahashi Note taker: Roman Danyliw and Chris Inacio Jabber scribe: Chris Inacio Number of Attendees: around 30 -------------------------------- Administrivia -------------------------------- https://www.ietf.org/proceedings/93/slides/slides-93-mile-0.pdf 1. Status update was shared - RFC5070-bis (Roman) : we will have the WGLC very soon. - the implementation draft (Daisuke): it will be finalized just after the RFC5070-bis is finalized (around the Yokohama meeting) - ROLIE draft (John): some PoC implementation work is going on, so we will wait for the feedback and then go for the WGLC. - Guideline draft (Panos): Mio Suzuki, the editor of the darknet draft, volunteered to work with Panos to finalize the work -------------------------------- 5070-bis -------------------------------- https://www.ietf.org/proceedings/93/slides/slides-93-mile-3.pdf 1. The changes made after the IETF 92 meeting was summarized. - regarding the issue #48 (identifying private extensions), the author mentioned the drawback (= we can allow only one private extension for this field) - the author checked whether any objection exists on this issue; no objection raised. 2. Issue #54: reformat the schema; how to list the enum values was discussed - Available options are listing them in a single xml, in a separate xml, or in IANA table - listing in a single xml (at the top of the xml) seems to be preferred - the author will ask opinions on this to the IANA people as well 3. Issue #46: cause of the incident; we preferred the use of SCI extension and existing classes along with adding a new free-form field. 4. Issue #38: improved examples; we preferred to have more variety of examples - we do not have any restriction to have many more examples in the draft - we could also make use of the guidance draft - assorted types of use cases are wanted; minimal IODEF document, simple list of indicators, and incident reports - the use of IODEF for darknet monitoring case will be also added to the guidance draft - "There are IODEF examples in the implementation guide which could be used in the core spec. I'll share some information later on the mailing list."(Kathleen) 5. Issue #39: RelatedDNS; how to represent the RelatedDNS was one major remaining issue. - The rough idea on how to deal with this issue was to prioritize the reuse of the existing work (an experimental draft).(Alexey, Kathleen, Nik) - We could have another author who could further develop the experimental draft if the original author is too busy to do that. 6. Other discussion: Q: (Take) What will happen with the phishing extension as it is not 5070bis compliant A: (Roman) We need to take a look where it is incompatible, but 5070bis does not necessarily cover everything. 7. The WGLC on this draft will be started soon, before the next meeting. -------------------------------- Implementreport draft -------------------------------- https://www.ietf.org/proceedings/93/slides/slides-93-mile-1.pdf The editor shared the tools on IODEF that were added to the draft after the IETF 92 meeting. The progress was acknowledged. -------------------------------- FLEX -------------------------------- https://www.ietf.org/proceedings/93/slides/slides-93-mile-2.PDF The flow-based event information exchange work was presented. The audience acknowledge the usefulness of the work, and the relevance to the IETF works. The editors will consider where to fit the work within IETF by discussing with assorted WGs, such as DOTS and MILE. Active discussion took place, as below. Q: (Frank Xialiang) What Netflow needs to be shared to detect an attack? A: That decision is out of scope for my work Q: (Alexey) Why use ASN.1? A: The x-xarf community uses it and I was attempting to build on it. Q: (Nik Teague) Is your approach designed for real-time detection? A: From simulations in which it has been run, it worked. Q: (Nik Teague) Have you identified any challenges with using S/MIME? A: Not yet. Q: (Nik Teague) Could you clarify your expectation for collaboration? A: This work is intended to inform another party about something suspicious that was observed.