Routing Policy Specification Language Ambrose Magee LM Ericsson Ltd. <ambrose.magee@eei.ericsson.se> Tuesday, 28th August, 2001 APNIC-12

Introduction Tutorial Target Audience not a substitute for reading the RFC documents Target Audience knowledge of Internet Routing familiar with APNIC Whois Database no need to know Internet Routing Registry

Contents of this tutorial The Internet Routing Registry Routing Policy Specification Language RIPE Database Version 3 Routing Policy System Security (RPSS) security for Internet Routing Registry (IRR) RAToolSet & RtConfig RPSL - RIPE Database Version 3 - extra object types

The Internet Routing Registry Background Structure Why use it ? BGP configuration from the Internet Routing Registry

The Internet Routing Registry (IRR) Established in 1995 http://www.irr.net/ Stability and consistency of routing network operators share information Both public and private databases These databases are independent but some exchange data only register your data in one database Internet Routing Registry - promotes stability and consistency of routing.

Internet Routing Registry ARIN, ArcStar, FGC, Verio, Bconnex, Telstra, ... RIPE CW RADB By sharing policy and contact information, mistakes can be avoided. Also, with contact information,any mistakes can be quickly fixed. Bell.db ANS Policy and contact information is shared.

Why use the Internet Routing Registry ? When peering register your routes and filter your peers Some transit providers and big ISP’s ask for this Useful for fixing problems contact information

Why use the Internet Routing Registry ? BGP->RIP->BGP injection 128/7 leak bogon 0/0, 10/8 leaks Daily, someone is leaking somelse’s prefix.

BGP Configuration from Internet Routing Registry Routing Policy specification Language (RPSL) abstract, high-level policies policies for each Autonomous System (AS) Internet Routing Registry policies, routes and contact informatiom benefit from the data and delegation of others RtConfig RAToolSet generate router configuration files automates details and tedious aspects

Routing Policy Specification Language

Routing Policy Specification Language Background RPSL Objects Contact Information Specifying Policy Set Objects Inet-rtr object Advanced Features

Routing Policy Specification Language Object-based language route, autonomous system, router, contact and set objects Defines the syntax, semantics and format of data in IRR Vendor independent Extensible IETF Proposed Standard (RFC2622) Based on RIPE-181 (RFC 1786) Currently, no support for IPv6

Routing Policy Specification Language 2 RIPE-181 some policies cannot be specified Internet Routing Registry needed a more powerful language RPSL more expressive than RIPE-181 policies can be expressed at the AS level policies can be detailed => router configurations PRDB RIPE-81 RIPE-181 RPSL

Routing Policy Specification Language Background RPSL Objects Contact Information Specifying Policy Set Objects inet-rtr object Advanced Features

RPSL Objects

Objects in RPSL RPSL is based on objects Format of RPSL similar to RIPE-181 Objects and Attributes Attributes and Values Object Names Reserved Names

RPSL is based on Objects Each object describes an entity in the real world Object classes (= object types) 12 types of object RPS-Sec defines one more (as-block)

RIPE Database Version 3 Includes most RPSL object classes Excludes dictionary object class Defines 4 other object classes

RPSL Object Attribute name Attribute value person: Clare Lancers address: Corrofin phone: + 123 123 # day time e-mail: clancers@apnic.net nic-hdl: CL123-TEST remarks: This is a test object changed: clancers@apnic.net 20010730 source: TEST Comment Continuation

RPSL Objects RPSL objects are similar to RIPE-181 objects Objects set of attributes Attributes mandatory or optional values: single, list, multiple see the object template

Template of person object N.B. 'phone' attribute is mandatory. N.B. 'e-mail' attribute is optional.

RPSL Objects Class “key” Class “key” = primary key set of attributes usually one attribute has the same name as the object’s class uniquely identify each object Class “key” = primary key must be specified first

Template of person object

RPSL Object Attribute name Attribute value person: Clare Lancers address: Corrofin phone: + 123 123 # day time e-mail: clancers@apnic.net nic-hdl: CL123-TEST remarks: This is a test object changed: clancers@apnic.net 20010730 source: TEST Comment Continuation

