[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02                                                      
Internet Draft                                                 T. Hansen
draft-ietf-grip-user-00.txt                            AT&T Laboratories
Valid for six months                                         T. Killalea
                                                         Verio Northwest
                                                        January 31, 1999

     Security Expectations for Internet Service Provider Consumers


                         Author's version: 1.5

     Status of this Memo

     This document is an Internet-Draft and is in full conformance  with
all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the  Internet  Engineering
Task  Force  (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid  for  a  maximum  of  six
months  and may be updated, replaced, or obsoleted by other documents at
any time.  It is  inappropriate  to  use  Internet-Drafts  as  reference
material or to cite them other than as "work in progress."

     To  view  the   list   Internet-Draft   Shadow   Directories,   see

     This memo and its companions are  discussed  on  the  GRIP  working
group mailing list, grip-wg[-request]@uu.net.

Copyright Notice

     Copyright (C) The Internet Society (1998).  All Rights Reserved.


     The purpose of this document is to provide information to the  gen-
eral Internet community regarding security expectations of Internet Ser-
vice Providers (ISPs).

     It is not the intent of this document to define a set  of  require-
ments  that would be appropriate for all ISPs, but rather to provide the
community with a framework for discussion of security expectations  with
current and prospective service providers.

Hansen                                                          [Page 1]

Internet Draft  Security Expectations for ISP Consumers January 31, 1999

     This document is written from  the  perspective  of  the  consumer.
Companion documents provide information from the ISP perspective.

1.  Introduction

     The purpose of this  document,  and  its  companions  [RFCisp]  and
[RFCsshadd], is to express the general Internet community's expectations
of Internet Service Providers (ISPs) with respect to security.

     A goal is that customers could have a framework to  facilitate  the
discussion  of security with prospective service providers; regrettably,
such a discussion rarely takes place today.

     Additionally, in informing ISPs of what  the  community  hopes  and
expects of them, a further goal is to encourage ISPs to become proactive
in making security not only a priority,  but  something  to  which  they
point with pride when selling their services.

     This  document  is  addressed  to   Internet   service   purchasing
decision-makers (customers).

     It has been argued that vendors begin to care about  security  only
when prompted by customers.  We hope that these documents will encourage
both parties to more readily express how much they care about  security,
and  that  discussion  between  the  community  and  its  ISPs  will  be

1.1.  Conventions Used in this Document

     The key words "REQUIRED", "MUST",  "MUST  NOT",  "SHOULD",  "SHOULD
NOT",  and  "MAY" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

2.  Incident Response

     A Security Incident Response Team (SIRT) is a team  that  performs,
coordinates,  and  supports  the  response  to  security  incidents that
involve sites within a defined constituency.  The  Internet  community's
expectations of SIRTs are described in [BCP21].

2.1.  ISPs and Security Incident Response Teams

     Some ISPs have Security Incident Response Teams  (SIRTs).   However
it should not be assumed that either the ISP's connectivity customers or
a site being attacked by a customer of that ISP can automatically  avail
of the services of the ISP's SIRT.  ISP SIRTs are frequently provided as
an added-cost service, with the team defining as their constituency only
those  who  specifically  subscribe  to  (and  perhaps pay for) Incident

Hansen                                                          [Page 2]

Internet Draft  Security Expectations for ISP Consumers January 31, 1999

Response services.

     Thus it's important to determine what incident response  and  secu-
rity  resources  are available to you, and define your incident response
escalation chain BEFORE an incident occurs.

     You should find out if your ISP has a SIRT,  and  if  so  what  the
charter,  policies  and services of that team are.  (This information is
best expressed using the  SIRT  template  as  shown  in  Appendix  D  of

     If the ISP doesn't have a SIRT, you should find out what  role,  if
any,  they  WILL take in incident response.  You should also find out if
there is any other SIRT whose constituency would include yourself and to
whom incidents could be reported.

2.2.  Assistance with Inbound Security Incidents

     When a security incident targeting one of their connectivity custo-
mers  occurs,  you  should  expect your ISP to inform you of the attack,
provide assistance to trace the attack, and collect and protect evidence
of  the  incident  and  guard  against  its destruction or unintentional
announcement.  If the event continues, you may ask the  ISP  to  provide
logging  in order to further diagnose the problem, or to perform filter-
ing of certain types of traffic.

2.3.  Notification of Vulnerabilities and Reporting of Incidents

     You should expect your ISP to be  proactive  in  notifying  you  of
security  vulnerabilities in the services they provide.  In addition, as
new vulnerabilities in systems and software are discovered, they  should
indicate whether their services are threatened by these risks.

     When security incidents occur that affect components  of  an  ISP's
infrastructure, your ISP SHOULD promptly report to you:

     -    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

Hansen                                                          [Page 3]

Internet Draft  Security Expectations for ISP Consumers January 31, 1999

     -    the  expected  schedule  for  response,  assuming  it  can  be

2.4.  Contact Information

     If you need to contact someone at your  ISP,  you  should  use  the
address   SECURITY@your.isp.example   for   network   security   issues,
ABUSE@your.isp.example  for  issues  relating  to  inappropriate  public
behaviour,  and  NOC@your.isp.example  for  issues  relating  to network
infrastructure.  ([RFC2142] states  that  sites  (including  ISPs)  must
maintain  these  mailboxes,  as  well  as  additional mailboxes that are
defined for receiving queries and  reports  relating  to  specific  ser-
vices.)    Your   ISP   may   also   have   web  site  addresses  (e.g.,
http://www.ISP-name-here.net/security/) that you may use  to  check  for
expanded  details on the above.  You should also be able to find contact
information for your ISP in Whois and in the routing registry [RFC1786].

2.5.  Communication and Authentication

     You should expect your ISP to have clear policies and procedures on
the  sharing  of  information  about a security incident with you, other
ISPs or SIRTs, with law enforcement, and with the press and the  general
public.   If  your jurisdiction permits, you should expect to be able to
conduct such communication with your ISP over a secure channel.

3.  Policies

3.1.  Security Policy

     You should expect your ISP to have a policy with regard to privacy,
authentication, accountability, application of security patches, availa-
bility and violations reporting.

     A more detailed discussion of Security Policy can be found  in  the
Site Security Handbook [RFC2196].

3.2.  Appropriate Use Policy

     When you establish a contract with your ISP to provide connectivity
to  the Internet, that contract SHOULD be governed by an Appropriate Use
Policy (AUP).  The AUP SHOULD clearly identify what you may and may  not
do  on  the  various  components of the 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.

     The AUP should be reviewed each time you renew your contract.   You
should  also expect your ISP to proactively notify you as their policies

Hansen                                                          [Page 4]

Internet Draft  Security Expectations for ISP Consumers January 31, 1999

are updated.

3.3.  Sanctions

     You should expect the AUP to be clear  in  stating  what  sanctions
will  be  enforced  in the event of inappropriate behaviour.  You should
also expect your ISP to be forthcoming in announcing  to  the  community
when such sanctions are imposed.

3.4.  Announcement of Policies

     You should expect your ISP to publish their security and  appropri-
ate  use  policies  in a public place such as their web site.  This way,
the community can be aware of what the ISP considers appropriate and can
know what action to expect in the event of inappropriate behaviour.

4.  Network Infrastructure

     Your ISP is responsible for managing the network infrastructure  of
the Internet in such a way that it is:

     -    reasonably resistant to known security vulnerabilities

     -    not easily hijacked by attackers for use in subsequent attacks

5.  Physical Security

     If you have co-located equipment at your ISP's facility, the physi-
cal  security of the installation should be given appropriate considera-
tion.  This is particularly so for co-located facilities to which people
from  different  organisations and with different security policies have
access.  Many issues arise surrounding  customer  access  to  their  co-
located equipment.

     Ideally you and each other customer SHOULD have  a  fully  enclosed
locking  'cage',  akin  to  a small room with walls and ceiling of heavy
wire mesh fencing, containing the racks  in  which  their  equipment  is
mounted.   Each customer would be allowed access to their own cage under
escort by one of the ISP's employees, or with  keys  that  grant  access
specifically to their cage.

     This assignment of separate cages is expensive in  terms  of  space
however,  so  many  ISPs  compromise by putting all co-located equipment
together in a single machine room, and managing the actions of  escorted
customers  very  closely.   However  this may be insufficient to prevent
mishaps such as  the  accidental  disconnection  of  another  customer's
equipment.  If a single machine room is used then the ISP SHOULD provide
separate locking cabinets for each co-location customer in preferance to

Hansen                                                          [Page 5]

Internet Draft  Security Expectations for ISP Consumers January 31, 1999

an open common area.

     You should expect to always be supervised  while  in  the  physical
presence of any equipment that is not yours, and should not expect to be
allowed to touch, photograph, or examine equipment belonging to  another

     Also of concern is layer 2 security of co-located equipment.   Your
equipment SHOULD NOT be allowed to share a physical network segment with
hosts belonging to anyone else, whether  another  customer  or  the  ISP
themselves.   It's common for crackers to exploit weak security or unen-
crypted remote logins on co-located  customer-owned  equipment  to  take
control  of that equipment and put it into promiscuous listening mode on
the local network segment, thereby potentially compromising the  privacy
and security of any other devices on that segment.

6.  References

     [BCP21]   Brownlee, N and E. Guttman,  "Expectations  for  Computer
               Security Incident Response", BCP 21, RFC 2350, June 1998.

     [RFC1786] Bates, T., Gerich, E., Joncheray,  L.,  Jouanigot,  J-M.,
               Karrenberg,  D., Terpstra, M., and J. Yu, "Representation
               of IP Routing  Policies  in  a  Routing  Registry  (ripe-
               81++)", RFC 1786, March 1995.

     [RFC2119] Bradner, S., "Key words  for  use  in  RFCs  to  Indicate
               Requirement Levels", RFC 2119, March 1997.

     [RFC2142] Crocker, D., "Mailbox Names for  Common  Services,  Roles
               and Functions", RFC 2142, May 1997.

     [RFC2195] Klensin, J.,  Catoe,  R.,  and  P.  Krumviede,  "IMAP/POP
               AUTHorize  Extension  for Simple Challenge/Response", RFC
               2195, September 1997.

     [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September

7.  Acknowledgements

     We gratefully acknowledge the constructive comments  received  from
Nevil  Brownlee,  Randy  Bush, Bill Cheswick, Barbara Y. Fraser, Randall
Gellens, Erik Guttman, Larry J.  Hughes  Jr.,  Klaus-Peter  Kossakowski,
Michael A. Patton, Don Stikvoort and Bill Woodcock.

Hansen                                                          [Page 6]

Internet Draft  Security Expectations for ISP Consumers January 31, 1999

8.  Security

     This entire document discusses security issues.

9.  Author's Address

Tony Hansen
AT&T Laboratories
Lincroft, NJ 07738

Phone: +1 732 576-3207
E-Mail: tony@att.com

Tom Killalea
Verio Northwest
15400 SE 30th Pl., Ste. 202
Bellevue, WA 98007-6546

Phone: +1 425 649-7417
E-Mail: tomk@nw.verio.net

10.  Full Copyright Statement

     Copyright (C) The Internet Society (1998).  All Rights Reserved.

     This document and translations of it may be copied and furnished to
others,  and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and  dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included  on  all
such copies and derivative works.  However, this document itself may not
be modified in any way, such as by  removing  the  copyright  notice  or
references  to  the  Internet  Society  or other Internet organisations,
except as needed for the purpose of  developing  Internet  standards  in
which  case  the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as  required  to  translate  it  into
languages other than English.

     The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is  provided  on

Hansen                                                          [Page 7]

Internet Draft  Security Expectations for ISP Consumers January 31, 1999


     This document expires August 1999.

Hansen                                                          [Page 8]