Operational Security Current Practices in Internet Service Provider Environments
RFC 4778

#x27;s
   environments and as such, does not in itself pose any security risk.

4.  Acknowledgments

   The editor gratefully acknowledges the contributions of: George
   Jones, who has been instrumental in providing guidance and direction
   for this document, and the insightful comments from Ross Callon, Ron
   Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola,
   Fernando Gont, Chris Morrow, Ted Seely, Donald Smith, and the
   numerous ISP operators who supplied the information that is depicted
   in this document.

Kaeo                         Informational                     [Page 32]
RFC 4778                    OPSEC Practices                 January 2007

5.  References

5.1.  Normative References

   [RFC2827]     Ferguson, P. and D. Senie, "Network Ingress Filtering:
                 Defeating Denial of Service Attacks which employ IP
                 Source Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC2828]     Shirey, R., "Internet Security Glossary", RFC 2828,
                 May 2000.

   [RFC3552]     Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                 Text on Security Considerations", BCP 72, RFC 3552,
                 July 2003.

   [RFC3682]     Gill, V., Heasley, J., and D. Meyer, "The Generalized
                 TTL Security Mechanism (GTSM)", RFC 3682,
                 February 2004.

   [RFC3704]     Baker, F. and P. Savola, "Ingress Filtering for
                 Multihomed Networks", BCP 84, RFC 3704, March 2004.

   [RFC3882]     Turk, D., "Configuring BGP to Block Denial-of-Service
                 Attacks", RFC 3882, September 2004.

5.2.  Informational References

   [BCP84-URPF]  Savola, P., "Experiences from Using Unicast RPF", Work
                 in Progress, November 2006.

   [ICMPv6]      Davies, E. and J. Mohacsi, "Recommendations for
                 Filtering ICMPv6 Messages in Firewalls", Work
                 in Progress, July 2006.

   [RTGWG]       Savola, P., "Backbone Infrastructure Attacks and
                 Protections", Work in Progress, July 2006.

Kaeo                         Informational                     [Page 33]
RFC 4778                    OPSEC Practices                 January 2007

Appendix A.  Protocol Specific Attacks

   This section will list many of the traditional protocol-based attacks
   that have been observed over the years to cause malformed packets
   and/or exploit protocol deficiencies.  Note that they all exploit
   vulnerabilities in the actual protocol itself and often, additional
   authentication and auditing mechanisms are now used to detect and
   mitigate the impact of these attacks.  The list is not exhaustive,
   but is a fraction of the representation of what types of attacks are
   possible for varying protocols.

A.1.  Layer 2 Attacks

   o  ARP Flooding

A.2.  IPv4 Protocol-Based Attacks

   o  IP Addresses, either source or destination, can be spoofed which
      in turn can circumvent established filtering rules.

   o  IP Source Route Option can allows attackers to establish stealth
      TCP connections.

   o  IP Record Route Option can disclose information about the topology
      of the network.

   o  IP header that is too long or too short can cause DoS attacks to
      devices.

   o  IP Timestamp Option can leak information that can be used to
      discern network behavior.

   o  Fragmentation attacks which can vary widely - more detailed
      information can be found at http://www-src.lip6.fr/homepages/
      Fabrice.Legond-Aubry/www.ouah.org/fragma.html.

   o  IP ToS field (or the Differentiated Services (DSCP) field) can be
      used to reroute or reclassify traffic based on specified
      precedence.

   o  IP checksum field has been used for scanning purposes, for example
      when some firewalls did not check the checksum and allowed an
      attacker to differentiate when the response came from an end-
      system, and when from a firewall.

   o  IP TTL field can be used to bypass certain network-based intrusion
      detection systems and to map network behavior.

Kaeo                         Informational                     [Page 34]
RFC 4778                    OPSEC Practices                 January 2007

A.2.1.  Higher Layer Protocol Attacks

   The following lists additional attacks, but does not explicitly
   numerate them in detail.  It is for informational purposes only.

   o  IGMP oversized packet

   o  ICMP Source Quench

   o  ICMP Mask Request

   o  ICMP Large Packet (> 1472)

   o  ICMP Oversized packet (>65536)

   o  ICMP Flood

   o  ICMP Broadcast w/ Spoofed Source (Smurf Attack)

   o  ICMP Error Packet Flood

   o  ICMP Spoofed Unreachable

   o  TCP Packet without Flag

   o  TCP Oversized Packet

   o  TCP FIN bit with no ACK bit

   o  TCP Packet with URG/OOB flag (Nuke Attack)

   o  SYN Fragments

   o  SYN Flood

   o  SYN with IP Spoofing (Land Attack)

   o  SYN and FIN bits set

   o  TCP port scan attack

   o  UDP spoofed broadcast echo (Fraggle Attack)

   o  UDP attack on diagnostic ports (Pepsi Attack)

Kaeo                         Informational                     [Page 35]
RFC 4778                    OPSEC Practices                 January 2007

A.3.  IPv6 Attacks

   Any of the above-mentioned IPv4 attacks could be used in IPv6
   networks with the exception of any fragmentation and broadcast
   traffic, which operate differently in IPv6.  Note that all of these
   attacks are based on either spoofing or misusing any part of the
   protocol field(s).

   Today, IPv6-enabled hosts are starting to be used to create IPv6
   tunnels, which can effectively hide botnet and other malicious
   traffic if firewalls and network flow collection tools are not
   capable of detecting this traffic.  The security measures used for
   protecting IPv6 infrastructures should be the same as in IPv4
   networks, but with additional considerations for IPv6 network
   operations, which may be different from IPv4.

Author's Address

   Merike Kaeo
   Double Shot Security, Inc.
   3518 Fremont Avenue North #363
   Seattle, WA  98103
   U.S.A.

   Phone: +1 310 866 0165
   EMail: merike@doubleshotsecurity.com

Kaeo                         Informational                     [Page 36]
RFC 4778                    OPSEC Practices                 January 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Kaeo                         Informational                     [Page 37]