[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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
      <length, prefix>, 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/