Mark wrote: > So what is the validator's role in this decision-making? Nothing [*].
> My IOS XR boxes have accepted the route for installation. It's not about 194.45.182.0/23. It's about 194.45.182.0/24 and 194.45.183.0/24. These should be -according to RFC6907- considered as invalid, not as unknown (what JunOS currently does). Cisco XR might consider 194.45.182.0/24 as unknown or in- valid (?), but 194.45.183.0/24 as valid (as within the AS_SET an AS is listed, for which a matching ROA exists) [source 7018]. The consequences on JunOS: Easy bypassing the validation mechanism (and even works for more specifics, which you can't do by just "spoofing" the origin AS). Checking lg.seacomnet.com I see both /24 accepted as with "RPKI State not found". Markus [*] Well, the validator should - beside validating the ROAs - as well ensure, that the <prefix,max-length,originAS> are "reasonable" ... ever fed <1.2.3.0/24,23,1> via rtr to JunOS (max-length > prefix mask)? Another "hope there will never be published ROAs passing through validators causing similar effects" (JunOS simply takes the rtr session down when seeing such records via rtr). -- AS286 - for the time being ... _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
