Re: [sidr] BGPSEC Threat Model ID

[Brian Dickson <[e-mail]>]

On Fri, Nov 4, 2011 at 12:49 AM, Christopher Morrow
<[e-mail]> wrote:
> (coming in late to the party, weee!)
>
> On Wed, Nov 2, 2011 at 1:08 PM, Brian Dickson
> <[e-mail]> wrote:
>>>> (5) If any BGP path attribute used in Path Selection is not signed,
>>>> then BGPSEC has failed to meet its charter requirements.
>>>
>>> Then MED and Local Pref must also be signed, along with a number of
>>> communities, and even the next hop.
>>
>> Yes.
>
> err, so... you receive a route update from AS1 at AS2, it looks roughly like:
>   1.2.3.0/24 nh = 192.168.1.1
>  this is signed (all of the above data)
>
> When you pass this route off to AS3 you do so as:
>   1.2.3.0/24 nh = 10.1.1.1
>  the nh changed, the sig originally is for 192.168.1.1
>
> Did you really mean to sign the next-hop? it seems infeasible...
>
> Also, LocalPref is a locally used/determined/created (non-transitive)
> item, adding that set of bits into the signature seems blatantly
> wrong, since the data won't exist when you pass the route outside your
> ASN the verification is going to fail, for every route you send (which
> had a localpref != default), That CERTAINLY seems like something you
> would want to avoid, right?

Er, on non-transitive items like LocalPref, there is a use case for signing
them iff the iBGP elements are decided as being in-scope.
(I agree with Danny on this being worth considering.)

What we are discussing is the threat model, and how threats could be
countered.

This in turn is used to inform the design of the protocol, not vice versa.

So, when I say "signed", what I was thinking of was something along the lines
of a sequence of  blocks that might look something like:
LocalBGPPerHopData
signature(LocalBGPPerHopData|previousSignature)
and after all those blocks,
originatorSignature(FirstHopData|RPKI-validatable-data)

The stack gives a history of transitive and non-transitive values,
some of which won't be used for local policy decisions per se, and some of which
can quite reasonably have been changes at each hop. The signatures protect
that data.

How the protected data itself is used is local policy, for selecting best path.
This is more information than vanilla BGP has, of course, but arguably allows
for better path selection by virtue of more data being available locally.

Note that nothing is present than is generally known through various
data sources,
including local BGP tables, looking glasses, routeviews/Renesys, traceroutes,
whois, RADB/IRR, RIRs, reverse DNS etc.

Adding this "stack" allows for other aspects of local policy to be
marked into the path,
including markers suitable for preventing route leaks.

It also means that non-transitive values can magically become pseudo-transitive,
presuming the cruft that permits constructing local policy can be made
to understand
the association between AS-path hops and the captured policy at those hops.
(This is a feature, not a bug.)

The signatures make it possible to reject changes to this stack of
path-historical data.
The data makes it possible to choose to use the originated values, the
latest values,
or anything in between, however one chooses.
The requirements to continue adding to this stack ensures the next AS
to which the
prefix is sent, has the same opportunity to apply local policy.
Add a dollop of 'transit/non-transit' at each hop (mandatory but
arbitrary), and simple
leak-blocking (nearly fool-proof, in fact) is possible to support.

Brian