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

45th IETF, Oslo, Sweden - July 1999

Guidelines and Recommendations for Incident Processing (GRIP)

1. Agenda

9:00-9:10 Agenda bashing
9:10-11:15 Document reviews
- draft-ietf-grip-user-02.txt
- draft-ietf-grip-isp-expectations-01.txt
- addendum for SSH
- user security expectation of vendors
11:15-11:30 Next steps

No changes proposed.

2. draft-ietf-grip-user-02.txt

Tony Hansen led a discussion on the current draft. We weren't able to complete the full review and remaining issues will be discussed on the list. The following are the issues that were discussed.

• Tristan remarks that we should define what we consider to be an ISP. Tristan will provide a definition. This definition will include organizations providing connectivity to the Internet as well as organizations who may not provide connectivity b ut rather provide services like web hosting, or email service.
• There was discussion about what we mean when we refer to the term policy. There was concern that we were suggesting that ISPs should disclose their internal policies. Nevil Brownlee proposed that we add a sentence to explain that we are referring to a high-level general view and not the implementation details that an ISP may use. It was suggested by Tony that we probably should include a definition for security policy within the context of this document.
• Discussion continued as to whether we should go more deeply into a discussion on policy in the document. It was suggested that perhaps an example in an appendix might be helpful to the reader. This is still an open issue and will be discussed on the list. Espen Torseth (espen.torseth@sds.no) will submit several sentences to the list for incorporation into the document.
• In section "Sanctions", the sentence "You should also expect your ISP to be forthcoming in announcing to the community when such sanctions are imposed" will be removed.
• 2.1.4 Announcement of Policies : "You should expect your ISP to publish their security" : this policy will be included in the announcement of security policies.
• Incident Handling : The document is more generaly is focused on helping the customer solicit information about what incident handling services the ISP provides and doesn't attempt to delve into how the ISP accomplishes those services.
• Assistance with inbound security incident : "inform you of the attack" removed.
• "2.2.3 Notification of Vulnerabilities" : Report incident that might affect you. The new first bullet is : "What information will the ISP make available to you when security vulnerabilities that might affect you are discovered in their services?"
• 2.2.3. A new bullet is added : "What information will the ISP make available to you when incidents occurring at the ISP may impact you"
• Modification in "When security incidents occur that ..." : "When security incidents occur that affect components of an ISP's infrastructure and that may affect you, your ISP should promptly report to you"
• "Many ISPs have established procedures for notification of customers for outadges and service degradation. It is reasonable for the ISP to use these channels for some internal incidents. In these cases, the customer's security point of conta ct will probably not be the person notified. Rather to the normal POC will received the report."
• Contact information : "Who should contact <delete>via email</delete> for ..."
• Add something about authentication and communication.
• There was concern that the language of the document implied it was only for individual end users. The working group intends for it to apply to any size customer of an ISP so we will add some sentences to clearly communicate this to the reader.
• 2.6 References: new first bullet: "Will the ISP provide a list of reference customers that have security incident handled by the ISP. All references must be voluntary."
• "can be found in the Site Security Handbook RFC2196". There is concern that we're asking for an ISP's internal proprietary information.
• "You should also expect your ISP to be forthcoming in announcing to the community when such sanctions are imposed." This sentence is inappropriate.
• 2.1.4. Announcement of Policies: "If the AUP changes, will you be notified of changes to it, and if so, how?" We need to tweak this and it will be discussed on the list.
• 2.2.1. ISPs and Security Incident Response Teams: "Does the ISP have a Security Incident Response Team (SIRT)?" We want the user to care about whether the ISP has a service. Need the customer to know that security and privacy concerns m ay preclude the ISP from divulging certain kinds of information. The important thing is to get disclosure to the user of what procedures the ISP has, or doesn't have.
• "2.2.3. Notification of Vulnerabilities and Reporting of Incidents" replaced by "Notification of vulnerabilities and reporting of incidents that may affect you."
• "When security incidents occur that affect components of an ISP's infrastructure, your ISP should promptly report to you:" is replaced by "When security incidents occur that affect components of an ISP's infrastructure, and may aff ect you, your ISP should promptly report to you:"
• "Who should you contact via email for network security issues?" Add a bullet: "** What mechanisms are being used to provide authentication and privacy?"
• "** Is the ISP up-to-date in applying security patches to their software/firmware running on their production equipment?" we need to resolve whether this stays in or goes.

3. draft-ietf-grip-isp-expectations-01.txt

• The definition ISPs should be added. Tristan will provide a short definition of what we mean by "ISP".
• Message submission : remove the explicit reference to the work in progress.

The paragraph "The (undocumented) XTND XMIT POP3 extension which allows clients to send mail through the POP3 session rather than using SMTP may also be considered. It also provides a way to support mobile users at sites where open relaying is disabled, and has the benefit of an authenticated connection and a better audit trail" will be deleted.

4. Addendum for SSH

The draft document is not issued yet.

The main ideas of the document are :

• technical operations of services
• security issues surrounding the way they manage and operate their network
• section 7,8,9,10

Work done :

• document mainly based on Tom's work
• deletion of the different paragraphs
• 2.4 Notification of vulnerabilities and Reporting of Incidents
• 3. Appropriate Use Policy
  • 3.1 Announcement of Policy
  • 3.2 Sanctions
• 4.1 Cooperation (conforming december minutes)
• 4.4 Registry Data Maintenance
• new ideas for the chapter named "Network Infrastructure" ? We will discussed that on the list.

5. Next steps

• ISP expectation update from Tom next week
• SSH addendum from Tristan this week,
• User document update from Tony
• WG last call will be issued shortly after the next draft of the ISP expectations document is released.
• An interested subset of the WG will meet for lunch tomorrow to hammer out some of the unresolved issues in the user document.
• Barbara mentioned that Klaus-Peter Kossakowski and she had pulled together past content intended for a document expressing the community's expectations of technology vendors. This draft will be submitted to ID in 2 weeks.

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