RIPE Routing Working Group

                      Policy based routing within RIPE

                                  ripe-60

                                  May 1992


                           Jean-Michel Jouanigot

                           Antonio Blasco Bonito
                               Francis Dupont
                             Stefan Fassbender
                               Anders Hillbo
                              Ferdinand Hommes
                                Lothar Klein
                                Willi Porten
                               Don Stikvoort
                              Marten Terpstra
                               Ruediger Volk

                             Author's address:
                 Jean-Michel Jouanigot, jimi@dxcoms.cern.ch





        1.  Introduction

        RIPE,   Reseaux   IP   Europeens,   is    a    collaboration
        between  Regional   networks.   RIPE   is  not  a network in
        itself, and has therefore  no  Network   Operation   Center.
        One   of  the  most important issues in such a collaboration
        is the inter-regional routing between  the  networks  colla-
        borating within RIPE.

        In order to achieve  global  connectivity,   all   organiza-
        tions  have  to  collaborate  with  each other, and create a
        "coordinated routing core".  This coordinated  routing  core
        exists  de   facto  for   more   than  one year now, but the
        current setups have been built on case by  case  basis,  and
        have never been published.

        At the very beginning, the routing  between   the   interna-
        tional  routers   where   mainly  built  on  dynamic routing
        algorithms, using interior or  exterior  routing  protocols.
        However   it  is believed that this "open routing" organiza-
        tion has reached its limits and another structure has to  be
        used.



                                   - 1 -





        Policy based routing within RIPE                    May 1992


        2.  Interior vs Exterior routing protocols


        Whilst a single interior routing protocol would  be   easier
        to  manage,    this    approach  is  currently  unrealistic,
        mainly because:

        *  An  interior  routing  protocol   between   international
        routers  would  mean  that an European Backbone exists, with
        shared lines and  routers,  and   with   a   common  routing
        policy for all the routers and the lines in this backbone.

        * If such a backbone would exist, a  central  entity  should
        take care  of it, and organize the interior routing protocol
        within the backbone,  as  well  as  the   Exterior   routing
        protocols  between   this  backbone  and  the  National  and
        disciplinary networks connected to  it.   This  organization
        would   obviously  manage  the routers within this backbone,
        as well as the lines connecting these routers.

        As there is no  such  "global"   backbone,   and   no   such
        network  operation  center, this approach is not applicable.
        [1]

        The current collaboration is built  on  a   set   of   lines
        and   routers,    managed    by   different   organizations,
        without real general supervision. The RIPE  internetwork  is
        built on a set of Administrative Domains, (every RIPE member
        organization has its own) which can  have  multiple  Routing
        Domains  internally.   Therefore,  at the borders, the  only
        applicable  routing scheme is to use External Routing proto-
        cols   between  the  different Administrative Domains (using
        different Autonomous systems numbers),  each  Administrative
        Domain applying its own routing policy.



        3.  Current routing structure

        A  routing  core    member    mainly    collaborates    with
        its  "neighbors",    using   an  Exterior  routing  protocol
        (or  an interior routing protocol used as  an  Exterior  one
        in   some  cases).  Unless a router applies a  set  of  res-
        trictions,  it routes all  the  European   networks,   using
        the   shortest   path  algorithm.   Most   of   the  routers
        filter  the  routes on one  criteria:   all   the   networks
        they    propagate    should    be  registered  in  the  RIPE
        database, with a "non LOCAL" flag  in  the  connected  field
        [R1,R2].   A  few  others use filters according to  peer  to
        _________________________
          [1] The EBONE initiative,  which  goal  is   to   im-
        plement   a   central common  backbone,  will  not  in-
        clude   all   the   international infrastructures.



                                   - 2 -





        Policy based routing within RIPE                    May 1992


        peer  agreements  between  two routers, applying therefore a
        routing policy.

        Even if the current network infrastructure  is  quite   sim-
        ple,  with   very  few backdoors, and very few backup agree-
        ments, care  must  be  taken  to  avoid  routing  loops  and
        unpredictable  routing  paths.  This is avoided on a case by
        case basis, using routing announcement filtering.

        Finally, a general default route mechanism is   being   used
        to access  the  US  backbones.  Most  of  the  routers point
        to a default router (or a default network) in Europe  or  in
        the   US.  This  does  not prevent European traffic to cross
        the Atlantic twice, even if this is avoided as much as  pos-
        sible [R1].

        The current number of European networks routed  within  RIPE
        is more than 1200.


        4.  Policy based routing


        Every router within RIPE is applying a routing policy,  even
        if it  has  never  been  published.  These  routing policies
        were implemented in order to:

        * Protect a private line from carrying unwanted traffic,

        * Enforce a certain path to a network,

        * Avoid incorrect network announcements.

        These routing policies have  been  implemented  for  politi-
        cal  and/or   technical   reasons,   and   many of them have
        never been documented and are still evolving.

        Policy  based  routing  is   currently   under   study    in
        the   networking   community,  and  several  documents  have
        already been published [R3,4,5,6,7,8].  All these  proposals
        try   to   resolve  the  issue  of  expressing policies, and
        implementing them.  Even if some "simple" models have proved
        their  efficiency,   it  is believed  that these studies are
        not yet finalized, and that a lot of work need to be done.

        A good starting point would be to publish, for all the rout-
        ing core  routers,  their  routing policies, using for exam-
        ple the description proposed in [R3].  However, these policy
        statements  would   require  a  precise  definition  of  the
        Administrative Domains they refer  to,  the  definition   of
        the   User   Class  Identifiers...  It  would  be  more con-
        venient to start with a description of the routing  policies
        in  English,  collect  all this  information  and define the
        Administrative Domains later on.



                                   - 3 -





        Policy based routing within RIPE                    May 1992


        All the RIPE members are asked to produce the routing  poli-
        cies  their  routers  apply.  These routing policies will be
        collected by the RIPE routing-WG, and published as  soon  as
        possible.


        5.  Implementation of the Policy based routing

        Lots of theoretical solutions  exist  in  order  to   imple-
        ment  routing  policies  between  IP networks.  Some of them
        resolve the problem  in  general,  and  others  only  a  few
        aspects   of   it.   The   main  issue  is to find an imple-
        mented mechanism which is able to deal with the  problem  we
        want to solve.

        Proposals like [R3] imply developments of  servers,  routers
        and  sometimes  modification  of  the  end-nodes,  which  is
        impossible in  the  near   future.   The   routers  we  have
        today all share a common specification:

        * Only one routing space,

        * Routing on destination address.

        Therefore, only two solutions  exist  to  implement  routing
        policies [R5]:

        * Policy based distribution of routing information

        * Policy based packet filtering/forwarding.

        The second solution cannot be seriously  used,  because   of
        its  impact  on  the  performance  of  the  routers.  Policy
        based distribution  of  routing   information  is  the  only
        solution  in  our  environment  right  now.  In  some  cases
        however,  packet filtering can be used to enforce a particu-
        lar routing policy.

        Policy based distribution  of   routing   information   does
        not  solve  the  problem of routing loops, illegal announce-
        ments, and security issues.  However, if we can  concentrate
        in  one   place  all the routing information, it is expected
        that we can  avoid most of these drawbacks.



        6.  Autonomous systems organization

        One way to implement this  policy  based   distribution   of
        routing  information  is  to  use  the well-known concept of
        Autonomous System and protocols such as BGP[R6].  Because it
        is   expected   that   we  can  use  such  a protocol, a BGP
        pilot  project  has  been  proposed  within  RIPE,  and   is
        currently progressing.



                                   - 4 -





        Policy based routing within RIPE                    May 1992


        For many reasons Autonomous System  numbers  have  not  been
        used   in  the   RIPE  community  to  distinguish  different
        Administrative Domains with their  own  lines,  routers  and
        policies.   Many  routers  within  RIPE  do  not  really use
        Autonomous Systems for routing.  They are rather  used  only
        at  the   AD  border  to  implement  some routing filtering.
        Therefore,  for  the  time  being,  the  Autonomous  systems
        organization   is   not   currently   suitable  for  routing
        purposes.

        Once the Autonomous systems have been reorganized in Europe,
        the  Autonomous  Systems  Numbers  and  BGP could be used to
        implement routing policies.  However, BGP is unable to avoid
        incorrect   and  illegal   routing   announcements.   There-
        fore,   the  routing-wg proposes to use policy based distri-
        bution  of  routing   information  using  route announcement
        filtering.

        The issue is therefore to  obtain  reliable  network  lists.
        This  would  require administrative tasks to be performed in
        all the routing centers.  These tasks would be greatly  sim-
        plified  by using a common database.


        7.  The RIPE database

        The  RIPE  database  already  contains   a   set   of   use-
        ful   informations  on  networks.   These  informations  are
        described in [R2].  An example of information one can   find
        about  networks is:


                *in: 192.16.184.0
                *na: CWI-ETHER
                *de: CWI Ethernet (Classical)
                *de: Amsterdam
                *de: Netherlands
                *tc: Piet Beertema
                *tc: Daniel Karrenberg
                *co: RIPE Internet NSFnet
                *de: CWI, Amsterdam
                *ch: dfk@cwi.nl 900802
                *so: RIPE


        The current definition for the "co" field is:

             The definition  of  this  is   arbitrary   and   should
             be  replaced  by  something more rational as e.g.  AS's
             that may  be traversed or some such.  Suggestions  wel-
             come.






                                   - 5 -





        Policy based routing within RIPE                    May 1992


             LOCAL   local only This means routing updates will be blocked in RIPE routers.
             RIPE    European. This means RIPE routers will distribute routes for this net.
             NSF     NSFnet. This means the net is in the NSFnet database
             ICS     Internet Connected Status
             EU      member of InterEUnet
             NORDU   member of NORDUnet
             BLOCK   for local purposes (not in RIPE database)


        It is proposed to  add   a   new   field   named   'rout-pr'
        (rp),  similar  the  actual 'co' field.  The new field indi-
        cates the privileges  as granted  by  a  certain  networking
        organization. The value of the field is a mnemonic specified
        by the networking organization.











































                                   - 6 -





        Policy based routing within RIPE                    May 1992


        Possible values of  this  field  can be:


        LOCAL      local only (This means routing updates will be
                   blocked in RIPE routers.)
        EUNET      member of InterEUnet
        NORDUNET   member of NORDUnet
        HEPNET     member of HEPNET
        GARR       member of GARR
        EASINET    member of EASINET
        NSFNET     This network has the NSFNET connected status.


        The complete list of these attributes will be defined  later
        on,  as  well  as the organizations/persons that can grant a
        privilege  .   Procedures  to  collect  attributes  and   to
        authorize     the     use     of   attributes    with    the
        organization/person when networks  are  added  to  the  RIPE
        database,  are  being  defined  by  the   NIC   coordination
        working-group.

        These connectivity flags can only be  set   if   agreed   by
        the  organizations   that  can  grant  them.  This field can
        contain several tags.


                EXAMPLES:

                     rp: HEPNET EASINET NSFNET

                     rp: GARR NSFNET



        In addition to this  field,  a  new  field  'bdry-gw'   (bg)
        should  indicate   the  origin  of the announcement for this
        network  in  the   international   routing    core.     This
        'bdry-gw'    field  indicates   the   site   name  which  is
        allowed to announce this network.  Should this field contain
        more than one value,  this means  that the network described
        has more than one  connection  point  to  the  international
        infrastructure  (for  backup  purposes  for  example).  This
        field  should  contain   "routing   center  names"  and  not
        router's  names  in  order  to limit the number  of possible
        values for this field.  Possible values can be :[2]





        _________________________
          [2] The complete list of these attributes is  to   be
        defined later on




                                   - 7 -





        Policy based routing within RIPE                    May 1992



                        CEA
                        CERN
                        CIEMAT
                        CNAF
                        CNUCE
                        CNUSC
                        EUNET/Amsterdam
                        DESY
                        DFNGATE
                        DIST
                        EASIGATE
                        FORTH
                        GMD
                        ILAN
                        IN2P3
                        INRIA
                        IRIS
                        JKU
                        KTH
                        LEUVEN
                        NIKHEF
                        SARA
                        SWITCH
                        UKC
                        ULCC
                        UNIDO
                        VIENNA



        8.  Database object definition



        8.1.  rout-pr definition


        _______________________________________________________________________________________________________________
       ||                                                       ||
       || rout-pr     [flag]                         [mandatory]||
       || descr       [text]            [multiple]   [mandatory]||
       || authority   [text]                         [mandatory]||
       || guardian    [email-address]                [mandatory]||
       || admin-c     [person]          [multiple]   [mandatory]||
       || tech-c      [person]          [multiple]   [optional] ||
       || changed     [text]                         [mandatory]||
       || source      RIPE                           [mandatory]||
       ||||_______________________________________________________________________________________________________________||||


        rout-pr:
             The name of the flag, that can be a value in  the  con-
             nectivity field of a network entry.



                                   - 8 -





        Policy based routing within RIPE                    May 1992


             Format : one textual flag
             Example: rout-pr: WCW
             status : mandatory

        descr:A short description of what the rout-pr is.
             Format : text, multiple.
             Example: description: Wetenschappelijk  Centrum  Water-
             graafsmeer (WCW)
             status: one line mandatory, multiple lines optional

        authority:
             Formal authority for  this  rout-pr.  This  can  be  an
             institute, committee etc.
             Format : text
             Example: authority: WCW LAN committee
             status: mandatory

        guardian:
             Email address of the guardian authorizing requests  for
             this rout-pr. It is expected that this email address is
             present in the returning authorization message.
             Format : one email address
             Example: guardian: wcw-guardian@nikhef.nl
             status: mandatory

        admin-c:
             Person administratively responsible for this rout-pr.
             Format: person, multiple
             Example: admin-c: John Doe
             status: mandatory

        tech-c:
             person technically responsible for this rout-pr.
             Format: person, multiple
             Example: tech-c:  Jon Doe
             status: optional

        changed:
             Field containing the person (email) who made the change
             and the date of last change.
             Format : mailbox yymmdd
             Example: changed: dfk@cwi.nl 910129
             status: mandatory

        source:
             Source of this information. This will normally be RIPE.
             Format : text
             Example: source: RIPE
             status: mandatory








                                   - 9 -





        Policy based routing within RIPE                    May 1992


        8.2.  bdry-gw definition



        _______________________________________________________________________________________________________________
       ||                                                       ||
       || bdry-gw     [flag]                         [mandatory]||
       || descr       [text]            [multiple]   [mandatory]||
       || location    [text]            [multiple]   [mandatory]||
       || authority   [text]                         [mandatory]||
       || guardian    [email-address]                [mandatory]||
       || admin-c     [person]          [multiple]   [mandatory]||
       || tech-c      [person]          [multiple]   [mandatory]||
       || changed     [text]                         [mandatory]||
       || source      RIPE                           [mandatory]||
       ||||_______________________________________________________________________________________________________________||||



        bdry-gw:
             Name of the boundary gateway.  This is not the name  of
             the actual physical router since that may change.
             Format: one textual flag
             Example: bdry-gw: NIKHEF
             Status: mandatory

        descr:Short textual description of the bdry-gw.
             Format: text, multiple
             Example: description: IP over IXI links
             Status: one line mandatory, multiple lines optional

        location:
             Short textual description of the location of the  brdy-
             gw.
             Format: text, multiple
             Example:  location:  Wetenschappelijk  Centrum   Water-
             graafsmeer (WCW)
             Status: one line mandatory, multiple lines optional

        admin-c:
             Person administratively responsible for this bdry-gw.
             Format: person, multiple
             Example: admin-c: Marten Terpstra
             Status: one line mandatory, multiple lines optional

        tech-c:
             Person technically responsible for this bdry-gw.
             Format: person, multiple
             Example: tech-c:Marten Terpstra
             Status: one line mandatory, multiple lines optional

        authority:
             Formal owner of this bdry-gw.
             Format: text



                                   - 10 -





        Policy based routing within RIPE                    May 1992


             Example: authority: NIKHEF
             status: mandatory

        guardian:
             Mailbox of the guardian of the bdry-gw. Usage as in the
             rout-pr object.
             Format: mailbox
             Example: guardian: terpstra@nikhef.nl
             Status: mandatory

        changed:
             Field containing last change date and person  who  made
             the change.
             Format : mailbox yymmdd
             Example: changed: dfk@cwi.nl 910129
             status: mandatory

        source:
             Source of this information. This will normally be RIPE.
             Format : text
             Example: source: RIPE
             status: mandatory


        8.3.  Objects Examples

        Please note that these are examples, they may not  represent
        the real values for these objects.


        rout-pr:     NIKHEF-IXI
        descr:       IP over IXI to NIKHEF
        authority:   NIKHEF
        guardian:    terpstra@nikhef.nl
        admin-c:     Rob Blokzijl
        tech-c:      Marten Terpstra
        changed:     911001 dfk@cwi.nl
        source:      RIPE

        bdry-gw:     NIKHEF
        descr:       IP over IXI gateway
        location:    NIKHEF
        location:    Wetenscappelijk Centrum Watergraafsmeer (WCW)
        location:    Amsterdam
        authority:   NIKHEF
        guardian:    terpstra@nikhef.nl
        admin-c:     Rob Blokzijl
        tech-c:      Marten Terpstra
        change:      911001 dfk@cwi.nl
        source:      RIPE

        rout-pr:     HEPNET
        descr:       High Energy Physics Network
        authority:   HEPnet Technical Committee IP (HTC-IP)



                                   - 11 -





        Policy based routing within RIPE                    May 1992


        guardian:    hip-adm@frcpn11.in2p3.fr
        admin-c:     HTC-IP Chairman
        tech-c:      HTC-IP Chairman
        change:      911001 dfk@cwi.nl
        source:      RIPE



        9.  Implementation of the routing policies


        9.1.  Principle

        The routing policies are implemented in each routing  center
        using the information contained in the database. The routing
        announcements are filtered according to local rules that are
        widely published.


        As an example, we will consider a routing center composed of
        3  routers,  and connecting 5 international lines. The lines
        1,2,3,4,5 are international  connections  to  other  routing
        centers,   whereas   A,B,C  are  "intra-domain"  connections
        between routers  inside  the  routing  center.  The  routing
        announcements  on  A,B,C cannot generally be described using
        the the information found in the database.

        Each network in the database is tagged with a set  of  flags
        (i.e.  rout-pr,  bdry-gw, cy ...) which could be used by the
        routing center to accept  or  refuse  network  announcements
        comming  from  other  routing  centers  on the international
        lines 1,2,3,4,5 according to the local routing  policy.  The
        database does not describe any "global" routing policy for a
        network.  Examples :

                on line (1) accept any network with cy=PL
                on line (2) accept any network with cy=IT except those with rp=EUNET
                on line (3) accept any network with cy=IT and rp=EUNET [3]


        9.2.  Practical examples

        one  can  easily  implement  the  (non   published)  routing
        policy on the GARR-CERN line by:

        at CERN:  Accept any network  from  INFN  with  the  follow-
        ing statement: cy = IT && rp = GARR

        Routing policy for the EUnet/Amsterdam-Dortmund line:

        at EUnet/Amsterdam:  Accept any network from  Dortmund  with
        _________________________

          [3] line (3) is supposed to be an EUNET line to Italy



                                   - 12 -





        Policy based routing within RIPE                    May 1992


        the following statement: cy = DE && rp = EUNET

        Routing policy for the IN2P3-CERN line:

        at CERN: Accept any network from  IN2P3  with  the   follow-
        ing statement: cy = FR && bg = IN2P3


        9.3.  Rules Compiler

        The policy based routing statements should be  listed  in  a
        common  format. A 'Rules Compiler' [4] processes these rules
        and extracts, from the database, the lists of networks  that
        have  to be downloaded in the routers to implement the rout-
        ing policy.


        10.  References


        R1   Bernhard Stochman, "8th RIPE meeting  minutes",
             (ripe-m-8), March 1991

        R2   R.Blokzijl, "RIPE Databases   (ripe-13)",   RIPE,   28
             August, 1990

        R3   D.  Clark, "Policy Routing in Internet Protocols",  RFC
             1102, M.I.T., May 1989

        R4   J.  Rekhter, "EGP and Policy Based Routing in  the  New
             NSFNet backbone", RFC 1092, February 1989

        R5   H-W.  Braun, "Models of  Policy  Based  Routing",   RFC
             1104, Merit/NSFNET, June 1989

        R6   J.  Honig & all, "Application  of  the  Border  Gateway
             Protocol in the Internet", RFC 1164, Merit/NSFNet, June
             1990

        R7   B.  Leiner,  "Policy  Issues  in  Interconnecting  Net-
             works",  RFC 1124, RIACS, September 1989

        R8   D  Estrin,  "Policy  Requirements  for  Inter  Adminis-
             trative  Domain  Routing", RFC  1125,  U.S.C.  Computer
             Science  Dpt., November 1989

        R9   H-W.  Braun, "The NSFNET  routing  architecture",   RFC
             1093, Merit, February 1989

        _________________________
          [4] A Beta test version of this compiler  written  at
        CERN  is  currently  "field tested" at the CERN Routing
        Center.




                                   - 13 -





        Policy based routing within RIPE                    May 1992


        R10  K.  Lougheed, "A border gateway protocol",  RFC   1163,
             Cisco Systems, June 1990

        R11  Scott Brim,  "IP  routing   Between   U.S.   Government
             Agency  Backbones   and   Other   Networks",   Internet
             Draft,  Cornell University, January 1990

        R12  M.   Lepp  and  M.   Steenstrup,    "An    Architecture
             for   Inter-Domain     Policy     Routing",    Internet
             Draft,   BBN Communication Corporation, February 1990















































                                   - 14 -