idnits 2.17.1 draft-ietf-rtfm-ruleset-language-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 96 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 329 has weird spacing: '...decimal e.g. ...' == Line 331 has weird spacing: '...in bits e.g....' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8834 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'V6-ADR' is mentioned on line 854, but not defined == Unused Reference: 'V6-ADDR' is defined on line 948, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. 'ASG-NBR') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'NETRAMET' ** Obsolete normative reference: RFC 2063 (ref. 'RTFM-ARC') (Obsoleted by RFC 2722) ** Obsolete normative reference: RFC 2064 (ref. 'RTFM-MIB') (Obsoleted by RFC 2720) ** Obsolete normative reference: RFC 2373 (ref. 'V6-ADDR') (Obsoleted by RFC 3513) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Nevil Brownlee 2 INTERNET-DRAFT The University of Auckland 4 August 1999 5 Expires February 2000 7 SRL: A Language for Describing Traffic Flows and 8 Specifying Actions for Flow Groups 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet Draft is a product of the Realtime Traffic Flow 33 Measurement Working Group of the IETF. 35 Abstract 37 This document describes a language for specifying rulesets, i.e. 38 configuration files which may be loaded into a traffic flow meter so 39 as to specify which traffic flows are measured by the meter, and the 40 information it will store for each flow. 42 Contents 44 1 Purpose and Scope 3 45 1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 3 46 1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2 SRL Language Description 5 49 2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . 5 50 2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3 Statement 6 54 3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1.1 expression . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.1.4 operand_list . . . . . . . . . . . . . . . . . . . . . 8 59 3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1.8 ELSE Clause . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . 10 64 3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . 10 65 3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . . . 11 66 3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . . . 11 67 3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . . . 11 68 3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . 12 69 3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . 12 70 3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . . . 12 71 3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . . . 13 72 3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . 13 73 3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . 14 75 4 Example Programs 15 76 4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . 15 77 4.2 Classify Traffic into Groups of Networks . . . . . . . . . . 16 79 5 Security Considerations 17 81 6 IANA Considerations 17 83 7 APPENDICES 18 84 7.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 18 85 7.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 20 86 7.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . 21 88 8 Acknowledgments 22 90 9 References 22 92 10 Author's Address 23 93 1 Purpose and Scope 95 A ruleset for an RTFM Meter is a sequence of instructions to be executed 96 by the meter's Pattern Matching Engine (PME). The form of these 97 instructions is described in detail in the 'RTFM Architecture' and 'RTFM 98 Meter MIB' documents [RTFM-ARC, RTFM-MIB], but most users - at least 99 initially - find them confusing and difficult to write, mainly because 100 the effect of each instruction is strongly dependent on the state of the 101 meter's Packet Matching Engine at the moment of its execution. 103 SRL (the Simple Ruleset Language) is a procedural language for creating 104 RTFM rulesets. It has been designed to be simple for people to 105 understand, using statements which help to clarify the execution context 106 in which they operate. SRL programs will be compiled into rulesets 107 which can then be downloaded to RTFM meters. 109 An SRL compiler is available as part of NeTraMet (a free-software 110 implementation of the RTFM meter and manager), version 4.2 [NETRAMET]. 112 1.1 RTFM Meters and Traffic Flows 114 The RTFM Architecture [RTFM-ARC] defines a set of 'attributes' which 115 apply to network traffic. Among the attributes are 'address 116 attributes,' such as PeerType, PeerAddress, TransType and TransAddress, 117 which have meaning for many protocols, e.g. for IPv4 traffic (PeerType 118 == 1) PeerAddress is an IP address, TransType is TCP(6), UDP(17), 119 ICMP(1), etc., and TransAddress is usually an IP port number. 121 An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter 122 as they pass across a network between two end points (or to/from a 123 single end point). Each 'end point' of a flow is specified by the set 124 of values of its address attributes. 126 An 'RTFM Meter' is a measuring device - e.g. a program running on a Unix 127 or PC host - which observes passing packets and builds 'Flow Data 128 Records' for the flows of interest. 130 RTFM traffic flows have another important property - they are 131 bi-directional. This means that each flow data record in the meter has 132 two sets of counters, one for packets travelling from source to 133 destination, the other for returning packets. Within the RTFM 134 architecture such counters appear as further attributes of the flow. 136 An RTFM meter must be configured by the user, which means creating a 137 'Ruleset' so as to specify which flows are to be measured, and how much 138 information (i.e. which attributes) should be stored for each of them. 139 A ruleset is effectively a program for a minimal virtual machine, the 140 'Packet Matching Engine (PME),' which is described in detail in 141 [RTFM-ARC]. An RTFM meter may run multiple rule sets, with every passing 142 packet being processed by each of the rulesets. The rule 'actions' in 143 this document are described as though only a single ruleset were 144 running. 146 In the past creating a ruleset has meant writing machine code for the 147 PME, which has proved rather difficult to do. SRL provides a high-level 148 language which should enable users to create effective rulesets without 149 having to understand the details of the PME. 151 The language may be useful in other applications, being suitable for any 152 application area which involves selecting traffic flows from a stream of 153 packets. 155 1.2 SRL Overview 157 An SRL program is executed from the beginning for each new packet 158 arriving at the meter. It has two essential goals. 160 (a) Decide whether the current packet is part of a flow which is of 161 interest and, if necessary, determine its direction (i.e. decide 162 which of its end-points is considered to be its source). Other 163 packets will be ignored. 165 (b) SAVE whatever information is required to identify the flow and 166 accumulate (COUNT) quantitative information for that flow. 168 At execution, the meter's Packet Matching Engine (PME) begins by using 169 source and destination attributes as they appear 'on the wire.' If the 170 attributes do not match those of a flow to be recorded, the PME will 171 normally execute the program again, this time with the source and 172 destination addresses interchanged. Because of this bi-directional 173 matching, an RTFM meter is able to build up tables of flows with two 174 sets of counters - one for forward packets, the other for backward 175 packets. The programmer can, if required, suppress the 176 reverse-direction matching and assign 'forward' and 'backward' 177 directions which conform to the conventions of the external context. 179 Goal (a) is achieved using IF statements which perform comparisons on 180 information from the packet or from SRL variables. Goal (b) is achieved 181 using one or more SAVE statements to store the flow's identification 182 attributes; a COUNT statement then increments the statistical data 183 accumulating for it. 185 2 SRL Language Description 187 The SRL language is explained below using 'railway diagrams' to describe 188 the syntax. Flow through a diagram is from left to right. The only 189 exception to this is that lines carrying a left arrow may only be 190 traversed right to left. In the diagrams, keywords are written in 191 capital letters; in practice an SRL compiler must be insensitive to 192 case. Lower-case identifiers are explained in the text, or they refer 193 to another diagram. 195 The tokens of an SRL program obey the following rules: 197 - Comments may appear on any line of an SRL program, following a # 198 - White space is used to separate tokens 199 - Semicolon is used as the terminator for most statements 200 - Identifiers (e.g. for defines and labels) must start with a letter 201 - Identifiers may contain letters, digits and underscores 202 - The case of letters is not significant 203 - Reserved words (shown in upper case in this documents) 204 may not be used as identifiers 206 2.1 Define Directive 208 --- DEFINE -- defname ---- = ---- defined_text ------------------ ; 210 Simple parameterless defines are supported via the syntax above. The 211 define name, defname, is an identifier. The defined text starts after 212 the equal sign, and continues up to (but not including) the closing 213 semicolon. If a semicolon is required within the defined text it must 214 be preceded by a backslash, i.e. \x; in an SRL define produces ; in the 215 text. 217 Wherever defname appears elsewhere in the program, it will be replaced 218 by the defined text. 220 For example, 222 DEFINE ftp = (20, 21); # Well-known Port numbers from [ASG-NBR] 223 DEFINE telnet = 23; 224 DEFINE www = 80; 226 2.2 Program 228 ------------+-------+-------- Statement -------+-------+----------- 229 | | | | 230 | +------- Declaration ------+ | 231 | | 232 +---------------------<--------------------+ 234 An SRL program is a sequence of statements or declarations. It does not 235 have any special enclosing symbols. Statements and declarations 236 terminate with a semicolon, except for compound statements, which 237 terminate with a right brace. 239 2.3 Declaration 241 ---------------------- Subroutine_declaration --------------------- 243 SRL's only explicit declaration is the subroutine declaration. Other 244 implicit declarations are labels (declared where they appear in front of 245 a statement) and subroutine parameters (declared in the subroutine 246 header). 248 3 Statement 250 ----------------+---- IF_statement ----------------+--------------- 251 | | 252 +---- Compound_statement ----------+ 253 | | 254 +---- Imperative_statement --------+ 255 | | 256 +---- CALL_statement --------------+ 258 An SRL program is a sequence of SRL statements. There are four kinds of 259 statements, as follows. 261 3.1 IF_statement 263 Test Part Action Part 264 ............. ............... 266 --- IF --- expression ---+------------+---- Statement ----+---> 267 | | | 268 +-- SAVE , --+ | 269 | | 270 +-- SAVE ; ----------------------+ 272 >-----------+-----------------------------+----------------- 273 | | 274 +-----ELSE --- Statement -----+ 276 3.1.1 expression 278 -------- term --------+------------------------+------------------- 279 | | 280 +--<-- term ----- || ----+ logical OR 282 3.1.2 term 284 ------- factor -------+------------------------+------------------- 285 | | 286 +--<-- factor --- && ----+ logical AND 288 3.1.3 factor 290 ------------+-------- attrib == operand_list --------+----------- 291 | | 292 +------------ ( expression ) --------------+ 294 3.1.4 operand_list 296 ----------+------------------ operand -----------------+----------- 297 | | 298 +-- ( operand ---+-------------------+-- ) --+ 299 | | 300 +-<-- operand , ---+ 302 3.1.5 operand 304 ------------- value ---------+----------------------+-------------- 305 | | 306 +------- / width ------+ 307 | | 308 +------- & mask -------+ 310 3.1.6 Test Part 312 The IF statement evaluates a logical expression. If the expression 313 value is TRUE, the action indicated in the 'Action Part' of the diagram 314 is executed. If the value is FALSE and the IF has an ELSE clause, that 315 ELSE clause is executed (see below). 317 The simplest form of expression is a test for equality (== operator); in 318 this an RTFM attribute value (from the packet or from an SRL variable) 319 is ANDed with a mask and compared with a value. A list of RTFM 320 attributes is given in Appendix C. More complicated expressions may be 321 built up using parentheses and the && (logical AND) and || (logical OR) 322 operators. 324 Operand values may be specified as dotted decimal, hexadecimal or as a 325 character constant (enclosed in apostrophes). The syntax for operand 326 values is given in Appendix B. 328 Masks may be specified as numbers, 329 dotted decimal e.g. &255.255 330 or hexadecimal e.g. &FF-FF 331 or as a width in bits e.g. /16 333 If a mask is not specified, an all-ones mask is used. 335 In SRL a value is always combined with a mask; this combination is 336 referred to as an operand. For example, if we were interested in flows 337 originating from IP network 130.216, we might write: 339 IF SourcePeerAddress == 130.216.0.0 & 255.255.0.0 SAVE; 341 or equivalently 343 IF SourcePeerAddress == 130.216/16 SAVE; 345 A list of values enclosed in parentheses may also be specified; the test 346 succeeds if the masked attribute equals any of the values in the list. 347 For example 349 IF SourcePeerAddress == ( 130.216.7/24, 130.216.34/24 ) SAVE; 351 As this last example indicates, values are right-padded with zeroes, 352 i.e. the given numbers specify the leading bytes of masks and values. 354 The operand values and masks used in an IF statement must be consistent 355 with the attribute being tested. For example, a four-byte value is 356 acceptable as a peer address, but would not be accepted as a transport 357 address (which may not be longer than two bytes). 359 3.1.7 Action Part 361 A SAVE action (i.e. SAVE , or SAVE ;) saves attribute(s), mask(s) and 362 value(s) as given in the statement. If the IF expression tests more 363 than one attribute, the masks and values are saved for all the matched 364 attributes. For each value_list in the statement the value saved is the 365 one which the packet actually matched. See below for further 366 description of SAVE statements. 368 Other actions are described in detail under "Imperative statements" 369 below. Note that the RETURN action is valid only within subroutines. 371 3.1.8 ELSE Clause 373 An ELSE Clause provides a statement which will be executed if the IF's 374 test fails. The statement following ELSE will often be another IF 375 statement, providing SRL's version of a 'select' statement. Note that 376 an ELSE clause always matches the immediately preceding IF. 378 3.2 Compound_statement 380 -------+-------------+----- { ---+---- Statement ----+--- } ------- 381 | | | | 382 +-- label : --+ +--------<----------+ 384 A compound statement is a sequence of statements enclosed in braces. 385 Each statement will terminate with a semicolon, unless it is another 386 compound statement (which terminates with a right brace). 388 A compound statement may be labelled, i.e. preceded by an identifier 389 followed by a semi-colon. Each statement inside the braces is executed 390 in sequence unless an EXIT statement is performed, as explained below. 392 Labels have a well-defined scope, within which they must be unique. 393 Labels within a subroutine (i.e. between a SUBROUTINE and its matching 394 ENDSUB) are local to that subroutine and are not visible outside it. 395 Labels outside subroutines are part of a program's outer block. 397 3.3 Imperative_statement 399 ------+---------------------------------------------------+------ ; 400 | | 401 +-- SAVE attrib --+--+-----------+--+---------------+ 402 | | | | | | 403 | | +- / width -+ | | 404 | | | | | | 405 | | +- & mask --+ | | 406 | | | | 407 | +--- = operand ---+ | 408 | | 409 +-- COUNT ------------------------------------------+ 410 | | 411 +-- EXIT label ------------------------------------+ 412 | | 413 +-- IGNORE -----------------------------------------+ 414 | | 415 +-- NOMATCH ----------------------------------------+ 416 | | 417 +-- RETURN --+-------+------------------------------+ 418 | | | | 419 | +-- n --+ | 420 | | 421 +-- STORE variable := value ------------------------+ 423 3.3.1 SAVE Statement 425 The SAVE statement saves information which will (later) identify the 426 flow in the meter's flow table. It does not actually record anything in 427 the table; this is done when a subsequent COUNT statement executes. 429 SAVE has two possible forms: 431 SAVE attrib = operand ; 432 saves the attribute, mask and value as given in the statement. 433 This form of the SAVE statement is similar to that allowed 434 in an IF statement, except that - since imperative statements 435 do not perform a test - you may save an arbitrary value. 437 SAVE attrib ; 438 SAVE attrib / width ; 439 SAVE attrib & mask ; 440 saves the attribute and mask from the statement, and the 441 value resulting from their application to the current packet. 442 This is most useful when used to save a value with a wider 443 mask than than was used to select the packet. For example 445 IF DestPeerAddress == 130.216/16 446 NOMATCH; 447 ELSE IF SourcePeerAddress == 130.216/16 { 448 SAVE SourcePeerAddress /24; 449 COUNT; 450 } 451 ELSE IGNORE; 453 3.3.2 COUNT Statement 455 The COUNT statement appears after all testing and saving is complete; it 456 instructs the PME to build the flow identifier from the attributes which 457 have been SAVEd, find it in the meter's flow table (creating a new entry 458 if this is the first packet observed for the flow), and increment its 459 counters. The meter then moves on to examine the next incoming packet. 461 3.3.3 EXIT Statement 463 The EXIT statement exits a labelled compound statement. The next 464 statement to be executed will be the one following that compound 465 statement. This provides a well-defined way to jump to a clearly 466 identified point in a program. For example 467 outer: { 468 ... 469 if SourcePeerAddress == 192.168/16 470 exit outer; # exits the statement labelled 'outer' 471 ... 472 } 473 # execution resumes here 475 In practice the language provides sufficient logical structure that one 476 seldom - if ever - needs to use the EXIT statement. 478 3.3.4 IGNORE Statement 480 The IGNORE statement terminates examination of the current packet 481 without saving any information from it. The meter then moves on to 482 examine the next incoming packet, beginning again at the first statement 483 of its program. 485 3.3.5 NOMATCH Statement 487 The NOMATCH statement indicates that matching has failed for this 488 execution of the program. If it is executed when a packet is being 489 processed with its addresses in 'on the wire' order, the PME will 490 perform the program again from the beginning with source and destination 491 addresses interchanged. If it is executed following such an 492 interchange, the packet will be IGNOREd. 494 NOMATCH is illustrated in the SAVE example (section 3.3.1), where it is 495 used to ensure that flows having 130.216/16 as an end-point are counted 496 as though 130.216 had been those flows' source peer (IP) address. 498 3.3.6 STORE Statement 500 The STORE statement assigns a value to an SRL variable and SAVEs it. 501 There are six SRL variables: 503 SourceClass SourceKind 504 DestClass DestKind 505 FlowClass FlowKind 507 Their names have no particular significance; they were arbitrarily 508 chosen as likely RTFM attributes but can be used to store any 509 single-byte integer values. Their values are set to zero each time 510 examination of a new packet begins. For example 512 STORE SourceClass := 3; 513 STORE FlowKind := 'W' 515 3.3.7 RETURN Statement 517 The RETURN statement is used to return from subroutines and can be used 518 only within the context of a subroutine. It is described in detail 519 below (CALL statement). 521 3.4 Subroutine_declaration 523 -- SUBROUTINE subname ( --+-----------------------------+-- ) --> 524 | | 525 +--+-- ADDRESS --- pname --+--+ 526 | | 527 +-- VARIABLE -- pname --+ 528 | | 529 +------<------- , ------+ 531 >------+-------- Statement ---------+----- ENDSUB -------- ; 532 | | 533 +-------------<--------------+ 535 A Subroutine declaration has three parts: 537 the subname is an identifier, used to name the subroutine. 539 the parameter list specifies the subroutine's parameters. 540 Each parameter is preceded with a keyword indicating its 541 type - VARIABLE indicates an SRL variable (see the STORE 542 statement above), ADDRESS indicates any other RTFM attribute. 543 A parameter name may be any identifier, and its scope is 544 limited to the subroutine's body. 546 the body specifies what processing the subroutine will perform. 547 This is simply a sequence of Statements, terminated by the 548 ENDSUB keyword. 550 Note that EXITs in a subroutine may not refer to labels outside it. The 551 only way to leave a subroutine is via a RETURN statement. 553 3.5 CALL_statement 555 ---- CALL subname ( --+---------------------+-- ) ----> 556 | | 557 +--+-- parameter --+--+ 558 | | 559 +----<--- , ----+ 561 >---+-------------------------------------+--- ENDCALL ---- ; 562 | | 563 +---+--+-- n : --+--- Statement --+---+ 564 | | | | 565 | +----<----+ | 566 | | 567 +--------------<--------------+ 569 The CALL statement invokes an SRL subroutine. The parameters are SRL 570 variables or other RTFM attributes, and their types must match those in 571 the subroutine declaration. Following the parameters is a sequence of 572 statements, each preceded by an integer label. These labels will 573 normally be 1:, 2:, 3:, etc, but they do not have to be contiguous, nor 574 in any particular order. They are referred to in RETURN statements 575 within the subroutine body. 577 e.g. RETURN 2; would return to the statement labelled 2: 578 within in the CALL statement. 580 Execution of the labelled statement completes the CALL. 582 If the return statement does not specify a return label, the first 583 statement executed after RETURN will be the statement immediately 584 following ENDCALL. 586 4 Example Programs 588 4.1 Classify IP Port Numbers 590 # 591 # Classify IP port numbers 592 # 593 define IPv4 = 1; # Address Family number from [ASG-NBR] 594 # 595 define ftp = (20, 21); # Well-Known Port numbers from [ASG-NBR] 596 define telnet = 23; 597 define www = 80; 598 # 599 define tcp = 6; # Protocol numbers from [ASG-NBR] 600 define udp = 17; 601 # 602 if SourcePeerType == IPv4 save; 603 else ignore; # Not an IPv4 packet 604 # 605 if (SourceTransType == tcp || SourceTransType == udp) save, { 606 if SourceTransAddress == (www, ftp, telnet) nomatch; 607 # We want the well-known port as Dest 608 # 609 if DestTransAddress == telnet 610 save, store FlowKind := 'T'; 611 else if DestTransAddress == www 612 save, store FlowKind := 'W'; 613 else if DestTransAddress == ftp 614 save, store FlowKind := 'F'; 615 else { 616 save DestTransAddress; 617 store FlowKind := '?'; 618 } 619 } 620 else save SourceTransType = 0; 621 # 622 save SourcePeerAddress /32; 623 save DestPeerAddress /32; 624 count; 625 # 627 This program counts only IP packets, saving SourceTransType (tcp, udp or 628 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W' 629 for www, 'F' for ftp, 'T' for telnet, '?' for unclassified). The 630 program uses a NOMATCH action to specify the packet direction - its 631 resulting flows will have the well-known ports as their destination. 633 4.2 Classify Traffic into Groups of Networks 635 # 636 # SRL program to classify traffic into network groups 637 # 638 define my_net = 130.216/16; 639 define k_nets = ( 130.217/16, 130.123/16, 130.195/16, 640 132.181/16, 138.75/16, 139.80/16 ); 641 # 642 call net_kind (SourcePeerAddress, SourceKind) 643 endcall; 644 call net_kind (DestPeerAddress, DestKind) 645 endcall; 646 count; 647 # 648 subroutine net_kind (address addr, variable net) 649 if addr == my_net save, { 650 store net := 10; return 1; 651 } 652 else if addr == k_nets save, { 653 store net := 20; return 2; 654 } 655 save addr/24; # Not my_net or in k_nets 656 store net := 30; return 3; 657 endsub; 658 # 660 The net_kind subroutine determines whether addr is my network (130.216), 661 one of the Kawaihiko networks (in the k_nets list), or some other 662 network. It saves the network address from addr (16 bits for my_net and 663 the k_net networks, 24 bits for others), stores a value of 10, 20 or 30 664 in net, and returns to 1:, 2: or 3:. Note that the network numbers 665 used are contained within the two DEFINEs, making them easy to change. 667 net_kind is called twice, saving Source- and DestPeerAddress and Source- 668 and DestKind; the COUNT statement produces flows identified by these 669 four RTFM attributes, with no particular source-dest ordering. 671 In the program no use is made of return numbers and they could have been 672 omitted. However, we might wish to re-use the subroutine in another 673 program doing different things for different return numbers, as in the 674 version below. 676 call net_kind (DestPeerAddress, DestKind) 677 1: nomatch; # We want my_net as source 678 endcall; 679 call net_kind (SourcePeerAddress, SourceKind) 680 1: count; # my_net -> other networks 681 endcall; 682 save SourcePeerAddress /24; 683 save DestPeerAddress /24; 684 count; 686 This version uses a NOMATCH statement to ensure that its resulting flows 687 have my_net as their source. The NOMATCH also rejects my_net -> my_net 688 traffic. Traffic which doesn't have my_net as source or destination 689 saves 24 bits of its peer addresses (the subroutine might only have 690 saved 16) before counting such an unusual flow. 692 5 Security Considerations 694 SRL is a language for creating rulesets (i.e. configuration files) for 695 RTFM Traffic Meters - it does not present any security issues in itself. 697 On the other hand, flow data gathered using such rulesets may well be 698 valuable. It is therefore important to take proper precautions to 699 ensure that access to the meter and its data is secure. Ways to achieve 700 this are discussed in detail in the Architecture and Meter MIB documents 701 [RTFM-ARC, RTFM-MIB]. 703 6 IANA Considerations 705 Appendix C below lists the RTFM attributes by name. Since SRL only 706 refers to attributes by name, SRL users do not have to know the 707 attribute numbers. 709 The size (in bytes) of the various attribute values is also listed in 710 Appendix C. These sizes reflect the object sizes for the attribute 711 values as they are stored in the RTFM Meter MIB [RTFM-MIB]. 713 IANA considerations for allocating new attributes are discussed in 714 detail in the RTFM Architecture document [RTFM-ARC]. 716 7 APPENDICES 718 7.1 Appendix A: SRL Syntax in BNF 720 ::= | 722 ::= | 724 ::= 726 ::= | 727 | 728 | 729 731 ::= IF 733 ::= SAVE ; | 734 SAVE , | 735 737 ::= | 738 ELSE 740 ::= | || 742 ::= | && 744 ::= == | 745 ( ) 747 ::= | ( ) 749 ::= | 750 , 752 ::= | 753 / | 754 & 756 ::= { } 758 ::= | 759 : 761 ::= | 762 ::= ; | 763 SAVE ; | 764 COUNT ; | 765 EXIT