[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
SIDR Working Group                                        Dai GuangMing
Internet Draft                                                    Z. Ye
Expires: March 2007                                 Huawei Technologies
                                                              FEKI Ines
                                                         France Telecom
                                                     September 25, 2006


                   BGP UPDATE Advertisement Restriction
                  draft-dai-sidr-bgp-advertisement-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.

   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 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). All Rights Reserved.

Abstract

    SIDR working group is working on an extended architecture for
   interdomain routing security framework. One of the functions that
   this architecture should provide is origin authentication of prefixes
   for BGP, i.e. a BGP speaker must be able to determine whether an AS
   (autonomous system) is authorized to originate certain prefixes. This
   draft documents some ideas from the perspective of internal control
   in order to alleviate this problem.




Dai                    Expires March 25, 2007                 [Page 1]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


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................................................2
      1.1. Problem Description.....................................2
      1.2. Existing solutions......................................3
      1.3. Internal control ideas..................................3
      1.4. Proposed solution.......................................3
   2. Threat Model................................................3
   3. Solution....................................................4
      3.1. Framework..............................................5
      3.2. Operation..............................................5
         3.2.1. Policy maintaining.................................5
         3.2.2. Policy deployment..................................5
         3.2.3. Violation Response.................................6
   4. Future Work...................................................7
   5. Security Considerations......................................7
   6. Acknowledgements............................................7
   7. References..................................................7
      7.1. Normative References....................................7
      7.2. Informative References..................................8
   Author's Addresses.............................................9
   Intellectual Property Statement.................................9
   Disclaimer of Validity.........................................9
   Copyright Statement...........................................10
   Acknowledgment................................................10

1. Introduction

1.1. Problem Description

   It has been observed that BGP is vulnerable to several types of
   attacks (refer to [VULN]). Because of lacking inherent security
   mechanisms, a UPDATE message receiver can not tell whether the origin
   AS listed in AS_PATH is authorized to originate the prefixes. Because
   of misconfiguration or deliberate attacks, wrong prefixes may be
   propagated through UPDATE messages which may cause traffic
   redirection, black hole and some other problems.





Dai                    Expires March 25, 2007                 [Page 2]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


1.2. Existing solutions

   [SBGP] proposes an autonomous system numbers and prefix allocation
   based PKI to provide an authentication infrastructure to solve this
   problem.

   [SoBGP] solves it in a similar ways except that it uses web-of-trust
   model for AS identity authentication.

   [IRR] is a global distributed database where routing information is
   stored . The purpose is to ensure stability and consistency of the
   Internet-wide routing. One can consult the database to obtain the
   origin AS of a prefix.

1.3. Internal control ideas

   Some research projects have focused on internal control of an AS.
   [RCC] is a configuration analysis tool. Network operators can use it
   to verify whether network configurations satisfy a prior anticipation.

   [RCP] offers a proposal which introduces a routing control plane and
   mainly focuses on internal problems within an AS, such as protocol
   oscillation, forwarding loops, blackholes and so on.

1.4. Proposed solution

   This draft proposes a solution to alleviate the problem. Since the
   root cause of the problem is mistake on advertisements, it is
   necessary to check the outbound advertisements besides of validating
   received UPDATE. This draft proposes methods to make sure that origin
   of routes is consistent with the anticipated configuration.

   This solution is not brand-new, but it is low cost and incrementally
   deployable. The solution can be applied alone or be part of a future
   total solution about BGP security. When an AS has too limited
   resource to support an expensive security mechanism, this proposal
   may also be beneficial.

2. Threat Model

   Basically, the threat will occur in following two situations.

   1            In a deliberate attack situation

   An attacker may intercept BGP protocol traffic and modify the
   information of the traffic. Authentication mechanism can counter the



