Re: Great Suggestion for the DNS problem...?

[Mikael Abrahamsson]

On Thu, 28 Aug 2008, Brian Dickson wrote:

However, if *AS-path* filtering is done based on IRR data, specifically 
on the as-sets of customers and customers' customers etc., then the 
attack *can* be prevented.


Yes, but I can't do this for everybody else. Doing AS-path and prefix 
filtering (matching that a certain prefix can only be announced by a 
certain AS) doesn't scale in IOS for instance.


We do prefix filtering for OUR customers, but there is no feasable way for 
me to do this for everybody else. I think this needs to be fixed, but it 
involves something new that isn't present today, and I think it needs to 
involve vendors because they need to produce new code to handle it.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Generic network agreement template

[Frank Bulk]

I need to supply a network agreement to a friendly customer so that they can
obtain an ASN from ARIN.  Some of you will mutter that we should have
executed one already, but we still shake on things around here.

Does anyone have a simple, even one-page template of a network agreement
that they can share?  Please e-mail me offline.

Thanks,

Frank

Re: Great Suggestion for the DNS problem...?

[Brian Dickson]

Alex Pilosov wrote:

On Thu, 28 Aug 2008, Brian Dickson wrote:

  

However, if *AS-path* filtering is done based on IRR data, specifically
on the as-sets of customers and customers' customers etc., then the
attack *can* be prevented.

The as-path prepending depends on upstreams and their peers accepting
the prefix with a path which differs from the expected path (if the
upstreams register their as-sets in the IRR).


You are thinking about this specific exploit - which may in fact be
stopped by as-path-filtering. However, that's not the problem you are
solving. Problem is the hijacking. There are many other ways to reinject
traffic closer to victim - will require attacker to work a little harder,
but not really fix the problem. (Think, GRE tunnels, no-export,
no-export-to-specific-peer, etc).



  


Very true. Tying allocations and assignments to ASN-of-origin and 
providing a suitable place
to validate such, for building prefix and as-path filters, would do a 
lot towards further limiting
the ability to hijack prefixes - but only to the degree to which 
providers filter their customers.


And that's only on routes - to say nothing of packet filtering (BCP 38)...


So, if the upstreams of as-hijacker reject all prefixes with an as-path
which includes as-bar (because as-bar is not a member of any customer's
as-set expansion), the attack fails.


What's to stop me from adding as-bar into my as-set? To do what you are
describing, you will have to enforce "export AS-LEFT" and "import
AS-RIGHT" rules on every pair of AS-PATH adjacencies. And I'm not sure if
existing tools can do that - or how many existing adjacencies fail that
test.


  


True, there is nothing actually stopping you from doing this.

However, (and this is both the key, and a big presumption) changes to 
as-sets are the kind of thing
that automatic provisioning tools should alert on, and require 
confirmation of, before updating prefix-lists

and as-path lists based on the new members of the as-set.

While prefixes are routinely added, new transit relationships at a BGP 
level don't happen all *that* often.


The idea isn't just to stop the prefix announcement, it is to trap 
activity that would otherwise permit the

prefix hijack, at the time it occurs and before it takes effect.

The closer this occurs to the hijacker, the more likely it is that 
appropriate responses can be directed at the bad guy,

and with a greater likelihood of success (e.g. prosecution).

The threat alone of such response may act as a suitable deterrent...

As for the filter building and enforcement mechanisms:

The inbound as-path filters need to permit the permutations of paths 
that result from expanding as-sets, but that can
be accomplished unilaterally on ingress, without enforcement beyond the 
immediate peering session. The expansion
is for each as-set behind an ASN, there should be a corresponding 
as-set, and so on... each gets expanded and added to

the expansion of the permitted paths via that ASN. Lather, rinse, repeat.

All filtering is local, although the more places filtering happens, the 
better.


Brian

Re: Great Suggestion for the DNS problem...?

[Alex Pilosov]

On Thu, 28 Aug 2008, Brian Dickson wrote:

> However, if *AS-path* filtering is done based on IRR data, specifically
> on the as-sets of customers and customers' customers etc., then the
> attack *can* be prevented.
> 
> The as-path prepending depends on upstreams and their peers accepting
> the prefix with a path which differs from the expected path (if the
> upstreams register their as-sets in the IRR).
You are thinking about this specific exploit - which may in fact be
stopped by as-path-filtering. However, that's not the problem you are
solving. Problem is the hijacking. There are many other ways to reinject
traffic closer to victim - will require attacker to work a little harder,
but not really fix the problem. (Think, GRE tunnels, no-export,
no-export-to-specific-peer, etc).



> So, if the upstreams of as-hijacker reject all prefixes with an as-path
> which includes as-bar (because as-bar is not a member of any customer's
> as-set expansion), the attack fails.
What's to stop me from adding as-bar into my as-set? To do what you are
describing, you will have to enforce "export AS-LEFT" and "import
AS-RIGHT" rules on every pair of AS-PATH adjacencies. And I'm not sure if
existing tools can do that - or how many existing adjacencies fail that
test.

