Re: [RPSEC] BGP Security Requirements v08

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Tony Tauber writes:
>  
>  
> What meaning a receiving AS might assign to a partially authenticated
> piece of data is left up to that AS (keeping in the spirit of autonomy).
>  
> Certainly one can envision an attack which exposes the authenticated
> origin info but which nefariously removes intervening hops to draw in
> traffic improperly (e.g., to inspect, alter, or drop).


You could imagine that but ...

The major ISPs have important major customers and peer.  For example
they would not want their routing corrupted by a bad route to a major
content provider.  Therefore many major providers will only accept
these major customer and peer routes from a very limited set of ISPs.

In order to get a short enough AS Path to have an effect on those
routes, you'd need to first break into the ISP infrastructure.

Then there are routes farther away.  For example, a few AS hops might
be required to reach a destination in Europe from the US.  If the AS
in between have both secure infrastructure and reasonable route policy
for any major European customer or peer the same situation exists.

This is why in theory a man-in-th-middle could inject bad information
but in practice it can't happen for most "important" routes (ones that
the ISPs consider most important because they are big paying customers
or having bad routes to them would be a significant disruption and
embarasement).

Add some authentication and you may have further improviment in the
reliability of routing information.  Don't allow that to cross the
major ISPs and the authenticaion is of very little use for ISPs.

A small ISP in the far reaches (less developed world, for example) may
get better connectivity and immunity from injection of bad routing
information for their own routes if they provide authenticaion on
routes they originate, register their routes for policy verification
by other ISPs, and check authentication and registration of routes
they receive.  The standard routing and security hygene also applies.


> > >I believe that you are arguing whether solutions should be REQUIRED
> > >to provide benefit when island hopping.  And Curtis is arguing that
> > >they should, because otherwise incremental deployment will be very
> > >very unattractive.
> > >
> > >The choices seem to boil down to MUST or SHOULD.
> > 
> > Or a MUST/SHOULD vs. MAY.
>  
> Right, based on the discussion thus far, I was leaning toward keeping
> the idea in as a MAY.  One might argue that doing so is effectively the
> same as leaving it out altogether, but the intention and information is
> retained.  Beyond that, asserting it as a "MAY" explicitly blocks any
> interpretation which ends in "... NOT".
>  
> Tony


The MAY or SHOULD words MUST apply only to decisions regarding
deployment (MAY use some featured, SHOULD use some feature, MAY or
SHOULD pass some information ...).

In the requirements the word MUST has to be applied to protocol
definitions and protocol implementations or at the very least a SHOULD
with very strong emphasis.

Curtis


_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec