Showing T14: OV: ROA Parent Prefix Revoked,New ROA SameAS,I-Invalid
||2011-11-14 21:10:19 UTC
Same as test OV:ROA Parent Prefix Revoked,New ROA Diff AS,Ignore Invalid,
but the ROA is renewed with the same AS as that in the previously revoked ROA.
The IUT MUST be configured to reject "invalid", and to accept both "valid"
and "unknown" 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.
At the beginning of the test, two ROAs (a more-specific ROA and a covering ROA)
and 6 Updates (see below) are sent to the IUT.
A covering ROA is revoked and later renewed with the same AS as that in the previously
revoked ROA to see how the IUT handles the revocation/renewal of a covering ROA.
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 five Updates (Update 2-6) except an invalid route, Update 7, from the IUT.
- 00:02 - BRITE revokes ROA 2 and expects to receive no WDs or Updates. The IUT is expected
to change the validity state of the previously "valid" routes to"unknown" (Updates 2 and 5)
and sends no WDs or Updates.
- 00:03 - BRITE sends ROA 2 again. The IUT changes the validity state of previously "unknown" routes
to "valid" again (Updates 2 and 5) and sends no WDs and ANNs.
- 00:04 - Test ends.