| < draft-ietf-opsec-current-practices-02.txt | draft-ietf-opsec-current-practices-03.txt > | |||
|---|---|---|---|---|
| OPSEC M. Kaeo | OPSEC M. Kaeo | |||
| Internet-Draft Double Shot Security, Inc. | Internet-Draft Double Shot Security, Inc. | |||
| Expires: January 18, 2006 July 17, 2005 | Expires: November 25, 2006 May 24, 2006 | |||
| Operational Security Current Practices | Operational Security Current Practices | |||
| draft-ietf-opsec-current-practices-02 | draft-ietf-opsec-current-practices-03 | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| 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 | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on January 18, 2006. | This Internet-Draft will expire on November 25, 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| This document is a survey of the current practices used in today's | This document is a survey of the current practices used in today's | |||
| large ISP operational networks to secure layer 2 and layer 3 | large ISP operational networks to secure layer 2 and layer 3 | |||
| infrastructure devices. The information listed here is the result of | infrastructure devices. The information listed here is the result of | |||
| information gathered from people directly responsible for defining | information gathered from people directly responsible for defining | |||
| and implementing secure infrastructures in Internet Service Provider | and implementing secure infrastructures in Internet Service Provider | |||
| environments. | environments. | |||
| skipping to change at page 27, line 14 ¶ | skipping to change at page 27, line 14 ¶ | |||
| Filters are used to limit access to uploading/downloading | Filters are used to limit access to uploading/downloading | |||
| configuration files and system images to specific IP addresses and | configuration files and system images to specific IP addresses and | |||
| protocols. | protocols. | |||
| The software images perform CRC-checks but many ISPs expressed | The software images perform CRC-checks but many ISPs expressed | |||
| interest in having software image integrity validation based on the | interest in having software image integrity validation based on the | |||
| MD5 algorithm for enhanced security. The system binaries use the MD5 | MD5 algorithm for enhanced security. The system binaries use the MD5 | |||
| algorithm to validate integrity. | algorithm to validate integrity. | |||
| In all configuration files, the passwords are stored in an obfuscated | In all configuration files, most passwords are stored in an | |||
| format. This includes passwords for user authentication, MD5 shared | obfuscated format. This includes passwords for user authentication, | |||
| secrets, AAA server shared secrets, NTP shared secrets, etc. For | MD5 shared secrets, AAA server shared secrets, NTP shared secrets, | |||
| older software which may not support this functionality, | etc. For older software which may not support this functionality, | |||
| configuration files are stored with passwords in readable format. [is | configuration files may contain some passwords in readable format. | |||
| this true? are configuration files then protected? if passwords in | Most ISPs mitigate any risk of password compromise by either storing | |||
| readable format, is the thought that an OOB management network with | these configuration files without the password lines or by requiring | |||
| SCP will be enough protection? ] | authenticated and authorized access to the configuration files which | |||
| are stored on protected OOB management devices. | ||||
| Automated security validation is performed on infrastructure devices | Automated security validation is performed on infrastructure devices | |||
| using nmap and nessus to ensure valid configuration against many of | using nmap and nessus to ensure valid configuration against many of | |||
| the well-known attacks. | the well-known attacks. | |||
| 2.6.8. Security Services | 2.6.8. Security Services | |||
| o User Authentication - All users are authenticated before being | o User Authentication - All users are authenticated before being | |||
| able to download/upload any system images or configuration files. | able to download/upload any system images or configuration files. | |||
| skipping to change at page 32, line 8 ¶ | skipping to change at page 32, line 8 ¶ | |||
| IPv6 networks require the use of specific ICMP messages for proper | IPv6 networks require the use of specific ICMP messages for proper | |||
| protocol operation. Therefore, ICMP cannot be completely filtered to | protocol operation. Therefore, ICMP cannot be completely filtered to | |||
| and from a device. Instead, granular ICMPv6 filtering is always | and from a device. Instead, granular ICMPv6 filtering is always | |||
| deployed to allow for specific ICMPv6 types to be sourced or destined | deployed to allow for specific ICMPv6 types to be sourced or destined | |||
| to a network device. | to a network device. | |||
| 2.8.3. Routing Control Plane Filtering | 2.8.3. Routing Control Plane Filtering | |||
| Routing filters are used to control the flow of routing information. | Routing filters are used to control the flow of routing information. | |||
| In IPv6 networks, some providers are liberal in accepting /48Os due | In IPv6 networks, some providers are liberal in accepting /48s due to | |||
| to the still unresolved multihoming issues. Anything longer than a | the still unresolved multihoming issues. Any announcement received | |||
| /48 is discarded on EBGP. | that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing | |||
| is discarded on EBGP. | ||||
| 2.9. Denial of Service Tracking / Tracing | 2.9. Denial of Service Tracking / Tracing | |||
| Denial of Service attacks are an ever increasing problem and require | Denial of Service attacks are an ever increasing problem and require | |||
| vast amounts of resources to combat effectively. Some large ISPs do | vast amounts of resources to combat effectively. Some large ISPs do | |||
| not concern themselves with attack streams that are less than 1G in | not concern themselves with attack streams that are less than 1G in | |||
| bandwidth - this is on the larger pipes where 1G is essentially less | bandwidth - this is on the larger pipes where 1G is essentially less | |||
| than 5% of offered load. This is largely due to the large amounts of | than 5% of offered load. This is largely due to the large amounts of | |||
| DDoS traffic which continually requires investigation and mitigation. | DDoS traffic which continually requires investigation and mitigation. | |||
| At last count the number of hosts making up large distributed DoS | At last count the number of hosts making up large distributed DoS | |||
| skipping to change at page 38, line 9 ¶ | skipping to change at page 38, line 9 ¶ | |||
| Today, IPv6 enabled hosts are starting to be used to create IPv6 | Today, IPv6 enabled hosts are starting to be used to create IPv6 | |||
| tunnels which can effectively hide botnet and other malicious traffic | tunnels which can effectively hide botnet and other malicious traffic | |||
| if firewalls and network flow collection tools are not capable of | if firewalls and network flow collection tools are not capable of | |||
| detecting this traffic. | detecting this traffic. | |||
| Author's Address | Author's Address | |||
| Merike Kaeo | Merike Kaeo | |||
| Double Shot Security, Inc. | Double Shot Security, Inc. | |||
| 520 Washington Blvd. #363 | 3518 Fremont Avenue North #363 | |||
| Marina Del Rey, CA 90292 | Seattley, WA 98103 | |||
| U.S.A. | U.S.A. | |||
| Phone: +1 310 866 0165 | Phone: +1 310 866 0165 | |||
| Email: merike@doubleshotsecurity.com | Email: merike@doubleshotsecurity.com | |||
| Intellectual Property Statement | Intellectual Property Statement | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| skipping to change at page 39, line 41 ¶ | skipping to change at page 39, line 41 ¶ | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| Copyright Statement | Copyright Statement | |||
| Copyright (C) The Internet Society (2005). This document is subject | Copyright (C) The Internet Society (2006). This document is subject | |||
| to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| Acknowledgment | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| End of changes. 8 change blocks. | ||||
| 18 lines changed or deleted | 20 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||