Action Items

• Chas will work with developers to publish a design document that will be a bit rough for now.
• Matt will coordinate possible meetings times for face-to-face meeting with Chas and Mark.
• We need to get information back to Bart Kerver, SURFnet, that addresses how we see the SURFnet Detective working or not working in our space. (This item was not assigned to any specific person.)
• Ken will follow up with Brent Sweeny for scenarios from Indiana NOC.
• Mark will get names from his Microsoft meeting to Ken before his meeting at Microsoft on July 26th.
• Mark & Chas will let Ken know what he could do in a one hour meeting to keep Microsoft appropriately engaged. Also for Ken's meeting at Microsoft July 26.
• Chas will see to getting DTD for the XML out soon so that people can begin to write to them.
• Matt will follow up with Chas and Russ about how to best use Abilene logging data and then will report back to the group.
• Russ will help identify people on networking side who could look at Abilene data logging event process and give us comments.

Agenda Items

Pilot progress report

Chas reported that the pilot progress is going very well between the collection agent and the diagnostic agent. The work is still in sync with the timeline mapped out on the slides from the last call. He will be meeting with the developers in Pittsburgh at the end of July.

Matt asked if there are any design documents for the pilot agents that could be shared. Chas said yes, they are currently rough, but we should be able to put them on the project web site. Russ agreed that this would help to map entities to events.

Involving other groups and participating in other efforts

RID-INCH: Markreported on Kathy Moriarty, MIT, working with the Real-Time Inter-network Defence (RID) - Incident Handling (INCH). INCH setting up standard formats for messages regarding security incidents such as DDOS events. RID-INCh is working to pull together protocol work and format information that relates to the Incident Object Description and Exchange Format (IODEF) working group and the RID-INCH effort.

Mark saidthat Ken has asked us to follow up with Kathy or Roman Danyliw, CERT person. Contacted Roman previously, but he did not have time to respond well. Perhaps we'll have better traction with Kathy and figure how these things dove tail. While their work is specific to security it could be generalized to have diagnostic application. Matt said he will be attending IETF, but not sure if he would be free during the RID-INCH session times. Ken encouraged Matt to arrange meeting time with Kathy to let her know that we will engage her more when we figure how the pieces fits. This would be part of continued contact with her. INCH IETF page: http://www.cert.org/ietf/inch/inch.html.

SURFnet Detective: Mark reported about the SURFnet Detective. He said that Ken had given references to it and that he had spent some time looking at it. Mark and Chas had conversation that it looks like interesting UI that MWRX may be able to plug in to later in the project.

SURFNet folks interested in extending detective in direction of the diagnostics. While current tests are active performance/capability measurement, they let the user see if it works. Matt had looked at this and noted that there is not much there right now. Mark agreed but said that this might be a useful framework to use plug-ins to fire off MW-e2eD diagnostic tests.

Chas asked if there isn't a similar tool at Internet2. Matt described the Internet2 Detective which uses a stoplight metaphor with red, yellow, green light. He said it is not as flexible to use either.

Matt described the Network Diagnostic Tool (NDT) which has been improved. It uses a central server and does tests in JAVA. This makes it easier to do, but still limited. This is not yet ready for use by novices. Like SURFnet it makes inferences

Mark pointed out how these tools are available in similar spaces. The tools have some overlap, but we're not sure how they fit together. MW-E2ED may need to spend some time sorting out these connections. The survey that was done did not include these tools, but there have been recent questions how these relate. So, we may have to provide some context on how they relate to MW-E2ED.

Chas agreed that it would be good to talk with the SURFnet folks and see what we can leverage. Ken agreed and said that the SURFNet team would like critique from us to see what pieces would make the Detective more globally useful. Ken would like to see traction with this because he sees the Detective as a way to get CIO's more engaged in this activity. It would be good for us to have some response to the Dutch how we see Detective relating to MW-E2ED space and the event record. Ken said he liked the fact that the detective has white space -- room for changes and growth.

Ken had two data points: First now has a set of diagnostic scenarios from Brendan Bellina who has worked on diagnostic tools in the past. He will be attending MW-E2ED calls in the future. Ken will forward his scenarios to the list. His scenarios need to be pulled apart into diagnostics with middleware directly and not with the tools. For example one is about directory performance issues which is not necessarily for this group. Chas pointed out that Brendan had submitted scenarios for middleware applications. Brendan will be the point person for directory middleware associated with diagnostic space.

Second data point Ken share with us is that we're going to have Derek funded to specifically work on diagnostic pieces of Shibboleth. So, he will be available to work with MW-E2ED in a couple weeks. Derek will be the Shibboleth point person to interact with MW-E2ED.