Re: IP Fragmentation

[Glen Kent]

I understand, but the question is what if they dont?

Or let me rephrase the question.

What do standard implementations do if they send a regular IP packet
(no DF bit set) and receive an ICMP dest unreachable - Fragmentation
reqd message back? Do they fragment this packet and then send it out
again with the MTU reported in the ICMP error message, or is the ICMP
error message silently ignored?

Glen

On 8/29/08, Tony Li <[EMAIL PROTECTED]> wrote:
>
>
> |OK, so what happens if a transit router does not support IP
> |fragmentation
>
>
> All IPv4 routers are supposed to support fragmentation per RFC 1812 (Router
> Requirements), section 4.2.2.7.
>
> Tony
>
>

RE: IP Fragmentation

[Tony Li]

 

|OK, so what happens if a transit router does not support IP
|fragmentation 


All IPv4 routers are supposed to support fragmentation per RFC 1812 (Router
Requirements), section 4.2.2.7.

Tony

Re: IP Fragmentation

[Fernando Gont]

At 08:44 p.m. 28/08/2008, Glen Kent wrote:


I understand that routers usually must send this error only when a
fragmentation is required and they recieve a packet with DF bit set.
However, in this case this router would drop the packet (for it doesnt
support fragmentation) and sending an ICMP error back to the host,
warning it that its packets will get dropped seems to be a better
option.

OTOH, what do most of the implementations do if they send a regular IP
packet and receive an ICMP dest unreachable - Fragmentation reqd
message back? Do they fragment this packet and then send it out, or
this message is silently ignored?


You may want to have a look at this IETF I-D: 
http://www.gont.com.ar/drafts/icmp-attacks/draft-ietf-tcpm-icmp-attacks-03.txt. 
The PMTUD modification described in the draft ships (at least) in 
OpenBSD and NetBSD.


Thanks!

Kind regards,

--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: IP Fragmentation

[Glen Kent]

> >
> I'm not sure how to address the above points since there appear to be some
> incorrect assumptions at play. It all depends on whether the Don't Fragment
> (DF) bit is set in IPv4 and how the source application responds to any
> resulting ICMP error responses (if the DF is set and one of the routes
> requires fragmentation).

OK, so what happens if a transit router does not support IP
fragmentation and it receives a packet which is bigger than the
outgoing link's MTU. Should it simply drop the packet or proactively
send an ICMP Dest Unreachable error (Frag required) to the peer?

I understand that routers usually must send this error only when a
fragmentation is required and they recieve a packet with DF bit set.
However, in this case this router would drop the packet (for it doesnt
support fragmentation) and sending an ICMP error back to the host,
warning it that its packets will get dropped seems to be a better
option.

OTOH, what do most of the implementations do if they send a regular IP
packet and receive an ICMP dest unreachable - Fragmentation reqd
message back? Do they fragment this packet and then send it out, or
this message is silently ignored?

Glen

Re: Revealed: The Internet's well known BGP behavior

[Danny McPherson]

On Aug 28, 2008, at 3:47 PM, Deepak Jain wrote:


We can go into lots of reasons why the Internet runs this way. I  
think we can all agree 1) Its amazing it runs as well as it does,  
and 2) No one has clearly articulated a financial reason for any  
large organizations to significantly change their interconnection  
methodologies over the current BCP [that exceeds the costs of doing  
so].


Until either of those assertions change, the status quo will  
essentially remain.


Well, there's also been a bit of a chicken and egg problem here -
as no formally verifiable authoritative source for who is authorized
to originate what IP address space has ever existed, and until that
happens, you can't secure the routing system.

Fortunately, the RPKI work will address this, and some of the RIRs
are working on RPKI implementations now.  If there are ways the IRRs
can be populated using this information and non-RPKI derived
updates can be considered less preferable (whatever that means),
then we can get to a better place with the IRRs as a stop gap until
a secure routing protocol can actually be deployed.  However,
without that as a stepping stone, it's an awfully large leap from
RPKI directly into a secure inter-domain routing protocol.

-danny

Re: Revealed: The Internet's well known

[Brian Dickson]

(Sorry - repost with fixed Subject line. My bad. -briand)

Alex P wrote:


*) There is no currently deployable solution to this problem yet.

*) Filtering your customers using IRR is a requirement, however, it is 
not

a solution - in fact, in the demonstration, we registered the /24 prefix
we hijacked in IRR. RIRs need to integrate the allocation data with their
IRR data.

-alex [your former moderator]


Kind of true. When doing *prefix* filtering, this kind of hijack is not
preventable.

However, if *AS-path* filtering is done based on IRR data, specifically
on the as-sets
of customers and customers' customers etc., then the attack *can* be
prevented.

The as-path prepending depends on upstreams and their peers accepting
the prefix with a path
which differs from the expected path (if the upstreams register their
as-sets in the IRR).

