RPKI con JunOS / RPKI with JunOS

    English below

    Además de los ejemplos con Cisco IOS que Carlos a comentado también hemos estado trabajando en probar validación de origen en routers Juniper. Antes que nada queremos agradecer el esfuerzo y el apoyo de Serpil Bayraktar, Alain Durand, Hannes Gredler y Joel Obstfeld de Juniper para poder montar estas pruebas. También agradecemos a Tim Bruijnzeels y al equipo de desarrollo de RIPE NCC para probar exitosamente su validador y cache de RPKI.

     

    Las pruebas que hicimos fueron hechas usando el validador de RIPE NCC y JunOS.

    Configuración del caché en JunOS

    Básicamente la IP y el puerto para comunicarse con el caché

     

    routing-options {
        autonomous-system 10;
        validation {
     
            group cache1 {
                session 10.1.1.6 {
                    refresh-time 120;
                    hold-time 180;
                    port 8282;
                    local-address 10.1.1.5;
                }
            }
        }
    }
     
    Configuración de BGP en JunOS
     
    Se configura la sesión y las políticas de validación
     
    protocols {
        bgp {
            group ASN200 {
                import rv;
                export p;
                peer-as 200;
                neighbor 10.1.1.2;
            }                               
        }                                   
    }               
     
    Políticas
     
    Aquí configuramos las políticas y asignamos un "local preference" de acuerdo a la validez de la ruta.
     
    policy-options {                        
        policy-statement p {                
            from protocol direct;           
            then accept;                    
        }                                   
        policy-statement rv {               
            term a {                        
                from {                      
                    protocol bgp;           
                    validation-state valid; 
                }                           
                then {                      
                    local-preference 110;   
                    validation-state valid; 
                    accept;                 
                }                           
            }                               
            term b {                        
                from {                      
                    protocol bgp;           
                    validation-state invalid;
                }                           
                then {                      
                    local-preference 9;     
                    validation-state invalid;
                    accept;                 
                }                           
            }                               
            term c {                        
                from {                      
                    protocol bgp;           
                    validation-state unknown;
                }                           
                then {                      
                    validation-state unknown;
                    accept;                 
                }                           
            }                               
        }                                   
    }                                     
     
    Verificación
     
    En este caso nuestra tabla de ROAs es pequeña:
     
    >show validation database
       
    RV database for instance master
     
    Prefix                 Origin-AS Session                                 State   Mismatch
    10.0.0.0/16-19                20 12.1.1.6                                valid  
    10.0.0.0/19-24                 2 12.1.1.6                                valid  
     
      IPv4 records: 2
      IPv6 records: 0
     
    Y como se ve en la tabla de ruteo:
     
    >show route protocol bgp     
     
    inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
     
    10.0.0.0/16        *[BGP/170] 00:45:53, localpref 110
                          AS path: 200 20 I, validation-state: valid
                        > to 10.1.1.2 via em1.0
    10.0.0.0/24        *[BGP/170] 00:42:58, localpref 9
                          AS path: 200 20 I, validation-state: invalid
                        > to 10.1.1.2 via em1.0
    13.1.1.4/30        *[BGP/170] 3w1d 17:34:46, localpref 100
                          AS path: 200 20 I, validation-state: unknown
                        > to 10.1.1.2 via em1.0
     
    En este caso 10.0.0.0/16 coincide con un ROA y es asignado estado válido. 10.0.0.0/24 es inválida porque el ROA indica que debe ser originado por el ASN 2 y es el ASN 20 el que origina la ruta. La 13.1.1.4/30 aparece como desconocida porque no hay ROA que coincida con esta ruta.
     
    =========================

     

    We wanted to show more RPKI examples related with origin-validation but now using Juniper routers. But first we want to thank Serpil Bayraktar, Alain Durand, Hannes Gredler and Joel Obstfeld from Juniper for their support and help to do this testing. We also want to thank Tim Bruijnzeels and the development team in RIPE NCC to let us test their validator and cache.

     

     

    We made this testing using RIPE NCC validator and JunOS.

    Cache configuration in JunOS

    Basically, the IP address and port to communicate with the cache

     

    routing-options {
        autonomous-system 10;
        validation {
     
            group cache1 {
                session 10.1.1.6 {
                    refresh-time 120;
                    hold-time 180;
                    port 8282;
                    local-address 10.1.1.5;
                }
            }
        }
    }
     
    BGP Configuration in JunOS
     
    We configure BGP neighbors and policies
     
    protocols {
        bgp {
            group ASN200 {
                import rv;
                export p;
                peer-as 200;
                neighbor 10.1.1.2;
            }                               
        }                                   
    }               
     
    Policies
     
    Here we configure the routing policies and we assig "local preference" according with the validity attribute of the prefix.
     
    policy-options {                        
        policy-statement p {                
            from protocol direct;           
            then accept;                    
        }                                   
        policy-statement rv {               
            term a {                        
                from {                      
                    protocol bgp;           
                    validation-state valid; 
                }                           
                then {                      
                    local-preference 110;   
                    validation-state valid; 
                    accept;                 
                }                           
            }                               
            term b {                        
                from {                      
                    protocol bgp;           
                    validation-state invalid;
                }                           
                then {                      
                    local-preference 9;     
                    validation-state invalid;
                    accept;                 
                }                           
            }                               
            term c {                        
                from {                      
                    protocol bgp;           
                    validation-state unknown;
                }                           
                then {                      
                    validation-state unknown;
                    accept;                 
                }                           
            }                               
        }                                   
    }                                     
     
    Verification
     
    In this case, the ROA table is very short
     
    >show validation database 
       
    RV database for instance master
     
    Prefix                 Origin-AS Session                                 State   Mismatch
    10.0.0.0/16-19                20 12.1.1.6                                valid  
    10.0.0.0/19-24                 2 12.1.1.6                                valid  
     
      IPv4 records: 2
      IPv6 records: 0
     
    And the routes in BGP:
     
    >show route protocol bgp     
     
    inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
     
    10.0.0.0/16        *[BGP/170] 00:45:53, localpref 110
                          AS path: 200 20 I, validation-state: valid
                        > to 10.1.1.2 via em1.0
    10.0.0.0/24        *[BGP/170] 00:42:58, localpref 9
                          AS path: 200 20 I, validation-state: invalid
                        > to 10.1.1.2 via em1.0
    13.1.1.4/30        *[BGP/170] 3w1d 17:34:46, localpref 100
                          AS path: 200 20 I, validation-state: unknown
                        > to 10.1.1.2 via em1.0
     
    As you can see, 10.0.0.0/16 matches with a ROA and it is valid. 10.0.0.0/24 is invalid because the ROA says that the origin must be ASN, and now it is originated by ASN 20. The route 13.1.1.4/30 is unknown because there is no ROA matching it.