[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-grip-isp-expectations-03.txt
more notes from last call iesg input and discussion
randy
---
there is a difference between describing good security practice and
mandating technical and business processes which may not be universally
implementable, universally applicable, or particularly sensible.
the following are examples. as mo says, the problem is actually the
pervasive attitude. many of the examples would be much more reasonable
if phrased as advice, e.g. "standards for better email security are
evolving, see for example [rfcfoux rfcbarre]. it would be constructive
if isps kept abreast of these advances, tried to support them, and kept
their customer base aware of them and how to take advantage of them."
---
it is believed to be generally accepted practice that, until
vulnerabilities are closed, announcing them 'pomptly' is ill-advised.
yet, in the guise of good communication, we see the following:
When security incidents occur that affect components of an ISP's
infrastructure the ISP should promptly report to their customers
- who is coordinating response to the incident
- the vulnerability
- how service was affected
- what is being done to respond to the incident
- whether customer data may have been compromised
- what is being done to eliminate the vulnerability
- the expected schedule for response, assuming it can be
predicted
---
given the sadly high number of rotten apples in today's barrels, is the
following really wise?
Many ISPs have established procedures for notifying customers of
outages and service degradation. It is reasonable for the ISP to use
these channels for reporting security-related incidents. In such
cases, the customer's security point of contact might not be the
person notified. Rather, the normal point of contact will receive
the report. Customers should be aware of this and make sure to route
such notifications appropriately.
separation of vetted security channels is becoming more the norm. and
an isp may not want to tell non-vetted customers about vulnerabilities
and their exploitations.
---
Whether or not an ISP has a CSIRT, they should have a well-advertised
way to receive and handle reported incidents from their customers.
In addition, they should clearly document their capability to respond
to reported incidents ...
some wondered if this was requiring "dear crackers. we are not very
capable of responding to incidents [of type x]..."
---
Every ISP SHOULD have an Appropriate Use Policy (AUP).
An AUP should clearly identify what customers shall and shall not do
on the various components of a system or network, including the type
of traffic allowed on the networks. The AUP should be as explicit as
possible to avoid ambiguity or misunderstanding. For example, an AUP
might prohibit IP spoofing.
this seems to prescribe legal aspects of how an isp does business, and
at level of detail which one would only expect from paid council.
---
In addition to communicating their AUP to their customers ISPs should
publish their policy in a public place such as their web site so that
the community can be aware of what the ISP considers appropriate and
can know what action to expect in the event of inappropriate
behaviour.
do we really have the prerogative to tell an isp that and how they
should reveal the terms and conditions of their customer contracts?
---
Many jurisdictions have Data Protection Legislation. Where such
legislation applies, ISPs should consider the personal data they hold
and, if necessary, register themselves as Data Controllers and be
prepared to only use the data in accordance with the terms of the
legislation.
this seems to assume pre-knowledge of local legislation. what if the
local legislagtion is about protecting information on what chocolate is
consumed, and not about personal data? this seems to specify *what*
subjects are protected by local legislation, and we can't really know
it.
---
ISPs are commonly responsible for maintaining the data that is stored
in global repositories such as the Internet Routing Registry (IRR)
and the APNIC, InterNIC and RIPE databases. Updates to this data
should only be possible using strong authentication.
is "internic" the correct term these days?
some isps do not believe in the registries and do not choose to use
them. that is their prerogative. it actually seems to make them no
less stable than those which use registries and filtering. this may be
partially due to the data being less usable than advertised (routers
will not handle an acl the size of a tier-1's).
and not all registries support strong authentication. and even if they
did, do we have the prerogative to tell isps how to do business with
registries? yes, it might be a good idea. but this waxes overly-
prescriptive again.
---
ISPs should 'SWIP' (Shared WhoIs Project) the address space that they
assign to their customers so that there is more specific contact
information for the delegated space.
swip is an americanism. and a dying one (see distributed whois, which
sucks too).
---
An ISP's ability to route traffic to the correct destination depends
on routing policy as configured in the routing registries [RFC1786].
not necessarily. some really don't do it that way.
---
ISPs should also strongly encourage their customers to disable open
relaying on their mail servers. Sanctions for running an open mail
relay should be covered in an ISP's AUP.
there are knowledgable isp lawyers who seem not to support this advice.
it seems to have to do with it being hard to show that a customer
running an open relay directly damages the isp. that it incites net
vigilantes to write nastygrams to one;s management and noc may not be
any more evil than, e.g., a porn site (which we may not like, but may
not have the legal prerogative to proscribe).
---
"open mail relay" is sometimes a matter of degree; the language, as
written, seems to leave determination of whether or not my relay is open
up to the anti-spam crazies.
-30-