Dai                    Expires March 25, 2007                 [Page 3]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


   attack of this type, and [IPsec], [TLS] or [TCPMD5] can be applied to
   provide such authentication.

   An attacker may also compromise a BGP border router and advertises
   vicious prefixes through it.

   2            In a misconfiguration situation

   BGP provides no inherent measure to control or monitor route
   advertisements. Misconfigurations will not be checked or trigger any
   alarm either. With the size of the AS growing, manual configuration
   may increase the probability of configuration error. In many known
   problems, the wrong prefixes have been advertised were mainly caused
   by misconfiguration. Deliberate attacks are similar to
   misconfiguration and attacks were reported relatively rarely.

   A number of reasons (for example, the complexity of network and its
   configuration, manual configuration and absence of unified bound to
   apply AS-level strategy) leads to the fact that the actual network
   operation is not consistent with the anticipation.

3. Solution

   The proposal suggests mechanisms to avoid advertising a wrong message
   from the inside of an AS and to avoid the mistake in the first place.

   The main obstacles [IRR] faces are how to keep the database up-to-
   date and complete, which limit its use. Conversely, for an AS the
   range of prefixes that originate from it is a prior knowledge.
   Therefore, it is possible to validate and restrict the advertisement
   behavior of the AS. Technically, attacks caused by compromised device
   are similar to those by misconfiguration, so the solution is also
   effective to mitigate such attacks.

   This solution can be incrementally deployed. Prefixes originating
   from AS are filtered inside of the AS and EBGP sessions between ASes
   will not be affected. Besides, received advertisements are also
   filtered on the basis of a legitimacy level associated with an AS. It
   is considered as its legitimacy to originate prefixes. This level is
   inferred from IRR and received advertisements.

   This solution is compatible with [SBGP] and [SoBGP]. Introduced
   infrastructure in these proposals, such as PKI, can be used to
   provide trust, when restricting advertised prefixes.





Dai                    Expires March 25, 2007                 [Page 4]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


3.1. Framework

                        +-------+ ------>   +-------+

                        |       | (policy)  |       |

                        |   PS  |---------- |   RA  |

                        |       | <------   |       |

                        +-------+ (alarm)   +-------+

                    Figure 1: System Architecture

   Figure 1 is the framework of the system. RA is a border router in a
   single AS and PS is a policy station in that AS.

   One task of PS is to maintain a uniform advertising policy and to
   deploy the policy inside the whole AS. Another task is to collect
   alarms of inconsistent behavior from border routers inside the AS.

   As a border router, such as RA in figure 1, before prefixes being
   advertised out of the AS, they should check them against the policy
   to determine whether the prefixes are consistent with the policy.

3.2. Operation

3.2.1. Policy maintaining

   A policy station in an AS is responsible for maintaining a prefixes
   advertisement policy. A policy station could be a dedicated host or a
   router who has implemented additional functions of policy maintaining.

   Conceptually a policy defines the range of prefixes which originate
   from the AS. The policy may be established by manual configuration or
   introduced into an AS through some external mechanism. For example,
   for the address PKI proposed by [SBGP], the policy may be introduced
   by utilizing Address Attestation (AA). In any case, the most
   important thing is to ensure the accuracy of the range of prefixes,
   i.e. to ensure the advertised prefixes originating from some AS is
   properly authorized.

3.2.2. Policy deployment

   There are two types of deployment model according to participation of
   a router.



Dai                    Expires March 25, 2007                 [Page 5]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


   o Distributed deployment model

   In this scenario, the advertisement policy should be deployed in
   every BGP speaker in an AS. A policy station could use a BGP-based
   mechanism to distribute the policy, such as a new type of BGP message
   or some technology similar to [ORF]. The policy could also be
   distributed in an "out-of-band" channel.

   In this model, border routers are responsible for the policy
   execution. The policy may be implemented with some filtering
   mechanisms. Before distributing static or IGP routes into RIB of BGP,
   the routes should be checked.

   Since the policy is deployed inside an AS, transport security of the
   policy may not be a serious problem. It is important to keep policy
   deployment reliable and on time.

   o Centralized deployment model

   In this model, border routers need not execute security policies. A
   policy station can make use of IBGP, as mentioned in [RCP], to obtain
   advertised routes and check them against the deployed policy. In this
   way, the policy station is able to determine whether a route is
   consistent with the policy. If not, it triggers an alarm to a
   management system.

   Because a policy check occurs at a single host, a policy station is
   supposed to keep online and analyze the alteration of routes in time.

