WG Chair hat off
On 14/11/2008, at 9:58 PM, Andy Newton wrote:
George,
I do not follow your argument. Yes, I understand using the BOA to
restrict
everything and using more specific ROAs to specify valid IP space.
What I
don't understand is how that helps partial deployment. In fact,
doesn't
this make necessary full deployment? If a major provider blankets
their
space with a BOA, then all the downstreams MUST be covered by ROAs.
Or did
I miss something?
The problem with a model of using only ROAs is that while the presence
of a ROA that matches a route advertisement can provide the relying
party some level of reassurance that accepting the route matches the
intentions of the originator, the absence of a corresponding ROA for a
route object tells the relying party absolutely nothing. The only way
the absence of a ROA can be interpreted by a relying party is by
forcing the relying party to make an assumption about the state of ROA
use.
One possible answer is that relying parties simply assume that ROAs
are universally used and any and every route object that does not
match a currently valid ROA is discarded. I trust you would agree that
this would be an unwise assumption for a relying party yo make. In a
world of incremental deployment where only a few prefix holders are
generating ROAs this assumption would effectively cause a relying
party to reject all of the (valid) routing table with the exception of
the set of objects covered by ROAs. Not good. Even in a world of
comprehensive deployment this would be an unwise move. Because prefix
holders essentially publish their own signed objects in a repository
of their choosing, relying parties, if they wish to avoid using the
services of RPKI aggregators or middle-agents will need to access wach
and every repository in order to collect the ROAs and the necessary
certificate material that is required to validate each ROA. But what
if the ROA for a prefix is contained in a repository that is located
at an address that is described in the ROA. i.e. you can't get the ROA
until you treat the corresponding route object as valid, and you can;t
treat it as valid until you have the ROA.
The other option is that the relying party assumes that ROAs are not
universally deployed, and that implies that a relying party must
assume that there exists valid route objects for which there is no
corresponding ROA. In a world of partial deployment where a relying
party has no idea whether the absence of a ROA indicates an attempted
routing hijack of the simple absence of a ROA, then the relying party
really is no better off than if there were no ROAs whatsoever!
So how could this situation be improved for relying parties?
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. 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, as far as I can tell, BOAs are a simple and effective mechanism to
allow relying parties to detect attempts at origination hijack even in
a world of partial use of origination attestations - i.e. they meet
the criteria of the RPSEC document relating to incremental deployment,
as referenced in George's message, without relying on comprehensive
ROA deployment.
Andy, your example is somewhat different, because you posit the
existence of some intermediate IR that has issued portable address
space to clients of the service and allows the clients of this space
to independently announce their address space. In this example your
comment was that if the IR blankets the space with a BOA then that
forces the clients to use ROAs to have their independent routes
treated as valid, if I have got this right. Yes, that would be the
case, and if the IR did not want that outcome then the IR should not
issue a BOA in the first place. On the other hand if the IR, being a
major provider, had a policy that all space allocated by the IR was
NOT portable address space, then the BOA would be a means to announce
that provider-dependent routing policy to all others in the inter-
domain routing cloud.
What I don't see in this example is the leap from this case to the
conclusion that the potential for prefix holder to publish BOAs
necessarily implies that prefix holders are _all_ forced to publish
ROAS, i.e. I don't see how you get to the assertion that "this make[s]
necessary full deployment" (Where I interpret "full deployment" as the
situation each and every prefix holder that authorizes routes in to
the inter-domain routing space is required to publish a ROA.)
And who is to be in the business of publishing trusted BOAs for
bogons?
Seems to me that it would be fraught with peril if they screw it up.
Only the certified holder of an address block can generate a BOA. So I
suppose the answer to your question would depend on your preferred
interpretation of what is a "bogon".
But then, it is early and the
coffee hasn't kicked in.
ditto.
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
