Re: [sidr] BGPSEC Threat Model ID

[Brian Dickson <[e-mail]>]

On Wed, Nov 2, 2011 at 12:32 PM, Russ White <[e-mail]> wrote:
>
>> (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.

Trust policy is necessarily per AS. Routing policy is de facto per route.
Each prefix will be independently signed, so it follows that including other
parameters in the signature is not unreasonable. It does not change the
number of signatures needed, only the size of the blob being signed,
and generally speaking marginally.

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

Signed.

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

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

Correct. And given that there exist malicious use cases for violating implicit
policy, it makes sense that it be addressed in conjunction with BGPSEC.

The particulars on how to implement marking and enforcement are important,
and there are pros and cons to the variety of ways of doing this.

However, the high-level semantics can be captured easily, on a per-prefix,
per-peering basis:

"You're not my transit provider"
vs
"Please be my transit provider"

Perhaps this would best be done as a BGP Option negotiated on a
peering session, in each direction:
"Transit Requested" / "Transit Offered"

(In the oddball case of mutual transit, both flags would be set in
both directions).

Even if there isn't enforcement of behavior per se, the ability to
view the asserted policy
on a per-AS-hop basis allows for local receiver filtering based on the
presence/absence
of such a flag bit anywhere in the path, per-prefix.

Having the bit signed by the Sender (as part of the signed data, that
is) means that anyone wishing
to honor the sender's intent, is able to do so automatically.

(There are two options - enforce behavior per AS hop within the
protocol, or expose the per-hop values.
The latter is more robust, protecting against malicious
implementations as well as poor configurations.)

Brian