Inter-Domain Routing A. Retana Internet-Draft R. Raszuk Intended status: Standards Track Cisco Systems, Inc. Expires: September 8, 2011 March 7, 2011 BGP Security State Diagnostic Message draft-retana-bgp-security-state-diagnostic-00 Abstract This document describes an extension to the BGP Diagnostic Message to communicate the security state of a route. An application of this extension is to propagate information about non-secure advertisements back to the eBGP peer from where the information was received. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Retana & Raszuk Expires September 8, 2011 [Page 1] Internet-Draft BGP Security State Diagnostic Message March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. The BGP Security State Diagnostic Message . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Retana & Raszuk Expires September 8, 2011 [Page 2] Internet-Draft BGP Security State Diagnostic Message March 2011 1. Introduction BGP Prefix Origin Validation [I-D.ietf-sidr-pfx-validate] defines the interaction between BGP and a database able to map prefixes to their authorized ASes. One of the potential actions resulting from an "invalid" route is to reject it. This document describes an extension to the BGP Diagnostic Message [I-D.raszuk-bgp-diagnostic-message] and its use to communicate information about these "invalid" paths. The main motivation is to facilitate troubleshooting, monitoring, logging or even correction of the security mechanisms' operation, especially during initial deployment. 2. Requirements Language 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 [RFC2119]. 3. The BGP Security State Diagnostic Message The BGP Security State Diagnostic Message is a TLV to be carried in the BGP Diagnostic Message and is used to communicate the local security state of a path. It is defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method Code | Validity Code | Reason Code |Reason Sub-Code| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | SAFI | # NLRI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BGP Security State Diagnostic Message Retana & Raszuk Expires September 8, 2011 [Page 3] Internet-Draft BGP Security State Diagnostic Message March 2011 Type: Two octet field with a value TBD. Length: Two octet field indicating the TLV length in octets. Method Code: One octet field. Indicates which security mechanism was used to determine the validity of the path. Value Meaning 0 Reserved 1 BGP Prefix Origin Validation [I-D.ietf-sidr-pfx-validate] Method Codes Validity Code: One octet field. Indicates whether the path is considered secure or not by the local AS. The values are to be interpreted relative to the Method defined above. The following values are defined for Method Code 1: Value Meaning 0 Reserved 1 Not Found 2 Invalid Path Validity Codes Reason Code: One octet field. Indicates the reason the security mechanism listed in the Method Code considered the path as indicated in the Validity Code. The values are specific to the Method Code used. The following Reason Codes are defined for Method Code 1, Validity Code 2: Value Meaning 0 Reserved 1 Invalid Origin 2 Certificate doesn't exist Reason Codes Retana & Raszuk Expires September 8, 2011 [Page 4] Internet-Draft BGP Security State Diagnostic Message March 2011 Reason Sub-Code: One octet field. Indicates any additional information related to the Reason Code indicated for the specific Method used. At this time no specific values are defined. AFI (Address Family Identifier): Two octet field, encoded the same way as in RFC 4760 [RFC4760]. SAFI (Subsequent Address Family Identifier): Two octet field, encoded the same way as in RFC 4760 [RFC4760]. # NLRI (Number of Network Layer Reachability Information entries): One octet field indicating the number of NLRI entries to follow. NLRI: Variable length field encoded as one or more 2-tuples of the form , as described in RFC 4760 [RFC4760]. Data: Variable length field. Indicates any additional information related to the Reason Code indicated for the specific Method used. This is an OPTIONAL field with variable length. 4. Operation The mechanism described is intended to be primarily applied at autonomous system border routers. When a BGP speaker receives what considers to be an invalid advertisement it MAY send a BGP Security State Diagnostic Message to the eBGP peer from where it received it. It is RECOMMENDED that a BGP speaker limit the number of messages sent to a specific peer over a given period of time and that the messages be built in such a way as to include as many NLRI as possible. A BGP speaker SHOULD also send the BGP Security State Diagnostic Message in response to the "Prefix specific BGP query" TLV (type 17) or the "Diagnostic Message Query" TLV (type 3). The BGP Security State Diagnostic Message SHOULD NOT be sent periodically to a peer; to achieve this behavior the "Max frequency permitted" TLV (type 2) should be used to announce a value of 0. The information contained in the BGP Security State Diagnostic Message can then be used to diagnose and correct any potential local security policy violations. Specific actions taken are outside the scope of this document, but could include withdrawing the original UPDATE or simply logging the information. Retana & Raszuk Expires September 8, 2011 [Page 5] Internet-Draft BGP Security State Diagnostic Message March 2011 5. IANA Considerations IANA is asked to create and maintain registries for the fields described in Section 3, and to assign the corresponding TLV type. 6. Security Considerations The mechanism described in this document doesn't add any new security concerns. 7. Acknowledgements The mechanism described in this document was influenced by discussions with Dacheng Zhang and Mingui Zhang. The authors would like to thank the following people for their comments and suggestions: Bertrand Duvivier, Keyur Patel, Roque Gagliano and Russ White. 8. References 8.1. Normative References [I-D.raszuk-bgp-diagnostic-message] Raszuk, R., Chen, E., and B. Decraene, "BGP Diagnostic Message", draft-raszuk-bgp-diagnostic-message-00 (work in progress), October 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 8.2. Informative References [I-D.ietf-sidr-pfx-validate] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", draft-ietf-sidr-pfx-validate-01 (work in progress), February 2011. Retana & Raszuk Expires September 8, 2011 [Page 6] Internet-Draft BGP Security State Diagnostic Message March 2011 Authors' Addresses Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Email: aretana@cisco.com Robert Razsuk Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: raszuk@cisco.com Retana & Raszuk Expires September 8, 2011 [Page 7]