Internet DRAFT - draft-zhao-sidr-architecture
draft-zhao-sidr-architecture
SIDR Z. Ye
Internet Draft Huawei Technologies
Expires: December 1 2007 July 20, 2006
Architecture to Secure Inter-Domain Routing
draft-zhao-sidr-architecture-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 January 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Zhao Expires January 20, 2007 [Page 1]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
Abstract
This draft describes an architecture for secure inter-domain routing
(BGP [RFC4271]). The architecture consists of components (i.e.
functional modules) which address the requirements mentioned in
[REQUIREMENT]. The draft describes interfaces (i.e. security services)
that the architecture provides to routing engine as well.
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
1.1. Overview...............................................3
1.2. Traditional Inter-Autonomous Routing System.............3
1.3. Goals of the architecture...............................3
2. Overview of the architecture.................................4
2.1. BGP Routing engine......................................5
2.2. BGP Security Architecture...............................6
2.3. Interface provided to BGP Routing engine................6
3. BGP Security Architecture....................................7
3.1. Payload Security........................................7
3.2. Semantics Security......................................8
3.2.1. Semantics Security of SIDR entities................8
3.2.1.1. AS (autonomous system)........................8
3.2.1.1.1. Entities inside an AS....................8
3.2.1.2. Address Holder................................9
3.2.1.3. Route Object..................................9
3.2.1.3.1. Authenticity of a Prefix.................9
3.2.1.3.2. Authenticity of Attributes...............9
3.2.2. Semantics Security of Entities Relationship........10
3.2.2.1. Relationship about Prefix Authorization.......10
3.2.2.2. Relationship during Transitive of Route Objects11
3.2.2.3. Other Relationship...........................11
3.3. Security Mechanism.....................................11
3.3.1. Certificate Mechanism.............................11
3.3.2. Signed Digital Data Object........................12
3.3.3. Protection Mechanisms of BGP Session..............12
3.3.4. Others...........................................12
3.4. Other Mechanism........................................12
3.4.1. Trust Mechanism...................................12
3.4.2. Transportation and Storage of Security Data........13
Zhao Expires January 20, 2007 [Page 2]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
4. Security Considerations.....................................13
5. Acknowledgments............................................13
6. References.................................................14
6.1. Normative References...................................14
6.2. Informative References.................................14
Author's Addresses............................................15
Intellectual Property Statement................................15
Disclaimer of Validity........................................15
Copyright Statement...........................................16
Acknowledgment................................................16
1. Introduction
1.1. Overview
This document describes an architecture for secure inter-domain
routing (BGP [RFC4271]). The architecture consists of components (i.e.
functional modules) which address the requirements mentioned in
[REQUIREMENT]. The draft describes interfaces (i.e. security services)
that the architecture provides to routing engine as well.
EDITORS NOTE: This is an early draft. Additional work will be needed.
Functional models should be refined and interfaces should be defined
as well.
1.2. Traditional Inter-Autonomous Routing System
An inter-autonomous routing system can be modeled simply as follow:
o ASes (autonomous systems). Each has a single interior routing plan
and uses inter-domain routing protocol (BGP) to determine how to
route packets to others.
o BGP sessions. ASes are interconnected to each other by EBGP
session and form a network of ASes.
o Route objects. A route object consisting of network reachability
information and relevant attributes is transmitted between ASes.
In general it is contained in the BGP UPDATE. ASes originate and
re-generate route objects and exchange them through established
BGP sessions.
1.3. Goals of the architecture
1. The architecture should use existing SIDR (Secure Inter-Domain
Routing) solutions as a reference and should be consistent to them
mostly. BGP security has been studies during the past decade and a
Zhao Expires January 20, 2007 [Page 3]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
number of solutions have been proposed. Each solution addresses
some aspects of the issues, so one important goal of this
architecture is consistency to these ideas and different deployment
scenarios.
2. Potential requirements must be taken into account. For example,
when a new attributes type is introduced in the future, the
architecture still can be kept stable.
3. Incremental deployment is a MUST requirement listed in section
3.2 of [REQUIREMENT] and is an architecture requirement as well. A
proposed security system MUST be able to coexist with traditional
systems (compatible with prior BGP system) and support incremental
additions of functional module.
2. Overview of the architecture
+-------------------------------------------------------------------+
| BGP Routing engine |
| +----------------+ +----------------+ +----------------+ |
| | Input | | Route | | Output | |
| | Policy | | Selection | | Policy | |
| +----------------+ +----------------+ +----------------+ |
+---------|----------------------|----------------------|-----------+
| | |
V V V
+-------------------------------------------------------------------+
| BGP Security Architecture |
| +--------------+ +--------------------+ |
| | | | Semantics Security | |
| | Security | | +----------------+ | |
| | Mechanism | | | Entities | | |
Zhao Expires January 20, 2007 [Page 4]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
| | | | | Relationship | | |
| +--------------+ | +----------------+ | |
| | +----------------+ | |
| | | Entities | | |
| +--------------+ | | | | |
| | | | +----------------+ | |
| | Other | +--------------------+ |
| | Mechanisms | +--------------------+ |
| | | | Payload Security | |
| | | | | |
| +--------------+ +--------------------+ |
+-------------------------------------------------------------------+
Figure 1: Architecture of SIDR
The figure above depicts the architecture of BGP security and its
relationship with the BGP routing engine. The routing engine invokes
the interfaces to obtain security services.
2.1. BGP Routing engine
From an implementation point of view, a BGP routing engine consists
of three functional modules. Each functional module may be affected
by BGP security requirements.
o Input Policy.
Input policy contains rules to filter route information received from
peers. In a SIDR system, input policy may be affected through
introducing security rules.
o Route Selection.
Route selection is a complex procedure to determine a best path to a
specific destination. In a SIDR system, security should be considered
in this procedure.
Zhao Expires January 20, 2007 [Page 5]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
o Output Policy.
Output policy contains rules to determine which routes could be
advertised to peers. The output policy may be affected by introduced
security rules as well.
2.2. BGP Security Architecture
This BGP security architecture includes several components:
o Payload Security
As mentioned in section 1.3 of [REQUIREMENT], the data payload of the
protocol is one primary point where BGP may be secured. "Payload
security" functional module serves for this purpose.
o Semantics Security
This module is used to verify authenticity of entities of BGP system
and relationships among them.
o Security Mechanism
These mechanisms are basic security components which will be invoked
by payload and semantics security components.
Some standard security protocols such as IPSec, TLS and so on are all
included.
o Other mechanisms
This section describes the mechanisms which will not be invoked
directly by the routing engine, but is necessary to SIDR system.
Generally, they are not directly correlative with security
requirements.
These mechanisms may include key management, trust module,
transportation and storage of security data.
2.3. Interface provided to BGP Routing engine
The architecture provides interfaces through which the routing engine
obtains security services. These services include verifying the
validation of an entity in BGP system, verifying the relationship
between entities, inserting security information into PDUs (Protocol
Data Unit), processing security information in received PDUs and so
on.
Zhao Expires January 20, 2007 [Page 6]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
NOTE: Such interfaces are not necessarily implemented in one device.
For example, [IRV] proposes a solution in which a router consults a
dedicated server to verify an UPDATE.
3. BGP Security Architecture
The architecture focuses on functional partitioning, which concerns
more about what to do. Each component in it is a functional module.
[REQUIREMENT] is a guideline and restriction document to implement
these functional modules.
Section 1.3 of [REQUIREMENT] mentions two primary points in BGP
security, the data payload and the data semantics security of the
protocol which are all basic components of the architecture. Section
3 of [REQUIREMENT] lists some operational restrictions which could be
referenced during designing specific functions.
3.1. Payload Security
o Payload Security of a BGP session
This module mainly offers services to secure a BGP session between
ASes including protecting establishment and closure of a BGP session
and transportation of BGP protocol data. These services may include
data integrity, anti-replay, data origin authentication, peer entity
authentication and so on.
Generally, the security services will affect the efficiency of a
routing system, which is one restriction when designing this
functional module. Requirements in section 3.1 and 3.5 of
[REQUIREMENT] should be referenced.
A feasible solution may be implemented in different layers, such as
the network layer, the transport layer and the application layer.
IPSec, TCP MD5 option, TLS are all candidates. [TCPAUTH] proposes a
new option to secure a TCP session, which can be regarded as an
enhance version of the TCP MD5 option and can provide a integrality
service to a BGP session.
o Payload Security during the Propagation of an UPDATE Message
This module provides security services to protect propagation of a
UPDATE Message.
For example, an origin AS may sign specific attributes in a UPDATE in
order to make other ASes in the AS_PATH to verify whether information
has been modified during the transportation.
Zhao Expires January 20, 2007 [Page 7]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
Since this is a BGP problem, relevant services should be provided in
the application layer.
3.2. Semantics Security
Semantics Security is a central component of the architecture. It
focuses on the authenticity of SIDR entities and relationships
between them. Whether an AS number is valid is an example of the
former. Whether an AS is authorized to originate an address prefix by
its address holder is an example of the latter.
Current deployment mechanisms, such as route filters, are used to
deal with some semantics problems. One example is to filter bogon
address prefixes. Another example is to determine whether an origin
AS is listed in AS_PATH attribute.
Generally, semantics security protects two aspects: authenticity of
entities and authenticity of relationships.
3.2.1. Semantics Security of SIDR entities
Authenticity of entities is the precondition to validate relationship.
There are several top level entities in a SIDR system: ASes, address
holders, route objects.
NOTE: In current BGP system, ASes trust each other and address
holders need not participate. However, in a SIDR system, an address
holder needs to authorize ASes to originate its prefix so it is a
necessary entity.
3.2.1.1. AS (autonomous system)
o the authenticity of an AS
An AS number is an identity of an AS. This functional module is used
to determine if a specific AS number is valid and to verify related
identity claimed by an AS.
3.2.1.1.1. Entities inside an AS
An AS is a complicated system and consists of various components,
such as ASBR (AS border router), RR (route reflector), PE (provider
edge) and so on. Not all BGP entities need to participate in a SIDR
system or at least different entities may play different roles.
On the one hand route information is originated from inside of an AS
such as static route and IGP route, on the other hand
Zhao Expires January 20, 2007 [Page 8]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
misconfigurations and deliberate attacks toward AS are root of
problems we faces. Therefore, a complete SIDR system may include
components to ensure security inside an AS and should protect AS from
advertising invalid UPDATEs.
o the authenticity of an ASBR
An ASBR (AS border router) is a BGP speaker router which is
responsible for advertising route information representing the AS.
This functional module is to validate if a speaker has the identity
claimed by it.
o the authenticity of other entities
TBD.
3.2.1.2. Address Holder
o the authenticity of an address holder
An address holder, such as IANA, RIR, did not appear in the
traditional BGP system. Since validation of a prefix and whether an
AS is authorized to advertise a prefix are all concerned by SIDR. An
address holder is supposed to participate in the SIDR system.
This module is to validating if an address holder is a valid holder.
3.2.1.3. Route Object
The term "route object" mainly refers to prefixes and related path
attributes conveyed in a BGP UPDATE message.
3.2.1.3.1. Authenticity of a Prefix
A valid prefix should be an allocated global unicast address.
Allocation of IPv4 address space can be consulted from [IANA].
3.2.1.3.2. Authenticity of Attributes
EDITORS NOTE: attributes should be classified in order to be
compatible with new attributes. This may be potential work items.
o Authenticity of an AS_PATH attribute
Validation of AS_PATH is mentioned in section 1.3 of [REQUIREMENT].
The first category summarized in it is whether the AS_PATH actually
exists. Since BGP is a path vector protocol and does not maintain a
Zhao Expires January 20, 2007 [Page 9]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
topology, there is not a protocol mechanism to resolve this problem.
This functional module focuses on the problem. It is used to check if
an AS_PATH is a valid path in the network.
NOTE [SoBGP] proposes a topology map to resolve this problem.
Existence of an AS path may not mean its validation. A further demand
may be a valley-free path, but it is difficult to validate such
semantics.
o Authenticity of Other path attributes
TBD.
3.2.2. Semantics Security of Entities Relationship
This section describes relationships between the entities mentioned
above. In particular this includes relationships about prefixes
authorization and relationship occurring during propagation of route
information.
3.2.2.1. Relationship about Prefix Authorization
Following table depict potential relationships about prefixes
authorization.
+--------------+----------------+----------------+------------------+
| | Address Holder | AS | ASBR |
+--------------+----------------+----------------+------------------+
| | Authorize to |Authorize to | |
|Address Holder| own |originate | N/A |
| | | | |
+--------------+----------------+----------------+------------------+
| | |Authorize to |Authorize to |
| AS | N/A |originate |advertise |
| | | | |
+--------------+----------------+----------------+------------------+
Zhao Expires January 20, 2007 [Page 10]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
o Ownership of an Address
The ownership of an address is the anchor of subsequent authorization.
This functional module is used to verify whether an address holder
own specific prefixes.
o Prefix Authorization
This function module involves several types of authorization as
follows:
- Is a subordinate address holder authorized to own specific prefixes
by an upper address holder?
- Is an AS authorized to originate specific prefixes by an address
holder or another AS?
- Is a router authorized to advertise specific prefixes representing
a specific AS?
3.2.2.2. Relationship during Transitive of Route Objects
Since route processing is a per-hop based behavior, except for
immediate ASes, a receiver could not tell which AS an UPDATE has
arrived at.
o Authenticity of AS_PATH Travel.
This function is used to verify whether the UPDATE has actually
traveled the ASes listed in AS_PATH.
3.2.2.3. Other Relationship
o Relationship between ASes
Do two ASes really interconnect each other?
3.3. Security Mechanism
3.3.1. Certificate Mechanism
In this document, a certificate means a public-key certificate which
binds a public/private key pair to a specific subject. It may also
include extensions about the subject.
Zhao Expires January 20, 2007 [Page 11]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
In SIDR system, a certificate mechanism serves for identity
authentication, data integrality validation and prefix authorization.
NOTE: Generally lifetime of a subject is longer than validity period
of authorization, so it may be not adequate to convey a short-term
authorization in a public-key certificate.
3.3.2. Signed Digital Data Object
A signed digital data object is used to convey authorizations and
policies to specific subjects and is protected by a digital signature.
For example, it can be used to verify whether an AS is authorized to
advertise a block of address space.
3.3.3. Protection Mechanisms of BGP Session
Mechanisms to protecting BGP sessions serve for payload security,
which may include data integrity, anti-replay, peer authentication,
etc.
Some standardized security protocols provide these mechanisms, such
as IPSec, TLS. [TCPAUTH] proposes a lightweight solution to provide
an integrality service to a TCP session.
3.3.4. Others
TBD.
3.4. Other Mechanism
3.4.1. Trust Mechanism
+-------------------------------------+
| trust mechanism |
| +-------------+ +-------------+ |
| | underlying | | underlying | |
| | trust model | | trust model | |
| +-------------+ +-------------+ |
+-------------------------------------+
Zhao Expires January 20, 2007 [Page 12]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
With regard to trust models in SIDR systems, there are two issues
involved. One is which type of underlying trust model to choose. The
other is how to cooperate with a SIDR system which has a different
trust model. The former is a business issue which depends on
practical requirements. The latter is an unsolved technical issue.
Section 5 of [REQUIREMENT] mentions some requirements about the trust
model. From the point of view of this architecture, an underlying
trust model should be transparent to the routing engineer.
3.4.2. Transportation and Storage of Security Data
TBD.
4. Security Considerations
Security is the subject matter of this entire document.
5. Acknowledgments
The authors gratefully acknowledge the contributions of:
o tbd, xxx, yyy, ...
o We would like to thank Miao Fuyou and Hui Liu for their helpful
comments and suggestions.
o This listing is intended to acknowledge contributions, not to imply
that the individual or organizations approve the content of this
document.
o Apologies to those who commented on/contributed to the document and
were not listed.
Zhao Expires January 20, 2007 [Page 13]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
6. References
6.1. Normative References
[RFC4271] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IPSec] S. Kent, K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
6.2. Informative References
[REQUIREMENT] B. Christian, T. Tauber, "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-05, April 2006.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000.
[IRV] Geoffrey Goodell, William Aiello, Timothy Griffin, John
Ioannidis, Patrick McDaniel, Aviel Rubin, "Working Around
BGP: An Incremental Approach to Improving Security and
Accuracy of Interdomain Routing".
[SBGP] Charles Lynn, Joanne Mikkelson, Karen Seo, "Secure BGP (S-
BGP)", draft-clynn-s-bgp-protocol-01.txt, June 2003.
[SoBGP] R. White, "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)", draft-white-sobgp-architecture-
01.txt, May 24, 2005.
[TCPAUTH] R. Bonica, B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
"Authentication for TCP-based Routing and Management
Protocols", draft-bonica-tcp-auth-04.txt, February 2006.
Zhao Expires January 20, 2007 [Page 14]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
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-5849 1057
Email: yezhao@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
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.
Zhao Expires January 20, 2007 [Page 15]
Internet-Draft Architecture to Secure Inter-Domain Routing July 2006
Copyright Statement
Copyright (C) The Internet Society (2006).
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 January 20, 2007 [Page 16]
