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
15:30-15:40 |
Review Agenda |
15:40-16:00 |
Review Expectations for ISP-ISP Security Coordination |
16:00-16:20 |
Review Consumer Checklist for ISPs |
16:20-16:40 |
Site Security Handbook Addendum for ISPs |
16:40-17:00 |
Review Security Expectations for Product Vendors |
17:00-17:15 |
Open Discussion; Document Authors |
17:15-17:30 |
Next Steps |
After discussion, the new agenda was:
Modified :
15:30-15:40 |
Review Agenda |
16:00-16:20 |
Review Consumer Checklist for ISPs |
15:40-16:00 |
Review Expectations for ISP-ISP Security Coordination |
16:40-17:00 |
Review Security Expectations for Product Vendors |
17:00-17:15 |
Open Discussion; Document Authors |
17:15-17:30 |
Next Steps |
There was discussion about the format we should use for this document. There was concern that the existing paragraph style wasn't what the working group had in mind.
Tony Hansen (ATT) presented several alternatives for making the document more similar to a checklist. After discussion, there was there a consensus that we will begin each section with a list of questions th at the consumer would ask of their ISP candidate. The following section would expand on the importance and rationale for asking the questions. In addition to the main document text, we will also list the complete list of questions as an appendix. IE SG. Concern was raise by the AD that we keep the appendix consistent with the rest of the document. Therefore, we won't create the appendix until after we have completed the document, just before submission to the IESG.
The rest of discussion on this document focused on the content of the sections. The following is a summary of those discussions.
Comments on the document :
About the title : The title "Security Expectations for Internet Service Provider Consumers" has to be modified for "Security Checklist for Internet Service Provider Consumers".
The abstract will also be modified to reflect this change.
Section 2.1 :
The suggestion was made to use "incident handling" instead of just incident reporting or response.
Section 2.2 :
"Assistance with inbound security incident" included suggestion that the ISP inform users of incidents that were targeted at other customers. This was decided to be inappropriate. This section will be rewritten to cover questions desig
ned to solicit information about how the ISP will respond to attacks on the consumer. For example: What help will you get from ISP ? What are you going to be told if the ISP notices that someone is attacking you ?
Section 2.3 :
This section will be revised to cover a set of questions "What sort of security information the ISP will make available to you ?"
Section 2.4 :
Comments made on the list will be incorporated into this section by the document editor.
Section 2.5 :
To make it easier to understand, we will provide some examples of what we mean by "secure channels" e.g., Secure Web, Secure Email, telephone, fax, ...
Section 3 :
This section will simply ask if the ISP has a security policy and what is in it.
Section 3.2 :
The first sentence will be rewritten.
Section 3.4 :
Content will include questions covering whether the policy is public and where it is published.
Section 4 :
It was decided that this section doesn't belong in this document and it will be removed.
Section 5 and 6 :
Discussion will occur on the mailing list.
Section 2.1 :
Comments from the mailing list will be integrated
Section 2.3 :
This section has to be synchronised with the previous document (Security Checklist for Internet Service Provider Consumers), especially the last sentence.
Sections 2.4 and 2.5 should be removed from this document. The subject of how the ISP deals with security incident that involve them will be added.
Section 2.3 :
Include recommendation to notify appropriate people when a new vulnerability is discovered.
Section 2.5 : Contacts
Section 3 :
The language needs to be edited so that it no longer reads as if there is a contracts AUP that guides everything.
Section 4 :
A reference to the site security handbook RFC will be added.
Section 4.1, 4.2 :
Some duplications will be removed.
Section 4.1 :
Modify to read "ISP should 'SWIP' or equivalent."
Section 4.2 :
A transition sentence is needed to explain that the advice given is not going to prevent bogus announcement.
Section 4.3 and 4.4 are already in RFC 2265, so the major portions of text will be removed and a reference to 2265 will be highlighted.
Section 4.6 :
There is a proposal to change default way to accept directed broadcast to the opposite. Must add the reference to "Changing the Default for Directed Broadcasts in Routers", D. Senie, 02/22/1999, draft-senie-directed-broadcast-02.txt.
Section 5 :
This section will be removed from this document and included in the SSH addendum document.
We didn't have a draft prepared in time for this IETF. Tristan volunteered to be the document editor.
We ran out of time. The draft will be submitted to I-Ds and discussed on the list.
New drafts for each document will be ready by April 15, 1999. The goal of the working group is to complete all documents by the Oslo IETF meeting.
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.)