Showing T05: OV: Scenario3, I-Invalid, I-Unknown

Owner sspies
Date created 2011-06-09 17:39:02 UTC

Test Description

Intention

This test checks, if an IUT (Implementation Under Test) can
  • re-validate prefix/origin pairs of incoming BGP announcement Updates according to RPKI/RTR whitelist entries, which are announced afterwards
  • can still operate the acceptance policy (ignore-invalid, ignore-unknown) correctly, when the validation state of prefix/origin pairs changes
  • can fulfil both above, if ROA2 is replaced by ROA2_repair (6.0.0.0/16, OAS6) and ROA4 is replaced by ROA4_repair (11.0.0.0/16-24, OAS11)
within the following requirements, dataset and scenario 3

Requirements

  • Policy
    Ignore prefix/origin pairs of incoming BGP announcement updates
    if their validation state is INVALID or UNKNOWN.
  • Cache to Router
    It is expected that the implementation under test will send a "Query Request" message within 60 seconds of the receipt of a "Notify" message.
  • Policy
    Do not execute any other policies on incoming BGP Updates and do not change the default BGP best path selection algorithm.

Dataset

Scenario 3 and Expectations according to ignore-invalid, ignore-unknown

  • t0: Send all BGP Updates
  • Implicitely do not expect to receive any Updates
  • t60: Send all ROAs as whitelists
  • t60-120 Goal "Valid Updates": Expect to receive announcements for all green BGP routes.
  • t120: Remove ROA2 and ROA4 as whitelists
  • Implicitely do not expect to receive any Updates
  • t180: Add ROA2_repair (6.0.0.0/16, OAS6) and ROA4_repair (11.0.0.0/16-24, OAS11) as whitelists
  • t180-t240 and if "Valid Updates" success
    Goal "New Valid Routes": Expect to receive announcements for the BGP routes (6.0.0.0/16, OAS6), (11.0.0.0/16, OAS11), (11.0.0.0/20, OAS11) and (11.0.0.0/24, OAS11)