Internet DRAFT - draft-shishio-bmwg-copp
draft-shishio-bmwg-copp
Network Working Group S. Tsuchiya, Ed.
Internet-Draft Cisco Systems
Intended status: Informational October 18, 2015
Expires: April 20, 2016
Benchmarking for CoPP
draft-shishio-bmwg-copp-00
Abstract
COntrol Plane Policing (CoPP) which is defined as RFC6192 to protect
router's control plane from undesired or malicious traffic.
This document provides methodology to confirm implementation of CoPP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 20, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Tsuchiya Expires April 20, 2016 [Page 1]
Internet-Draft Benchmarking Methodology for CoPP October 2015
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Network . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Test procedure . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Attack Packet . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Typical . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Routing Protocol from trust networkl . . . . . . . . . 4
3.1.3. Routing Protocol from untrust networkl . . . . . . . . 4
3.1.4. Control Packet from trust network . . . . . . . . . . . 4
3.1.5. Control Packet from un-trust network . . . . . . . . . 4
3.1.6. Management Packet from trust network . . . . . . . . . 5
3.1.7. Management Packet from un-trust network . . . . . . . . 5
3.1.8. undefined packets . . . . . . . . . . . . . . . . . . . 5
4. Test Result . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Tsuchiya Expires April 20, 2016 [Page 2]
Internet-Draft Benchmarking Methodology for CoPP October 2015
1. Introduction
COntrol Plane Policing (CoPP) which is defined as RFC6192 to protect
router's control plane from undesired or malicious traffic. Some
modern router implemented this RFC6192 mechanism as the default.
Also some router can support RFC6192 by configuration.
Ethernet based service has been widely deployed for both consumer and
business . In some case , service provider has to converge customer
network directly without CPE. There is ARP/NDP and broadcast/
multicast protocol in the segment , therefore service provider
becomes carefully for protection of router's control plane.
This document provides methodology to confirm implementation of CoPP.
2. Test setup
2.1. Topology
The DUT need to at least 3 interfaces to connect Attack Emulator/
Uplink Router/Traffic Generator.
Basic network topology is here
+------------------------+
| |
| DUT |
| |
| +----------------+ |
| | Router Control | |
| | Plane | |
| +------+ +-------+ |
| | | |
| Router Control |
| Plane Protection |
+-----------+ | | | |
| Attack | | +------+ +-------+ |
| Emulator |---|---[ | |
+-----------+ | | Forwarding | | +----------+
+----|---[ Plane ]---|----| Router |---+
| | +----------------+ | +----------+ |
| +------------------------+ |
| +----------------+ |
+-------| Traffic |------------------------+
| Generator |
+----------------+
Tsuchiya Expires April 20, 2016 [Page 3]
Internet-Draft Benchmarking Methodology for CoPP October 2015
2.2. Network
Configure applicable network parameter on both DUT and uplink router
such as IGP/BGP. Send traffic from traffic generator to transit
between DUT and Router. If needed configure DUT to protect Control
plane. section-3.1 of RFC6192 would be reference.
3. Test procedure
Attack emulator sends packets to DUT to confirm influence of CoPP.
section-3.1 of RFC6192 describes example of CoPP. It completely
depends on network environment but it can be categorized in the
following section.
3.1. Attack Packet
3.1.1. Typical
fragment/ip option/ ICMP ttl exceed
Expect Action: drop/rate-limit
3.1.2. Routing Protocol from trust networkl
BGP/OSPF
Expect Action: accept but rate-limit would be prefered
3.1.3. Routing Protocol from untrust networkl
BGP/OSPF
Expect Action: drop
3.1.4. Control Packet from trust network
ARP/NDP/ICMP/ICMPv6
Expect Action: accept but rate-limit would be prefered
3.1.5. Control Packet from un-trust network
ARP/NDP/ICMP/ICMPv6
Expect Action: drop
Tsuchiya Expires April 20, 2016 [Page 4]
Internet-Draft Benchmarking Methodology for CoPP October 2015
3.1.6. Management Packet from trust network
NTP/SSH/Telnet/Radius/DNS/DHCP
Expect Action: accept/rate-limit
3.1.7. Management Packet from un-trust network
NTP/SSH/Telnet/Radius/DNS/DHCP
Expect Action: drop
3.1.8. undefined packets
IPX/Apple talk
Expect Action: drop
The section will be update more detail(src ip/dst ip and packet type)
Attack duration must be higher than routing protocol hold timer
between DUT and router. Transit packets should be non drop.
4. Test Result
Test Result report needs these information.
+--------+----------------+----------------+------------------------+
| Attack | Attack | Attack | Loss of packets on |
| | rate[pps/bps] | duration time | traffic generator |
+--------+----------------+----------------+------------------------+
| - | - | - | - |
+--------+----------------+----------------+------------------------+
5. Acknowledgements
TBD
6. IANA Considerations
No IANA Action is requested at this time.
Tsuchiya Expires April 20, 2016 [Page 5]
Internet-Draft Benchmarking Methodology for CoPP October 2015
7. Security Considerations
There is no additional consideration from RFC6192.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <http://www.rfc-editor.org/info/rfc6192>.
8.2. Informative References
Author's Address
Shishio Tsuchiya (editor)
Cisco Systems
Midtown Tower, 9-7-1,Akasaka
Minato-Ku, Tokyo 107-6227
Japan
Phone: +81 3 6434 6543
Email: shtsuchi@cisco.com
Tsuchiya Expires April 20, 2016 [Page 6]