If the as-path filter only allows generally-feasible as-paths from
customers, where the permitted
variations are just "N copies of ASfoo" (where "foo" is a member of an
as-set), then adding
a fake "ASbar" in the as-path will cause the prefix to be rejected.

If you follow the diagram from the presentation, information about the
*real* path to the victim,
from the perspective of the hijacker, requires that the AS's on that
path not see the hijacked prefix
as announced by the hijackers.

This means that if the AS's traversed are: as-hijacker, as-bar,
as-victim, then as-bar must *not* see
the hijacked victim, for the attack to work. By adding "as-bar" into the
as-path of the hijacked prefix,
the loop-prevention logic of BGP makes sure as-bar can't see the
hijacked prefix.

So, if the upstreams of as-hijacker reject all prefixes with an as-path
which includes as-bar (because as-bar is not
a member of any customer's as-set expansion), the attack fails.

I hope I haven't managed to confuse folks too much.

But, the short answer is:

If you use the IRR, the full value is best realized by adding *as-path*
filters to the things you build
from the IRR data, and applying them to your customers (and peers !!).

Oh, and if you already do IRR stuff, it's really quite easy to do.

Brian Dickson

Re: Great Suggestion for the DNS problem...?

[Brian Dickson]

Alex P wrote:


*) There is no currently deployable solution to this problem yet.

*) Filtering your customers using IRR is a requirement, however, it is 
not

a solution - in fact, in the demonstration, we registered the /24 prefix
we hijacked in IRR. RIRs need to integrate the allocation data with their
IRR data.

-alex [your former moderator]


Kind of true. When doing *prefix* filtering, this kind of hijack is not 
preventable.


However, if *AS-path* filtering is done based on IRR data, specifically 
on the as-sets
of customers and customers' customers etc., then the attack *can* be 
prevented.


The as-path prepending depends on upstreams and their peers accepting 
the prefix with a path
which differs from the expected path (if the upstreams register their 
as-sets in the IRR).


If the as-path filter only allows generally-feasible as-paths from 
customers, where the permitted
variations are just "N copies of ASfoo" (where "foo" is a member of an 
as-set), then adding

a fake "ASbar" in the as-path will cause the prefix to be rejected.

If you follow the diagram from the presentation, information about the 
*real* path to the victim,
from the perspective of the hijacker, requires that the AS's on that 
path not see the hijacked prefix

as announced by the hijackers.

This means that if the AS's traversed are: as-hijacker, as-bar, 
as-victim, then as-bar must *not* see
the hijacked victim, for the attack to work. By adding "as-bar" into the 
as-path of the hijacked prefix,
the loop-prevention logic of BGP makes sure as-bar can't see the 
hijacked prefix.


So, if the upstreams of as-hijacker reject all prefixes with an as-path 
which includes as-bar (because as-bar is not

a member of any customer's as-set expansion), the attack fails.

I hope I haven't managed to confuse folks too much.

But, the short answer is:

If you use the IRR, the full value is best realized by adding *as-path* 
filters to the things you build

from the IRR data, and applying them to your customers (and peers !!).

Oh, and if you already do IRR stuff, it's really quite easy to do.

Brian Dickson

Re: Revealed: The Internet's well known BGP behavior

[Deepak Jain]

*) Filtering your customers using IRR is a requirement, however, it is not 
a solution - in fact, in the demonstration, we registered the /24 prefix 
we hijacked in IRR. RIRs need to integrate the allocation data with their 
IRR data.




further clarification... [if this is obvious, just skip over the message].

IRR filters helps prevent *accidental* hijacking and *accidental* route 
spillage. In that, they seem to do their job. I don't know why people 
think that would help prevent a deliberate hijacking job.


I don't think there is enough "trust" in the IP allocation system from 
the RIRs yet (trust anchors being the word of the week) to even 
contemplate non-repudiation in advertisements yet.


We can go into lots of reasons why the Internet runs this way. I think 
we can all agree 1) Its amazing it runs as well as it does, and 2) No 
one has clearly articulated a financial reason for any large 
organizations to significantly change their interconnection 
methodologies over the current BCP [that exceeds the costs of doing so].


Until either of those assertions change, the status quo will essentially 
remain.


Alex et al, I apologize if you already covered this in your preso...

One way to help mitigate the effects of this [as a user] is to keep all 
of your conversation end points on the same network -- especially if you 
run a VPN or similar -- and [rather than scan your traceroutes daily as 
someone suggested] scan the IRRs daily to make sure no changes have been 
entered for prefixes you care about.


Just some thoughts,

Deepak Jain

Re: Revealed: The Internet's well known BGP behavior

[Randy Bush]

Steven M. Bellovin wrote:
> On Thu, 28 Aug 2008 10:16:16 -0500
> "Anton Kapela" <[EMAIL PROTECTED]> wrote:
> 
>> I thought I'd toss in a few comments, considering it's my fault that
>> few people are understanding this thing yet.
>>
 On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]>
 wrote:
