Internet Draft						       T. Hansen
draft-ietf-grip-user-01.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 1.7

     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]

Copyright Notice

     Copyright (C) The Internet	Society (1998).	(1999).	 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.

     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

     Three types of customers are considered in	 this  document:   first
connectivity  customers,  then hosting customers, and finally co-located

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

     Some providers go even further and	offer services such  as	 Virtual
Private	 Network  (VPN)	 and  firewall	management, as well as intrusion
detection for a	substantial fee.

     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. response to an incident.  You	should also find
out if there is	any other SIRT whose constituency would	include	yourself
and  to	 whom incidents	could be reported.  You	may also be able to con-
tract these services from third-party companies	to  perform  these  ser-
vices on a routine or one-time basis.

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.

     You should	ask your ISP what information they will	be able	to  give
out  if	another	customer is the	party attacking	you to determine whether
or not their response is acceptable to you.   Some  providers  may  give
this  information  freely, while others	will not release the identity of
the attacker without a court order.

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

     -	  the  expected	 schedule  for	response,  assuming  it	 can  be

     -	  the trouble ticket number being used to track	the incident  by
	  the  provider,  or  other  suitable  means  of identifying the
	  incident at a	later date.

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.your.isp.example/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.4.1.	After Hours
You should recieve information for reaching customer support  or  opera-
tions personnel	on a 24x7 (24 hours, 7 days per	week) basis.  If the ISP
does not maintain 24x7 operations (NOC,	Customer  Support,  etc.)   then
some  means  of	 reaching  customer  support  after  hours  for	security
incidents should be relayed to you in advance.

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
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
their portion 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

     -	  capable of preventing	internal illegal  traffic  (bogus  route
	  announcements,  spoofed traffic, etc.) generated by its custo-
	  mers from reaching the global	Internet

5.  Physical Security  Concerns Specific to Hosting Service Customers

     [Ed: this section is totally new and needs	lots of	work.]

     If	you are	hosting	content	on your	ISP, you  have	additional  con-

     -	  Generally there is a separate	AUP from that used  for	 connec-
	  tivity customers.

     -	  These	machines may be	housed in unlocked cabinets.   As  such,
	  there	 must  be  tight restrictions as to who	may have access.
	  Electronic access control, guards, video  surveillance,  etc.,
	  are  all  fair  game.	  All  visitors	 ESPECIALLY  need  to be
	  escorted, as the potential for damage	is much	higher than in a
	  colocation situation.

     -	  As the customer is not generally responsible for securing  the
	  operating   system  or  applications,	 there	needs  to  be  a
	  heightened understanding of how the ISP reacts.

     -	  If you also get connectivity from the	ISP (i.e.,  a  T1),  you
	  should  check	 to see	if security for	the managed site is done
	  by a different group and check to see	if  the	 procedures  for
	  reporting and	notification are much different.

     -	  A modality for backups must be included, as the  ISP	will  be
	  doing	 the  majority	of these.  Most	providers also have off-
	  site backup services.

     -	  Other	customers may legitimately cause  a  denial  of	 service
	  attack  by  hogging  all  of	the network capacity.  Providers
	  should have standards	as far as how saturated	 their	networks
	  may get, and should prevent this from	occurring.

     -	  Cold site facilities,	and hot	spare hardware can be  important
	  when	recovering  from  an incident.	Customers should inquire
	  with the ISP if this is important to them.

     -	  Providers should do a	good deal of proactive testing	against,
	  and active patching of the OS	and application	loads.	As these
	  loads	tend to	be the same from customer to customer,	the  ISP
	  should be responsible	in assuring host based security.

     -	  Many providers offer a managed security service for additional
	  fees.	  Customers  are encouraged to find out	what is	included
	  in the service that  they  are  paying  for,	and  to	 explore
	  options as far as what they can do.

     -	  Generally there is option of whether or not the customer  even
	  has root privs.

6.  Concerns Specific to Co-location Customers

     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.

6.1.  Acceptable Use Policy
The AUP	for co-located customers is usually different from that	used  by
connectivity customers.	 You should inquire about the AUP.

6.2.  Separated	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 by a guard,  with	 keys  or  elec-
tronic	access	control	that grant access specifically to their cage.	cage, or
some combination thereof.

     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
an  open  common  area.	  Another  alternative	are  cabinets  which can
separate all of	 the  facilities  within  the  same  cabinet,  and  have
independent locking mechanisms for each	portion	of the rack.

     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

6.3.  Layer 1 Security

     Also of importance	is "layer 1" security of  co-located  equipment.
Other  customers should	not blow the same fuse that you	are on by power-
ing all	their machines up at once.  The	ISP can	control	this  by  having
separate breakers and circuits for each	customer, or by	overbuilding the
power system and keeping track of the power ratings of all equipment  in

6.4.  Layer 2 Security

     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.  The use of	a switch
is generally recommended for this sort of thing.

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


8.  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 Stikvoort, Bill Woodcock.

8. Woodcock	and Chris Kuivenhoven.

9.  Security

     This entire document discusses security issues.

9.  Author's Address

10.  Authors' Addresses

Tony Hansen
AT&T Laboratories
Lincroft, NJ 07738

Phone: +1 732 576-3207

Tom Killalea
Verio Northwest
15400 SE 30th Pl., Ste. 202
1516 2nd Ave
Seattle, WA 98007-6546 98101

Phone: +1 425 649-7417 206 694-2196


11.  Full Copyright Statement

     Copyright (C) The Internet	Society (1998).	(1999).	 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

     This document expires August 1999.