Showing T18: OV: ROA Grandarent Prefix Revoked,New ROA Same AS,I-Invalid
||2011-11-14 21:14:21 UTC
Same as test OV:ROA Grandarent 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.
Scenario and Expectations
- 00:00 - BRITE cache sends three ROAs (data records) to the IUT:
- ROA 1 [10.10.0.0/16,24,AS30]: ROA for grandparent prefix (i.e., super-super prefix) with maxLength.
- ROA 2 [10.10.0.0/20,24,AS30]: ROA for parent prefix (i.e., super prefix) with maxLength.
- ROA 3 [10.10.0.0/24,24,AS30]: ROA for an end-entity prefix with no maxLength (or prefix length is
equal to maxLength).
- 00:01 - The following Updates are sent to the IUT:
- Update 1 (10.10.0.0/16, AS30)
- 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 six Updates (Updates 1-6) except an invalid route, Update 7, from the IUT.
- 00:02 - BRITE revokes ROA 1 and expects to receive no WDs or Updates. The IUT changes the
validity state of the previously "valid" routes to "unknown" (Updates 1, 3 and 6).
- 00:03 - BRITE sends the previously revoked ROA 1 again. The IUT changes the validity state
of previously "unknown" routes to "valid" (Updates 1, 3 and 6) and sends no Updates.
- 00:04 - Test ends.