WG chair hat off
On 17/11/2008, at 10:28 AM, Danny McPherson wrote:
On Nov 14, 2008, at 1:07 PM, Geoff Huston wrote:
A good example for me in thinking about this has been the YouTube
hijack at the start of this year. A salient question I asked myslef
was: what mechanisms could YouTube have used to alert relying
parties to the unauthorised advertisement of more specifics from a
different origin AS?
ROAs alone are not a good answer here, in that a ROA does not say
what is bogus.
But does the existence of a ROA, with origin authorization not
make this implicit enough?
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?
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.
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.
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.
The only way that ROAs can do this is when a relying party is
justified in assuming that _absolutely everything_ is covered by a
ROA. In a world of incremental deployment this assumption does not
hold, and therefore the absence of a ROA conveys no information at
all.
In this case BOAs can assist. Lets say that MeTube has published a
ROA to allow 10.1.0.0/16, max length=16 to be advertised from
origin AS 1, and a relying party sees an advertisement for
10.1.1.0/24 originating from AS 2 (a hijack attempt). In this case
the relying party has no grounds to assume that the /24
advertisement is bogus, and will accept the advertisement and the
hijack will be effective. But what if MeTube also published a BOA
for 10.1.0.0/16 at the same time as the ROA. Now as a ROA "trumps"
a BOA then any advertisement for 10.1.0.0/16 with an origination of
AS 1 will be regarded as valid by a relying party, while any other
use of 10.1.0.0/16 or any more specific will be regarded as bogus.
So wouldn't this mean that in the current model everyone would publish
ROAs and BOAs? Do we really want that? Perhaps I'm missing something
here?
Well if relying parties could safely assume that _everyone_ was
publishing ROAs then there would be no need for BOAs as the absence of
a positive authority in the form of a ROA could be reliably inferred
to be unauthorized. But in a world where that assumption does not
hold, and where there is incremental partial deployment of publication
of these origination credentials, when relying parties cannot assume
that the absence of a positive authority means anything at all. All it
means is that if the route object matches the ROA then its been
authorized by the prefix holder. But if there is no matching ROA then
the relying party cannot assume anything at all.
The problem here is similar to the problem of filter generation: There
is a qualitative difference in these two statements:
"I give my authority for AS 1 to advertise a route object for
10.1.0.0/16"
"I give my authority for AS1 and only AS1 to advertise a route object
for 10.1.0.0/16"
If you want the second statement, then we either need to change the
ROA to offer closure ("i.e. include "any only") or introduce a new
object that allows the authorizing party to state the "and only" part
explicitly). I contend that leaving this part of the authority as
something implicit that relying parties may or may not choose to infer
from the authority is a compromised model, imho.
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.
regards,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