Ken said he felt that the MW-E2ED work would be able to have immediate impact on the work of SIGNET due to the granularity of what they're doing.

Mark pointed out this is mostly a framework for working with these folks to make sure the API is done right and that the requirements are clear to support the diagnostics they want to do. Maker sure we can classify and clarify it. Ken asked where the line was between a directory diagnostic and middleware diagnostic. Mark replied that this would be where a use case would help clarify the problem. A forensic search to identify which level the problem was happening at -- a correlation piece. Chas said that it could do both with a plug-in to do either general or specific tests.

There was a brief discussion about what network services are. Mark defined them as infrastructure services like directories, authentication, authorization and things like that. There are domains for those that are inter and intra realm. When seeking these, the relevant domains will depend on the application path. Since we're working with application designers and enterprise support folks we should have a good idea what these applications are supposed to be doing with having to reverse engineer them. We should be able to stamp out directory or shib prototypes based on information given by folks from those domains. Mark said this is what Chas and the developer have done to create diagnostic infrastructure.

Chas this is where we need to start doing the correlation. The correlation can be specific to an application but much broader to other parts of the infrastructure. One piece of middleware influences another and can take it down. We have to correlate behavior of both parts and applications themselves to the other influencing applications.

Mark went on to say we need to put together a structure for capturing and cataloging events. We provide a mechanism that various provider can give hints about own protocols to give hints about the forensics. It may harvest these things because it knows where to look.

Ken asked if there was a story here, like: "My outbound email queues are backing up and why?" Like a story where various failures have occurred. Chas said that he and Brendan had work on this. The question, "My directory service is slow, how do I know why?" Well using Netflow log entries demonstrated that his directories were being harvested in a way that slowed them down. Ken said that while this was helpful what we need is a "finger pointing tool" like the one in Russ's presentations. Now we're at an upper level with this. Ken wondered if he should write something based on this to answer these questions - what would I do and where would I go.

There was a brief discussion about how people are reluctant to use services. Recent discussion on a Higher Ed Email listserv was about how to overlay a diagnostic architecture on top of this thing, how would you do it. It was suggested that Brad Judy would be a good person to bounce this idea off of.

Ken raises issue that this might not be an inter-realm thing, but is worth looking into. He said he'd like to get these into one or two scenarios. Chas asked to help get a handle on scenarios from the web section. What question will this answer before, during and after problem resolution. Von Welch did a good one for the Grids that applies to a number of areas. Ken said he'd check this out.

Agenda for BoF at fall Internet2 Member Meeting.

Chas is trying to figure out how to get over people involved that would lay ground work for next steps. Ken suggested in identifying the people to be involved to think about the sales pitch to CIO level. There is a possible CIO session during the meeting and it would be a good time to present the idea of how does the help desk live in a modern era of complex interactions? The help desk conversation could help define when it's a user test like the SURFnet Detective or a more technical test by a diagnostician. Ken said he's suggested "the Help Desk in the 21rst Century" as topic for the CIO session.

Ken then asked the basic question of who is the target population? Who do we want to attract to the BoF? What outcomes would we expect from the meeting? Then have a look at who usually attends the meeting to see if there are other people we'd want to contact. If there are other folks, we'd need to get the message out early. Chas agreed with this plan.

Other business

Chas asked Russ and Matt about their communication with Abilene NOC people. Russ said, yes he had spoken with Brent Sweeny who had agreed either he or one of his staff would write a scenarios. There was brief discussion how to make sure this happens.

Mark talked about a meeting at Microsoft and how their security effort is about integrating their designs with their code. So diagnostics are an important part. He and Chas are trying to figure out how to get back to them. Ken said that he would be having another meeting at Microsoft on July 26th and would talk with the Microsoft people. Mark will send Ken the right names. Chas pointed out that this directly points too the Microsoft Operations Manager (MOM http://www.microsoft.com/mom/) and we might want to wait a bit before going further with Microsoft. Mark agreed, but said that it is good to keep in touch.

Russ said that he has been talking with George and how a lot of what we're looking at has been top down. Now we are starting to get an idea of the infrastructure. What would an event look like in order to get a repository in place and then get people to put some data into that repository. He said that it might be useful to use Abilene logging data and put them into a repository in a event format. But he asked if this might be too soon. Chas said no, that he felt this would be a good time and will talk with the developers to get DTD's for XML out so people can write to it.

Russ then mentioned that with the Abilene data they are starting to define window envelope of normalcy. When that's collected what is outside the window kicks off the diagnostic tools. Mark suggested that Russ and Chas talk about this and then report back to the group.