3.2.3. Violation Response

   When local routes violate the deployed policy, there are two kind of
   possible measures to be taken:

   o A loose measure

   If a router uses a loose measure, violating routes will still be
   advertised. However, an event should be reported to a management
   system immediately, so an administrator could perform a proper
   counter measure in time.

   o A strict measure

   If a router uses a strict measure, violating routes will be filtered
   and will not be spread out of the AS. This is an active measure and
   can prevent false route from being advertised, which may be caused by
   misconfiguration.


Dai                    Expires March 25, 2007                 [Page 6]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


   If this security measure is implemented as a mandatory option,
   attacks made by a compromised router may also be detected.

4. Future Work

   This application framework is more fit for BGP stub ASes which do not
   provide transitive services and for the ASes whose devices are with
   limited resource.

   As to upper ASes, frequent changes of internet route must be
   considered. In such situation, a policy station is supposed to know
   these changes, so it should be [s|so|ps]BGP-aware and could get
   credible routing and authorization information from outside security
   systems.

   Furthermore, the policy station could be enhanced to process more
   complicated semantic validation, such as AS_PATH validation.

   To sum up, in this framework only a few devices in an AS are required
   to participate in security validation. In this way most BGP router
   could meet security requirements without update hardware.

5. Security Considerations

   This draft focuses on preventing sending and receiving BGP false
   advertisements incurred by misconfiguration. Since attack may also be
   a potential cause of the problem, the proposal is a security
   mechanism for BGP in the same time.

   A policy station is the key element of the solution. Since it is
   located in the domain of an AS, launching an attack toward it may be
   difficult. If strict security requirements are needed, operators may
   take more strict access control to the policy station.

6. Acknowledgements

7. References

7.1. Normative References

   [RFC1208]  Jacobsen, O. and D. Lynch, "Glossary of networking terms",
   RFC 1208, March 1991.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
   1812, June 1995.




Dai                    Expires March 25, 2007                 [Page 7]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
   E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918,
   February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   equirement Levels", BCP 14, RFC 2119, March 1997.

   [BGP]  Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4
   (BGP-4)", RFC 4271, January 2006.

   [IPsec]  Kent, S. and R. Atkinson, "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998.

   [TLS]  T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
   January 1999.

   [TCPMD5]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
   Signature Option", RFC 2385, August 1998.

7.2. Informative References

   [VULN]  S. Murphy, "BGP Security Vulnerabilities Analysis", RFC 4272,
   January 2006.

   [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.

   [IRR]  "Internet Routing Registry", http://www.irr.net.

   [RCC]  MIT, "Routing Configuration Checker",
   http://nms.lcs.mit.edu/bgp/rcc/#status.

   [RCP]  Matthew Caesar, Donald Caldwell, Nick Feamster, Jennifer
   Rexford, Aman Shaikh, Jacobus van der Merwe, "Design and
   Implementation of a Routing Control Platform".

   [ORF] Enke Chen, Yakov Rekhter, "Cooperative Route Filtering
   Capability for BGP-4", draft-ietf-idr-route-filter-13.txt.







Dai                    Expires March 25, 2007                 [Page 8]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


Author's Addresses

   Dai Guangming
   Huawei Technologies
   No.3, Xinxi Road, Shangdi Information Industry Base
   Haidian District, Beijing City 100085
   Email: daigm@huawei.com

   Zhao Ye
   Huawei Technologies
   No.3, Xinxi Road, Shangdi Information Industry Base
   Haidian District, Beijing City 100085
   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



Dai                    Expires March 25, 2007                 [Page 9]


Internet-Draft  BGP UPDATE Advertisement Restriction    September 2006


   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 (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.

































Dai                    Expires March 25, 2007                [Page 10]