BGP Security Research Question

Tue Nov 4 13:34:52 UTC 2014

On Nov 4, 2014, at 8:00 AM, Nick Hilliard <nick at foobar.org> wrote:

> On 04/11/2014 12:38, sthaug at nethelp.no wrote:
>> These mechanisms do little or nothing to protect against unauthorized
>> origination of routing information. There are plenty of examples which
>> say it has *not* been enough, see for instance the Pakistan Telecom -
>> Youtube incident in 2008.
> 
> mis-origination and related problems are all policy problems rather than
> technical transport issues.  Policy implies human input at some stage along
> the chain, so probably the only way we'll ever see the end of unintended
> prefix leaks is to completely eliminate human input in all aspects of
> routing policy management.
> 
> Nick

I see a distinction between policy and authorization.

Policy is something the ISP decides for themselves - "I make my own routing policy as to what is my best path".

BGP was created to make it possible for operators to have that policy decision.

Authorization is something else.

Prefix holders want to say "I authorize the origination of this prefix".  Operators can decide to enforce that authorization in their policy or not, but at least the prefix holder gets to make the determination of what is authorized.  (See IRR route objects, RPKI ROAs)

There are those who call route leaks an authorization problem.  [[[I think.]]]]  They want to be able to say "I authorize my neighbor to propagate this announcement with the following constraints (no peers, no transit, customers only, etc)."  [[[I think.]]]  Again, operators could decide to enforce that authorization in their policy or not, but those wanting to stop route leaks want to make the determination of what is authorized.

Policy is local.

Authorization is global.  (And so it relies on global access to a statement of the authorization, aye, there's the rub.)

--Sandy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20141104/5163b394/attachment.sig>