Re: draft-ietf-grip-isp-00.txt (summarized comments)

[Klaus-Peter Kossakowski <kossakow@informatik.uni-hamburg.de>]

Hi all,

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!

Best regards,
	Peter


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:

	Source Routing: Source Routing is used for attacks on customers, so
		it might be better disabled. But Source Routing is also used
		for legitime applications and usage of the Internet, so there
		might be serious reasons not to disable this feature. Instead
		of ignoring the threat of Source Routing, the customer should
		be given a choice (or if the customer was made aware of the
		possible dangers he might choose to disable the service).

	I don't know, if I could make it clear what I would like throughout
	the document: just make sure, we list the topics that need clarification
	and discussion between customer and ISP and give good reasons why we
	think, this needs discussion. If we just ignore the threats, we will
	never live up to "best current practice" we were prepared to come up
	with.

	I am not sure about the issues Nevil raised in this mail of
	October 22nd, but I think, this needs to be discussed in
	Washington. But before that, I would like to hear from others,
	what they think this document should try to achieve.


Document Structure
------------------

	I would put Section 2 about Incident Response at the end, as this applies
	mainly when security fails.


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 Incident
	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 customers,
	   if the customers have an incident

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

- 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

- Subsection 2.3:

	Especially outgoing attacks could be caused by the customer itself, so
	there is also a real chance, that the ISP is contacted by a SIRT to get
	help without involving the customer, if its involvement is unknown.

	I can hear someone complaining, that the ISP must protect the customer,
	and this is true, but if the law enforcement gets involved, the ISP must
	protect himself first, I guess, in all countries. So the point is, to
	evaluate the situation first before making a blind decision ...

	In addition, I believe all the tasks of 2.2 applies here also.

- Subsection 2.4:

	The paragraph about incidents is coming to late, as I missed the "inform	
	the customer" in 2.2 and 2.3, so please move this ahead.

	List another topic:

		- other impact on customer (like wrong billing, etc.)


Section 4:
----------

	I don't like the heading (and the emphasize of the introduction). I 
	believe, that it is in the best interest of the ISP to protect its 
	customer, so this should not be forgotten. By doing that, the ISP
	will also take proactive steps which will have benefits for the whole
	Internet. But if we speak about the ISPs role in regard to the Internet,
	we should highlight their *responsibility* to do so.

- Subsection 4.2:

	I will not comment on the pros and cons of Source Routing, just the
	thought (as explained above) that there is a way to combine protection
	and reasonable use which will fit both parties present in the recent
	discussion.

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


Section 5
---------

- Subsection 5.3:

	2nd paragraph: TFTP ... "lacks authentication, access control and
		uses an insecure channel, " ...

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


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.

- Subsection 6.3:

	This text will be better placed in the introduction to Section 6 and
	reference the other sections coming later containing all the details
	about the most important services.

- Subsection 6.5:

	Actually, the message digests must be protected while transmitting over
	insecure channels. So digital signatures (or faxes) should be mentioned
	here as well.


Section 7 to 10
---------------

	Pretty many topics are global to specific services 6.4 Backup etc.
	Shouldn't remote administration, using tools like Secure Shell,
	be handled within 6 to be consistent.


Section 8
---------

- Subsection 8.2:

	This was already handled under 2.6 or should be handled there at least.


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.

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

- Subsection 10.2:

	Please list plugins like Microsoft Frontpage extensions as well to
	get the attentions of others also.

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

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

- Subsection 10.3:

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

	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.

- Subsection 10.4:

	1st paragraph: HTTP daemon again


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.


--
Klaus-Peter Kossakowski
Univ. Hamburg, FB Informatik, kossakow@informatik.uni-hamburg.de