RPSL vs RIPE-181 objects Line continuation possible Comments space, tab, ‘+’ Comments begin with ‘#’ can be anywhere inside an object but cannot start at beginning of a line (column 0) Objects ends at “\n\n” (blank line) The order of attribute-value pairs is significant

RPSL Object

Attributes Case insensitive ASCII Value of an attribute has a type <object-name> <as-number> <ipv4-address> <address-prefix> etc. Complete list of attributes in RFC 2622 & RIPE-223

Object Names Objects names can have - or _ inside Can have digits e.g. RIPE-DBM-MNT Can have digits Case-insensitive First character: alphabetic Last character: must be a letter or a digit Reserved names Reserved prefixes

Reserved Names any as-any rs-any peeras and or not atomic from to at action accept announce except refine networks into inbound outbound

Reserved Prefixes Prefix Object type as- as set rs- route set rtrs- router set fltr- filter set prng- peering set

Routing Policy Specification Language Background RPSL Objects Contact Information Specifying Policy Set Objects inet-rtr object Advanced Features Summarise the previous section and progress so far before continuing.

Contact Information

Contact Information person role mntner

Person Object person: Clare Lancers Person object information address: Corrofin phone: + 123 123 # day time e-mail: clancers@apnic.net nic-hdl: CL123-TEST remarks: This is a test object mnt-by: TEST-MNT changed: clancers@apnic.net 20010730 source: TEST Person object information Auxiliary information

Person Object 2 Information about technical or administrative contact The value of the “person” attribute cannot be changed The nic-handle is the primary key. In RIPE-181, name && nic-handle was the primary key The role object is very similar Auxiliary information is in all object types N.B. 'phone' attribute is optional, N.B. 'e-mail' attribute is mandatory; cf. person object.

Mntner Object Template

Mntner object

Mntner object 2 New attribute: referral-by the mntner that created this mntner New attribute: auth-override date after which the mntner can be modified only the mntner in “referral-by” can do this

“auth” attribute NONE MAIL-FROM CRYPT-PW e.g. MAIL-FROM webmaster@apnic.net e.g. MAIL-FROM .*apnic.net CRYPT-PW produced by the UNIX crypt routine e.g. CRYPT-PW lz1A7/JnfkTI

“auth” attribute 2 PGPKEY-<PGP Key ID> e.g. PGPKEY-1290F9D2 RFC 2726 key-cert object Be careful using many authentication methods in mntner logical OR used avoid using authentication NONE N.B. 'key-cert' object is only defined in RIPE DB Version 3.

Routing Policy Specification Language Background RPSL Objects Contact Information Specifying Policy Set Objects inet-rtr object Advanced Features

Specifying Routing Policy This is the single biggest section in the tutorial.

Specifying Policy Internet Routing aut-num object route-set object as-set object AS Path Regular Expression Composite Policy Filters Specifying Actions

Specifying Policy 2 Community Based Policies Ambiguity Resolution

Internet Routing ISP-2 A ISP-1 ISP-3 B

Inter-AS Topology Regional ISP Backbone Providers Other ASes

AS Relationships Customer-Regional Provider Peer-Peer Provider forwards traffice advertises customer routes Peer-Peer mutual benefit Regional Provider-Backbone Provider similar to Customer-Regional Provider Typical routing policies implement these

Inter-AS Routing Regional ISP AS level peering export AS1 AS2 128.9.0.0/16 import AS2 originates 128.9.0.0/16 AS2 exports 128.9.0.0/16 to AS1 AS1 imports 128.9.0.0/16 from AS2

BGP Routes: Path Attributes Destination address prefixes AS path Originator AS List of communities (flags) Metrices: med, pref

aut-num Object expresses routing policy Auxiliary information not shown

