Internet Engineering Task Force                                 C. Loibl
Internet-Draft                                 Next Layer Communications
Updates: 5575 (if approved)                                    M. Bacher
Intended status: Standards Track                        T-Mobile Austria
Expires: February 23, 2017                               August 22, 2016


                         Flowspec Clarification
            draft-loibl-bacher-idr-flowspec-clarification-00

Abstract

   This document clarifies multiple aspects of Flowspec (RFC 5575) to
   allow a consistent and robust implementation in an multi vendor /
   inter provider environment.

   This document updates RFC 5575.

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 February 23, 2017.

Copyright Notice

   Copyright (c) 2016 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




Loibl & Bacher          Expires February 23, 2017               [Page 1]


Internet-Draft           Flowspec Clarification              August 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Clarification of the Comparison Operator  . . . . . . . . . .   3
   4.  Clarification of the Component Type Length  . . . . . . . . .   3
   5.  (Re-)Validation of the Flow Specification NLRI  . . . . . . .   4
   6.  Transitivity of Traffic Filtering Actions . . . . . . . . . .   5
   7.  Clarification of Flowspec NLRI Parsing and Validation . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   This document clarifies multiple aspects of Flowspec (RFC 5575) to
   allow a consistent and robust implementation in a multi vendor /
   inter autonomous system environment.  It describes only minimal
   changes in the behaviour defined by RFC 5575 [RFC5575] but clarifies
   many of the unclear sections of RFC 5575.

   During a large interoperability lab session involving multiple
   routing equipment vendors (Alcatel, Cisco, Huawei, Juniper) we
   identified many incompatibilities in their Flowspec implementations.
   The identified incompatibilities range from valid Flowspec network
   layer reachability information (NLRI) updates being ignored by BGP
   speakers (and not forwarded according to the normal BGP update
   mechanisms) to the inability to parse valid Flowspec NLRIs causing
   BGP notifications sent to neighbors and sessions being closed, thus
   leading to partial or complete network outages.  Most of the
   incompatibilities found during those tests were results of unclear or
   missing definitions in the flowspec RFC 5575.

2.  Terminology

   AS - Autonomous System

   BGP - Border Gateway Protocol

   DSCP - Diffserv Code Point




Loibl & Bacher          Expires February 23, 2017               [Page 2]


