Showing T15: OV: ROA Parent Prefix Revoked,New ROA DiffAS,I-Unknown, I-Invalid

Owner okim
Date created 2011-11-14 21:11:35 UTC

Test Description

Same as test OV:ROA Parent Prefix Revoked,New ROA Diff AS,Ignore Invalid, but used the different policy - to accept "valid" only.

Requirements

The IUT MUST be configured to accept "valid", and ignore both "unknown" and "invalid" validity state of a received route (i.e., a prefix and an originAS) for further process. Here, the ROA is defined as "data record" received by the IUT from a RPKI Cache.

Test data

Scenario and Expectations

  • 00:00 - BRITE cache sends two ROAs (data records) to the IUT:
    • ROA 2 [10.10.0.0/20,24,AS30]: ROA for covering prefix (i.e., super prefix) with maxLength.
    • ROA 3 [10.10.0.0/24,24,AS30]: ROA for end-entity prefix with no maxLength (or prefix length is equal to maxLength).
  • 00:01 - The following BGP Updates are sent to the IUT:
    • Update 2 (10.10.0.0/20, AS30)
    • Update 3 (10.10.128.0/20, AS30)
    • Update 4 (10.10.0.0/24, AS30)
    • Update 5 (10.10.15.0/24, AS30)
    • Update 6 (10.10.128.0/24, AS30)
    • Update 7 (10.10.0.0/24, AS20)
    • BRITE expects to receive three Updates (Updates 2, 4 and 5) from the IUT.
  • 00:02 - BRITE revokes ROA 2 and later receives WDs for Updates 2 and 5. The IUT changes the validity state of of Updates 2 and 5, which became "unknown" from previously "valid" and announces Updates 2 and 5. Update 4 is still valid since the exact match ROA exists.
  • 00:03 - BRITE sends ROA 5, the previously revoked ROA with different AS. The IUT performs the following:
    • Announces Update 7, the previously "invalid" route, which became "valid".
    • Changes the validity state of Updates 2 and 5, which became "invalid" from previously "unknown" and have already been withdrawn.
  • 00:04 - Test ends.