Re: [RPSEC] BGP Security Requirements v08

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Sandy Murphy writes:
>  
> Curtis writes:
> >In message <p06240507c2c167b442a1@[128.89.89.71]>
> >Stephen Kent writes:
> >>  
> >> I think the question is why, if the path info received by an "island 
> >> AS" has a number of unverified hops, is this path info useful, in a 
> >> security sense, to the AS that receives? How does the requirement to 
> >> send such info promote adoption of the protocol?
> >>  
> >> Steve
> >
> >
> >Because it is likely to be more reliable than information with no
> >authentication at all.
> >
> >The major ISPs are fairly reliable at getting their internal routing
> >right so if the non-authenticating routers in the middle are entirely
> >in a set of ISPs that are known to generally not have breakins into
> >their own infrastructure.
>  
> Curtis, I'm not sure exactly what you mean here, but Steve was talking
> about AS hops, not router hops.  I *think* that's what you mean, also,
> but I'm not sure.

What I meant is that 1) major ISPs do a very good job of filtering
customer routes and not originating bogus information into the global
BGP routing and 2) major ISP security is good enough that it is very
hard for an attacker to inject BGP information into an ISP from within
the ISP's own infrastructure.

That Internet routing for the most part works is partially due to the
above and that places where this is not true are enough AS hops away
from the major ISPs that bogus information is localized to those far
reaches that may be a little behind on the operations learning curve.

> Steve, I strongly believe that incremental deployment scenarios WILL
> include cases where non-upgradable ASs will be provided with other,
> operational or algorithmic, protections, so that ISPs in the know will
> trust paths that come to them from those ASs.  I am less strongly
> convinced that incremental deployment scenarios MUST include such cases.
> But I see no way to provide benefit in incremental deployment otherwise.
>  
> I do not think that you are saying that solutions COULD NOT provide
> benefit when island hopping.  The work being done in the sidr wg
> (to provide an infrastructure that would provide authorization for
> prefix origination) would be an example of protections that would
> still provide benefit when island hopping, as the origin authorization
> check is of value no matter how many clueless ASs touch the UPDATE.
>  
> 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.
>  
> --Sandy

IMO if we are down to SHOULD and MUST:

  The protocol MUST support a mechanism ... [to connect islands, sic]

  The protocol MUST keep authentication information reasonable small.
  If that information needs to be large in order to be robust, then
  the protocol SHOULD provide an alternate smaller digest that is less
  likely to get tossed.

  ISPs SHOULD try to pass information to non-authenticating peers.

  ISPs SHOULD prefer information from a subset or trustworthy
  non-authenticating peer AS with partial authentication covering all
  less known AS over information where untrusted non-authenticating AS
  are in the path.

  Non-authenticating AS should pass the authentication information
  unchanged unless doing so is infeasible due to router memory
  constraints.

This needs rewording but I hope its clear enough for discussion.

Curtis


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