Chiming in a bit late after catching up on other IETF tasks: On Fri, Apr 04, 2008 at 09:46:29AM -0400, Sandra Murphy wrote: > This internet draft was presented at the sidr meeting in Philadelphia. > Please state whether you believe that this is appropriate to adopt as a > working group work item.
Like Steve, I would support this work, either independently or incorporated in the core ROA work. My personal preference would be that some form of this work is incorporated into the core ROA drafts. A few comments on the draft while I'm in here: : [Note: If the origination of the prefix is an AS Set then ??. The : draft authors do not have a clear idea as to what to propose here!] I would suggest text proposing that the validation process is doomed. Given the typical aggregation strategy chosen by current BGP implementations, one is almost never guaranteed a trailing AS_PATH that includes AS_SEQs despite the fact that the protocol will happily permit such a thing when it makes sense. Any reasonable mechanism for dealing with validation of aggregates would likely require changes in BGP code. I'm happy to speculate on such changes, but in a different thread. Personally I think the gain is minimal and we should focus our efforts on the 99.99% of the routes that don't have this issue. : In this case the ROA that would be used for the validation function : is selected from the set such that the most specific valid ROA that : matches or covers the route object address prefix and where the route : object origin AS matches the ROA AS. If there is no such ROA in the : set, then the most specific valid ROA is selected. If there is no : such ROA in the set then the most specific ROA is selected. There is one other case potentially worth mentioning although the authors may consider this a case worth disregarding. In the instance where no valid certificates are available due to *expiration* rather than revocation, an implementation may choose to add this to the candidate list of validation criteria as "better than unvalidated". The match criteria suggested in this draft, after all, provides good inputs to the "security metric" that we've previously discussed here and in RPSEC. With regards to the linked approach, I'm in favor of this mechanism in the referral form. Such a referral can likely be highly compressed - perhaps of the simple form of "repository ip:repository version". Something more general than a repository ip - perhaps a handle - would likely be more important given the desired distributed and replicated nature of the repositories. In section 3, Applying Validation Outcomes to BGP Route Selection, there is some strong suggestion of using BGP local preference for reflecting the "security metric" within the AS. I think this is a fine idea for reflecting a "valid" or "semi valid" or "probably not valid" granularity but I think it is overly strong for the "valid but covering" case. If a prefix is valid, it shouldn't be less preferable simply because it is covered differently by different ROAs. This is especially true in a deployment where multiple validation roots are present for whatever reason. These local preference tweaks also need to be affected by local policy. Doing so would reflect the general idea of a "security metric" from the original RPSEC discussions. Reflecting the security metric in LOCAL_PREF is a nice touch since it means that validation need only happen at the eBGP edges. In section 3.1, Using ROA Validation Outcomes to reject BGP advertisements, you may wish to differentiate the case of the linked and non-linked approach with regards to validation. In the linked case, there is sufficient information present that you could indeed reject a route if you can: 1) Reach the repository 2) Have a current enough version of the relevant objects 3) Know it is invalid. Open issues: : o When should validation of an advertised prefix be performed by a : BGP speaker? Is it strictly necessary to perform validation at a : point prior to loading the object into the Adj-RIB-In structure, : or once the object has been loaded into Adj-RIB-IN, or at a later : time that is determined by a local configuration setting? Should : validation be performed each time a route object is updated by a : peer even when the origin AS has not altered? I think validation could be accomplished at any step of the for a given AS. Downstream ASes will also perform their own validation and may choose to depref a route you have deferred security preference selection on during the distribution process. Ideally, one would do this prior to installing the route in the adj-rib-in. Less ideally would be to install the route but make it ineligible pending near-line validation. Even less ideal would be to advertise the route internally with a security preference that says "validation pending, trust this less than validated routes". Given the lack of additional cryptographic signatures on the BGP route, I believe no additonal validation is required when the prefix/Origin remains the same as long as it is within the window of validity of the ROA. In particular, given such lack, this would constitute a valuable caching mechanism. To whit: : o Can ROA validation be performed on a per-AS basis rather than a : per-BGP speaker? What BGP mechanisms would be appropriate to : support such a mode of operation? Again, presuming no additional cryptographic changes to the BGP route, absolutely. Validation of a BGP route reduces to a simple function: (Security Preference, Valid Until) = ROA_Validation(Prefix, Origin AS) Note that some implementations may choose to add properties relating to the interface or AS from which the route is learned as inputs to the function. This calculation can be done locally or via some RPC mechanism. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