> People (especially spammers) have been hijacking networks for a
> while
>> I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED,
>> AFP, and Forbes.
>>
>> We all know sub-prefix hijacking is not news. What is news? Using
>> as-path loop detection to selectively blackhole the hijacked route -
>> which creates a transport path _back to_ the target.
>>
>> That's all it is, nothing more. All but the WIRED follow-up article
>> missed this point *completely.* They over-represented the 'hijacking'
>> aspects, while only making mention of the 'interception' potential.
>>
>> Lets end this thread with the point I had intended two weeks ago:
>> we've presented a method by which all the theory spewed by academics
>> can be actualized in a real network (the big-I internet) to effect
>> interception of data between (nearly) arbitrary endpoints from
>> (nearly) any edge or stub AS. That, I think, is interesting.
>>
> Indeed, and I thank you for it.  As noted, I and others have been
> warning about the problem for a long time.  You've shown that it isn't
> just an ivory tower exercise; maybe people will now get serious about
> deploying a solution.
> 
> To quote Bruce Schneier quoting an NSA maxim, attacks only get better;
> they never get worse.  We now have running code of one way to do this.
> I think most NANOG readers can see many more ways to do it.  A real
> solution will take years to deploy, but it will never happen if we
> don't start.  And we want to have the solution out there *before* we
> see serious attacks on BGP.
> 
> Again, thank you -- it was really nice work.

Re: Revealed: The Internet's well known BGP behavior

[Alex Pilosov]

On Thu, 28 Aug 2008, Anton Kapela wrote:

> I thought I'd toss in a few comments, considering it's my fault that
> few people are understanding this thing yet.
> 
> >> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]> wrote:
> >>>
> >>> People (especially spammers) have been hijacking networks for a while
> 
> I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED,
> AFP, and Forbes.
> 
> We all know sub-prefix hijacking is not news. What is news? Using
> as-path loop detection to selectively blackhole the hijacked route -
> which creates a transport path _back to_ the target.
> 
> That's all it is, nothing more. All but the WIRED follow-up article
> missed this point *completely.* They over-represented the 'hijacking'
> aspects, while only making mention of the 'interception' potential.
> 
> Lets end this thread with the point I had intended two weeks ago: we've
> presented a method by which all the theory spewed by academics can be
> actualized in a real network (the big-I internet) to effect interception
> of data between (nearly) arbitrary endpoints from (nearly) any edge or
> stub AS. That, I think, is interesting.
Yep. While it was common knowledge that it is "easy" to jack space, it was
really considered in terms of "denial of service" attack. It was known
that you could do traffic monitoring via manipulation of BGP communities
and reinjecting traffic "closer" to the target via tunnels - however that
technique is not generic. We've demonstrated ability to monitor traffic to
arbitrary prefixes. Slides for presentation can be found here:  
http://eng.5ninesdata.com/~tkapela/iphd-2.ppt

I'd also like to draw attention that it didn't draw much attention when
Tony has posted immediately after the conference to the nanog-list, which 
has an extensive reading list - and I highly recommend that before further 
posting on this, you read through it. 
http://www.gossamer-threads.com/lists/nanog/users/107423 

Added attention to the issue after our public demonstration is good news -
more attention to the problem is likely to get people do use best
practices in filtering.

I'd also like to point out that while presentation went over a lot of 
people's heads at defcon, it appears that unexpectedly, it did went over 
people's heads here as well.

To clear up some misunderstandings:
*) Yes, this is a real problem. 

*) Yes, it has been known for years.

*) There is no currently deployable solution to this problem yet.

*) Filtering your customers using IRR is a requirement, however, it is not 
a solution - in fact, in the demonstration, we registered the /24 prefix 
we hijacked in IRR. RIRs need to integrate the allocation data with their 
IRR data.

-alex [your former moderator]

Re: Revealed: The Internet's well known BGP behavior

[Gadi Evron]

Thank you for making your presentation.

Gadi.


On Thu, 28 Aug 2008, Anton Kapela wrote:


I thought I'd toss in a few comments, considering it's my fault that
few people are understanding this thing yet.


On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]> wrote:


People (especially spammers) have been hijacking networks for a while


I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED,
AFP, and Forbes.

We all know sub-prefix hijacking is not news. What is news? Using
as-path loop detection to selectively blackhole the hijacked route -
which creates a transport path _back to_ the target.

That's all it is, nothing more. All but the WIRED follow-up article
missed this point *completely.* They over-represented the 'hijacking'
aspects, while only making mention of the 'interception' potential.

Lets end this thread with the point I had intended two weeks ago:
we've presented a method by which all the theory spewed by academics
can be actualized in a real network (the big-I internet) to effect
interception of data between (nearly) arbitrary endpoints from
(nearly) any edge or stub AS. That, I think, is interesting.

-Tk

Re: Revealed: The Internet's well known BGP behavior

[Joe Greco]

