[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-grip-isp-00.txt (summarized comments)
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!
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
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.
I would put Section 2 about Incident Response at the end, as this applies
mainly when security fails.
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
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.)
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
- 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 (!).
- 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).
- 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.
- Subsection 8.2:
This was already handled under 2.6 or should be handled there at least.
This section in particular fit to another group of people to address:
- 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
- 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
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.
Univ. Hamburg, FB Informatik, email@example.com