Opsec Working Group Zhao Ye
Internet Draft Miao Fuyou
Expires: January 2006 Huawei Technologies
October 9, 2005
Routing Control Plane Security Capabilities
draft-zhao-opsec-routing-capabilities-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any 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 aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 9, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
The document lists the security capabilities needed for routing control
planeof IP infrastructure to support the practices defined in [PRACTICES].
Zhao Expires April 9, 2006 [Page 1]
Internet-Draft Control Plane Security Capabilities October 2005
Capabilities are defined without reference to specific technologies.
This is done to leave room for deployment of new technologies that
implement the capability. Each capability cites the practices it
supports. Current implementations that support the capability are
cited. Special considerations are discussed as appropriate listing
operational and resource constraints, limitations of current
implementations, tradeoffs, etc.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]
Table of Contents
1. Introduction......................................... 3
2. Functional Capabilities................................ 3
2.1. Route Authentication Capabilities................... 3
2.1.1. Ability to configure/negotiate an authentication
mechanism for an interface........................... 3
2.1.2. Ability to generate authentication data for route update
................................................ 4
2.1.3. Ability to verify authentication data of route update5
2.1.4. Ability to rekey manually or automatically........ 5
2.1.5. Ability to be extensible to other authentication
mechanisms........................................ 6
2.2. Route Filtering Capabilities....................... 6
2.2.1. Ability to filter inbound or outbound route update. 7
2.2.2. Ability to filter specially used address ......... 7
2.2.3. Ability to filter routing update by address or prefix8
2.2.4. Ability to filter routing updates by protocols or ports
................................................ 9
2.2.5. Ability to filter routing update by TTL.......... 9
2.2.6. Ability to filter routing update by neighbour. ... 10
2.2.7. Ability to filter routing update by route properties10
2.2.8. Ability to limit the number of routes learned from a
specific neighbour................................ 11
2.2.9. Ability to limit the length of prefixes......... 12
2.2.10. Ability to fliter route redistribution......... 12
2.3. log........................................... 13
2.3.1. Ability to log the failure of authentication..... 13
2.3.2. Ability to counter and log denied packets........ 13
2.4. Route Flap Dampening............................. 14
2.4.1. Ability to dampen route flap.................. 14
2.5. Architectural Security Capabilities................. 15
Zhao Expires April 9, 2006 [Page 2]
Internet-Draft Control Plane Security Capabilities October 2005
2.5.1. Ability to isolate control plane from data plane
logically........................................ 15
2.6. Ability to provide route confidentiality ............ 15
2.7. Anti-replay.................................... 16
2.7.1. Ability to anti-replay....................... 16
3. Security Considerations............................... 16
4. Acknowledgments..................................... 16
5. References......................................... 17
5.1. Normative References............................. 17
5.2. Informative References........................... 17
Author's Addresses..................................... 18
Intellectual Property Statement .......................... 18
Disclaimer of Validity.................................. 19
Copyright Statement.................................... 19
Acknowledgment ........................................ 19
1. Introduction
The control plane is responsible for carrying the control information
or signaling of the IP network. Its major elements are various
unicast and multicast routing protocols. The control plane is very
central to the network. Attacking to the control plane may lead to
the collaps of the whole network.
The document tries to sum up the capabilities of control plane for IP
networks.
2. Functional Capabilities
In the section , capabilities are listed to ensure the control plane
security.
2.1. Route Authentication Capabilities
Routing protocol authentication prevents the introduction of false or
unauthorized routing messages from unauthorized sources. With
authentication configured, the router authenticates the source of
each routing protocol packet that it got from its neighbors.
sometimes authentication keys or passwords are configured between
neighbors. The shared keys or passwords are used to verify the
authenticity of routing packets.
2.1.1. Ability to configure/negotiate an authentication mechanism for
an interface
Capabilities.
Zhao Expires April 9, 2006 [Page 3]
Internet-Draft Control Plane Security Capabilities October 2005
The device has one or more methods to allow the protocol to negotiate
or be configured an authentication mechanism (null authentication,
simple password authentication, MD5 authentication etc) to be used
between routing peers. The authentication mechanism implements data
origin authentication and integrity verification for any routing
update message from peers. Parameters related to the mechanism must
be set by administrator or management software, too.
Supported Practices.
1. Route Authentication([PRACTICES] section 2.5.7)
2. Authentication is configurable
Current Implementations.
Authentication is defined in most routing protocols. Basically most
routing protocols support 3 basic mechanisms: null authentication,
simple password authentication and MD5 authentication. Null
authentication doesn't provide any data origin authentication or
integrity verification service, and simple password authentication
provides very weak authentication capability and is subject to many
kinds of attacks. Relatively MD5 provides the security service in a
more secure manner than other two mechanisms by applying
cryptographic computation.
Considerations.
Null authentication and simple password authentication should be
avoided in IP infrastructure network unless a high trustable
environment is available.
The progress of cryptography makes MD5 collision feasible with
current computation technologies. Whenever possible more strong
authentication algorithm should be considered for candidate, such as
SHA-256.
2.1.2. Ability to generate authentication data for route update
Capabilities.
When sending a route update to a peer a device is provided capability
to invoke authentication algorithm to generate authentication data
for the route update. The authentication data is sent to routing peer
along with route update message.
Supported Practices.
Zhao Expires April 9, 2006 [Page 4]
Internet-Draft Control Plane Security Capabilities October 2005
1. Route Authentication([PRACTICES] section 2.5.7)
Current Implementations.
Once configured with authentication mechanism, routing protocol will
invoke the algorithm to generate message authentication code(MAC),
which is carried in a specific field of the message, 64 bit
authentication field in OSPF for example. Typically MAC is generated
by applying a key hash algorithm (MD5 fro example) to the total
message or part of the message.
Considerations.
None.
2.1.3. Ability to verify authentication data of route update
Capabilities.
When got a route update message with authentication data from routing
peer, the device must be able to invoke a proper procedure to verify
the rightness of the data. If the data is not correct, the message
must be silently dropped.
Supported Practices.
1. Route Authentication([PRACTICES] section 2.5.7)
Current Implementations.
The receiver of the message applies keyed hash algorithm to the
message or part of the message and gets a MAC. If the MAC is same to
the one in the message, authentication passes.
Considerations.
None
2.1.4. Ability to rekey manually or automatically
Capabilities.
The device provides the capability to allow rekey the shared secret
by manually configuration or dynamic negotiation.
Supported Practices.
Zhao Expires April 9, 2006 [Page 5]
Internet-Draft Control Plane Security Capabilities October 2005
TBD
Current Implementations.
Most device implementation allows administrator to configure
authentication parameters, including shared secret.
Considerations.
Dynamically parameter negotiation may be preferable feature for
operator to reduce the effort of configuration.
2.1.5. Ability to be extensible to other authentication mechanisms
Capabilities.
The routing protocol can be extensible to support other
authentication algorithm, such as SHA-1 or SHA-256.
Supported Practices.
This allows device to improve the security of control plane by
extending stronger authentication mechanism to routing protocols.
Current Implementations.
OSPF has an AuType field to identify the authentication mechanism,
new mechanism can be added to the protocol by defining new AuType and
relevant processing procedure.
Considerations.
Most current routing protocols use MD5 for authentication. MD5 is
proven a weak authentication algorithm and subject to some
cryptographic attacks. It is important for routing protocols to
support other authentication algorithm, such as SHA-1 or SHA-256, in
the future.
2.2. Route Filtering Capabilities
In [FILTER] there are different filtering capabilities defined, some
filtering capabilities in [FILTER] are applied to route update.
Route filtering is a generic method which is important and used
widely in the field of the route security. We can prevent route
looping and black hole through deploying it properly. Route filtering
is also used to keep route information from leaking into illegal site
Zhao Expires April 9, 2006 [Page 6]
Internet-Draft Control Plane Security Capabilities October 2005
and often be used to counter against some attacks, such as by
injecting false routes.
2.2.1. Ability to filter inbound or outbound route update
Capabilities.
The device has the capability to filter the incoming or outgoing
route updates according to configured filters. The receiver will
spend less CPU cycles and memory to process route updates once
inbound or outbound filtering is applied.
Supported Practices.
1. Route Filter([PRACTICES] section 2.5.7)
2. Ability to filter inbound and outbound([FILTER] section 2.1.10)
3. Filtering the inbound route updates is an effictive countermeasure
against spurious packets attack.
Current Implementations.
Most of the route protocols support methods to configure route
filters which permit or deny learning or advertising of specific
routes.
Consideration.
None
2.2.2. Ability to filter prefix for specific purpose
Capabilities.
Some address spaces should not be used globally. For example, for an
edge router the address blocks listed below should not be accepted:
loopback address, 127.0.0.0/8
RFC1918 address for private use, such as 10.0.0.0/8,172.16.0.0/12,
192.168.0.0/16
prefix for link local address 169.254.0.0/16
prefix for multicast address 224.0.0.0/4
Zhao Expires April 9, 2006 [Page 7]
Internet-Draft Control Plane Security Capabilities October 2005
reserved address for IPv6/v4 interoperation 240.0.0.0/4
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7)
Current Implementations.
It is an essential function to filter prefix mentioned above to a
edge router.
Consideration.
None
2.2.3. Ability to filter routing update by prefix
Capabilities.
Teh device is configured to explicitly permit or deny prefix received
in route updates from neighbors by applying IP address filters.
Implementation should support a rule set in which each element of the
set is a rule with a specific action(deny/permit) to a prefix. If no
rule is matched ,the default action is applied to reject the route
update.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
2. Avoid injection of false routes.
3. Limit propagation of invalid routes
Current Implementations.
Most route protocols support the feature.
By this feature administrator can prevent false routes from
injecting and constrain the propagation of invalid routing
information.
Consideration.
None
Zhao Expires April 9, 2006 [Page 8]
Internet-Draft Control Plane Security Capabilities October 2005
2.2.4. Ability to filter routing updates by protocols or ports
Capabilities.
The device provide a means to filter route packets based on the value
of the protocol field in the IP header or the port field in the TCP
or UDP header.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
Current Implementations.
It is very common that more than one route protocols, such as OSPF
and BGP, run in the same router. IGP update messages from outside of
the route domain should be dropped.
It may be implemented by deploying ACLs.
Consideration.
None
2.2.5. Ability to filter routing update by TTL
Capabilities.
The device should provide a means to filter route packets based on
the value of the TTL field in the IPv4 header or the Hop-Limit field
in the IPv6 header.
Take adjacent routers for example,it is a good policy to drop the
protocols packets whose TTL is not equal to 255.
TTL filters should not be enabled by default.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
Current Implementations.
When a router got a packet, it will decrement TTL(Hop-Limit for IPv6)
value of the packet by one. Thus, TTL spoofing is considered nearly
impossible. Furthermore, vast majority of routing peers are adjacent.
Zhao Expires April 9, 2006 [Page 9]
Internet-Draft Control Plane Security Capabilities October 2005
TTL filter is a simple mechanism to authenticate origins and avoid
attack by spoofing a routing packet.
[GTMS] introduced a generalized TTL security mechanism which can be
used in several protocols.
Consideration.
It may be inadequate to use the technology where the situation is
multi-hop and the number of hops changes frequently.
If a router is in a environment where neighbor can be spoofed or is
not trustable the mechanism is not applicable.
2.2.6. Ability to filter routing update by neighbor.
Capabilities.
By default the device can learn routes form all available neighbors.
Neighbor filtering can be configured to explicitly permit or deny
learning route from specific neighbor.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
Current Implementations.
By the method administrator can implement simple origin controlling
without cryptographic authentication.
Consideration.
None
2.2.7. Ability to filter routing update by route attributes
Capabilities.
Some route protocols, such as BGP, attach attributes after route
information. So route can be classified and filtered by the
attributes values. Processing of receiving route is flexibly
controlled.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
Zhao Expires April 9, 2006 [Page 10]
Internet-Draft Control Plane Security Capabilities October 2005
Current Implementations.
Take BGP for example: router can filter routes received from BGP4
neighbors based on community names by either of the following methods.
A community is an optional attribute that identifies the route as a
member of a user defined class of routes. Community names are
arbitrary values made of two five-digit integers joined by a colon.
Administrator determines what the name means when community name is
generated as one of a route's attributes. Each string in the
community name can be a number from 0 - 65535. This format allows
administrator to easily classify community names. For example, a
common convention used in community naming is to configure the first
string as the local AS and the second string as the unique community
within that AS. Using this convention, communities 1:10, 1:20, and
1:30 can be easily identified as member communities of AS 1.
Router can filter updates received from BGP4 neighbors based on the
contents of the AS-path list accompanying the updates. For example,
if administrator want to deny routes that have the AS 4.3.2.1 in the
AS-path from entering the BGP4 route table, he can define a filter to
deny such routes.
Consideration.
The device may support this type of filter, only if it is applicable.
2.2.8. Ability to limit the number of routes learned from a specific
neighbor
Capabilities.
The device should provide a method to allow user to configure the
amount of routes that can be learned for a specific neighbor.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
Current Implementations.
A potential malicious neighbor may attack the routing table through
injecting large amounts of routes which may result in the decline of
efficiency. So it is reasonable to limit the amount of routes that
can be learned from a specific neighbor.
Some BGP implementations has a ''Max Prefix-Limit'' feature. A BGP
neighbor would be shut down when the number reaches some threshold.
Zhao Expires April 9, 2006 [Page 11]
Internet-Draft Control Plane Security Capabilities October 2005
Consideration.
None
2.2.9. Ability to limit the length of prefixes
Capabilities.
The device may has the capability to allow filtering route updates by
prefix length.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
Current Implementations.
With this method attacks can be mitigated, such as attacks mentioned
in 2.2.8. In order to forge enough routes, the prefix length in false
updates will always be long. For the routers used for large ISPs,
prefix length in the routing table should be relatively short, so it
is adequate to limit long prefix.
Consideration.
Some IPSs declare that they will not accept the announcements whose
prefix length is greater than a specific threshold.
''long'' and ''short'' are relative. Administrator may choose a proper
value according to the actual environment.
2.2.10. Ability to filter route redistribution
Capabilities.
The device should provide method to limit the scope of route
redistribution between different route protocols.
Supported Practices.
1. Route Filter ([PRACTICES] section 2.5.7
Current Implementations.
When more than two route protocols are available in a device in the
same time, it is neccessary to share route information among them.
Although route redistribution bridges between different route domains
Zhao Expires April 9, 2006 [Page 12]
Internet-Draft Control Plane Security Capabilities October 2005
and improves the flexibility of routing system , it may lead to
looping or black hole as well. Furthermore, if false routes injected
by the attacker are redistributed into other route domains(such as
BGP), the scope of the attack may be extended. Thus filtering
redistribution routes is necessary.
Some ISPs demand that an adjacent ISP should not configure unfiltered
redistribution from his interior routing protocol into BGP.
Consideration.
None
2.3. log
2.3.1. Ability to log the failure of authentication
Capabilities.
The device has a capability to allow the failing authentication to be
logged. The log must be stored in non-volatile media of the device or
other log server.
Supported Practices.
Logging consideration ([PRACTICES] section 2.7)
Current Implementations.
Most devices provide logging function. A failing authentication
indicates a security violation of the routing peer or an attack by
malicious nodes.
Considerations.
None
2.3.2. Ability to counter and log denied packets
Capabilities.
The device should provide ability to counter and log denied packets.
The log data is important for the audit. It is unnecessary to log
everything, but the follow points should be captured:
Source and destination address
Zhao Expires April 9, 2006 [Page 13]
Internet-Draft Control Plane Security Capabilities October 2005
Source and destination port
Protocol
Packet type
Time
Supported Practices.
1. Logging consideration ([PRACTICES] section 2.5.7
Current Implementations.
Logging is an essential function used for auditing.
Consideration.
None
2.4. Route Flap Dampening
''route flap'' means that a route's state changes from up to down or
down to up. When ''route flap'' occurs , the route process has to
insert or delete an item and the advertise update. That large amounts
of routes continue to flap will exhausting CPU and finally result in
DoS. The attacker can delete and insert routes to make route flap.
2.4.1. Ability to dampen route flap
Capabilities.
The device should provide ability to dampen route flap.
Different dampening algorithms may be involved in different
parameters.
Supported Practices.
Route flapping dampening is the primary mechanism to mitigate the
influence caused by flapping.
Current Implementations.
The function to dampen route flap may enhance the stability of
routing system and minimize the influence of flapping. It is useful
to counter against some DoS attacks.
Zhao Expires April 9, 2006 [Page 14]
Internet-Draft Control Plane Security Capabilities October 2005
BGP has implemented a dampening algorithm based on a penalty value.
Consideration.
None
2.5. Architectural Security Capabilities
Protective measures can be taken to prevent date from the data plane
and management plane into the control plane. In fact majority of
attacks aimed at the control plane are launched by the user in the
data plane.
2.5.1. Ability to isolate control plane from data plane logically
Capabilities.
The device should provide the ability to isolate the control plane
from the data plane.
Supported Practices.
1. Route Authentication([PRACTICES] section 2.5.7
Current Implementations.
Using routes authentication and origin filtering, it is ensured in
some certain that malicious users in the data plane can not
establish a session with the control plane.
Consideration.
None
2.6. Ability to provide route confidentiality
Capabilities.
The device should provides a means to prevent routing information
from unauthorized disclosure. It is generally realized through using
encryption.
Supported Practices.
1. Route Authentication([PRACTICES] section 2.5.7
Current Implementations.
Zhao Expires April 9, 2006 [Page 15]
Internet-Draft Control Plane Security Capabilities October 2005
It is not enough that only authentication is applied to route updates.
Through intercepting route information, the attacker may perform
analysis to the data and obtains the network topology.
Typically, a route protocol does not provide any encryption feature
by itself. The most common measure is to combine an external
encryption mechanism, such IPSec,SSL/TLS.
BGP can be deployed together with IPSec to ensure route date
confidentiality.
Consideration.
None
2.7. Anti-replay
2.7.1. Ability to anti-replay
Capabilities.
The device should provide anti-replay mechanism to make it impossible
for an attacker to insert packet in the route traffic.
Supported Practices.
1. Route Authentication([PRACTICES] section 2.5.7
Current Implementations.
It is natural for protocol based on TCP that provides the slide
window mechanism and detects sequence numbers repetition.
Other protocols which are not based on TCP can combine with special
security protocols, such as IPSec, to provide the anti-replay feature.
Consideration.
None
3. Security Considerations
TBD
4. Acknowledgments
TBD
Zhao Expires April 9, 2006 [Page 16]
Internet-Draft Control Plane Security Capabilities October 2005
5. References
5.1. Normative References
[RFC1195] R. Callon, ''Use OSI IS-IS for Routing in TCP/IP and Dual
Environment'', RFC 1195, December 1990
[RFC1771] Y. Rekhter, T. Li, ''A Border Gateway Protocol 4 (BGP-4)'',
RFC 1771, March 1995
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC2328] J. Moy, ''OSPF version 2'', RFC 2328, April 1998
[RFC3565] T. Li, R. Atkinson, Intermediary System to Intermediary
System (IS-IS) Cryptographic Authentication'', RFC 3567,
July 2003
[RFC3682] V. Gill, J. Heasley, D. Meyer, The Generalized TTL Security
Mechanism (GTSM), RFC 3682, February 2004
[RFC3330]IANA, Special-Use IPv4 Addresses,September,2002
5.2. Informative References
[PRACTICES] M. Kaeo, "Operational Security Current Practices",
Internet-Draft(to be published) draft-ietf-opsec-current-
practices-00, February 2005.
[ORF] Enke Chen, Yakov Rekhter, ''Cooperative Route Filtering
Capability for BGP-4'', Internet-Draft(to be published)
draft-ietf-idr-route-filter-11.txt, December, 2004
[FILTER] C. Morrow, G, Jones, ''Filtering Capabilities for IP Network
Infrastructure'', Internet-Draft(to be published) draft-
morrow-filter-caps-00.txt, February 2005
Zhao Expires April 9, 2006 [Page 17]
Internet-Draft Control Plane Security Capabilities October 2005
Author's Addresses
Zhao Ye
Huawei Technologies
No.3, Xinxi Road, Shangdi Information Industry Base
Haidian District, Beijing City
P.R. China 100085
Phone: 86-10-8288 2793
Email: z48186@huawei.com
Miao Fuyou
Huawei Technologies
No.3, Xinxi Road, Shangdi Information Industry Base
Haidian District, Beijing City
P.R. China 100085
Phone: 86-10-8288 2502
Email: miaofy@huawei.com
Intellectual Property Statement
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
Zhao Expires April 9, 2006 [Page 18]
Internet-Draft Control Plane Security Capabilities October 2005
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhao Expires April 9, 2006 [Page 19]