Re: [sidr] BGPSEC Threat Model ID

[Russ White <[e-mail]>]

> (4b) It follows that there is no reason not to trust all Transitive
> values set by Originator, and Signed by the Originator

It does not follow. Policy is per AS, not per route or destination.

> (4c) It also follows that Non-Transitive values could be set by one's
> Neighbor AS, signed by that AS, and have those values Secured.

Can you define "secure" here?

> (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.

>> How does BGP indicate (i.e., where are the bits that say) that the Update
>> sent to E is not to be propagated to another ISP?  I've been told that the
>> NO_EXPORT community does not have the right semantics, and that network
>> operators do not pay attention to this anyway.
>>
>> And it's most certainly a threat and one that some consider
>> out of scope at that?
>>
>> I presume that you mean in scope, right?
> 
> I believe what Danny was saying is, "some consider this out of scope",
> where "some" means at a minimum the authors of the Threat document,
> and that since it is a threat, it really should be *in* scope.

Maybe there's a reason for this particular capability not existing
within BGP. Perhaps it is because it's always been recognized that
transmitting reachability is routing, but failing to transmit
reachability that exists because you don't want someone else to use it,
or --even more-- asking someone you send reachability information to not
to forward that reachability information --is a matter of policy.

The failure to define and separate policy from routing has caused a
great deal of confusion within the BGP security space over the years.

Russ