GRIP WG meeting - Minneapolis
 Minutes recorded by: Tristan Debeaupuis
 15th, March 1999

 1.  Agenda
 ----------

 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

 2.  Review Consumer Checklist for ISPs
 --------------------------------------

 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 that 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.
 IESG.  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 designed 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.


 3.  Review Security Expectations for ISPs
 --------------------------------------


 �  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.


 4.  Site Security Handbook Addendum for ISPs
     ----------------------------------------

     We didn't have a draft prepared in time for this IETF. Tristan
     volunteered to be the document editor.

 5.  Security Expectations for Technology Vendors
     --------------------------------------------

     We ran out of time. The draft will be submitted to I-Ds and

     discussed on the list.

 6.  Next Steps
     ----------

     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.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.