Re: [Sidr] adoption of draft-huston-sidr-roa-validation-00.txt as a working group work item

[Jeffrey Haas <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr