Meetings:
30th IETF,
31st IETF,
32nd IETF,
33rd IETF,
34th IETF,
35th IETF,
36th IETF,
38th IETF,
39th IETF,
40th IETF,
41st IETF,
43rd IETF,
44th IETF,
45th IETF
and
46th IETF
The GRIP working group met once during the Memphis IETF.
The first part of the working group session was spent reviewing the current draft document. At least half of the group in attendance had read, and was familiar with, the draft.
The point was made that under Services there are only two items: Incident Response and Proactive Services. It was suggested that this leaves the interpretation completely up to the team and each will end up using its own definitions. It was suggested that we need more granularity and examples to direct the teams to use a more useful level of detail. On page 15 of the draft, there are already some examples given. Ane it was further suggested that using different types of incidents would be a good way to provide better explanations.
It was mentioned that there are different types and levels of services. For example, there is "technical incident response on a site level", "high-level incident response coordination within an organization, and still "higher level incident coordination across multiple organizations". These are very different. Don Stikvoort (SURFnet) agreed to look into this topic during the next month and will send his comments to the list.
The group felt that it is necessary to highlight coordination as one important service (on different levels) and to include the aggregation of information towards a more complete picture as another service.
Ann Bennett (Concordia University) submitted a number of useful comments which were reviewed, and the editors will make the necessary changes. In addition to the general editing comments, she also noted some other problems in the draft while attempting to populate a template for her local team. (The template will be provided as an appendix to the draft).
Another topic brought to attention of the group was that the use of the term "customer" in section 3.4.5, was misleading. That led to a discussion about contact information by itself. Section 3.4.5 will be moved to 3.1 to collect contact information in one place. The subscription for a mailing list, for example, goes with additional services (together with information about other information services) in section 3.5. All of the different services listed will need some more content to explain exactly what is meant by the service.
Acknowledgement will be given to Ann's contributions!
Ann Bennett provided a new filled-in template after the draft (version 4) was finally sent out on the list.
Some issues which came up during her work were already discussed (see above). The discussion of other issues was skipped, as nobody had really reviewed the new filled-in template in detail. Further discussion will be carried out on the mailing list.
Don will provide suggestions and comments about his task within one month. Erik will get the majority of the smaller comments and corrections into the draft within a very short time and send an updated version to the list. The goal is to submit a new draft within one month to ietf-drafts, including all issues brought up during this meeting. Comments will continue to be solicited from the list and if possible another draft will be produced prior to the August meeting.
The group then discussed two documents that had been proposed in past meetings:
The working group, in the past, has contributed a fair amount of material for a vendor document. There was a reasonable structure developed during the 37th IETF in Los Angeles, Calif. and Barbara will take an action item to distribute a short draft as input to the list for further discussion.
The group also felt that there would be a reasonable benefit to working on the ISP document. There was discussion as to the scope of this document and it wasn't clear how many operational issues would be included along with the incident handling/response material. There is no clear boundary between operations and incident-related topics and we will try to develop this document like the IRT document, where we describe what is expected but not dictate the details of how it is to be provided.
The example of IP spoofing filters in routers was given to illustrate the difficulties involved in balancing between incident response and operations. Such filters will clearly stop many attacks and avoid intrusions, but they may interfere with the operation and policies of the service provider. The provision of such filters will also impact the relationship between customer and provider. The problems with telling IRTs how to do their work, apply to this document as well. It was agreed that it will be difficult to write this document in such a way that it is both helpful to the community and acceptable to the service providers.
Nevil will put some initial ideas together for the ISP and distribute this to the list by end of June. Don is also interested in contributing to this document.
Vendors and ISPs are part of the overall community that is involved with dealing with incidents. Both documents should be based on the first document and should be very short. They should provide notice to the vendors and ISPs communities that people have expectations from them with regard to overall incident reponse in the Internet.
The mailing list is:
Please send questions, comments, and/or suggestions regarding the GRIP working group to the open mailing list grip-wg@uu.net.
All issues regarding these web pages should be directed to klaus-peter@kossakowski.de.
These pages are hosted on http://www.kossakowski.de and are provided on an "AS IS" basis without any explicite or implicite responsibility, liability, etc. (For a more fully understanding please refer to the legal statements within the Impressum, which is only available in German.)