WG Chair Hat _OFF_
Thanks for your comments Danny. I'll interleave some further responses
across this.
On Nov 16, 2008, at 5:25 PM, Geoff Huston wrote:
I assume you are referring to the situation where, for example, a
ROA exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for
10.1.0.0/16 origin AS2, and you are seeing a route object for
10.1.0.0/16 with origin AS 2, yes?
Or perhaps 10.1.0.0/24, sure..
The problem is that as a relying party you can't tell whether the
problem is with the retrieval of ROA objects or whether the route
object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2
was published a few seconds ago, whereas your local cache of ROA
objects was last refreshed a day ago. i.e. everything you have at
hand is valid, the manifests are good, and you are seeing something
that is not oin a locally held ROA, _but_ it is still valid.
This is one of the reasons timing issues need to be considered,
and one of the many reasons people stopped using explicit prefix
filters. The route would be announced, the prefix was dropped,
the filters were updated to support the announcement, but the
route wouldn't be accepted unless the session was reset or a
route re-announcement was triggered. You can imagine how painful
this can be across multiple AS hops.
Entirely true, but I'm not sure where this part of the thread is
leading in terms of the SIDR work in particular.
If there was also a BOA published for 10.1.0.0/16 then as a relying
party you now have grounds to believe that anything not described
in a valid ROA can be regarded as an invalid object. In this case
there is still the issue of time lag, and if the prefix holder had
intended to authorize 10.1.0.0/16 using AS 2 as an origination in
addition to AS1 then it would be incumbent on the prefix holder to
generate and publish the new ROA well in advance of the
advertisement of the new route.
So clearly, the same case holds true for the BOA. If a BOA was
just removed from the repository a few seconds ago but as a relying
party I don't update my "accept policies" because of a problem with
the retrieval of the BOA, it's just perturbing the issue. This could
be especially problematic during natural disasters or other similar
events where a publisher of a BOA can't update a repository or it
can't be accessed by a relying party, and therefore, route changes
that are common during those events can't happen.
yes - part of the underlying consideration is the manner in which the
validation information is propagated in relation to the route object -
in this model the validation information is in terms of the contents
of rpki publication point repositories, as distinct from attaching the
validation information to the route update itself. This is what is
referred to in the roa-validation draft as a distinction between
"decoupled" validation, as compared to "linked" validation. There are
relative timing issues in the decoupled model, of course.
Of course there is also the other case where AS 1 insists on a ROA
as a precondition for originating the route, and AS 2 does not, and
the prefix holder performs only what is required and no more. In
this case both routes are valid, but only one as a ROA. In tis case
the problem is not one of timing at the relying party side, and
will not be resolved by bring the relying party into sync with the
authority publisher.
Yes, I think there are lots of issues of this nature, issues which
BOAs only exacerbate.
I don't see the reasoning which leads to your observation that BOAs
_exacerbate_ the issue. There are much the same as the issues with
ROAs but I don;t see the case that makes the situation worse because
of the addition of these negative attestations in the form of BOAs.
Perhaps an example or two may help me (and possibly others) understand
precisely what you mean by "exacerbate" ?
So the BOA is a way of implementing the RPSEC requirement of being
able to support environments of incremental deployment, where it is
not
assured that everyone is publishing these authorities. Now if you
are of the view that the requirement of devising mechanisms to
support incremental piecemeal deployment is daft or unnecessary,
then perhaps this is a debate that in the IETF context should be
held in the context of the RPSEC WG, as the SIDR requirement here
is one that was gather up from the earlier RPSEC work and generate
mechanisms that met those requirements as stated in the RPSEC
documents.
I'm not entirely convinced of this yet...
fair enough - what might help? worked examples? other perspectives?
Also, Sam had a query about BOAs including AS numbers, and I think
that's a good point. Is the goal for an issue to say AS n can
announce
prefix x, but no one else, that would take one ROA and two
BOAs, right? Why wouldn't that just be done implicitly with a ROA?
The inclusion of the AS number had just a little to do with
origination and probably more to do with the AS path - the semantic
intent of the inclusion of the AS number in a BOA was to say "I'm the
holder of this AS number and I'm not using it in routing at all. If
you see a BGP update with this AS number anywhere in the AS Path then
that's a lie!"
regards,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