> To quote Bruce Schneier quoting an NSA maxim, attacks only get better;
> they never get worse.  We now have running code of one way to do this.
> I think most NANOG readers can see many more ways to do it.  A real
> solution will take years to deploy, but it will never happen if we
> don't start.  And we want to have the solution out there *before* we
> see serious attacks on BGP.
> 
> Again, thank you -- it was really nice work.

Seems like we *could* get a large part of the way there if people were
only checking the information in question.  While not the long-term fix
of being able to prove authorization to advertise space, simply requiring
a LOA at the edge, and requiring IRR further in, and keeping records of
what was advertised, would seem to be a worthwhile improvement on the
current state of affairs.  Total prevention is a very rough goal, so
making it more difficult, combined with being able to identify when 
someone did something bad, really ought to be a worthwhile interim goal,
and I've wondered for a long time why this isn't being done.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Anton Kapela on what the BGP attack *really* means

[Jay R. Ashworth]

[ I'm unthreading this, because Anton didn't think to, and I wouldn't
want anyone who canned the other thread to miss it.  --jra ]

On Thu, Aug 28, 2008 at 11:56:30AM -0400, Steven M. Bellovin wrote:
> On Thu, 28 Aug 2008 10:16:16 -0500
> "Anton Kapela" <[EMAIL PROTECTED]> wrote:
> 
> > I thought I'd toss in a few comments, considering it's my fault that
> > few people are understanding this thing yet.
> > 
> > >> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]>
> > >> wrote:
> > >>>
> > >>> People (especially spammers) have been hijacking networks for a
> > >>> while
> > 
> > I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED,
> > AFP, and Forbes.
> > 
> > We all know sub-prefix hijacking is not news. What is news? Using
> > as-path loop detection to selectively blackhole the hijacked route -
> > which creates a transport path _back to_ the target.
> > 
> > That's all it is, nothing more. All but the WIRED follow-up article
> > missed this point *completely.* They over-represented the 'hijacking'
> > aspects, while only making mention of the 'interception' potential.
> > 
> > Lets end this thread with the point I had intended two weeks ago:
> > we've presented a method by which all the theory spewed by academics
> > can be actualized in a real network (the big-I internet) to effect
> > interception of data between (nearly) arbitrary endpoints from
> > (nearly) any edge or stub AS. That, I think, is interesting.
>
> Indeed, and I thank you for it.  As noted, I and others have been
> warning about the problem for a long time.  You've shown that it isn't
> just an ivory tower exercise; maybe people will now get serious about
> deploying a solution.
> 
> To quote Bruce Schneier quoting an NSA maxim, attacks only get better;
> they never get worse.  We now have running code of one way to do this.
> I think most NANOG readers can see many more ways to do it.  A real
> solution will take years to deploy, but it will never happen if we
> don't start.  And we want to have the solution out there *before* we
> see serious attacks on BGP.
> 
> Again, thank you -- it was really nice work.
> 
>   --Steve Bellovin, http://www.cs.columbia.edu/~smb

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Josef Stalin)

Re: Revealed: The Internet's Biggest Security Hole

[Joel Jaeggli]

Hank Nussbacher wrote:
> At 09:40 PM 27-08-08 -0400, [EMAIL PROTECTED] wrote:
> 
> I beg to differ.  What will change is a serious uptick in the number of
> prefixes (279K) in the routing tables as everyone rushes to deaggregate
> to /24 size.  A year ago we were at 230K, how much you wanna bet we
> don't just add 40K routes over the next 12 months.

if you're only seeing 2k new prefixes a week then everything is normal.

a change in the slope of the curve would be cause for alarm (say 8k a week)

joelja

> -Hank
> 
>> Nothing will change. You think DNSSEC is hard?  Try getting support
>> for the deployment of S-BGP or soBGP. Without a trust anchor and lots
>> of community support it will remain largely an academic interest area.
>>
>> Marc
>>
>> --Original Message--
>> From: Gadi Evron
>> To: Frank
>> Cc: NANOG list
>> Sent: Aug 27, 2008 20:54
>> Subject: Re: Revealed: The Internet's Biggest Security Hole
>>
>> hehe
>> "new". hehe
>>
>> Maybe something will change now' though, it was a great and impressive
>> presentation, hijacking the defcon network and tweaking TTL to hide it.
> 
> 

RE: Revealed: The Internet's well known BGP behavior

[Jon Lewis]

Do you utilize the IRR, have an as-set, and put all customer AS/CIDR's 
into the IRR?  I've honestly never heard from LVL3 about our 
advertisements.  Other providers have varied from just needing a web form, 
email, phone call, or those combined with faxed LOAs.  The latter gets 
very annoying...but maybe it is the way it should be.


On Thu, 28 Aug 2008, Boyd, Benjamin R wrote:


We've encountered the same diligence with LVL3, especially after
acquisitions where records haven't been updated yet.  Although a little
annoying it's quite refreshing.



