Geoff Huston wrote:
"I give my authority for AS1 and only AS1 to advertise a route
object for 10.1.0.0/16"
Does the ROA format already permit this or would it require a modification?
If you allow this, what about a subprefix,say, 10.1.0.0/24?
Would that be precluded from having a ROA with a different AS?
Sriram
Quoting "Geoff Huston" <[EMAIL PROTECTED]>:
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
