Showing T15: OV: ROA Parent Prefix Revoked,New ROA DiffAS,I-Unknown, I-Invalid
||2011-11-14 21:11:35 UTC
Same as test OV:ROA Parent Prefix Revoked,New ROA Diff AS,Ignore Invalid,
but used the different policy - to accept "valid" only.
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.
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
- 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.