Hey everyone,
I've not forgotten about this. I plan on writing up the detail on our FCoE
experiences on Monday and will post it here. Have a few things going on
today and this weekend that are going to prevent me from keeping focused on
this.
David.
On Thu, Feb 23, 2012 at 12:50 PM, Tom Ammon
On Feb 23, 2012, at 10:42 PM, Randy Bush wrote:
> the problem is that you have yet to rigorously define it and how to
> unambiguously and rigorously detect it. lack of that will prevent
> anyone from helping you prevent it.
You referred to this incident as a "leak" in your message:
"a customer
> I thought they already existed: http://gearomat.com/
Yeah, that's correct. You can see the first version of the series production
at CeBIT Hannover this year (Hall 6 Booth K45) - the show will take place
between 6th - 10th of march. We also have some free tickets for the show. If
you plan to
- Original Message -
> From: "Gert Doering"
> > One of Telstra's downstream customers, a smaller ISP called Dodo,
> > accidentally announced the global table to Telstra (or perhaps a very
> > large portion of it.) Enough of it to cause major disruption.
>
> This is good. There is a chanc
If anyone at Hostway is listening -- though I don't really owe you this,
since you couldn't even be bothered to call me back in October when I was
shopping -- you might want to:
a) fix the content restrictions on the half dozen or more people on the
mailing list to which johnmartis@hostway redirec
On Feb 24, 2012, at 7:46 40AM, Danny McPherson wrote:
>
> On Feb 23, 2012, at 10:42 PM, Randy Bush wrote:
>
>> the problem is that you have yet to rigorously define it and how to
>> unambiguously and rigorously detect it. lack of that will prevent
>> anyone from helping you prevent it.
>
> Yo
On Fri, 24 Feb 2012, Steven Bellovin wrote:
Sure; I don't disagree, and I don't think that Randy does. But just
because we can't solve the whole problem, does that mean we shouldn't
solve any of it?
that is often the way things are argued in engineering circles.
the solution is imperfect ther
goe...@anime.net wrote:
On Fri, 24 Feb 2012, Steven Bellovin wrote:
Sure; I don't disagree, and I don't think that Randy does. But just
because we can't solve the whole problem, does that mean we shouldn't
solve any of it?
that is often the way things are argued in engineering circles.
the
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.
Daily listings are sent to bgp-st...@lists.ap
If anyone has any experiences they'd be willing to share, or even lab reports,
on HP A6600, it would be helpful. I believe this is the same product as H3C
SR6600.
We're being asked to "look at" A6604 facing our IPv4/IPv6 transit. I'd like to
get some opinions before I go through effort of get
Anyone have a clueful contact at HP? One of their proprietary DHCP
features is squatting on an IANA-registered code point.
Thanks,
--Richard
On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote:
> But just because we can't solve the whole problem, does that
> mean we shouldn't solve any of it?
Nope, we most certainly should decompose the problem into
addressable elements, that's core to engineering and operations.
However, simply bec
On Fri, Feb 24, 2012 at 2:26 PM, Danny McPherson wrote:
> happens by accident all the time. How we can justify putting all
> that BGPSEC and RPKI machinery in place and not address this
> "leak" issue somewhere in the mix is, err.., telling.
I think if we asked telstra why they didn't filter th
Are there any ongoing issues with Comcast and/or RCN in the Boston Metro Area?
Thanks,
Sherif Hashem
Harvard Medical School | Network Operations
25 Shattuck Street | Gordon Hall Suite 500 | Boston, MA, 02115
d: (617)432-7534 | c: (617)999-7818 | f: (617)432-6804
On Feb 24, 2012, at 2:29 PM, Christopher Morrow wrote:
>
> I think if we asked telstra why they didn't filter their customer some
> answer like:
> 1) we did, we goofed, oops!
> 2) we don't it's too hard
> 3) filters? what?
>
> I suspect in the case of 1 it's a software problem that needs more
>
>> I think if we asked telstra why they didn't filter their customer some
>> answer like:
>> 1) we did, we goofed, oops!
>> 2) we don't it's too hard
>> 3) filters? what?
>>
>> I suspect in the case of 1 it's a software problem that needs more
>> belts/suspenders
>> I suspect in the case of 2 it's
On Feb 24, 2012, at 2:49 PM, Richard Barnes wrote:
> You seem to think that there's some extension/modification to BGPSEC
> that would fix route leaks in addition to the ASPATH issues that
> BGPSEC addresses right now. Have you written this up anywhere? I
> would be interested to read it.
I do
Steve,
On Feb 24, 2012, at 11:10 AM, Steven Bellovin wrote:
> On Feb 24, 2012, at 7:46 40AM, Danny McPherson wrote:
>> On Feb 23, 2012, at 10:42 PM, Randy Bush wrote:
>>> the problem is that you have yet to rigorously define it and how to
>>> unambiguously and rigorously detect it. lack of that w
On Fri, Feb 24, 2012 at 3:04 PM, Shane Amante wrote:
> Solving for route leaks is /the/ "killer app" for BGPSEC. I can't understand
> why people keep ignoring this.
I don't think anyone's ignoring the problem... I think lots of people
have said an equivalent of:
1) "How do I know that this pat
Normally I wouldn't say anything to anyone about anything so mundane as
brute-force SSH attacks, but this one caught my eye just because of the
IP address:
1.234.35.245
I wanna get a connection in Korea so I can have 1.234.56.78.
jms
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ
In a message written on Fri, Feb 24, 2012 at 01:04:20PM -0700, Shane Amante
wrote:
> Solving for route leaks is /the/ "killer app" for BGPSEC. I can't understand
> why people keep ignoring this.
Not all "leaks" are bad.
I remember when there was that undersea landside in Asia that took
out a b
On Fri, Feb 24, 2012 at 3:59 PM, Leo Bicknell wrote:
> In a message written on Fri, Feb 24, 2012 at 01:04:20PM -0700, Shane Amante
> wrote:
>> Solving for route leaks is /the/ "killer app" for BGPSEC. I can't
>> understand why people keep ignoring this.
>
> Not all "leaks" are bad.
>
> I rememb
Je suis absent(e) du bureau jusqu'au 06/03/2012
Je suis absent pour le moment.
En cas de nécessité, merci de transmettre vos messages à l'équipe CSIRT:
cs...@bnpparibas.com
+33 1 40 14 26 95 (office hours UTC +1/+2)
--
I am currently out of office.
If necessary, please forward your messages to
In a message written on Fri, Feb 24, 2012 at 04:07:28PM -0500, Christopher
Morrow wrote:
> well for bgpsec so if the paths were signed, and origins signed,
> why would they NOT pass BGPSEC muster?
I honestly have trouble keeping the BGP security work straight.
There is work to secure the sess
BGP Update Report
Interval: 16-Feb-12 -to- 23-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS840286391 2.5% 43.1 -- CORBINA-AS OJSC "Vimpelcom"
2 - AS982935953 1.1
This report has been generated at Fri Feb 24 21:12:17 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date
On Fri, Feb 24, 2012 at 4:29 PM, Leo Bicknell wrote:
> In a message written on Fri, Feb 24, 2012 at 04:07:28PM -0500, Christopher
> Morrow wrote:
>> well for bgpsec so if the paths were signed, and origins signed,
>> why would they NOT pass BGPSEC muster?
>
> I honestly have trouble keeping t
On Feb 24, 2012, at 2:26 14PM, Danny McPherson wrote:
>
> On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote:
>
>> But just because we can't solve the whole problem, does that
>> mean we shouldn't solve any of it?
>
> Nope, we most certainly should decompose the problem into
> addressable ele
> -Original Message-
> From: Leo Bicknell
> Sent: Friday, February 24, 2012 1:00 PM
> There are plenty of cases where someone "leaks" more specifics with
> NO_EXPORT to only one of their BGP peers for the purposes of TE.
>
> The challenge of securing BGP isn't crypto, and it isn't enough
On 25/02/2012, at 7:54 AM, Christopher Morrow wrote:
> On Fri, Feb 24, 2012 at 3:04 PM, Shane Amante wrote:
>
>> Solving for route leaks is /the/ "killer app" for BGPSEC. I can't
>> understand why people keep ignoring this.
>
> I don't think anyone's ignoring the problem... I think lots of p
I thought the A6604 was EOL?
http://h17007.www1.hp.com/docs/products/eos/Select_HP_A6600_Routers_and_Modules_ES_Announcement.pdf
--
Leigh
> -Original Message-
> From: Christopher Pilkington [mailto:c...@0x1.net]
> Sent: 24 February 2012 19:05
> To: NANOG mailing list
> Subject: HP A66
On 24/02/2012 20:04, Shane Amante wrote:
> Solving for route leaks is /the/ "killer app" for BGPSEC. I can't
> understand why people keep ignoring this.
I'd be interested to hear your opinions on exactly how rpki in its current
implementation would have prevented the optus/telstra problem. Could
On 24/02/2012 20:59, Leo Bicknell wrote:
> It turns out the real world is quite messy though, often full of
> temporary hacks, unusual relationships and other issues.
... and, if you create a top-down control mechanism to be superimposed upon
the current fully distributed control mechanism, you wi
>> I'm optimistic that all the good folks focusing on this in their day
>> jobs, and expressly funded and resourced to do so, will eventually
>> recognize what I'm calling "leaks" is part of the routing security
>> problem.
>>
> Sure; I don't disagree, and I don't think that Randy does. But just
> Solving for route leaks is /the/ "killer app" for BGPSEC.
as would be solving world hunger, war, bad cooking, especially bad
cooking.
route leaks, as much as i understand them
o are indeed bad ops issues
o are not security per se
o are a violation of business relationshiops
o and 20 yea
1. Make your customers register routes, then filter them.
(may be time for big providers to put routing tools into
open source for the good of the community - make it
less hard?)
2. Implement the "1-hop" hack to protect your BGP peering.
98% of problem solved on the Internet to
On Feb 25, 2012, at 7:49 AM, Randy Bush wrote:
> i would love to see progress on the route leak problem. i do not confuddle
> it with security.
Availability is a key aspect of security - the most important one, in many
cases/contexts. The availability of the control plane itself (i.e., being
On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young wrote:
> 1. Make your customers register routes, then filter them.
> (may be time for big providers to put routing tools into
> open source for the good of the community - make it
> less hard?)
not a big provider, but ras@e-gerbil did
On Feb 24, 2012, at 17:43, Leigh Porter wrote:
> I thought the A6604 was EOL?
>
> http://h17007.www1.hp.com/docs/products/eos/Select_HP_A6600_Routers_and_Modules_ES_Announcement.pdf
Yes, and the recommended replacement is... the A6604. (Read whole EOL
announcement.)
>
-cjp
On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:
> max-prefix already exists... sometimes it works, sometimes it's a burden.
Some sort of throttle - i.e., allow only X number of routing updates within Y
number of [seconds? milliseconds? BGP packets?] would be more useful, IMHO.
If the
On 25/02/12 13:12, Dobbins, Roland wrote:
>
> On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:
>
>> max-prefix already exists... sometimes it works, sometimes it's a burden.
>
> Some sort of throttle - i.e., allow only X number of routing updates within Y
> number of [seconds? millisecon
On Fri, Feb 24, 2012 at 9:12 PM, Dobbins, Roland wrote:
>
> On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:
>
>> max-prefix already exists... sometimes it works, sometimes it's a burden.
>
> Some sort of throttle - i.e., allow only X number of routing updates within Y
> number of [seconds?
On Feb 25, 2012, at 9:39 AM, Christopher Morrow wrote:
> it seems to me that most of the options discussed for this are .. bad, in one
> dimension or another :(
Concur.
> X prefixes/packets in Y seconds/milliseconds doesn't keep the peer from
> blowing up your RIB,
How so? If the configured
On 25/02/2012, at 12:59 PM, Christopher Morrow wrote:
> On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young wrote:
>> 1. Make your customers register routes, then filter them.
>> (may be time for big providers to put routing tools into
>> open source for the good of the community - make i
Nick,
On Feb 24, 2012, at 4:16 PM, Nick Hilliard wrote:
> On 24/02/2012 20:04, Shane Amante wrote:
>> Solving for route leaks is /the/ "killer app" for BGPSEC. I can't
>> understand why people keep ignoring this.
>
> I'd be interested to hear your opinions on exactly how rpki in its current
> im
On Fri, Feb 24, 2012 at 11:01 AM, Christopher Pilkington wrote:
> If anyone has any experiences they'd be willing to share, or even lab
> reports, on HP A6600, it would be helpful. I believe this is the same
> product as H3C SR6600.
>
> We're being asked to "look at" A6604 facing our IPv4/IPv6 tr
On Feb 24, 2012, at 5:49 PM, Randy Bush wrote:
>> Solving for route leaks is /the/ "killer app" for BGPSEC.
>
> as would be solving world hunger, war, bad cooking, especially bad
> cooking.
>
> route leaks, as much as i understand them
> o are indeed bad ops issues
> o are not security per se
On Fri, Feb 24, 2012 at 10:52 PM, Dobbins, Roland wrote:
>
>> X prefixes/packets in Y seconds/milliseconds doesn't keep the peer from
>> blowing up your RIB,
>
> How so? If the configured parameters are exceeded, stop accepting/inserting
> updates until this is no longer the case. Exceptions w
On Feb 25, 2012, at 2:15 PM, Christopher Morrow wrote:
> if the rate is 1/ms ... I can fill the rib in 2million ms ... ~30mins? Rate
> alone isn't the problem :( size matters.
Sure; the idea is that some sort of throttling, coupled with overall size
limitations, might be useful.
> People are
On Fri, Feb 24, 2012 at 12:20 AM, Matlock, Kenneth L
wrote:
> Netflow + netflow collector.
+1 This guide should give you a good start.
http://techowto.files.wordpress.com/2008/09/ntop-guide.pdf
Regards
--
Mukom Akong Tamon
__
"If we can't BREATH, we'll die. Yet, we don't LIVE in
50 matches
Mail list logo