-Original Message-
From: Eric Spaeth [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 1:41 AM
To: Jon Lewis; [EMAIL PROTECTED]
Subject: Re: Revealed: The Internet's well known BGP behavior

Jon Lewis wrote:

At 11:32 PM 27-08-08 -0500, John Lee wrote:

They didn't have control of any routers other than their own.  What
they had to find is a single clueless upstream ISP that would allow
them to announce prefixes that didn't belong to them.


Clueless or big and inattentive?  AFAIK, Level3 will accept anything
from me...as long as I put it in one of the IRRs the day

before I plan

to announce it.


Working for a company that has been steadily growing through
acquisition, we have actually run into this problem a couple times
before.   I'm not sure if we hit the lottery, but our upstream
providers
(including LVL3) have definitely intervened when we've moved
netblocks from a company that doesn't match our name into our
facilities to be advertised under our ASNs.  I'm not sure how
diligent or widespread the validation checks are, but at least
on occasion they do occur.

-Eric





***

The information contained in this message, including attachments, may contain
privileged or confidential information that is intended to be delivered only to 
the
person identified above. If you are not the intended recipient, or the person
responsible for delivering this message to the intended recipient, Windstream 
requests
that you immediately notify the sender and asks that you do not read the 
message or its
attachments, and that you delete them without copying or sending them to anyone 
else.




--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Revealed: The Internet's well known BGP behavior

[Steven M. Bellovin]

On Thu, 28 Aug 2008 10:16:16 -0500
"Anton Kapela" <[EMAIL PROTECTED]> wrote:

> I thought I'd toss in a few comments, considering it's my fault that
> few people are understanding this thing yet.
> 
> >> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]>
> >> wrote:
> >>>
> >>> People (especially spammers) have been hijacking networks for a
> >>> while
> 
> I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED,
> AFP, and Forbes.
> 
> We all know sub-prefix hijacking is not news. What is news? Using
> as-path loop detection to selectively blackhole the hijacked route -
> which creates a transport path _back to_ the target.
> 
> That's all it is, nothing more. All but the WIRED follow-up article
> missed this point *completely.* They over-represented the 'hijacking'
> aspects, while only making mention of the 'interception' potential.
> 
> Lets end this thread with the point I had intended two weeks ago:
> we've presented a method by which all the theory spewed by academics
> can be actualized in a real network (the big-I internet) to effect
> interception of data between (nearly) arbitrary endpoints from
> (nearly) any edge or stub AS. That, I think, is interesting.
> 
Indeed, and I thank you for it.  As noted, I and others have been
warning about the problem for a long time.  You've shown that it isn't
just an ivory tower exercise; maybe people will now get serious about
deploying a solution.

To quote Bruce Schneier quoting an NSA maxim, attacks only get better;
they never get worse.  We now have running code of one way to do this.
I think most NANOG readers can see many more ways to do it.  A real
solution will take years to deploy, but it will never happen if we
don't start.  And we want to have the solution out there *before* we
see serious attacks on BGP.

Again, thank you -- it was really nice work.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

RE: Revealed: The Internet's well known BGP behavior

[Bogdanov, Oleg (IT)]

First, thank you all for the usually intelligent/enlightening
discussion.  My first post to this list and apologies in advance if
discussion of end point (customer) networks is off-topic:

I haven't seen the presentation that some of you have referred to.  If
someone can provide a link that would be helpful.  What is the
as-prepend piece of the puzzle?  Insert AS numbers of ISPs in the path
from hijacker to intended recipient so snooped data doesn't boomerang
back to the hijacker (exploit BGP loop detection mechanism)?
Theoretically, can one hijack both sender and receiver space to get
inline on the whole conversation?

And maybe the more relevant question:  Can the customer do anything?
What would my ISPs tell me if I asked them to take measures (magic
ones?) to mitigate my exposure?

Thanks,
Oleg Bogdanov
Morgan Stanley | Technology
1 Pierrepont Plaza, 12th Floor | Brooklyn, NY  11201
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

RE: Revealed: The Internet's well known BGP behavior

[Boyd, Benjamin R]

We've encountered the same diligence with LVL3, especially after
acquisitions where records haven't been updated yet.  Although a little
annoying it's quite refreshing.
 

>-Original Message-
>From: Eric Spaeth [mailto:[EMAIL PROTECTED] 
>Sent: Thursday, August 28, 2008 1:41 AM
>To: Jon Lewis; [EMAIL PROTECTED]
>Subject: Re: Revealed: The Internet's well known BGP behavior
>
>Jon Lewis wrote:
>>> At 11:32 PM 27-08-08 -0500, John Lee wrote:
>>>
>>> They didn't have control of any routers other than their own.  What 
>>> they had to find is a single clueless upstream ISP that would allow 
>>> them to announce prefixes that didn't belong to them.
>>
>> Clueless or big and inattentive?  AFAIK, Level3 will accept anything 
>> from me...as long as I put it in one of the IRRs the day 
>before I plan 
>> to announce it.
>
>Working for a company that has been steadily growing through 
>acquisition, we have actually run into this problem a couple times 
>before.   I'm not sure if we hit the lottery, but our upstream 
>providers 
>(including LVL3) have definitely intervened when we've moved 
>netblocks from a company that doesn't match our name into our 
>facilities to be advertised under our ASNs.  I'm not sure how 
>diligent or widespread the validation checks are, but at least 
>on occasion they do occur.
>
>-Eric
>
>
>

***

The information contained in this message, including attachments, may contain 
privileged or confidential information that is intended to be delivered only to 
the 
person identified above. If you are not the intended recipient, or the person 
responsible for delivering this message to the intended recipient, Windstream 
requests 
that you immediately notify the sender and asks that you do not read the 
message or its 
attachments, and that you delete them without copying or sending them to anyone 
else.

Re: Revealed: The Internet's well known BGP behavior

[Anton Kapela]

I thought I'd toss in a few comments, considering it's my fault that
few people are understanding this thing yet.

>> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]> wrote:
>>>
>>> People (especially spammers) have been hijacking networks for a while

