Hi Roque, >>> Security Consideration: >>> I think you need to consider what you already mentioned in section 4, if >>> the connectivity to the local-caches is lost, invalid routes will be >>> classified as "not-found", which could have a different set of local >>> policies. >> >> Is this different from current behavior? > > Not sure what do you refer for "current behavior". My point was that in the > security considerations you should point to the analysis in Section 4 on > loosing connectivity to the cache servers. > > Example: > Router set loc-pref 100 for "valid" and loc-pref 50 for "not-found". > If the router looses connectivity with caches, either by operational > issues or by malicious event (on the cache/ the router or the network between > the two), the set of prefixes that should be "valid" based on RPKI will be > classified as "not found" and loc-pref set to 50.
Does the following suffice for the security considerations section? Note the added sentence in emphasis "_Similarly..." Although this specification discusses one portion of a system to validate BGP routes, it should be noted that it relies on a database (RPKI or other) to provide validation information. As such, the security properties of that database must be considered in order to determine the security provided by the overall solution. If "invalid" routes are blocked as this specification suggests, the overall system provides a possible denial-of-service vector, for example if an attacker is able to inject one or more spoofed records into the validation database which lead a good route to be declared invalid. _Similarly, if the connection to the cache is lost for whatever reason, the integrity of the database is no longer maintained. This may result in undesired behavior._ In addition, this system is only able to provide limited protection against a determined attacker -- the attacker need only prepend the "valid" source AS to a forged BGP route announcement in order to defeat the protection provided by this system. This mechanism does not protect against "AS in the middle attacks" or provide any path validation. It only attempts to verify the origin. In general, this system should be thought of more as a protection against misconfiguration than as true "security" in the strong sense. Thanks, - Pradosh _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
