Re: (summarized comments)

[Tom Killalea <tomk@nwnet.net>]

Oops - forgot to cc the list.

Tom.

------- Forwarded Message

Date:    Wed, 26 Nov 1997 11:23:48 -0800
From:    Tom Killalea <tomk@cypress.nwnet.net>
To:      Klaus-Peter Kossakowski <kossakow@informatik.uni-hamburg.de>
Subject: Re: (summarized comments)

Hi Peter,

>instead of commenting on all the various mails already exchanged, I would like
>to comment on the whole discussion (until Saturday 15th). But before I go
>through all this, thanks for this good work!

Thanks for your comments on the draft.  Unfortunately many of your
comments relate specifically to the first draft 
(draft-ietf-grip-isp-00.txt).
  
The second draft (draft-ietf-grip-isp-01.txt) was announced on the
list on Nov 2nd.

At one point I was worried that I'd mysteriously been removed from the
GRIP list, as I've had no comments on the second draft :-( 

Anyway, comments below...

>Overall
>-------
>
>	One general comment right in front: I believe, much of the discussion
>	where there were no rough consensus could be leveled by remembering,
>	that we only give topics to consider and sometimes we just don't know
>	the final answer, so for example:

I agree.  I'd like to hear what you think about the revised wording for
the 2 most contentious sections - 

  5.7 Ingress Filtering on Source Address
and
  8.3 Open Mail Relay

In addition, I agree that we should discuss in Washington what this
document is trying to achieve, and, moving forward, what the target
state should be (BCP or Informational).

>Document Structure
>------------------
>
>	I would put Section 2 about Incident Response at the end, as this appli
>es
>	mainly when security fails.

My intention was that information that may be useful during an Incident 
should be towards the front so that it could be found more quickly.

>Section 2
>---------
>
>	The introduction need some wording about the role of Incident Response
>	within the ISP context. Referencing the teams doesn't help to motivate
>	the importance. So I see two dimensions of an ISP in relation to Incide
>nt
>	Response:
>
>	a) they are themselves target of attacks
>
>	b) they are an interface to the customers and might be used as contact
>	   by SIRTs - slightly different is the need for support of the custome
>rs,
>	   if the customers have an incident

I tried to be very concise in this introduction and to adhere to the IRT
draft.  ISP's SIRTs have a whole spectrum of missions and constituencies
- I don't think that a description of their responsibilities would be 
easy or constructive (and that should be spelled out in completed SIRT
templates anyway, right ?).

>- Subsection 2.1: 
>
>	There are still most of the SIRTs which provides service for free
>	(which means, that not the customer is paying directly but tax dollars
>	or community services are likely to provide the service). So the text
>	sets the wrong tone in the first sentence.

I don't think this is the case, and it's especially untrue for ISP SIRTs
outside of Europe.

>- Subsection 2.2:
>
>	There are more tasks to list here:
>
>	- inform the customer about (possible) breakins and the fact, that
>	  attacks were carried out
>	- forward the information to one of the relevant SIRTs (or let the
>	  customer decide if they want to contact a SIRT)
>	- protect the evidence in case the customer might fill a court case
>	- provide assistance to limit the further exposure of the customer, if
>	  there is no other way to deal with the incident/attack

I'm working these ideas into a rewrite of that section.

>Section 4:
>----------
>
>	I don't like the heading (and the emphasize of the introduction). I 

This section is now radically different (though the heading is the same)
- feedback welcome :-)

>- Subsection 4.3:
>
>	What is true for Source Routing is true for Open Mail Relays as well.
>	Allow necessary features for the limited (!) number of customers/hosts,
>	monitor the usage (!) and for the rest, disable the service (!).

That's a reasonable approach - let's discuss at Washington.

>Section 5
>---------
>
>- Subsection 5.3:
>
>	2nd paragraph: TFTP ... "lacks authentication, access control and
>		uses an insecure channel, " ...

done.

>- Subsection 5.4:
>
>	Physical security is here put in the middle. I would prefer it at
>	the beginning or at the end. Please make sure, that it is explained, 
>	that specific security services like Kerberos demand at least one
>	physical secured host or that physical measures could enhance the 
>	security of existing installations (guards and locks instead of 
>	protected serial interfaces of routers).

I don't understand.

>Section 6
>---------
>
>- Subsection 6.2:
>
>	The heading calls for Incident Detection, but I don't think, it is
>	in the text. While the provision of mechanisms to detect incidents 
>	like network monitoring clearly fit into the policy section, it also 
>	qualifies for Section 2. I am not sure where to put it best, ones 
>	there is content for this topic.

You're absolutely right.  In the absence of incident detection specifics
I've reduced the heading to 'System Management' for now.

>Section 8
>---------
>
>- Subsection 8.2:
>
>	This was already handled under 2.6 or should be handled there at least.

done.

>Section 10
>----------
>
>This section in particular fit to another group of people to address:
>web hosts.
>
>- Subsection 10.1:
>
>	This is very complete, while other sections lack that level of detail.
>	Please make the global issues available within Section 6 for example.
>
>	There should be also some rational, why such level of detail is given
>	for the web services.

I agree that other sections would benefit from greater detail - if
anyone wants to forward text please do so !

>	Process User and Group should be different from the owners of the
>	web content.

I considered it implicit when I used the phrase 'specifically for that
purpose' but I've now made it explicit.

>- Subsection 10.2:
>
>	Please list plugins like Microsoft Frontpage extensions as well to
>	get the attentions of others also.

I touch on such tools in 10.7 - "Content Loading and Distributed 
Authoring".  I'm disinclined to talk about any specific product.

>	Process limits (this qualifies in some way to email services as well)
>	should also consider disk space.

done.

>- Subsection 10.3:
>
>	1st paragraph: web daemon process instead of HTTP daemon process
>		(as web was used before)

done.

>	What about to recommend, that the users are informed, what kind of
>	data (and what for the data) is stored about their transactions?
>	We have such legislation within Germany, that will enforce all
>	web content provider to identify this not on demand but routinely
>	on the web itself.

It seems a little unnecessary to me, unless I'm missing something.

>Section 11
>----------
>
>	What about "Practical UNIX and Internet Security" by Garfinkel
>	and Spafford (by the way, Web Security and Commerce" is by both
>	authors, too) 2nd Edition.

Spaf doesn't get an author credit on 'Web Security and Commerce' 2nd
edition, just a 'with'.

I tried to keep the list of books referenced short, in keeping with
sentiments expressed by Joyce Reynolds at the SSH meeting in Memphis.
Basically, the intention is to point people at RFCs and net resources in 
preference to references that cost money.

If people agree that 'Practical UNIX and Internet Security' or any other
books should really be referenced I'll certainly add them.

Tom.
--
Tom Killalea   (425) 649-7417    NorthWestNet
               tomk@nwnet.net

------- End of Forwarded Message