draft-ietf-opsec-protect-control-plane-05.txt   draft-ietf-opsec-protect-control-plane-06.txt 
OPSEC D. Dugal OPSEC D. Dugal
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational C. Pignataro Intended status: Informational C. Pignataro
Expires: June 15, 2011 R. Dunn Expires: June 18, 2011 R. Dunn
Cisco Systems Cisco Systems
December 12, 2010 December 15, 2010
Protecting The Router Control Plane Protecting The Router Control Plane
draft-ietf-opsec-protect-control-plane-05 draft-ietf-opsec-protect-control-plane-06
Abstract Abstract
This memo provides a method for protecting a router's control plane This memo provides a method for protecting a router's control plane
from undesired or malicious traffic. In this approach, all from undesired or malicious traffic. In this approach, all
legitimate router control plane traffic is identified. Once legitimate router control plane traffic is identified. Once
legitimate traffic has been identified, a filter is deployed in the legitimate traffic has been identified, a filter is deployed in the
router's forwarding plane. That filter prevents traffic not router's forwarding plane. That filter prevents traffic not
specifically identified as legitimate from reaching the router's specifically identified as legitimate from reaching the router's
control plane, or rate limits such traffic to an acceptable level. control plane, or rate limits such traffic to an acceptable level.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on June 15, 2011. This Internet-Draft will expire on June 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 40 skipping to change at page 4, line 40
The examples given in this memo are simplified and minimalistic, The examples given in this memo are simplified and minimalistic,
designed to illustrate the concept of protecting the router's control designed to illustrate the concept of protecting the router's control
plane. From them, operators can extrapolate specifics based on their plane. From them, operators can extrapolate specifics based on their
unique configuration and environment. This document is about unique configuration and environment. This document is about
semantics and Appendix A exemplifies syntax. For additional router semantics and Appendix A exemplifies syntax. For additional router
vendor implementations, or other converged devices, the syntax should vendor implementations, or other converged devices, the syntax should
be translated to the respective language in a manner that preserves be translated to the respective language in a manner that preserves
the semantics. the semantics.
Additionally, there may be other vendor or implementation specific Additionally, the need to provide the router control plane with
isolation, stability and protection against rogue packets has been
incorporated into router designs for some time. Consequently, there
may be other vendor or implementation specific router control plane
protection mechanisms that are active by default or always active. protection mechanisms that are active by default or always active.
Those approaches may apply in conjunction with or in addition to the Those approaches may apply in conjunction with or in addition to the
method described in Section 3 and illustrated in Appendices A.1 and method described in Section 3 and illustrated in Appendices A.1 and
A.2. Those implementations should be considered as part of an A.2. Those implementations should be considered as part of an
overall traffic management plan but are outside the scope of this overall traffic management plan but are outside the scope of this
document. document.
This method is applicable for IPv4 as well as IPv6 address families, This method is applicable for IPv4 as well as IPv6 address families,
and the legitimate traffic example in Section 3.1 provides examples and the legitimate traffic example in Section 3.1 provides examples
for both. for both.
skipping to change at page 5, line 19 skipping to change at page 5, line 21
router is introduced and all traffic that its control plane must router is introduced and all traffic that its control plane must
process is identified. In Section 3.2, filter design concepts are process is identified. In Section 3.2, filter design concepts are
discussed. Cisco (Cisco IOS software) and Juniper (JUNOS) discussed. Cisco (Cisco IOS software) and Juniper (JUNOS)
implementations are provided in Appendices A.1 and A.2, respectively. implementations are provided in Appendices A.1 and A.2, respectively.
3.1. Legitimate Traffic 3.1. Legitimate Traffic
In this example, the router control plane must process traffic per In this example, the router control plane must process traffic per
the following criteria: the following criteria:
o Drop all IP packets that are fragments o Drop all IP packets that are fragments (see Section 3.3)
o Permit ICMP and ICMPv6 traffic from any source, rate-limited to o Permit ICMP and ICMPv6 traffic from any source, rate-limited to
500 kbps for each category 500 kbps for each category
o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and
OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10) OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10)
o Permit iBGP traffic from routers within subnets 192.0.2.0/24 and o Permit iBGP traffic from routers within subnets 192.0.2.0/24 and
2001:DB8:1::/48 2001:DB8:1::/48
skipping to change at page 5, line 48 skipping to change at page 5, line 50
and 2001:DB8:100:2::/64 and 2001:DB8:100:2::/64
o Permit SSH traffic from network management stations within subnet o Permit SSH traffic from network management stations within subnet
198.51.100.128/25 and 2001:DB8:100:3::/64 198.51.100.128/25 and 2001:DB8:100:3::/64
o Permit SNMP traffic from network management stations within subnet o Permit SNMP traffic from network management stations within subnet
198.51.100.128/25 and 2001:DB8:100:3::/64 198.51.100.128/25 and 2001:DB8:100:3::/64
o Permit RADIUS authentication and accounting replies from RADIUS o Permit RADIUS authentication and accounting replies from RADIUS
servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001:
DB8:100::10 that are listening on UDP ports 1645 and 1646. Note DB8:100::10 that are listening on UDP ports 1812 and 1813
that this doesn't account for a server using Internet Assigned (Internet Assigned Numbers Authority (IANA) RADIUS ports). Note
Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. that this does not accomodate a server using the original UDP
ports of 1645 and 1646.
o Permit all other IPv4 and IPv6 traffic that was not explicitly o Permit all other IPv4 and IPv6 traffic that was not explicitly
matched in a class above, rate-limited to 500 kbps, and drop above matched in a class above, rate-limited to 500 kbps, and drop above
that rate for each category that rate for each category
o Permit non-IP traffic (e.g., CLNS, IPX, PPP LCP, etc.), rate- o Permit non-IP traffic (e.g., CLNS, IPX, PPP LCP, etc.), rate-
limited to rate of 250 kbps, and drop all remaining traffic above limited to rate of 250 kbps, and drop all remaining traffic above
that rate that rate
The characteristics of legitimate traffic will vary from network to The characteristics of legitimate traffic will vary from network to
network. The list of criteria above is provided for example only. network. To illustrate this, a router implementing the DHCP relay
function can rate limit inbound DHCP traffic from clients and
restrict traffic from servers to a list of known DHCP servers. The
list of criteria above is provided for example only.
3.2. Filter Design 3.2. Filter Design
A filter is installed on the forwarding plane. This filter counts A filter is installed on the forwarding plane. This filter counts
and applies the actions to the categories of traffic described in and applies the actions to the categories of traffic described in
Section 3.1. Because the filter is enforced in the forwarding plane, Section 3.1. Because the filter is enforced in the forwarding plane,
it prevents traffic from consuming bandwidth on the interface that it prevents traffic from consuming bandwidth on the interface that
connects the forwarding plane to the router control plane. The connects the forwarding plane to the router control plane. The
counters serve as an important forensic tool for the analysis of counters serve as an important forensic tool for the analysis of
potential attacks, and as an invaluable debugging and troubleshooting potential attacks, and as an invaluable debugging and troubleshooting
skipping to change at page 8, line 29 skipping to change at page 8, line 36
included herein drops all fragments. included herein drops all fragments.
Similarly, some deployments may chose to drop all IP optioned Similarly, some deployments may chose to drop all IP optioned
packets. Others may need to loosen the constraint to allow for packets. Others may need to loosen the constraint to allow for
protocols that require IP optioned packets such as Resource protocols that require IP optioned packets such as Resource
Reservation Protocol (RSVP). The design trade-off is that Reservation Protocol (RSVP). The design trade-off is that
dropping all IP optioned packets protects the router from attacks dropping all IP optioned packets protects the router from attacks
that leverage malformed options, as well as attacks that rely on that leverage malformed options, as well as attacks that rely on
the slow-path processing (i.e., software processing path) of IP the slow-path processing (i.e., software processing path) of IP
optioned packets. For network deployments where the protocols optioned packets. For network deployments where the protocols
used rely on IP options, the filter is simpler to design in that used do not rely on IP options, the filter is simpler to design in
it can drop all packets with any IP option set. However for that it can drop all packets with any IP option set. However for
networks utilizing protocols relying on IP options, then the networks utilizing protocols relying on IP options, then the
filter to identify the legitimate packets is more complex. If the filter to identify the legitimate packets is more complex. If the
filter is not designed correctly, it could result in the filter is not designed correctly, it could result in the
inadvertent blackholing of traffic for those protocols. This inadvertent blackholing of traffic for those protocols. This
document does not include IP options filter configurations; document does not include IP options filter configurations;
additional IP options filtering explanations can be found at additional IP options filtering explanations can be found at
[I-D.gont-opsec-ip-options-filtering]. [I-D.gont-opsec-ip-options-filtering].
The goal of the method for protecting the router control plane is to The goal of the method for protecting the router control plane is to
minimize the possibility for disruptions by reducing the vulnerable minimize the possibility for disruptions by reducing the vulnerable
skipping to change at page 11, line 43 skipping to change at page 11, line 49
The authors would like to thank Ron Bonica for providing initial and The authors would like to thank Ron Bonica for providing initial and
ongoing review, suggestions, and valuable input. Pekka Savola, ongoing review, suggestions, and valuable input. Pekka Savola,
Warren Kumari, and Xu Chen provided very thorough and useful feedback Warren Kumari, and Xu Chen provided very thorough and useful feedback
that improved the document. Many thanks to John Kristoff, that improved the document. Many thanks to John Kristoff,
Christopher Morrow, and Donald Smith for a fruitful discussion around Christopher Morrow, and Donald Smith for a fruitful discussion around
the operational and manageability aspects of router control plane the operational and manageability aspects of router control plane
protection techniques. The authors would also like to thank Joel protection techniques. The authors would also like to thank Joel
Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie
Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni
Even, and Acee Lindem for providing thorough review, useful Even, Acee Lindem, Glen Zorn, Joe Abley, Ralph Droms, and Stewart
suggestions, and valuable input. Many thanks to Jim Bailey and Bryant for providing thorough review, useful suggestions, and
Raphan Han for providing technical direction and sample configuration valuable input. Many thanks to Jim Bailey and Raphan Han for
guidance on the IPv6 sections. Many thanks also go to Andrew providing technical direction and sample configuration guidance on
Yourtchenko for his review, comments, and willingness to present on the IPv6 sections. Many thanks also go to Andrew Yourtchenko for his
behalf of the authors. review, comments, and willingness to present on behalf of the
authors.
7. Informative References 7. Informative References
[I-D.gont-opsec-ip-options-filtering] [I-D.gont-opsec-ip-options-filtering]
Gont, F. and S. Fouant, "IP Options Filtering Gont, F. and S. Fouant, "IP Options Filtering
Recommendations", draft-gont-opsec-ip-options-filtering-00 Recommendations", draft-gont-opsec-ip-options-filtering-00
(work in progress), March 2010. (work in progress), March 2010.
[I-D.ietf-intarea-router-alert-considerations] [I-D.ietf-intarea-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage", Faucheur, F., "IP Router Alert Considerations and Usage",
skipping to change at page 13, line 44 skipping to change at page 14, line 4
permit tcp host 2001:DB8:100::29 any eq bgp permit tcp host 2001:DB8:100::29 any eq bgp
permit tcp host 2001:DB8:100::31 eq bgp any permit tcp host 2001:DB8:100::31 eq bgp any
permit tcp host 2001:DB8:100::31 any eq bgp permit tcp host 2001:DB8:100::31 any eq bgp
ip access-list extended DNS ip access-list extended DNS
permit udp 198.51.100.0 0.0.0.252 eq domain any permit udp 198.51.100.0 0.0.0.252 eq domain any
ipv6 access-list DNSv6 ipv6 access-list DNSv6
permit udp 2001:DB8:100:1::/64 eq domain any permit udp 2001:DB8:100:1::/64 eq domain any
permit tcp 2001:DB8:100:1::/64 eq domain any permit tcp 2001:DB8:100:1::/64 eq domain any
ip access-list extended NTP ip access-list extended NTP
permit udp 198.51.100.4 255.255.255.252 any eq ntp permit udp 198.51.100.4 255.255.255.252 any eq ntp
ipv6 access-list NTPv6 ipv6 access-list NTPv6
permit udp 2001:DB8:100:2::/64 any eq ntp permit udp 2001:DB8:100:2::/64 any eq ntp
ip access-list extended SSH ip access-list extended SSH
permit tcp 198.51.100.128 0.0.0.128 any eq 22 permit tcp 198.51.100.128 0.0.0.128 any eq 22
ipv6 access-list SSHv6 ipv6 access-list SSHv6
permit tcp 2001:DB8:100:3::/64 any eq 22 permit tcp 2001:DB8:100:3::/64 any eq 22
ip access-list extended SNMP ip access-list extended SNMP
permit udp 198.51.100.128 0.0.0.128 any eq snmp permit udp 198.51.100.128 0.0.0.128 any eq snmp
ipv6 access-list SNMPv6 ipv6 access-list SNMPv6
permit udp 2001:DB8:100:3::/64 any eq snmp permit udp 2001:DB8:100:3::/64 any eq snmp
ip access-list extended RADIUS ip access-list extended RADIUS
permit udp host 198.51.100.9 eq 1645 any permit udp host 198.51.100.9 eq 1812 any
permit udp host 198.51.100.9 eq 1646 any permit udp host 198.51.100.9 eq 1813 any
permit udp host 198.51.100.10 eq 1645 any permit udp host 198.51.100.10 eq 1812 any
permit udp host 198.51.100.10 eq 1646 any permit udp host 198.51.100.10 eq 1813 any
ipv6 access-list RADIUSv6 ipv6 access-list RADIUSv6
permit udp host 2001:DB8:100::9 eq 1645 any permit udp host 2001:DB8:100::9 eq 1812 any
permit udp host 2001:DB8:100::9 eq 1646 any permit udp host 2001:DB8:100::9 eq 1813 any
permit udp host 2001:DB8:100::10 eq 1645 any permit udp host 2001:DB8:100::10 eq 1812 any
permit udp host 2001:DB8:100::10 eq 1646 any permit udp host 2001:DB8:100::10 eq 1813 any
ip access-list extended FRAGMENTS ip access-list extended FRAGMENTS
permit ip any any fragments permit ip any any fragments
ipv6 access-list FRAGMENTSv6 ipv6 access-list FRAGMENTSv6
permit ipv6 any any fragments permit ipv6 any any fragments
ip access-list extended ALLOTHERIP ip access-list extended ALLOTHERIP
permit ip any any permit ip any any
ipv6 access-list ALLOTHERIPv6 ipv6 access-list ALLOTHERIPv6
permit ipv6 any any permit ipv6 any any
! !
!Class Definitions !Class Definitions
skipping to change at page 19, line 45 skipping to change at page 20, line 5
destination-port snmp; destination-port snmp;
} }
then accept; then accept;
} }
term radius { term radius {
from { from {
source-prefix-list { source-prefix-list {
RADIUS-SERVERS; RADIUS-SERVERS;
} }
protocol udp; protocol udp;
port [ 1645 1646 ]; port [ 1812 1813 ];
} }
then accept; then accept;
} }
term default-term { term default-term {
then { then {
count copp-exceptions; count copp-exceptions;
log; log;
policer 500kbps; policer 500kbps;
accept; accept;
} }
skipping to change at page 22, line 32 skipping to change at page 22, line 40
destination-port snmp; destination-port snmp;
} }
then accept; then accept;
} }
term radiusv6 { term radiusv6 {
from { from {
source-prefix-list { source-prefix-list {
RADIUSv6-SERVERS; RADIUSv6-SERVERS;
} }
next-header udp; next-header udp;
port [ 1645 1646 ]; port [ 1812 1813 ];
} }
then accept; then accept;
} }
term default-term-v6 { term default-term-v6 {
then { then {
policer 500kbps; policer 500kbps;
count copp-exceptions-v6; count copp-exceptions-v6;
log; log;
accept; accept;
} }
 End of changes. 16 change blocks. 
29 lines changed or deleted 37 lines changed or added

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