Re: [RPSEC] some thoughts on requirements

[Stephen Kent <kent at bbn.com>]

At 12:25 AM +0100 2/4/05, Stefan Mink wrote:
> Stephen Kent wrote:
>
> > agreed: securing route origination is just part of the solution.
> >
> > we need to define what is and is not an "authorized" advertisement, 
> > so that any advertisements that are not authorized can be rejected 
> > and thus avoid the problem you cite.  But, if we can't characterize 
> > what is and it not authorized, other than by saying "whatever ISPs 
> > agree to" then we don't have a good basis for putting into place 
> > mechanisms to allow ASes to detect and reject bogus advertisements.
>
>
> we would need the same as for origin verification: a database where
> the policy between two connected ISPs is stored, which is signed
> by both, so you can verify its authentic.
> RPSL contains some elements, but  it does not go far enough:
> it does not contain the reannouncement scope of a route, just
> who gets which routes.

verifying origin ASes can be done reliably based on the simple, tree 
structured allocation structure that is used for handing out and 
transferring prefixes. the folks who have to "sign off" are 
authoritative for the data i question.

I don't know if it is sufficient to have pairs of peers sign off on 
what their intent is re pairwise authorization to propagate routes. 
collusion between two peers, combined with a liberal interpretation 
of what constitutes legitimate route origination, might allow 
propagation of a lot of bogus routes. only if we impose stringent 
constraints on who can originate routes based on "implicit 
aggregation" might this be technically sound.

also, I've been told that some (many?) ISPs consider local policy 
data to be private and might be reluctant to share it. Or do you 
think that this more limited aspect of local policy is sufficiently 
benign to not be a concern?

Steve

_______________________________________________
RPSEC mailing list
RPSEC at ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec