draft-ietf-grip-user-00.txt   draft-ietf-grip-user-01.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-grip-user-00.txt AT&T Laboratories draft-ietf-grip-user-01.txt AT&T Laboratories
Valid for six months T. Killalea Valid for six months T. Killalea
Verio Northwest
January 31, 1999 January 31, 1999
Security Expectations for Internet Service Provider Consumers Security Expectations for Internet Service Provider Consumers
<draft-ietf-grip-user-00.txt> <draft-ietf-grip-user-01.txt>
Author's version: 1.5 Author's version: 1.7
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This memo and its companions are discussed on the GRIP working This memo and its companions are discussed on the GRIP working
group mailing list, grip-wg[-request]@uu.net. group mailing list, grip-wg[-request]@uu.net.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
The purpose of this document is to provide information to the gen- The purpose of this document is to provide information to the gen-
eral Internet community regarding security expectations of Internet Ser- eral Internet community regarding security expectations of Internet Ser-
vice Providers (ISPs). vice Providers (ISPs).
It is not the intent of this document to define a set of require- 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 ments that would be appropriate for all ISPs, but rather to provide the
community with a framework for discussion of security expectations with community with a framework for discussion of security expectations with
skipping to change at page 2, line 32 skipping to change at page 2, line 32
This document is addressed to Internet service purchasing This document is addressed to Internet service purchasing
decision-makers (customers). decision-makers (customers).
It has been argued that vendors begin to care about security only It has been argued that vendors begin to care about security only
when prompted by customers. We hope that these documents will encourage when prompted by customers. We hope that these documents will encourage
both parties to more readily express how much they care about security, both parties to more readily express how much they care about security,
and that discussion between the community and its ISPs will be and that discussion between the community and its ISPs will be
increased. increased.
Three types of customers are considered in this document: first
connectivity customers, then hosting customers, and finally co-located
customers.
1.1. Conventions Used in this Document 1.1. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described in NOT", and "MAY" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
2. Incident Response 2. Incident Response
A Security Incident Response Team (SIRT) is a team that performs, A Security Incident Response Team (SIRT) is a team that performs,
coordinates, and supports the response to security incidents that coordinates, and supports the response to security incidents that
skipping to change at page 2, line 49 skipping to change at page 3, line 4
A Security Incident Response Team (SIRT) is a team that performs, A Security Incident Response Team (SIRT) is a team that performs,
coordinates, and supports the response to security incidents that coordinates, and supports the response to security incidents that
involve sites within a defined constituency. The Internet community's involve sites within a defined constituency. The Internet community's
expectations of SIRTs are described in [BCP21]. expectations of SIRTs are described in [BCP21].
2.1. ISPs and Security Incident Response Teams 2.1. ISPs and Security Incident Response Teams
Some ISPs have Security Incident Response Teams (SIRTs). However Some ISPs have Security Incident Response Teams (SIRTs). However
it should not be assumed that either the ISP's connectivity customers or 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 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 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 an added-cost service, with the team defining as their constituency only
those who specifically subscribe to (and perhaps pay for) Incident those who specifically subscribe to (and perhaps pay for) Incident
Response services. 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- Thus it's important to determine what incident response and secu-
rity resources are available to you, and define your incident response rity resources are available to you, and define your incident response
escalation chain BEFORE an incident occurs. escalation chain BEFORE an incident occurs.
You should find out if your ISP has a SIRT, and if so what the 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 charter, policies and services of that team are. (This information is
best expressed using the SIRT template as shown in Appendix D of best expressed using the SIRT template as shown in Appendix D of
[BCP21].) [BCP21].)
If the ISP doesn't have a SIRT, you should find out what role, if 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 any, they WILL take in response to an incident. You should also find
there is any other SIRT whose constituency would include yourself and to out if there is any other SIRT whose constituency would include yourself
whom incidents could be reported. 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 2.2. Assistance with Inbound Security Incidents
When a security incident targeting one of their connectivity custo- When a security incident targeting one of their connectivity custo-
mers occurs, you should expect your ISP to inform you of the attack, mers occurs, you should expect your ISP to inform you of the attack,
provide assistance to trace the attack, and collect and protect evidence provide assistance to trace the attack, and collect and protect evidence
of the incident and guard against its destruction or unintentional of the incident and guard against its destruction or unintentional
announcement. If the event continues, you may ask the ISP to provide announcement. If the event continues, you may ask the ISP to provide
logging in order to further diagnose the problem, or to perform filter- logging in order to further diagnose the problem, or to perform filter-
ing of certain types of traffic. 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 2.3. Notification of Vulnerabilities and Reporting of Incidents
You should expect your ISP to be proactive in notifying you of You should expect your ISP to be proactive in notifying you of
security vulnerabilities in the services they provide. In addition, as security vulnerabilities in the services they provide. In addition, as
new vulnerabilities in systems and software are discovered, they should new vulnerabilities in systems and software are discovered, they should
indicate whether their services are threatened by these risks. indicate whether their services are threatened by these risks.
When security incidents occur that affect components of an ISP's When security incidents occur that affect components of an ISP's
infrastructure, your ISP SHOULD promptly report to you: infrastructure, your ISP SHOULD promptly report to you:
skipping to change at page 4, line 4 skipping to change at page 4, line 19
- the vulnerability - the vulnerability
- how service was affected - how service was affected
- what is being done to respond to the incident - what is being done to respond to the incident
- whether customer data may have been compromised - whether customer data may have been compromised
- what is being done to eliminate the vulnerability - what is being done to eliminate the vulnerability
- the expected schedule for response, assuming it can be - the expected schedule for response, assuming it can be
predicted predicted
- 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 2.4. Contact Information
If you need to contact someone at your ISP, you should use the If you need to contact someone at your ISP, you should use the
address SECURITY@your.isp.example for network security issues, address SECURITY@your.isp.example for network security issues,
ABUSE@your.isp.example for issues relating to inappropriate public ABUSE@your.isp.example for issues relating to inappropriate public
behaviour, and NOC@your.isp.example for issues relating to network behaviour, and NOC@your.isp.example for issues relating to network
infrastructure. ([RFC2142] states that sites (including ISPs) must infrastructure. ([RFC2142] states that sites (including ISPs) must
maintain these mailboxes, as well as additional mailboxes that are maintain these mailboxes, as well as additional mailboxes that are
defined for receiving queries and reports relating to specific ser- defined for receiving queries and reports relating to specific ser-
vices.) Your ISP may also have web site addresses (e.g., 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 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 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]. 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 2.5. Communication and Authentication
You should expect your ISP to have clear policies and procedures on You should expect your ISP to have clear policies and procedures on
the sharing of information about a security incident with you, other the sharing of information about a security incident with you, other
ISPs or SIRTs, with law enforcement, and with the press and the general 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 public. If your jurisdiction permits, you should expect to be able to
conduct such communication with your ISP over a secure channel. conduct such communication with your ISP over a secure channel.
3. Policies 3. Policies
3.1. Security Policy 3.1. Security Policy
You should expect your ISP to have a policy with regard to privacy, You should expect your ISP to have a policy with regard to privacy,
authentication, accountability, application of security patches, availa- authentication, accountability, application of security patches, availa-
bility and violations reporting. bility and violations reporting.
skipping to change at page 5, line 24 skipping to change at page 5, line 49
3.4. Announcement of Policies 3.4. Announcement of Policies
You should expect your ISP to publish their security and appropri- 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, 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 the community can be aware of what the ISP considers appropriate and can
know what action to expect in the event of inappropriate behaviour. know what action to expect in the event of inappropriate behaviour.
4. Network Infrastructure 4. Network Infrastructure
Your ISP is responsible for managing the network infrastructure of Your ISP is responsible for managing the network infrastructure of
the Internet in such a way that it is: their portion of the Internet in such a way that it is:
- reasonably resistant to known security vulnerabilities - reasonably resistant to known security vulnerabilities
- not easily hijacked by attackers for use in subsequent attacks - not easily hijacked by attackers for use in subsequent attacks
5. Physical Security - capable of preventing internal illegal traffic (bogus route
announcements, spoofed traffic, etc.) generated by its custo-
mers from reaching the global Internet
5. 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-
cerns.
- 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- If you have co-located equipment at your ISP's facility, the physi-
cal security of the installation should be given appropriate considera- cal security of the installation should be given appropriate considera-
tion. This is particularly so for co-located facilities to which people tion. This is particularly so for co-located facilities to which people
from different organisations and with different security policies have from different organisations and with different security policies have
access. Many issues arise surrounding customer access to their co- access. Many issues arise surrounding customer access to their co-
located equipment. 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 Ideally you and each other customer SHOULD have a fully enclosed
locking 'cage', akin to a small room with walls and ceiling of heavy locking 'cage', akin to a small room with walls and ceiling of heavy
wire mesh fencing, containing the racks in which their equipment is wire mesh fencing, containing the racks in which their equipment is
mounted. Each customer would be allowed access to their own cage under 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 escort by one of the ISP's employees, by a guard, with keys or elec-
specifically to their cage. tronic access control that grant access specifically to their cage, or
some combination thereof.
This assignment of separate cages is expensive in terms of space This assignment of separate cages is expensive in terms of space
however, so many ISPs compromise by putting all co-located equipment however, so many ISPs compromise by putting all co-located equipment
together in a single machine room, and managing the actions of escorted together in a single machine room, and managing the actions of escorted
customers very closely. However this may be insufficient to prevent customers very closely. However this may be insufficient to prevent
mishaps such as the accidental disconnection of another customer's mishaps such as the accidental disconnection of another customer's
equipment. If a single machine room is used then the ISP SHOULD provide equipment. If a single machine room is used then the ISP SHOULD provide
separate locking cabinets for each co-location customer in preferance to separate locking cabinets for each co-location customer in preferance to
an open common area. Another alternative are cabinets which can
an open common area. 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 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 presence of any equipment that is not yours, and should not expect to be
allowed to touch, photograph, or examine equipment belonging to another allowed to touch, photograph, or examine equipment belonging to another
customer. customer.
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
use.
6.4. Layer 2 Security
Also of concern is layer 2 security of co-located equipment. Your Also of concern is layer 2 security of co-located equipment. Your
equipment SHOULD NOT be allowed to share a physical network segment with equipment SHOULD NOT be allowed to share a physical network segment with
hosts belonging to anyone else, whether another customer or the ISP hosts belonging to anyone else, whether another customer or the ISP
themselves. It's common for crackers to exploit weak security or unen- themselves. It's common for crackers to exploit weak security or unen-
crypted remote logins on co-located customer-owned equipment to take crypted remote logins on co-located customer-owned equipment to take
control of that equipment and put it into promiscuous listening mode on control of that equipment and put it into promiscuous listening mode on
the local network segment, thereby potentially compromising the privacy the local network segment, thereby potentially compromising the privacy
and security of any other devices on that segment. and security of any other devices on that segment. The use of a switch
is generally recommended for this sort of thing.
6. References 7. References
[BCP21] Brownlee, N and E. Guttman, "Expectations for Computer [BCP21] Brownlee, N and E. Guttman, "Expectations for Computer
Security Incident Response", BCP 21, RFC 2350, June 1998. Security Incident Response", BCP 21, RFC 2350, June 1998.
[RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
Karrenberg, D., Terpstra, M., and J. Yu, "Representation Karrenberg, D., Terpstra, M., and J. Yu, "Representation
of IP Routing Policies in a Routing Registry (ripe- of IP Routing Policies in a Routing Registry (ripe-
81++)", RFC 1786, March 1995. 81++)", RFC 1786, March 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 6, line 44 skipping to change at page 8, line 49
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles
and Functions", RFC 2142, May 1997. and Functions", RFC 2142, May 1997.
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997. 2195, September 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
1997. 1997.
7. Acknowledgements 8. Acknowledgements
We gratefully acknowledge the constructive comments received from We gratefully acknowledge the constructive comments received from
Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall
Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski,
Michael A. Patton, Don Stikvoort and Bill Woodcock. Michael A. Patton, Don Stikvoort, Bill Woodcock and Chris Kuivenhoven.
8. Security 9. Security
This entire document discusses security issues. This entire document discusses security issues.
9. Author's Address 10. Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
Lincroft, NJ 07738 Lincroft, NJ 07738
USA USA
Phone: +1 732 576-3207 Phone: +1 732 576-3207
E-Mail: tony@att.com E-Mail: tony@att.com
Tom Killalea Tom Killalea
Verio Northwest 1516 2nd Ave
15400 SE 30th Pl., Ste. 202 Seattle, WA 98101
Bellevue, WA 98007-6546
USA USA
Phone: +1 425 649-7417 Phone: +1 206 694-2196
E-Mail: tomk@nw.verio.net E-Mail: tomk@neart.ie
10. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and dis- assist in its implmentation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organisations, references to the Internet Society or other Internet organisations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
skipping to change at page 8, line 4 skipping to change at page 10, line 8
which case the procedures for copyrights defined in the Internet Stan- which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into dards process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE." FITNESS FOR A PARTICULAR PURPOSE.
This document expires August 1999. This document expires August 1999.
 End of changes. 36 change blocks. 
32 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/