Re: draft-ietf-grip-isp-expectations-03.txt

[tomk@neart.org]

On Sat, 03 Jun 2000, Randy Bush wrote:

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

This issue was the subject of considerable discussion in GRIP working
group meetings.  The idea of doing due diligence in evaluating what 
universal implementability or applicability means was quickly discarded as
impossible and undesirable.  Another approach was to set the bar for
security expectations of ISPs as the lowest common denominator, however
the group agreed that doing nothing was preferable to this.  (It
appears that Mike, who wasn't present, favours the do-nothing approach).
The group concluded that the document should recommend secure technical
and business processes, even though such processes might not be an
option in every jurisdiction.  In one such GRIP meeting the suggestion of 
the sentence "Note, however, that in some jurisdictions secure channels 
might not be permitted" came from vendors/civil servants from countries 
(in Europe and SE Asia) where encryption technologies are less available
than in the US.

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

I'm very open to changing what appear to be mandates to advice.

>it is believed to be generally accepted practice that, until
>vulnerabilities are closed, announcing them 'pomptly' is ill-advised.

My text didn't recommend that announcements happen before the
vulnerabilities are closed, and my belief was that 'promptly' still left 
it to the discretion of the ISP to determine at what point the
announcement should take place.  I'd welcome suggestions that were less
open to misinterpretation.

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

It's widely agreed that the rotten apples have very efficient mechanisms
for disseminating information concerning vulnerabilites.  My point was
that it's reasonable (though not required) for ISPs to use the channels
available to them to inform their customers.  I didn't include anything
about the distribution of 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]..."

Were people really confused by what this meant ?  If so I'd like to talk
to them to find out how that could be, and what I could do to fix it.

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

Note that this document describes the expectations of the community.  And
it turns out that members of the community have expectations even of ISPs 
with whom they don't have a contracted commercial relationship.  Among
these are basic things such as an AUP.  The second paragraph, in which
an AUP is essentially defined, is basically lifted straight from section 
2.1.2 of rfc2196.  The example is changed to make it more relevant to
the audience at hand.

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

Not T&C, just the AUP.  In practice I find that incident response teams
at ISPs have no problem telling me what they consider appropriate and
what action they take in the event of inappropriate behaviour.

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

The point is simply that ISPs should be aware that in some of the 
jurisdictions where they operate such legislation may exist, and that
they may have an obligation to conform.  It's purely advisory.

>is "internic" the correct term these days?

No.  That will be a number of minor edits, along with SWIP.

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

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

Point taken - I'll do more research here.

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

How about just leaving the first sentence, and dropping the second ?

Tom.