aut-num Object Template Attribute Value Type aut-num <as-number> mandatory, single, class key as-name <object-name> mandatory, single member-of list of <as-set-names> optional, multiple import import policy optional, multiple export export policy optional, multiple default default policy optional, multiple Auxiliary information (admin-c, tech-c, etc. is not shown. The import, export and default attributes are defined later 'member-of' attribute is an inverse key and it is also defined later.

aut-num Object in RIPE-181 and RPSL as-out, interas-out => export as-in, interas-in => import default => default

Aut-num Object in RIPE DB Version 3 It has all the attributes described in RFC 2622 Cross-mnt a mntner to be notified Cross-nfy a person or role object to be notified Cross-mnt & cross-nfy are involved when a route object is created/deleted.

Policy in RPSL Prefix AS Path community prefix-length Future attributes through its dictionary Structured Policy Uses RPSL allows policy based on these. N.B. The dictionary object class/type is not implemented in RIPE DB Version 3, but it is in the RADB/IRRd.

Prefix based Policy 128.9.0.0/16 AS2 AS1 128.8.0.0/16 aut-num: AS1 export: to AS2 announce {128.9.0.0/16, 128.8.0.0/16} N.B. Filtering is based on Address-Prefix Set

Prefix based Policy 2 128.9.0.0/16 AS2 AS1 128.8.0.0/16 aut-num: AS2 import: fromAS1 accept {128.9.0.0/16, 128.8.0.0/16} N.B. Filtering is based on Address-Prefix Set

import Attribute import Set of routes matched by filter from <peering-1> [action <action-1>] ….. from <peering-N> [action <action-N>] accept <filter> Set of routes matched by filter imported from all peers in peerings While importing routes at <peering-M> <action-M> is done "filter" & "peering" are discussed later.

Choosing a Peering 1.1.1.1 1.1.1.2 AS1 AS2 2.2.2.2 aut-num: AS1 import: from AS2 at 2.2.2.2 action pref = 10; accept AS2

Choosing a Peering 2 aut-num: AS1 import: from AS2 at 2.2.2.2 action pref = 10; accept AS2 import: from AS2 1.1.1.2 at 1.1.1.1 action pref =5; N.B. In filter context, AS2 = routes originated by AS2

export Attribute export Set of routes matched by filter to <peering-1> [action <action-1>] ….. to <peering-N> [action <action-N>] announce <filter> Set of routes matched by filter exported to all peers in peerings While exporting routes at <peering-M> <action-M> is done

default Attribute default to <peering> [action <action>] [networks <filter>] Local AS defaults to the AS in <peering> <action> == attributes of defaulting <filter> == policy filter Router only uses the default policy if it received the routes matched by <filter> from this peer

Examples of default AS1 defaults to AS2 and uses 128.9.0.0/16 aut-num: AS1 default: to AS2 networks {128.9.0.0/16} AS1 defaults to AS2 and AS3, but prefers AS2 over AS3 default: to AS2 action pref=1; default: to AS3 action pref=2;

Routing Protocols Default is Exterior Gateway Protocol Valid Protocols BGP Valid Protocols in RPSL dictionary Injecting Routes between protocols Multi-Protocol Routing Protocols The "dictionary" type of object is not in RIPE DB Version 3.

Prefix based Policy 128.9.0.0/16 AS2 AS1 128.8.0.0/16 aut-num: AS1 export: to AS2 announce {128.9.0.0/16, 128.8.0.0/16} N.B. Filtering is based on Address-Prefix Set

Originate more routes ? 128.9.0.0/16 128.6.0.0/16 AS2 AS1 128.8.0.0/16 aut-num: AS1 export: to AS2 announce {128.9.0.0/16, 128.8.0.0/16, 128.6.0.0/16}

route-set Objects route-set object replaces the RIPE-181 community object N.B. "route-set" = = set of route prefixes <> set of RPSL route objects.

route-set Object Template Attribute Value Type route-set <object-name> mandatory, single, class key members list of optional, multi-valued <address-prefix-range> or <route-set-name> or <route-set-name><range-operator> or rs-any mbrs-by-ref list of optional, multiple-valued <mntner-names> or ANY Auxiliary information (admin-c, tech-c, etc. is not shown. The import, export and default attributes are defined later N.B. The keyword "rs-any".

Range Operators Address-prefix-range ^+: inclusive more specifics address prefix followed by a range operator ^+: inclusive more specifics 5.0.0.0/8^+ ^-: exclusive more specifics 128.9.0.0/16^- ^n: length n more specifics 30.0.0.0/^16 ^n-m: length n-m more specifics 30.0.0.0/^24-32

Indirect members of route-set Any is a reserved word Both of the route prefixes represented by the route objects are members of the route-set.

Restricted indirect members of route-set 192.157.69.0/24 is not a member of RS-ANS-IGP_ONLY

Direct & indirect members of route-set 192.157.69.0/24 is not a member of RS-ANS-IGP_ONLY

Direct Members The member-of attribute of the route object is an extra way to specify the members directly If an address-prefix is listed in the members attribute of a route-set, then it is a member of that route set The route object corresponding to this address-prefix does not need to contain a member-of attribute referring to this set name. Only use the member-of attribute of the route object when using the mbrs-by-ref attribute in the route-set object.

Members of sets in RIPE DB Version 3 route, aut-num and inet-rtr objects have “member-of” attribute This is not enough !!! The set object has “mbrs-by-ref” and “members” if “mbrs-by-ref” is absent, “members” is used Database software checks validity of membership rejects invalid creation or update of object

Example of route-set 128.9.0.0/16 128.6.0.0/16 AS2 AS1 128.8.0.0/16 aut-num: AS1 export: to AS2 announce {128.9.0.0/16, 128.8.0.0/16, 128.6.0.0/16}

Routing policy per route-set

Example of route-set 2 128.9.0.0/16 128.6.0.0/16 AS2 AS1 aut-num: AS1 export: to AS2 announce rs-red aut-num: AS2 import: from AS1 accept rs-red 128.8.0.0/16

Range operators and route-sets 192.157.69.0/24 is not a member of RS-ANS-IGP_ONLY

route Object Template Attribute Value Type route: <address-prefix> mandatory, single, class key origin: <as-numbers> mandatory, single, class key member-of: list of optional, multiple <route-set-names> inject: aggregation info optional, multiple components: aggregation info optional, single aggr-bndy: <as-expression> optional, single aggr-mtd: aggregation info optional, single export-comps: <filter> optional, single holes: list of optional, multiple <address-prefix> We talked about routes and route prefixes; now we talk about route objects. Auxiliary information (admin-c, tech-c, etc. is not shown. The inject, components, aggr-bndy, aggr-mrd, export-comps and the holes attributes are all for advanced use; discussed later. See RFC-2622.

Route Object in RIPE DB Version 3 Cross-mnt mntner(s) to be notifed Cross-nfy person or role to be notified No admin-c or tech-c in route object RFC-2622: admin-c and tech-c in route object

Route Object 1 Subset of a route ! The route and origin attributes == class key route: 128.8.0.0/16 origin: AS1 route: 128.8.0.0/16 origin: AS2 N.B. Two different routes

Route Object 2 route: 193.0.0.0/22 Policy information origin: AS3333 mnt-by: RIPE-NCC-MNT Policy information Route 193.0.0.0/22 is originated by AS3333 N.B. Auxiliary information is not shown

Using AS numbers in Policy route: 128.9.0.0/16 route: 128.8.0.0/16 origin: AS1 origin: AS1 aut-num: AS1 export: to AS2 announce AS1 aut-num: AS2 import: from AS1 accept AS1 AS1 == {128.9.0.0/16, 128.8.0.0/16} 'accept', 'announce' => route-set context => AS number == routes originated by the AS.

Cumbersome ? AS1 AS6 AS2 AS3 AS4 AS5 aut-num: AS1 export: to AS2 announce AS1 OR AS3 … AS6 aut-num: AS2 import: from AS1 accept AS1 OR AS3 … AS6 AS1 == {128.9.0.0/16, 128.8.0.0/16} 'accept', 'announce' => route-set context => AS number == routes originated by the AS.

Using as-set objects AS1 as-set: AS1:AS-Customers members: AS1, AS3, AS4, AS5, AS6 aut-num: AS1 export: to AS2 announce AS1 OR AS3 … AS6 aut-num: AS2 import: from AS1 accept AS1 OR AS3 … AS6 AS3 AS4 AS5 AS1 == {128.9.0.0/16, 128.8.0.0/16} 'accept', 'announce' => route-set context => AS number == routes originated by the AS.

as-set Object Template Attribute Value Type as-set <object-name> mandatory, single, class key members list of optional, multiple-valued <as-numbers> or <as-set-names> or as-any mbrs-by-ref list of optional, multiple-valued <mntner-names> or ANY Auxiliary information (admin-c, tech-c, etc. is not shown. The import, export and default attributes are defined later

Indirect members of as-set Any is a reserved word

Using as-set objects 2 AS7 AS6 AS1 AS2 AS8 AS3 AS4 AS5 as-set: AS6:AS-Customers members: AS6, AS7, AS8 as-set: AS1:AS-Customers members: AS1, AS3, AS4, AS5, AS6:AS-Customers AS1 == {128.9.0.0/16, 128.8.0.0/16} 'accept', 'announce' => route-set context => AS number == routes originated by the AS.

Using as-set objects 3 AS7 AS6 AS1 AS2 AS8 AS3 AS4 AS5 aut-num: AS1 export: to AS2 announce AS1:AS-Customers aut-num: AS2 import: from AS1 accept AS1:AS-Customers AS1 == {128.9.0.0/16, 128.8.0.0/16} 'accept', 'announce' => route-set context => AS number == routes originated by the AS.

More Customers ? AS3 AS2 AS1 AS4 aut-num: AS2 import: from AS1 accept AS1:AS-Customers import: from AS3 accept AS3:AS-Customers import: from AS4 accept AS4:AS-Customers This becomes cumbersome as we add more customers. Thus, PeerAs.

PeerAS AS3 AS2 AS1 AS4 as-set: AS2:AS-Customers members: AS1, AS3, AS4 aut-num: AS2 import: from AS2:AS-Customers accept PeerAS:AS-Customers This becomes cumbersome as we add more customers. Thus, PeerAs.

PeerAS 2 Keywoord :PeerAS Used in import attribute instead of the AS number of the peer AS Useful when using AS expression

Predefined Set Objects RS-ANY, rs-any AS-ANY, as-any

Route-set context AS number: ASX == routes originated by ASX as-set: AS-X == routes originated by the AS’es in AS-X

Complex example AS7 AS1 AS2 Solution ? AS8 AS9 AS6 AS3 AS4 AS5 'accept', 'announce' => route-set context => AS number == routes originated by the AS.

AS Path Based AS7 AS1 AS2 AS paths that start in AS1 and end in AS8: No prefix filters here !!! AS1 == {128.9.0.0/16, 128.8.0.0/16} 'accept', 'announce' => route-set context => AS number == routes originated by the AS.

AS Path Regular Expressions AS1 AS1 as-foo any AS in as-foo X* 0 or more occurrences of X X+ 1 or more occurrences of X X? 0 or 1 occurrence of X ^ beginning of path $ end of path X|Y X or Y XY X followed by Y

AS Path Regular Expressions Policy filter only when the expression is between ‘<‘ and ‘>’ Regular expressions the alphabet of AS numbers Router can check BGO: AS_PATH IDRP: RD_PATH Regular Expression Operators

AS Path RE Example AS7 AS1 AS2 <^AS1+ AS1:AS-Customers* $> matches: AS1 AS1 AS3 AS1 AS4 AS1 AS5 AS6 AS1 AS1 AS5 AS5 AS6 AS Paths into AS1's Customers

AS Path Based import/export import: from AS1 accept <^AS1 .* AS8> import: from AS1 accept <^AS1 AS1:AS-Customers*$> No route prefixes here !!! AS Paths into AS1's Customers

Composite Policy Filters NOT, AND, OR AS1 == {128.8.00/16, 128.9.0.0/16} rs-red == {128.6.0.0/16, 128.9.0.0/16} AS1 OR rs-red == {128.6.0.0/16, 128.8.0.0/16, 128.9.0.0/16} AS1 AND rs-red == {128.9.0.0/16} AS1 AND NOT rs-red == {128.8.0.0/16} NOT - negation AND - intersection OR - union

Composite Policy Filters 2 aut-num: AS1 import: from AS1 accept (AS1 OR rs-red) AND NOT {0.0.0.0/0} N.B. AS numbers & as-set names == routes NOT - negation AND - intersection OR - union

Filter Bad Routes Look again at the RS-MARTIANS route-set object. It is useful when expressing that you filter these route prefixes.

Prefix Length Based Policy aut-num: AS1 import: from any accept ANY AND NOT {192.168.0.0/16^+} N.B. Filter == Address-Prefix Set; Composite Policy NOT - negation AND - intersection OR - union

Actions Preference & Cost Community

Preference & Cost AS1 AS2 AS4 AS3 Slow link aut-num: AS4 import: from AS1 action pref = 10; accept ANY import: from AS4 action pref = 15; accept ANY Smaller the number, higher the preference !!! pref = 65536 - localpref localpref is a BGP attribute

Specifying Actions RPSL policy actions Which route attributes ? set or modify route attributes instruct routers to do special operations route flap dampening Which route attributes ? RPSL dictionary dictionary object not implemented in RIPE Database Version 3

Specifying Actions 2 Syntax of a policy action x.method(arguments) x “operator” argument Terminated by semicolon ‘;’ Composite policy actions possible evaluated left-to-right

Specifying Actions 3 import: from … action XXX; accept … export: to … action XXX; announce ... med = 0; med = igp_cost; community.append(NO_EXPORT, 10250, 3561:90); community.delete(NO_EXPORT); aspath.prepend(AS1, AS1, AS1);

Specifying Actions 4 AS1 AS2 AS4 AS3 Slow link aut-num: AS4 export: to AS1 announce AS4 export: to AS3 action aspath.prepend(AS4); announce AS4 Smaller the number, higher the preference !!! What would happen if aspath.prepend(AS4, AS4, AS4, AS4) ?

Choosing a Peering 1.1.1.1 1.1.1.2 AS1 AS2 2.2.2.2 aut-num: AS1 import: from AS2 accept AS2

Choosing a Peering 1.1.1.1 1.1.1.2 AS1 AS2 2.2.2.2 aut-num: AS1 import: from AS2 at 2.2.2.2 action pref = 10; accept AS2

Choosing a Peering 2 aut-num: AS1 import: from AS2 at 2.2.2.2 action pref = 10; accept AS2 import: from AS2 1.1.1.2 at 1.1.1.1 action pref = 5;

Community Based Policy Slow link AS4 wants AS3561 to prefer AS1 path AS3561 prefers routes with no community with community 3561:90 with community 3561:80 with community 3561:70

AS3561’s Policies

AS 4’s Policies AS1 AS3561 AS4 AS3 Slow link aut-num: AS4 export: to AS1 action community.={3561:90}; to AS3 action community.={3561:80}; announce AS4 community.={.....} means append ..... to theBGP community attribute.

Ambiguity Resolution Two or more peering expressions Which is used ? describe the same peering Which is used ? Specification-order rule the first peering specification is always used

Ambiguity Resolution 2 aut-num: AS1 import: from AS2 action pref = 2; accept AS4 import from AS2 action pref = 1; accept AS4 OR AS5 AS2 accepts AS4’s routes with pref = 2 AS2 accepts AS5’s routes with pref = 1

Routing Policy Specification Language Background RPSL Objects Contact Information Specifying Policy Set Objects inet-rtr object Advanced Features

Set Objects

Set Objects Sets of routes, autonomous systems, etc. Specify members route-set as-set filter-set peering-set rtr-set Specify members directly indirectly

Set Names Example: as-customers Example: rs-partner

Hierarchical Set Names Sequence of set names and AS numbers, separated by “:” At least one component must be an actual set name. All set name components must be of the same type. Authorization Mntner of AS1 controls AS1:AS-Customers AS1:RS-EXPORT controls AS1:RS-EXPORT:AS2

Filter-Set Objects A filter-set object defines a set of routes that are matched by its filter. N.B. No "members" attribute, but "filter".

“filter” attribute “filter” attribute defines a policy filter A policy filter matches routes Any BGP path attribute can be in the filter ANY Address-Prefix Set Route Set Name AS Path Regular Expressions Composite Policy Filters Routing Policy Attributes Filter Set Name Route Set Name: matches the routes that are members of the set. name of a route-set object AS number name of an as-set object Policy expression can be followed bu a range operator Can use other BGP attributes - evaluated before AND, OR, NOT. Can use the name of a filter-set in a filter. Can use the values of other [BGP] attributes; e.g. community.

Peering Set Object Defines a set of peerings Peering Set Name: prng- The peering attribute defines a peering used to import or export routes No “members” attribute

Peering-Set Objects 2 Router 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3.

Rtr-Set Objects A filter-set object defines a set of routes that are matched by its filter. N.B. No "members" attribute, but "filter".

rtr-set Object Template Attribute Value Type rtr-set <object-name> mandatory, single, class key members list of optional, multi-valued <inet-rtr-names> or <rtr-set-names> or <ipv4-addresses> mbrs-by-ref list of optional, multi-valued <mntner-names> or ANY Auxiliary information (admin-c, tech-c, etc. is not shown. The import, export and default attributes are defined later

Routing Policy Specification Language Background RPSL Objects Contact Information Specifying Policy Set Objects inet-rtr object Advanced Features

Inet-rtr Object

Inet-rtr Object The inet-rtr attribute is a valid DNS name of the router described. Each alias attribute, if present, is a canonical DNS name for the router. The local-as attribute specifies the AS number of the AS which owns/operates this router.

Inet-Rtr Object Template Attribute Value Type inet-rtr <dns-name> mandatory, single, class key alias <dns-name> optional, multi-valued local-as <as-number> mandatory, single ifaddr interface address mandatory, multi-valued peer peering information optional, multi-valued member-of list of optional, multi-valued <rtr-set-names> Auxiliary information (admin-c, tech-c, etc. is not shown. The import, export and default attributes are defined later

Inet-rtr Object 2 ifaddr: <ipv4-address> masklen <integer> [action <action>] The peer attribute: <protocol><ipv4-address> <options> |<protocol><inet-rtr-name> <options> |<protocol><rtr-set-name> <options> |<protocol><peering-set-name> <options> <protocol> is usually BGP.

Routing Policy Specification Language Background RPSL Objects Contact Information Specifying Policy Set Objects inet-rtr object Advanced Features

Routing Policy System Security

Routing Policy System Security (RPSS) Background as-block mnt-lower mnt-routes referral-by auth-override

Routing Policy System Security (RPS-Auth) RFC-2725 Data integrity and security in the Internet Routing Registry One new object as-block Four new attributes mnt-lower mnt-routes referral-by auth-override

New object in RPS-Auth; as-block

As-block Object Used by Regional Internet Registries Shows the delegation of a range of AS numbers Controls the creation of aut-num objects mnt-lower attribute Also controls creation of more specific as-block objects

New attributes in RPS-Auth New attributes increase security mnt-lower mnt-routes referral-by auth-override

Mnt-lower Attribute Used in as-block, aut-num, inetnum, route objects Points to a mntner object Controls creation of objects underneath root object as-block object: more specific as-block objects aut-num objects aut-num object hierarchical name objects

Mnt-lower Attribute 2 inetnum object route object inetnum objects with more specific address prefixes route object route objects with more specific address prefixes

As-block Object again

RPS-Auth; as-block & mnt-lower

Aut-num Object & mnt-lower

Inetnum Object & mnt-lower If the inetnum object 193.0.2.0 - 193.0.3.255 has no 'mnt-lower', then no check is done.

Route Object & mnt-lower

Mnt-routes Attribute Used in aut-num, inetnum, route objects Points to a mntner object Does not allow changes to the object where it appears Controls creation of route objects <mnt-name> [ {list of <address-prefix-range>} | ANY Default is ANY == all more specific routes Default is ANY. This is not specified in the object; it is assumed.

Mnt-routes; Summary Aut-num object Route object origin attribute of the route object mnt-routes mnt-by Route object exact or less specific match mnt-lower

Mnt-routes; Summary 2 Inetnum object exact or less specific match mnt-lower mnt-by

Aut-num Object & mnt-routes The 'mnt-routes' of AS1 is checked. Also, the 'mnt-by' of the new object is always checked. The db will keep looking for an exact/less specific matching route/inetnum object, until it finds something. It should always find a top-level object.

Inetnum Object & mnt-routes This object exists already. Before the route object can be created, the authentication in the aut-num object and in a route object with an exact prefix match. If there is no exact match, then the next less specific match is used. If there is no route object, then an inetnum object with an exact prefix match is checked. If there is no exact match, then the next less specific match is used. The authentication must always match the 'mnt-by' attribute of the route object that is to be created.

Route Object & mnt-routes Before the route object can be created, the authentication in the aut-num object and in a route object with an exact prefix match. If there is no exact match, then the next less specific match is used. If there is no route object, then an inetnum object with an exact prefix match is checked. If there is no exact match, then the next less specific match is used. The authentication must always match the 'mnt-by' attribute of the route object that is to be created.

Mnt-routes; Summary Aut-num object Route object origin attribute of the route object mnt-routes mnt-by Route object exact or less specific match mnt-lower

Mnt-routes; Summary 2 Inetnum object exact or less specific match mnt-lower mnt-by

Referral-by Refers to the mntner that created a mntner object Is never changed after the mntner object is created Usually points to database administrator

Auth-override Date after which a mntner can be modified Only the mntner in “referral-by” can do this Only the mntner in “referral-by” can modify the mntner auth-override attribute only added if inactive for 60 days Value must be >= 60 days from current date

Extra Object Types in RIPE Database Version 3

Extra Object Types in RIPE DB Version 3 Domain Top Level Domain (TLD) and Reverse Delegations referral mechanism inet6num IPv6 address space object key-cert object database public key certificate limerick humorous poem, five lines, with rhyming scheme “aabba”

Advanced Features

Advanced Features Aggregation Static Routes Structured Policy RAToolSet RTConfig

Aggregation 192.157.69.0/24 is not a member of RS-ANS-IGP_ONLY

Static Routes 192.157.69.0/24 is not a member of RS-ANS-IGP_ONLY

Structured Policy Example: autonomous system, AS1 AS1 prefers routes with no community community 1:20 community 1:10 AS1 only accepts AS2 routes from AS2 AS3 and AS4 routes from AS3 the routes of AS5’s customers from AS5

Structured Policy for AS1 192.157.69.0/24 is not a member of RS-ANS-IGP_ONLY

Structured Policy for AS3561 192.157.69.0/24 is not a member of RS-ANS-IGP_ONLY

AS3561’s Policies Practical example:AS2764 in the RADB db.

RAToolSet & RtConfig

RAToolSet & RtConfig RAToolSet RtConfig http://www.isi.edu/ra/RAToolSet/ a set of policy analysis tools RIPE DB Version 3 supports the query types RtConfig a tool that generates vendor specific router configurations use the policy data stored in the Internet Routing Registry supports several formats RtConfig supports formats from the following vendors: Juniper Networks Cisco Bay/Nortel Gated

Using RtConfig Register routing policy in the Internet Routing Regsitry Create an RtConfig source file router configuration file replace vendor-specific policy configuration commands with RtConfig commands Run RtConfig source file Internet Routing Registry % RtConfig < template > config-file Commands beginning with “@RtConfig” are instructions

RAToolSet 2 Route Object Editor Autonomous system Object Editor Other tools prtraceroute

Route Object Editor Lists routes registered by a provider Shows discrepancies Shows holes Can be used to correct these discrepancies Roe shows the routes registered by a provider, highlighting the discrepancies between the registered routes and the routes that are actually routed. Roe indicates all the holes punched in the provider's routes, or by the provider's routes. Roe's registration front-end can be used to correct these discrepancies with simple GUI operations.

Route Object Editor (roe) Example Shows the routes registered by an AS.

Autonomous system Object Editor (aoe) Aoe can display the policies registered by an AS.

Useful Links RPSL http://www.isi.edu/ra/rps/training/ IRR http://www.irr.net/ RIPE http://www.ripe.net/ http://www.ripe.net/rpsl/ http://www.ripe.net/ripe/docs/databaseref-manual.html RAToolSet http://www.isi.edu/ra/RAToolSet

Acknowledgements Cengiz Alaettinoglu RIPE NCC Packet Design Inc. Provided the slides from which many of these slides are derived But any errors are the responsibility of Ambrose Magee RIPE NCC Joao Luis Silva Damas Andrei Robachevsky Engin Guenduez, Shane Kerr, Vesna Manojlovic Engineering Group

Acknowledgements 2 Ericsson Services Ireland Network Services Solutions