[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of recent GRIP drafts
Hi Barbara, hi all,
good to hear, that the meeting in Washington
went well. I appologize for not sending in these
comments earlier, but as the comments are
really a mix of trivial and fundamental things,
it is useful to send them to the list. If you go
through them and comment on non-trivial things
you disagree with (or whenever my comment is
not clear :) might be best as next step ...
I have reviewed all of the three recent GRIP
drafts. In regard to the
* draft-ietf-grip-isp-expectations-01.txt
I don't have any comment at all. From my point
of view this draft is ready and I am waiting
for the announced next draft to make a last pass.
* draft-ietf-grip-user-02.txt
The format is broken :(
We are talking about:
- connectivity consumers
- hosting service consumers
- co-located consumers
More or less only connectivity providers are
covered in isp-expectations-01.txt
SIRT / Security Incident Response Team is
better abbreviated as CSIRT = Computer SIRT?
"Some of the services provided by SIRT's
include: ..., Virtual Private Network (VPN)
and firewall management, and intrusion detection."
I wouldn't call that services which are
offered by SIRT's as part of their standard
services ....
In "2.2.4. Contact Information" I don't think,
that it is correct to set the expectations that
everyone *has* "security@...". (Certainly he
should :) Customers should
find out, whether the ISP adhere to this ...
(p7) Realtime response for security issues even
out of hours if the ISP has no 24x7 hotline
is very strong ...
(p7/8) "prevent random packets from flowing through
their network " is a rather strange expression
(p8) "Methods of segmenting networks " can also
be packet screens or firewalls except the section
is really only devoted to "Layer 2". But why should
only be Layer 2 of interest here. I think,
segmenting on level three is of similar
importance ...
(p8) "2.4" - I think it is not wise to suggest that
customer checks on version numbers of services
using TELNET! I would characterize that as an
attack depending on the circumstances
(p8) "2.5" - "For the really serious consumer, "
should be better phrased like: "For customers with
specific security requirements, " but this whole
section needs more careful review ... I don't think,
we want to suggest, that customers try penetration
tests on the ISP, what would be the purpose?
(p9) "3.2" - contains text not related to physical
security
(p10) "3.3" - what about physical security for
off-site backups?
(p10) "3.4/3.5" - what about backups for connectivity?
(p11) "3.7" - the security of remote access is not
considered, it makes a huge difference if root access
is possible using TELNET from somewhere on the INTERNET
or if they have to use SSH ...
(p11) "3.8" - the spin off the text about content
management on secure web servers is not complete,
think of SSL and MS Frontpage ... User Authentication
is missing total (Basic Level, SSL Client Certificates)
(p12) "4.3" - Layer 1 means something different than
fuses :)
(p12) "4.4" - Layer 2 is missing again.
Overall:
- there is no discussion of personal security (who has
access from ISP personal to hosting services - all or
designated employees, who has root access
- who controls monitoring files and logs, how often
- if logs are made, is the customer informed, are the
logs in line with privacy law. Especially if hosting
services are used, logs do not belong to the provider.
- if intrusion detection systems are used, what is
monitored (the customer might be liable to visitors
of his pages for lost of privacy)
This document needs work.
* draft-ietf-grip-ssh-add-00.txt
(p2) [RFCsshadd] is referenced within
the introduction. It must be the other
of the three documents. As this is a
Copy and Paste Error, the remaining
text needs attention and is wrong. It
includes even a pointer to Appendix A
with questions, which is not needed
here
(p3, Section 1) The purpose section
is somehow taken from SSH (?) but is
not tailored for the purpose of this
addition. It is mandatory to explain
the purpose of this ADDITION ....
(p4) There is a paragraph about "purpose"
under Section 2 AUDIENCE, this maybe
needs to go to Section 1. But the whole
section needs tailoring in differentiate
between the audience of the SSH and the
need for reading this addendum.
(p3/p4/p5) Somewhere upfront should be
a discussion about EXPECTATIONS FOR
ISPs and the RFC listed.
(p5-p7) Section 3 seems to be duplicated
from one of the other two drafts. Therefore
it needs to be removed to avoid
- duplications
- changes in one not made in the other
- ease of use
(p7/p8) Same goes at least for 4.1
(p9, 5.1) better access to routers, example
would be SSH as this also protects
transmission of configuration instead
of authentication only
(p9, end of 5.1) bootp is not one of the
"small" services?
(p9, 5.2) same considerations for maintenance
access: Authentication and Encryption
The whole remarks for logging what is being
done, traces for manipulations of configurations,
hold true for routers (5.1) also ... maybe this
should be used to structure the content ...
(p10, 5.3) HTTP is also used nowadays to
configure printers, routers, etc. and I don't
think, it is logged ...
Actually use of this measures across trust
boundaries should be discouraged
One example would be to tunnel TELNET/HTTP
through SSH connections ...
(p10, 5.4) The use of SNMP is unavoidable
within the operation of ISPs. I would like
to recommend to have
- best security available
- don't use SET over trust boundaries without
proper security
(p11, 5.5) not only 2nd layer security needs
to be considered, at least 3rd is of equal
importance
One point, that we need to cover (might
perhaps missing) is that ISPs / Hosts of
equipments need to help to ensure secure
access (private line, SSH, strong authentication
at least, ...)
(p12/13, 5.8) if you have a backbone where
everything has INGRESS filtering, there is
no purpose of EGRESS filtering ...
(several pages) there are sections without
SHOULD or one of the other keywords
(p15, 6) The term "system" should be explained
to exclude active network components but include
email servers, proxy server, intrusion detection
sensors ???? Depending on this definition the
claim "not on the backbone" might be impossible
to achieve ...
Also the difference between "user" systems
and service systems must be explained ...
(p16, 6.2) Critical systems shouldn't be
reachable from internal == systems of customers
systems either except for the ports designed
for the customer (POP, SMTP, HTTP, ...)
The statement about transit segments might
be difficult to meet, see comment p15, 6
Actually the ISPs should allow users to
CHANGE reusable passwords - often you get one
for the whole lifetime (and this is also your
POP password so it is likely that it is misused
while on travel).
(p16, 6.4) or digital signatures like PGP
(p17, 7.2) The 1st paragraph refer to customer.
I think, this is a oversight of the old draft
used to create the three new documents.
A search for customer should show whether
there are any other references ...
(p17, 7) Shouldn't we say, that ISPs SHOULD
move to DNSSEC as soon as possible.
It should be mentioned somewhere in 7, that
- exception reporting
- security patches and service packs
- restricting access to logs
are necessary. One could argue, that logs should
at least routinely be inspected for signs of
attacks.
(p18, 8) The remark of ISPs having responsibilities
is difficult, I just signed up, pay only a few bucks
so there is nothing that they can invest in my
education :)
More appropriate would be, that the ISPs are a
focal point whenever one of their customers is
responsible for an incident (Spam, Attack, ...)
or is victim of such event ...
(p19, 8.1) routine inspection of logs for signs
of attacks
(p19, 8.2) this add nothing to running an email
service, especially not for customers.
If we want them to help the customers to securely
communicate with them, we need to say something
about keys and certificates and directory servers.
Actually directory servers are not mentioned
in this document separetely ...
(p21, 9) In the 2nd paragraph the reference to
"YOU" also addresses the customer of an ISP.
This is not as bad as the RFC's audience are
organizations, but even so it should be replaced
by "users of the service" ...
It should be mentioned somewhere in 9, that
- exception reporting
- security patches and service packs
- routinely inspection of logs
are necessary.
(p23, 10.1) The recommendation not to lookup
DNS names for clients is to strong. It might
be necessary (based on policy) to do so ...
A reminder that this lookup enables DoS attacks
should be sufficient ...
It should be mentioned somewhere in 10, that
- exception reporting
- routinely inspection of logs
- restricting access to logs
are necessary.
(p25, 10.3) I don't understand the 1st paragraph.
It might be that data from other users of a
database interface is confidential, but you can
also think of a bulletin board system which
stores public values only ...
The same is true for the 3rd paragraph. Cookies
will be handed out to browsers, that is their
only justification to be there ...
(p26, 10.5) leading blanks for each line are
missing.
(p27, 10.7) the paragraph about backups should
be handled in 6.3, as these considerations apply
to all kind of services. Usage logs are also
high confidential.
(p27, 10.8) the remark on the denial of service
attack really isn't to the point. The ISP needs
to tell the customer that this might decrade
the level of service the server is able to
provide ... and unauthorized access must be
prevented ...
--
Klaus-Peter Kossakowski, Germany
Phone: (+49) 0171 / 5767010
Klaus-Peter@Kossakowski.DE