SDR Working Group Tony Li INTERNET DRAFT cisco Systems 6/21/93 Source Demand Routing Policy Language Status of this Memo This document defines a policy language for use with the SDRP policy routing protocol for the Internet. This document specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this document is unlimited. This document is 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". 1 Overview The purpose of SDRP [1] is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This document refers to such source-initiated routes as "SDRP routes". For the computation of inter-domain routes, it is useful to be able to remotely request policy information from other routing domains. This document describes a mechanism and a language for exchanging policy information. The language provides a common, extensible, machine interpretable basis for determining if a packet flow is in compliance with the policies of the remote domain. Note that in this scheme, only certain transit and destination policies can be described. This scheme allows a domain to describe accessibility policies, but does not permit the encoding of route Expiration Date Dec. 1993 [Page 1] INTERNET DRAFT June 1993 preferences. Source policies remain private to the originating domain. 2 Policy requests and replies Requests for remote policies and replies are sent as SDRP control messages. Policy requests are sent with a Notification Code of 8, for "Policy Request", and replies are send with a Notification Code of 9, for "Policy Reply". The payload of both messages is used to convey the policy information. For a Policy Request control message, the payload has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Code | Authentication Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a Policy Reply control message, the payload has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Code | Policy Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Policy Information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication Code (2 octets) and Authentication Data (variable) The Authentication Code is a 2 octet unsigned integer that indicates the authentication mechanism being used. Whenever an authentication mechanism is specified for use within SDRP, three things must be included in the specification: - the value of the Authentication Code that indicates use of the mechanism, - the form and meaning of the Authentication Data in Policy Request messages, and - the form and meaning of the Authentication Data in Policy Reply messages. Expiration Date Dec. 1993 [Page 2] INTERNET DRAFT June 1993 Only one authentication mechanism is specified as part of this memo: - its Authentication Code is zero, - its Authentication Data field has zero length in both Policy Request and Policy Reply messages. The semantics of non-zero Authentication Codes lies outside the scope of this document. Policy Length (2 octets) The Policy Length field is a 2 octet unsigned integer that indicates the number of octets of policy information that is contained in a Policy Reply message. TTL (4 octets) The TTL field is a four octet unsigned integer. This field is the time to live of the Policy Reply and indicates the number of seconds that the Policy Reply may be cached. Policy Information (variable) The Policy Information field is a variable length field that contains the transit and destination policies of the domain sending the Policy Reply message. The Policy Information is encoded in the SDRP policy language described below. 3 SDRP Policy Language The language used for transmission of policy information is a simple, extensible, easily interpreted form of a boolean expression. A system that wishes to evaluate a policy for a particular packet or flow need only substitute appropriate values in the expression. A result of true indicates that the packet or flow is permissible within the policy. To aid in debugging and implementation, the policy language is distributed in ASCII. The additional bandwidth consumed by not encoding it in binary is expected to be negligible since policies change infrequently and can be cached for a relatively long time. The language presented here is loosely based on the language 'C' [2]. In general, a policy expression is syntactically a 'C' expression, but no bit manipulations are allowed. An additional "OR" separator has been added to the language that allows simple separation of Expiration Date Dec. 1993 [Page 3] INTERNET DRAFT June 1993 different parts of a policy for independent evaluation. 3.1 Syntax Spaces, tabs and newlines are ignored except as token separators. Identifiers are sequences of letters and digits, the first character must be a letter. Identifiers are case sensitive. The remainder of the syntax is described in a variant of BNF in which terminals are enclosed in double quotes. Alternatives for productions are listed on separate lines. policy: expression policy "OR" expression expression: OR-expression OR-expression "?" expression ":" expression OR-expression: AND-expression OR-expression "||" AND-expression AND-expression: equality-expression AND-expression "&&" equality-expression equality-expression: relational-expression equality-expression "==" relational-expression equality-expression "!=" relational-expression relational-expression: additive-expression relational-expression "<" additive-expression relational-expression ">" additive-expression relational-expression "<=" additive-expression relational-expression ">=" additive-expression additive-expression: multiplicative-expression additive-expression "+" multiplicative-expression additive-expression "-" multiplicative-expression multiplicative-expression: unary-expression Expiration Date Dec. 1993 [Page 4] INTERNET DRAFT June 1993 multiplicative-expression "*" unary-expression multiplicative-expression "/" unary-expression multiplicative-expression "%" unary-expression unary-expression: primary-expression unary-operator unary-expression "(" expression ")" primary-expression: identifier constant IPaddr IPaddr: octet "." octet "." octet "." octet unary-operator: "-" "!" A constant is a 4 octet unsigned integer. Syntactically, it may be specified as a string of decimal digits from "0" to "9", or as a string of hexidecimal digits if preceeded by "0x" or "0X". The hexidecimal digits are "0" to "9", "a" to "f", and "A" to "F". An octet is specified as a string of decimal digits from "0" to "9", and the resulting value must be between 0 and 255. 3.2 Semantics The semantics for most of this language are taken directly from [2], which should be considered authoritative for all constructs that are taken from "||" operator. An IPaddr is semantically equivalent to a constant. Thus, evaluation of a policy produces a boolean result, either 0 or 1. Evaluation of the null policy (the empty string) produces the result 0. A result of 0 indicates that the policy has not been satisfied and that the this route should not be used. A result of 1 indicates that the route is permissible with respect to this policy. Expiration Date Dec. 1993 [Page 5] INTERNET DRAFT June 1993 3.3 Variables Identifiers that appear in policies are variables that describe some attribute of the data flow. For each variable used in this language, there must be a written specification of the variable that includes the name of the variable and the semantics of the variable. The value of the variable may be dependent on the traffic in the flow, external physical constants, or other systems. Any two systems that support a particular variable must attach identical semantics to the variable. If a system does not support a variable that occurs in a policy, the entire expression containing that variable must evaluate to 0. 3.4 Base variables This document specifies the following variables: 3.4.1 src_address The variable "src_address" is the source IP address for packets in the flow. 3.4.2 dst_address The variable "dst_address" is the destination IP address for packets in the flow. 3.4.3 ip_tos The variable "ip_tos" is the IP Type Of Service octet for packets in the flow. Note that the value of the entire octet is used [5]. 3.4.4 ip_protocol The variable "ip_protocol" is the Protocol field from the IP header for packets in the flow. Expiration Date Dec. 1993 [Page 6] INTERNET DRAFT June 1993 3.4.5 hour The variable "hour" is the current hour, in UTC. An implementation supporting this variable must derive the current time from a reliable source, such as [2] or [3]. 3.4.6 minute The variable "minute" is the current minute, in UTC. An implementation supporting this variable must derive the current time from a reliable source, such as [2] or [3]. 3.4.7 day The variable "day" is the current day of the week for UTC. The following table lists days and corresponding values. An implementation supporting this variable must derive the current time from a reliable source, such as [2] or [3]. Value Day ------------------- 0 Monday 1 Tuesday 2 Wednesday 3 Thursday 4 Friday 5 Saturday 6 Sunday 3.4.8 date The variable "date" is the current day of the month for UTC. Legal values are 1 through 31. An implementation supporting this variable must derive the current time from a reliable source, such as [2] or [3]. 3.4.9 month The variable "month" is the current month for UTC. The following Expiration Date Dec. 1993 [Page 7] INTERNET DRAFT June 1993 table lists months and their corresponding values. An implementation supporting this variable must derive the current time from a reliable source, such as [2] or [3]. Value Month ------------------- 1 January 2 February 3 March 4 April 5 May 6 June 7 July 8 August 9 September 10 October 11 November 12 December 3.4.10 year The variable "year" is the current year for UTC. Legal values are integers greater than or equal to 1993. An implementation supporting this variable must derive the current time from a reliable source, such as [2] or [3]. 3.4.11 src_port The variable "src_port" is the source port for TCP or UDP packets for packets in the flow. 3.4.12 dst_port The variable "dst_port" is the destination port for TCP or UDP packets for packets in the flow. 3.4.13 new_connection The variable "new_connection" has value 0 for TCP packets that have the ACK or RST bit set and the value 1 otherwise. A frequent Expiration Date Dec. 1993 [Page 8] INTERNET DRAFT June 1993 application is deny new connections to particular ports in the destination domain. 3.5 Future research We would also like to be able to create variables that represent the domain of the source and the domain of the destination. However no standard mechanism exists for determining this information dynamically. We would also like to be able to classify the community associated with a particular traffic flow, such as Research, Education, Commercial, or Government. There has also been some discussion about performing pattern matching on the entire SDRP route. The utility of this is not yet clear and is a matter for future research. This may require adding pattern matching primitives to the language. A frequent request is the ability to determine the utilization of inter-domain links. There is currently no standard mechanism for relaying this information. Note that if such a mechanism is developed, it should be independent of this policy language, possibly as another component to SDRP. 4 Examples This section demonstrates how this policy language might be used. Suppose that a company `SANFRAN' has many interconnections to a number of different networks. Suppose that SANFRAN agrees that a local eductional institution may use its domain as a transit. The educational institution uses network address 63.0.0.0, and all packets destined or sourced from this network would be permitted: (src_address > 63.0.0.0) && (src_address < 63.255.255.255) || (dest_address >= 63.0.0.0) && (dst_address <= 63.255.255.255) SANFRAN then decides that this is too restrictive and it also wishes to provide transit service for DNS. DNS uses port 53 over both TCP (protocol 6) and UDP (protocol 17): (src_address > 63.0.0.0) && (src_address < 63.255.255.255) || Expiration Date Dec. 1993 [Page 9] INTERNET DRAFT June 1993 (dest_address >= 63.0.0.0) && (dst_address <= 63.255.255.255) OR ((src_port == 53) || (dst_port == 53) && (ip_protocol == 6) || (ip_protocol == 17)) SANFRAN also wishes to allow all Research networks to use it as a transit. To do this, it makes use of a new variable called "community", for which the Research community has the value 4: ... OR community == 4 This policy will be ignored by any SDRP speaker which does not support that variable. SANFRAN also is willing to provide transit service after business hours, on weekends and on Groundhog day. This policy allows traffic between the hours of 1100UTC and 1900UTC, on Saturday and Sunday, and on Feb. 2nd: ... OR (hour >= 1100) && (hour <= 1900) || (day == 5) || (day == 6) || (month == 2) && (date == 2) 5 Security Considerations Security issues are not discussed in this memo. 6 Acknowledgements The author would like to express his thanks to Deborah Estrin (USC/ISI), Steve Hotz (USC/ISI), and Yakov Rekhter (IBM) for their insightful comments and assistance. 7 Author's Address Tony Li cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025 Expiration Date Dec. 1993 [Page 10] INTERNET DRAFT June 1993 Phone: (415) 688-8186 email: tli@cisco.com 8 References [1] Estrin, D., Li, T., Rekhter, Y., "Source Demand Routing: Packet Format and Forwarding Specification (Version 1)", work in progress [2] Kernighan, B.W., Ritchie, D.M., "The C Programming Language", Second Edition, Prentice-Hall, New Jersey, 1998 [3] Mills, D.L., "Simple Network Time Protocol (SNTP)", RFC 1361, August 1992 [4] Mills, D.L., "Network Time Protocol (Version 3): Specification, implementation, and analysis", RFC 1305, March 1992 [5] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992 Expiration Date Dec. 1993 [Page 11]