I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED,
AFP, and Forbes.

We all know sub-prefix hijacking is not news. What is news? Using
as-path loop detection to selectively blackhole the hijacked route -
which creates a transport path _back to_ the target.

That's all it is, nothing more. All but the WIRED follow-up article
missed this point *completely.* They over-represented the 'hijacking'
aspects, while only making mention of the 'interception' potential.

Lets end this thread with the point I had intended two weeks ago:
we've presented a method by which all the theory spewed by academics
can be actualized in a real network (the big-I internet) to effect
interception of data between (nearly) arbitrary endpoints from
(nearly) any edge or stub AS. That, I think, is interesting.

-Tk

Re: Service Outage in Indiana

[Elijah Savage]

- "Elijah Savage" <[EMAIL PROTECTED]> wrote:
> Anyone know what is going on there.
> 
> Sprint Verizon data and voice circuits affected in the Fort Wayne
> area.

Ok I have some data now. It seems the local LEC has multiple DS3's down in the 
area. I asked here as a last resort because I have facilities that were down 
for over an hour with no answers.

Sorry for the bother.

Service Outage in Indiana

[Elijah Savage]

Anyone know what is going on there.

Sprint Verizon data and voice circuits affected in the Fort Wayne area.

Re: interger to I P address

[Mohacsi Janos]

On Wed, 27 Aug 2008, Simon Lockhart wrote:


On Wed Aug 27, 2008 at 07:11:41AM -0400, kcc wrote:

ls it possible t convert the interger to ip


Yes.

Simon


Yes. But be aware whether you are using IPv6 or IPv4...

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

reviving the botnets@ mailing list: a new statregy in fighting cyber crime

[Gadi Evron]

The public botnets@ mailing list, where malicious activity on the Internet can 
be openly shared, has been revived, and boy is it active.


Warning: live samples and malicious URLs are openly shared there.

NANOG relevance: These can be operationally used by ISP security 
operators not of those "in the know" to block new attacks and to identify 
abusers in their own networks.


Reminder: this mailing list was started to take off-topic traffic from
NANOG.

Mailing list URL: http://www.whitestar.linuxbox.org/mailman/listinfo/botnets

Reasons, thinking and explanations:
http://gadievron.blogspot.com/2008/08/public-sharing-and-new-statregy-in.html

Excerpt:
--
A couple of years ago I started a mailing list where folks not necessarily 
involved with the vetted, trusted, closed and snobbish circles of cyber crime 
fighting (some founded by me) could share information and be informed of 
threats.


In this post I explore some of the history behind information sharing online, 
and explain the concept behind the botnets mailing list. Feel free to skip 
ahead if you find the history boring. Also, do note the history in this post is 
mixed with my own opinions. As I am one of the only people who where there in 
the beginning though and lived through all of it, I feel free to do so (in my 
own blog post).


As I conclude, we may not be able to always share our resources, but it is time 
to change the tide of the cyber crime war, and strategize. One of the 
strategies we need to use, or at least try, is public information sharing of 
"lesser evils" already in the public domain.


..
..

To fight a war, you have to be involved and engaged. On the Internet that is 
very difficult, but the Russians found a way. It is a fact that while we made 
much progress in our efforts fighting cyber crime, we had nearly no effect 
what-so-ever on the criminals and the attackers. Non. They maintain their 
business and we play at writing analysis and whack-a-mole.


Using the botnets mailing list, I am burrowing a page from the apparent Russian 
cyber war doctrine, getting people involved, engaged. Personally aware and a 
part of what's going on.


It can't hurt us, and perhaps now, four years over-due and two years after the 
previous attempt, we may be ready to give it a go and test the concept.

---

Gadi Evron.

--
"You don't need your firewalls! Gadi is Israel's firewall."
-- Itzik (Isaac) Cohen, "Computers czar", Senior Deputy to the Accountant 
General,
   Israel's Ministry of Finance, at the government's CIO conference, 2005.

(after two very funny self-deprication quotes, time to even things up!)

My profile and resume:
http://www.linkedin.com/in/gadievron

