Anyone notice strange announcements for 174.128.31.0/24

Tue Jan 13 18:20:48 UTC 2009

On Jan 13, 2009, at 1:11 PM, David Barak wrote:
> --- On Tue, 1/13/09, Patrick W. Gilmore <patrick at ianai.net> wrote:

>>>> 	Personally, I would be upset if someone injected
>> a route
>>>> with my ASN in the AS_PATH without my permission.
>>>
>>> Why?  Is this a theoretical "because it's
>> ugly" complaint, or is there a reason why manipulating
>> this particular BGP attribute in this particular way is so
>> bad?  Organizations do filtering and routing manipulation
>> all over the place.  Is there something worse about doing it
>> this way than others?
>>
>> Filtering and other manipulation happened on your router,
>> prepending my ASN is putting that information into every
>> router.  That seems to be a serious qualitative difference
>> to me.  Do you disagree?
>
> This is qualitatively similar to an ASN announcing de-aggregated  
> routes - it may be nice if they don't, and you don't have to accept  
> them, but are they permitted?

No it is not.  You own the prefix in question, so you own the  
deaggregates of it.  You do not own the ASN in question.

That you do not see the difference explains a great deal.

>> This thread has been interesting & educational.  So
>> many people seem to be happy to explain why they should be
>> allowed to use globally unique identifiers they do not own
>> in ways which were not intended, then explain to the people
>> who do own those identifiers how they should react, which
>> alarms should go off, and even which priority the alarms
>> should have.
>>
>> As I have repeated probably hundreds of times: Your
>> network, your decision.  I have yet to hear a credible
>> argument against that stance.  What you do _inside_ your
>> network is _your_ decision.  When it leaves your network,
>> however, things change.
>
> Exactly!  Provider RB announces $WEIRD.  A bunch of providers  
> receive alarms about the existence of $WEIRD, and they treated this  
> as $IMPORTANT.  The bunch of providers who treated this as  
> $IMPORTANT are informing all of us about their monitoring thresholds  
> and their responses to this threshold being met.  Their networks,  
> their decisions.

Wow.  Just .. wow.

"Exactly, even though I do something with your resources, announcing  
to the whole world, that cause you issues, you shouldn't tell me about  
because the alarms are inside your network."

Again, this explains a great deal.

> It should be pointed out that pre-provisioned AS_Path filters and  
> prefix-lists would actually be effective at defeating this and  
> preventing someone who is actually malicious from using this  
> technique.  This is an excellent argument for implementing SIDR...

Finally we agree.  Although I am not certain SIDR is the optimal  
answer, we agree it would solve the problem.

>> Announcing an ASN which is not yours to eBGP peers means it
>> is leaving your network, which means it is not just your
>> business.  Doing so and then telling the ASN owner that they
>> should not worry about it afterwards - and in fact arguing
>> when the owner repeatedly tells you this caused them
>> problems - does not seem to be the proper course of action.
>
> Understood, but if this is viewed as problematic, there is a very  
> simple solution: don't allow a BGP customer (or peer!) to prepend  
> someone else's ASN.

How do you suppose I stop Randy from prepending my ASN?

-- 
TTFN,
patrick