Many thanks to Take Takehashi, Kazuya Okada, and Paul Hoffman for taking notes and preparing minutes! ======================================================================= Mile meeting minutes ======================================================================= Meeting time: 15:00 UTC on Tuesday 30 July. Agenda: ======================================================================= I. Welcome and Administrivia ------ --------------------------------------------------------------- 17:00 Welcome, Status, and Agenda Bash 10m Chairs (K. Moriarty, B. Trammell) II. Current Working Group Drafts ------ --------------------------------------------------------------- 17:10 draft-ietf-mile-sci-08 (WGLC complete 27 July) 10m T. Takehashi 17:20 draft-ietf-mile-rfc5070-bis-00 20m R. Danyliw 17:40 draft-ietf-mile-enum-reference-format-00 10m A. Montville 17:50 draft-ietf-mile-iodef-guidance-01 20m K. Moriarty for P. Kampanakis III. Additional Topics ------ --------------------------------------------------------------- 18:10 Any other business 20m ----------------------------------------------------------------------- Welcome, Status, and Agenda Bash, by Brian Trammell ----------------------------------------------------------------------- New improved note well was explained. Agenda bashing was done. Status of MILE activities are explained here. Kathleen Moriarty: who is interested in implementing rolie draft? (some has raised hands, but not many) Kathleen: We have folks interested in that. We will keep this going a little longer, but we need comments on the draft, even if everything is perfect. We need to see implementations to move forward. Sean Turner: If a draft does not be changed for 6 months, just times out. ----------------------------------------------------------------------- draft-ietf-mile-sci-08 (WGLC complete 27 July), by Takeshi. Takahashi ----------------------------------------------------------------------- Changes after the previous meeting was explained. Take: reflect comments received from Eric in the mailing list. Brian: we had more than enough discussion on it, and the working group last call was done, at this point we were waiting for the write up, which is my job. I will get it that probably next week. Then we will go ahead and send that to the IESG. ----------------------------------------------------------------------- draft-ietf-mile-rfc5070-bis-00, by Roman Danyliw ----------------------------------------------------------------------- (regarding page 2) Roman: I'm standing alone since Paul Stoecker has dropped off. The draft has not been formally updated since the cutoff was missed since the document went from individual submission to working group document. So we are still talking about -00. I'm trying hard to track the discussion of all the open issues in one place. We have the list of issues. Eric Burger: If we put something in here, make sure to send note out. Roman: Absolutely, please use mailing list. Roman: The -01 draft has added couple of things, as described by the red circle in the slides. So few minutes will be spent for some of the nits, (regarding slide 3) Roman: Last time we have discussed categories but not sure conclusion. Instead, talk about great level of details what would be categories of information. (regarding slide 4) Roman: We talked about cyber intelligence. Right now we are largely talking about describing the source and target in technical level, we have talked about indicators. Is there any desire to talk about actors and capabilities? (no so much excitement sensed from the room) (regarding slide 5) Roman: We have been discussing what indicators we want to be representing. Any feeling on the list in the slide? Kathleen: We've previously talked about using ARF (Abuse Reporting Format) for more complex email representation. It seems to be agreed upon. Is ARF a good approach and do we just extend that so the mail community would maintain that standard? Murray Kucherawy: Who besides me would want this in here? Kathleen: At least one person in the meetecho is in favor of the approach. Murray: If you want to extend it to cover more than ARF can do, I'm happy to work on this with you, if it is useful to your community? Kathleen: You guis are already working on this area, so why not duplicate the work. We can just use that. Murray: After you check your demand, if you need help, just let me know. Kathleen: With the explanation, does that change anyone's view? Is ARF more favorable? Sean: The extension of the protocol, are you going to use it? Murray: Not me at least. Sean: Is there any discussion of using this in mail community? Murray: I don't know any. This is the issue came from MILE community, not from the mail community. Kathleen: Thank you. Brian: Clarification question on these points. We are talking about adding these things into the scope of 5070-bis, or just into the scope of MILE? Roman: both Brian: Because we have some discussion on forensic issue Chris was working on. The draft seemed not to gather enough attention, but there were discussion on Friday that there might be support for that. So, the murf things, we do not want to put the entire ARF directly in the 5070-bis. I think this is another extension mechanism. The idea of 5070-bis is not making the whole a lot bigger. MILE should be lightweight Roman: Now, what do we wanna do relationship between indicators beyond currently done? (no discussion was taken place.) (regarding slide 6) Roman explained the slide (on indicator-uid and indicator-set-id), and asked feedback from implementators. Kathleen: I do not think we have enough discussion yet on this. This discussion continues in the mailing list. (regarding slide 7) Roman explained the slide (on confidence etc.). Paul Hoffman: I would say that the ability to put the level on (the first bullet) is important, but should not be emphasized at all. Don't encourage it at all, but don't prevent it. Just allow somebody who knows what the level means, but do not encourage it. Roman: Got it. Eric corrected this all regarding should/must issues. Kathleen: goes to issue tracker (regarding slide 8) Roman explained Expectation, HistoryItem, and System classes. Murray: Question on the expectation. We toy around this expectation thing because if you say I expect you to reject this message, receiver may not care what you want to happen. Is that understood in this context? Roman: it is. there is no way to make you execute. Roman explained Contact class. Roman: Are there any things else you would like to add in this class? Brian (as a contributor): I've noticed that defining substructural name might not be needed. if you can get to the person by looking at the contact name, you do not want to spend lots of time trying to build ontology naming. (regarding slide 9) Roman explained the slide (on Assessment class). Chris Inacio: I think we should add the intended purpose of attack. Roman: Got it. Do you have some good idea where we can put the enumeration list? Chris: What we can generally see from various organizations doing security that it helps understand the impact of attack, if they understand they think about in terms of actors, but if it is a kind of a crime versus extortion etc. So intended purpose of attack can map back what does class of activity would be which is political etc. Roman: Do you have any concrete ideas on them? Chris: I would task somebody else to do that. Roman: How much do we want to talk about that? Is there any desire, five indicators, two matchies on IP address 2 etc... The last question is inch working group and mile. talk about updates. Now we want to send you the other one. Kathleen: I've heard this from some of developers, came up on Friday in the workshop One of the presenter brought this question up. According to the discussion there, 5901 could be one solution. Workshop implementers will post solutions. Brian: nothing happens cause it is tsome interests, beyond the interest of me, data model. we need to something before discussion. (concluding the presentation) Roman: I throw open issues to the mailing list. Kathleen: what timeline for each question? Roman: before the end of week, questions posted on mailing list. 2 weeks for response. Kathleen: at least yes-or-no, more than 2 weeks needed. interest expressed. Paul: Each slide essentially should be one, and send it one by one to the mailing list. Give at least one week between each. Brian the two weeks after the meeting is the worst weeks to expect response from Europeans. Roman: Each of 7 slides will be sent to the mailing list over the next 7 weeks. Kathleen: May add one editor or two editors to this topic. Brian: (refering slide 3). The things that came up to my mind in the workshop on Friday is we need some sort of intellectual framework what we are doing here. Big nasty question is, "what is incident?" and "what are we reporting?". This is a nice summary. Are there any text behind this? Roman: Yes Brian: Are they in the RFC 5070-bis right now? Roman: No, they are the text I made up for the presentation. Brian: Could you bring them in the IODEF-bis for a moment, so that we can discuss later? Roman: Yes ----------------------------------------------------------------------- draft-ietf-mile-enum-reference-format-00, by Adam Montville ----------------------------------------------------------------------- Paul Hoffman: Do we actually keep versions in IANA? We could, but we normally do not do. I think IANA already does it for some registries but they are sort of edge cases. Brian: I have the experience for ipfix. We have kind of hybrid solution for this problem. We have versions of data revision of entire registry and each entry has a version number, but they only keep the most current version alive in the registry. They can indicate that you are using outdated revision, but the outdated revision is not kept in the registry. Adam: Maybe version list is the wrong word. Eric (on behalf of Jabber, no ): The enumeration version of this example, the version of the enumeration is free form string from ASCII character set. This means, in this example, it will be the string "any", which I do not think what you want. Adam: Registry version (instead of just version) might be the right word. What we wanted to do is to have just accounting integer, 1, 2, 3, 4, 5, so that we can have for example, CCE 1.0.1 could be equivalent to 1, 2 could be CCE 2.0, 3 could be CCE 6, if we skip some version. Eric: So the question is, is there any use of the enumeration version entry in the table? Adam: Maybe not. if necessary, we can sort of take it out. Brian: We need to send the last issues, and we will go to last call. Roman: What the other drafts in the working group do is creating a normative reference to this, correct? Adam: Yes. Kathleen: aggregating SCI and this draft into RFC5070-bis. Ok? Anybody disagree? (none) OK. ----------------------------------------------------------------------- draft-ietf-mile-iodef-guidance-01, by K. Moriarty for Panos Kampanakis ----------------------------------------------------------------------- The draft was explained by Kathleen following the slide. Kathleen (for Panos): Want to be sure that predicate logic meet everyone's use cases for creating relationships; this is meant for machines, so we can get more complicated Sean: Do not turn this into marketing document. If it goes to that direction, I'll blow much of the text away to avoid that. RFC is not a good marketing tool. At the end of the day, we want to see how you use this particular case. Kathleen: Agree. Thank you. ----------------------------------------------------------------------- Any other business (overall) ----------------------------------------------------------------------- Two issues for this slot was raised. - IODEF's transport issue - SHOULD/MUST discussion ----------------------------------------------------------------------- Any other business: Transport issue ----------------------------------------------------------------------- Kathleen: What do people really want for transport? It seems that different usecases might want different transport. So we brought up the Rolie's draft. There is bubbling interest in XMPP because people are starting to implement. Who is interested in XMPP as a transport? (6 peoples raised hand) David Waltermire: It is very difficult to understand how specific transports are going to be used, because there is no architecture picture for mile. Kathleen: We might use the Wiki to just explain this a bit further. If it is better to do it in a document, we can brush up the FINE(Format for Incident Reporting) document and fix it. Sean: Individual submissions are always welcome. Nevertheless, I would not going to change the charter to adopt anything else until current work items are done. I do not think it is a good idea to work outside the current scope of the working group. Brian: This is something I think is missing, and we need sort of a high-level picture. I would like to see somewhere in 5070-bis, which talks about transport use case and transport that is also useful. We originally had a document called FINE in the days of INCH. It did not get published, but it went over some of the requirement. Kathleen In the workshop on last Friday, we get feedback that this type of information is helpful. It is from the people who are implementing and/or being involved in the field. I got it from several folks. Be it either some sort of webinar face wiki or document, we need something so that we can haveChrisper picture there Roman: Make sure that we have Chris's scope. If we put more text, we will come out how we envision using those overloaded words, so maybe we do not need for architecture but we need more discussion about what it actually means to treat information and share information. And I would not dust out the FINE one. David: I'm not suggesting that we go to something that is very extensive in this perspective. Why we are not getting lots of energy here is people do not understand how it will impact them ultimately. So, the architecture document could provide a lot of clarity that will help drive some of these answers. ----------------------------------------------------------------------- Any other business: SHOULD/MUST discussion ----------------------------------------------------------------------- This is the continuation of the discussion taken place on the mailing list between Eric and Roman. (on 3.4 AlternativeID Class) Brian: Regarding this issue, option #1 is preferred here. Does anyone prefer option #2? (silence) We will be confirmed in the mailing list. (on 3.13 Expectation Class) Paul: your response to the original message cannot be found in the archive. Brian: We should see what's going on in the mailing list, but that sounds like just a mail issue. You need to have some guidance about being fuzzy around the time, and I am not exactly sure how you would say that. Sean: Two things. First, we means "must not", you use it to say what badness happens after the "must not". The purpose is protocol testing, right? Second, don't put "NOTE". Roman: My point is I think we can put broader text in the expectation class, but we can't make you do it. Whether you do or not is completely out of our hands. Brian: Yes, so be fuzzy. Roman: Do we drop "Note" and keep the text here? Brian: Yes (on 3.16 Node Class) Roman: Why do we need a time binding? The answer was fast flux. Eric: If you have an address and node name, why would you not also provide a resolution time? Roman: you might, but do you have to? Eric: That's my question. Roman: If you think it is important, you (e.g. providers) just do not do that, and that is ok. Eric: Then we could use "may". Brian, Roman: Agree. (on 3.17 Service Class) The issue on Service class was explained by Roman. Roman: The resolution is to remove the text that speaks to the "many-to-many". Brian: Ok. (on 3.19 Record Class) The issue on Record Class was explained by Roman. Brian: Where do you want to balance the pain? Do you want to put the pain on the generator or receiver? That becomes another question especially when we start talking about use cases that Rolie is looking at for you generating once and sharing hundreds of thousands of times. I think in that case, make it easy on the collector I think you want to be really kind of hard on them to say if not must, then you really really should. When you are generating a thing, you can parse all of this things that are automatically generated anyway. Brian: Can we have another indication type here which is just like pile of craps? Eric: It is called AdditionalData. Paul: I would like to point out that you are stressing not only to the receiver but to transport. Different transport will handle large amount of data differently. You've chosen XML, wordy one. In this case you have way more meta data than real data. Roman: I'm not sure maybe the use case I have in my mind is that you have a text file, log entry from three snort alerts, and something kind of syslog, and you paste it all into a same text file. Do I get to create two record data entries, one for the snort, one for the syslog, or can I just give you the text file that has both? Brian: I can see where the use cases are useful, such as a system problem of stock exchange. Roman: The end of the discussion is don't change the current language, and leave it as "SHOULD". (on 5.2 Extending Classes) Roman: The original implementation guidance No.5 says it probably doesn't make a lot of sense to download a scheme everytime you get a document. So the comment was that you should not download schema every time. You wanna look at the document, but wait, if you are not downloading it, should you be validating it all? When people cash the schema anyway, so you will still cope with validation with cashed schema. Brian: The schema changes once every every 7 years. So, cashing is we probably wanna have explicit guidance, saying don't hammer the IANA servers. They hate automated download from IANA. They'll find you at the meeting. Eric: It really the thing here is in the spec. Because it changes every 7 years, does anyone even load and validate schema? Brian: The only application I know of for the schema is we did use it for essentially in interop again about 7 years ago. We found some errors in the schema and fix those. That was a useful exercise but I think that's sort of the whole you should use the schema things one of the whole problems to the entire XML torturing in the first place. Roman: So, for the stuff we have first passes, you validate because that's how you cash the stupid stuff. After that you need lots of application logic, e.g. extraction Eric: Sean, do we get snaps solely if we actually say something but when you first read it you must first validate? Sean: People would validate it, but I do not know whether they continue to do it after they did once. Brian: Do we provide guideline for the 5070-bis about where we get schema from? We wanna put little line in there that says "Please don't. Please try to use cached copy or use the copy that is part of your (built-in) implementation". Sean: We can just say "you should just validate," nothing else. Brian: Yes, we can say "use the schema, enjoy". (On 6. Internationalization Issue) Roman: We need help there. Kathleen: Peter (St. Andre), can you help us. Brian: Wasn't it that you (Peter) discuss on RID and got this issue in the first place? A bit of background. We had some language in RID that was compatible with this language in RFC 5070. Kathleen: We need to make sure we can do something to get this right. Peter St. Andre: I'll look it. Brian: I think the guidance that I remember we came up with when we realized that we need to fix this in RID was that let's apply what we did to RID to RFC5070-bis as a starting point. We start from there. It probably makes sense to do that first before you'll get it because otherwise you will be angry at it because you've seen them before. Kathleen: We have to do translation etc. Punycode Peter: I don't recall from my reading IODEF last time, there were things that especially concerned me. As I said, I'll review 5070-bis and take a look, and I'll provide a report on the list. Roman: I believe the feedback was very unkind to the approach. Paul: I think you might be conflating two things here, some of the stuff we wanted to be more careful on was on language, not on character set and such like that. Anything with domain name should have no internationalization issues because it is going in punycode form. If you are allowing non-unicode form in there, that's an issue. Kathleen: That was the result in RID and not in IODEF. Brian: IODEF does not mention punycode specifically. Paul: The issue here is extracting language stuff, which has nothing to do with character set. Who is going to be reading this and what language is needed are actually the orthogonal issues. Kathleen: We put them only in the RID document in the internationalization section. Paul: It is presentation, because you can't have all ascii text in all different languages. (On Section 5.2 Extending Classes) The issue on extension schema was explained by Roman. Roman: question is why would you not put extension if you use AdditionalData that is not the closest. It is because people like to maintain only one extension schema. They put everything into one place even if it is more appropriate to break it up into 3 or 4 things and put them into different AdditionalData. Eric: You can come up with both encouraging and not encouraging doing so. The direction of the original sentence is also entirely sensible. Kathleen: We integrate the SCI draft, which does advocate the specific places for each extension point. Roman: It seems to be that there is a desire for a sentence after the current text. It should say something like, "yes do this because the document probably be easier for parser and future extensions."