Re: Revealed: The Internet's well known BGP behavior

[Patrick W. Gilmore]

On Aug 28, 2008, at 6:25 AM, Suresh Ramasubramanian wrote:


Most of the spammer acquired /16s have been

1. pre arin

2. caused by buying up assets of long defunct companies .. assets that
just happen to include a /16 nobody knew about

Not exactly hijacks this lot .. just like those "barely legal" teen  
mags.


There have been tons of spam runs I have seen from "hijacked" blocks  
were simply announcing an unused block or a de-agg of a used block,  
sending spam for a few minutes / hours / days, and stopping the  
announcement.


This does not require special techniques, just an upstream willing to  
accept & propagate your announcement.  Alex & Anthony's preso is about  
intercepting legit traffic, not sending illegitimate traffic.


--
TTFN,
patrick



On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]> wrote:


People (especially spammers) have been hijacking networks for a  
while now,

maybe now that we have a presentation to whore around, operators can
pressure vendors and bosses.

RE: Revealed: The Internet's well known BGP behavior

[michael.dillon]

 
> I stand by my assertion that most people do not run 
> traceroutes all day and watch for it to change.
> 
> That some people are diligent does not change the fact the 
> overwhelming majority of people are not.
> 
> Or the fact that with the right placement of equipment (read 
> "luck") and cooperation of networks involved (read 
> "laziness"), even a traceroute won't show any change besides 
> additional latency.

Bingo!
Latency is the magic word and that *IS* measured by a lot
more people than do traceroutes. Unless the attackers are
lucky enough or smart enough to do their dirty work from
a server that is reasonably closely colocated to the router
that they exploit, you *WILL* see latency changes. 

It would be wise to change the process for investigating
latency increases to include examining routers for this
BGP rerouting exploit.

--Michael Dillon

RE: Revealed: The Internet's well known BGP behavior

[michael.dillon]

> Lastly, can you show me a single inter-AS MPLS deployment?  When you  
> can, then you can use that as a method to avoid this h4x0r.

Just some quick googling found this
 from back in 2006.

  "Sprint has expanded its global MPLS network capabilities with
network-to-network interface (NNI) partnerships and has introduced the
industry's first standard end-to-end MPLS VPN SLA as part of its global
network."

Re: Revealed: The Internet's well known BGP behavior

[Suresh Ramasubramanian]

Most of the spammer acquired /16s have been

1. pre arin

2. caused by buying up assets of long defunct companies .. assets that
just happen to include a /16 nobody knew about

Not exactly hijacks this lot .. just like those "barely legal" teen mags.

srs

On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <[EMAIL PROTECTED]> wrote:
>
> People (especially spammers) have been hijacking networks for a while now,
> maybe now that we have a presentation to whore around, operators can
> pressure vendors and bosses.
>

Re: interger to I P address

[Beat Vontobel]

"Anything concerning an "end network" is not relevant to this list. "

lol

I am however, very interested in the content/replies thus far. Very
entertaining.


Yes, while certainly off topic, also for me it's probably been one of  
the most entertaining threads of this kind.


So just one more solution, as there's so much unused processing power  
available on all your PostScript gear: Let your printer do the math!


# BEGIN of ntoa.ps #
%!
/ntoa {
3 { dup 256 idiv exch 256 mod exch } repeat 256 mod
} def

/printa {
3 string cvs show 3 { (.) show 3 string cvs show } repeat
} def

/Helvetica findfont 36 scalefont setfont 36 444 moveto

1089055123 ntoa printa

showpage
## END of ntoa.ps ##

Re: Revealed: The Internet's well known BGP behavior

[Gadi Evron]

On Wed, 27 Aug 2008, Patrick W. Gilmore wrote:

On Aug 27, 2008, at 11:07 PM, John Lee wrote:

1. The technique is not new it is well known BGP behavior and not stealthy 
to people who route for a living.


Using existing technology in novel ways is still novel.  Plus it makes the 
technique more accessible.  (Perhaps that is not a good thing?)


People (especially spammers) have been hijacking networks for a while now, 
maybe now that we have a presentation to whore around, operators can 
pressure vendors and bosses.


Gadi.



2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what 
packets are going where.


No, you cannot.  You can only ensure your end points are the end points you 
think they are.  In no way, shape, or form do things like IPsec, SSL, etc. 
verify or control the intermediate hops.



3. When you are running some number of trace routes per hour to see how and 
where your packets are going you spot the additional hops.


The presentation specifically shows hiding the hops by re-writing TTLs. 
Perhaps you do not understand this attack as well as you thought?



4. If you do cold potatoe routing and know where you peering points are and 
what the acls and peering policies are it is more difficult to hijack.


Would that network operators were so diligent.


And finally you use high speed optical paths or broad band ISDN (ATM) why 
route when you can deterministically switch.


Because people want to be able to reach the entire planet with a single port 
and without "deterministically" creating paths to every single end point.


Why use ISDN (ATM) when you can do something useful?

--
TTFN,
patrick