Internet-Draft           Flowspec Clarification              August 2016


   ICMP - Internet Control Messaging Protocol

   NLRI - Network Layer Reachability Information

   VPN - Virtual Private Network

   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.  Clarification of the Comparison Operator

   RFC 5575 section 4 under Type 3 defines the encoding of {operator,
   value} pairs where the operator bits 5-7 contain comparison flags (<,
   >, =).  The following table obsoletes the last paragraph of RFC 5575
   section 4 Type 3 ("The bits lt, gt, and eq can be combined to produce
   "less or equal", "greater or equal", and inequality values.").
   Combinations of the bits MUST be interpreted as follows:

             +---+---+---+----------------------------------+
             | < | > | = | Resulting operation              |
             +---+---+---+----------------------------------+
             | 0 | 0 | 0 | true (independent of the value)  |
             | 0 | 0 | 1 | == (equal)                       |
             | 0 | 1 | 0 | > (greater than)                 |
             | 0 | 1 | 1 | >= (greater than or equal)       |
             | 1 | 0 | 0 | < (less than)                    |
             | 1 | 0 | 1 | <= (less than or equal)          |
             | 1 | 1 | 0 | != (not equal value)             |
             | 1 | 1 | 1 | false (independent of the value) |
             +---+---+---+----------------------------------+

                Table 1: Comparison operation combinations

3.1.  Changes to RFC5575

   The behaviour of the bit-combinations is not explicitly defined.
   Especially the three combinations (0,0,0), (1,1,0), (1,1,1) are
   subject to misinterpretation.

4.  Clarification of the Component Type Length

   RFC 5575 section 4 under Type 3 defines the encoding of {operator,
   value} pairs.  The operator component contains a 2 bit length field
   (bit 2 and 3) representing the length of the value field.  This
   length field allows to encode a 1-4 byte long value.  This {operator,
   value} pairs are used as a match criteria for the flow component type




Loibl & Bacher          Expires February 23, 2017               [Page 3]


Internet-Draft           Flowspec Clarification              August 2016


   3, 4, 5, 6, 7, 8, 10, 11.  The allowed length for these components is
   as following:

                +------+--------------+------------------+
                | Type | Length       | Name             |
                +------+--------------+------------------+
                | 3    | 1-byte       | IP protocol      |
                | 4    | 1- or 2-byte | Port             |
                | 5    | 1- or 2-byte | Destination port |
                | 6    | 1- or 2-byte | Source port      |
                | 7    | 1-byte       | ICMP type        |
                | 8    | 1-byte       | ICMP code        |
                | 10   | 1- or 2-byte | Packet length    |
                | 11   | 1-byte       | DSCP             |
                +------+--------------+------------------+

                      Table 2: Allowed value lengths

4.1.  Changes to RFC5575

   The allowed length of the value for a type 3 component (IP protocol)
   was not explicitly defined.  This is inconsistent with all other
   types where the allowed length is explicitly specified.

5.  (Re-)Validation of the Flow Specification NLRI

   RFC 5575 section 6 defines a validation procedure for the flow
   specification NLRI.  The outcome of the defined validation procedure
   is depending on the best-match unicast route for the destination
   prefix embedded in the flow specification.

   Since the best-match unicast route may change over the time
   independently of the flow specification NLRI, revalidation of the
   flow specification NLRI MUST be performed whenever unicast routes
   change.  Thus changes in the best-match unicast route can effect the
   validation-state of a flow specification NLRI.

5.1.  Changes to RFC5575

   Explicit definition of the requirement of revalidation.  Revalidation
   of flow specification NLRI is not explicitly described in RFC5575,
   however it is compared with the "validation" of the reachability of
   the NEXT_HOP in the context of IP routing information.  A unicast
   route becomes unfeasible if the NEXT_HOP for that particular route
   becomes unreachable.






Loibl & Bacher          Expires February 23, 2017               [Page 4]


Internet-Draft           Flowspec Clarification              August 2016


6.  Transitivity of Traffic Filtering Actions

   RFC 5575 section 7 defines a minimum set of filtering actions.  The
   predefined traffic filtering actions are standardized as BGP extended
   community values [RFC4360].  All predefined filtering action
   communities SHALL be treated as transitive BGP extended communities.

6.1.  Changes to RFC5575

   The transitivity of the traffic filtering action extended community
   was only defined for the "traffic-rate" action (defined as non-
   transitive).  Since all filtering communities were assigned from an
   transitive pool by IANA, for consistency with RFC4360 section 2 this
   document explicitly redefines the "traffic-rate" action as
   transitive.  It also defines the transitivity of all other traffic
   filtering actions as transitive (this definition is missing in
   RFC5575).  This redefinition also reflects the behaviour of many of
   the current implementations.

7.  Clarification of Flowspec NLRI Parsing and Validation

   A flow specification NLRI is syntactically correct if it is encoded
   according to RFC 5575 section 4.  The semantic of the NLRI is opaque
   to BGP.  As a result of this statement the following behaviour is
   expected:

   Flow specification NLRI propagation through the network is following
   the BGP propagation mechanisms independent of the semantic of the
   particular NLRI itself.  The inability of the particular
   implementation to actually make use of a given flow specification
   SHOULD NOT affect the BGP NLRI propagation.  Nor SHOULD a semantical
   incorrect NLRI affect the propagation of the NLRI (the NLRI, even if
   semantically incorrect should be propergated according to BGP
   propagation mechanisms).

   Invalid NLRI semantics SHOULD NOT trigger BGP failures (ie BGP
   notifications).

   An example of a syntactically correct, but semantically incorrect
   NLRI match criteria may be the following:

      IP Protocol == 1, Port == 2

   Since IP protocol 1 (ICMP) packets do not contain a port information
   the NLRI is incorrect from the semantical perspective and may not be
   applied to the forwarding plane in the network.  However it is still
   syntactically correct and thus subject to BGP propagation.




Loibl & Bacher          Expires February 23, 2017               [Page 5]


Internet-Draft           Flowspec Clarification              August 2016


7.1.  Changes to RFC5575

   None.  See RFC5575 section 3 last 2 paragraphs.

8.  Acknowledgements

   The authors would like to thank Alexander Mayrhofer and Nicolas
   Fevrier for their comments and support.

9.  IANA Considerations

   This document has no IANA actions.

10.  Security Considerations

   The required filtering action for a specific NLRI may vary throughout
   the network.  Extensive modification and filtering of filter actions
   is needed in an inter AS setting.  Therefore implementations SHALL
   provide a policy framework to allow modification (add, modify,
   delete) of the filtering actions.

   Especially in an inter-AS-setting unverified filtering actions like
   "redirect" (0x8008) or "traffic-marking" (0x8009) may potentially be
   harmful ("redirect" may allow any Flowspec-peer to redirect any
   traffic into arbitrary VPNs; "traffic-marking" allows any malicious
   Flowspec-peer to assign different forwarding classes to arbitrary
   traffic).

   Inbound and outbound Flowspec route filters may also be necessary in
   order to match and filter specific filtering actions and flow
   component types from being accepted or sent by the local BGP daemon.
   The implementations SHALL therefore also provide a policy framework
   which provides the described functionality.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.




Loibl & Bacher          Expires February 23, 2017               [Page 6]


Internet-Draft           Flowspec Clarification              August 2016


   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <http://www.rfc-editor.org/info/rfc4360>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <http://www.rfc-editor.org/info/rfc4760>.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
              <http://www.rfc-editor.org/info/rfc5575>.

11.2.  Informative References

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <http://www.rfc-editor.org/info/rfc2474>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <http://www.rfc-editor.org/info/rfc4364>.

Authors' Addresses

   Christoph Loibl
   Next Layer Communications
   Mariahilfer Guertel 37/7
   Vienna  1150
   AT

   Phone: +43 664 1176414
   Email: cl@tix.at


   Martin Bacher
   T-Mobile Austria
   Rennweg 97-99
   Vienna  1030
   AT

   Phone: +43 676 8200 5143
   Email: martin.bacher@t-mobile.at





Loibl & Bacher          Expires February 23, 2017               [Page 7]