[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GRIP-WG: Minutes April 97
Dear colleaguages,
finally, here are the minutes from the April Meeting.
Sorry for the delay.
Best regards,
Peter Kossakowski
--
Klaus-Peter Kossakowski DFN-CERT, University of Hamburg
kossakowski@cert.dfn.de Fachbereich Informatik - RZ
Tel.:+49-40-5494-2262, Fax: -2241 Vogt-Koelln-Strasse 30, D-22527 Hamburg
PGP-Key available via finger kossakow@concert.cert.dfn.de or any key-server
PEM-Key available via finger kossakow@concert.cert.dfn.de or by mail request
Team: http://www.cert.dfn.de/ Person: http://www.cert.dfn.de/team/kpk/
38th IETF, Memphis, Tenn. - April 1997
**************************************
Guidelines and Recommendations for Incident Processing (GRIP)
=============================================================
Prepared by Klaus-Peter Kossakowski
The GRIP working group met once during the Memphis IETF.
Agenda
++++++
o Review new draft
o Review new filled-in template
o Update schedule
o Future directions
Review of the new draft (version 4)
+++++++++++++++++++++++++++++++++++
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).
o "About this document" comes after section one which does not allow a reader to
easily check whether the document is the current version. It also makes it
difficult for the reader to find other relevant information about the document
itself. Ann suggested reversing the orders of sections 1 and 2. A compromise
would be to give the date and location of the document in the header and to go on
with the actual order of the template.
o By filling out the template a problem showed up with section 4.2 and 4.3.
Section 4.2, "Interaction", deals with the same content as section 4.3,
"Disclosure", to some degree. Because they are so similar, Ann suggested that
we combine the two sections. The group supported this suggestion. It was also
noted that it is still important to list special relationships since constituents
might consider this information important.
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!
Review of the filled-in template
++++++++++++++++++++++++++++++++
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.
Updated schedule
++++++++++++++++
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.
Future directions
+++++++++++++++++
The group then discussed two documents that had been proposed in past meetings:
o adressing the vendors
o adressing the ISP community
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.
Administrivia
+++++++++++++
The mailing list is:
o grip-wg@uu.net
o Subscription: grip-wg-request@uu.net
Access to the GRIP charter and minutes is possible via World Wide Web.
o http://www.cert.dfn.de/eng/resource/ietf/grip/