Todd,
>>- Forged AS paths and AS path segments
>
>
> ditto, provided that you have long enough AS path segments in your
> list of valid prefixes. if you have a long enough memory of routes
> and a fast enough system, it's trivial to produce weighted lists of
> the likelihood of a given prefix
tony, all,
On Thu, May 26, 2005 at 11:12:09PM -0700, Tony Li wrote:
> You're not going to like this.
on the contrary, i don't find it surprising or unpleasant. :-)
> The simplest way to stop the hijacking is going to end up looking a LOT
> like one of the s*BGP proposals. Here's why:
>
> Th
On Thu, 26 May 2005, Tony Li wrote:
You're not going to like this.
The simplest way to stop the hijacking is going to end up looking a LOT
like one of the s*BGP proposals. Here's why:
The threat model includes:
- Forged origin ASs
- Unauthorized advertisements from authenticatable sources
Daniel, Todd,
> The most significant problem is hijacking of IP address space for various
> purposes. That's it. Solve that in the SIMPLEST way possible, lets implement
> it (because everyone sees the problem) than we can either iteratively
> improve the solution or start working on the next s
> The thing we should keep in mind is that the problem set is really very
> limited.
and if we just stick our heads in the sand, it will stay so?
have we learned nothing about internet threat models in the
last decade?
there are very smart and nasty people out there, and there is
a very high pay
The thing we should keep in mind is that the problem set is really very
limited. Although I acknowledge Tony's cockpit door analogy, we live in the
world of today.
The most significant problem is hijacking of IP address space for various
purposes. That's it. Solve that in the SIMPLEST way possib
On Thu, 26 May 2005, Todd Underwood wrote:
> the scalability problem, as i understand it (not at all an expert
> here) is that routers won't currently handle such a list with regexps
> very well. apparently, ciscos will not allow filtering advertisements
> on a combination o
On Thu, 26 May 2005, Todd Underwood wrote:
> the list of all prefixes seen in the global table combined with all
> origination patterns seen for the past 6 months or so is realively
> easy to produce.
This is something that we, or RIPE/RIS, or RouteViews, could produce and
cr
steve, tony, all,
just catching up. trying to ignore the TOS fest but the soBGP thread
actually is interesting.
On Wed, May 25, 2005 at 03:51:25PM -0700, Tony Li wrote:
> > And yet, in the nine or so years I've been working on network
> > infrastructure stuff, spoofed BGP announcements have ne
On Thu, 26 May 2005, Jeroen Massar wrote:
In short, you mean setting up, eg a Quagga box behind the existing core
infra that one has, feeding it a full feed, which matches the current
best paths one has in it's RIB and verifying the paths.
This is somewhat similar how the detection of GRH (*1
tony, all,
On Wed, May 25, 2005 at 04:24:07PM -0700, Tony Li wrote:
> Fundamentally, there is a serious scalability issue with doing
> everything at configuration generation time. Since one cannot predict
> with certainty what AS paths will be seen for which prefix, one would
> have to authenti
On Wed, 2005-05-25 at 16:24 -0700, Tony Li wrote:
> For example, an operator can begin by enabling authentication on a BGP
> speaker that is wholly outside of the traffic path. Instability of this
> one speaker would have no effect on production traffic. Authentication
> alarms generated by this
On Wed, 25 May 2005, Tony Li wrote:
I know all the issues up there are real, since I've occasionally heard
about them happening. I understand the devastating consequences of
somebody finding a sufficiently well connected unfiltered BGP session
and using it to announce some important prefixes.
Daniel,
Well, I wish I could have been part of the discussions that you had, as
what you report is at variance with what I've heard.
Fundamentally, there is a serious scalability issue with doing
everything at configuration generation time. Since one cannot predict
with certainty what AS path
Steve,
> I know all the issues up there are real, since I've occasionally heard
> about them happening. I understand the devastating consequences of
> somebody finding a sufficiently well connected unfiltered BGP session
> and using it to announce some important prefixes. I fully agree that i
On Mon, 23 May 2005, Tony Li wrote:
Which is EXACTLY why we need to remember that we are NOT trying to come
up with the perfect solution. We have operational issues *TODAY* that
we are trying to address.
- We have people (admittedly accidentally) advertising prefixes that
they do not own and
On 23.05 22:13, Tony Li wrote:
> ... We,
> as responsible operators/architects/vendors/coders need to pick a
> solution and field it. It may well be an interim solution, but we MUST
> act, and soon. We are already seeing the stress patterns, without
> reinforcement it is only a matter of time be
Randy,
> wrong. as deployment will be expensive and long, we will have one chance to
> deploy. so need a serious solution set for what we have to consider to be a
> very serious attack model. plan for attacks against the routing system as
> smart, well-researched, constant, ... as the best we
>>> the certificates are carried ... in soBGP in a new BGP message.
>> btw, am i supposed to be cheered by yet another overloading of bgp?
> Since S-BGP overloads signatures into the current packet formats, destroys
> packing, and destroys peer groups, I'm not certain that you can make the
> cla
> Which is EXACTLY why we need to remember that we are NOT trying to come
> up with the perfect solution. We have operational issues *TODAY* that
> we are trying to address.
wrong. as deployment will be expensive and long, we will have one chance to
deploy. so need a serious solution set for w
>>> the certificates are carried ... in soBGP in a new BGP message.
>> btw, am i supposed to be cheered by yet another overloading of
>> bgp?
> Well gee Randy, I think you would have been happy. Here we are
> carrying related data in the same place.
related, but not congruent. so it is just ano
- soBGP allows the receiver to determine that the AS Path describes a
plausible traversal across the network, but cannot validate that the update
itself traversed this path.
further, the latter, because it relies on a separate data set for
path validity, has serious and very kinky temporal
the certificates are carried ... in soBGP in a new BGP message.
btw, am i supposed to be cheered by yet another overloading of bgp?
Since S-BGP overloads signatures into the current packet formats, destroys
packing, and destroys peer groups, I'm not certain that you can make the
claim tha
> >Why create reliance on more databases? The RIRs are iffy. We rely on
DNS
> >right now. Why not keep relying on it? This solution doesn't solve all
of
> >our problems, but it does help, its easy, and people will implement it.
>
> Who populates the DNS (well, the .arpa domain)? The RIRs do.
eimer" <[EMAIL PROTECTED]>
To: "Steven M. Bellovin" <[EMAIL PROTECTED]>
Cc: "Pekka Savola" <[EMAIL PROTECTED]>; "Randy Bush" <[EMAIL PROTECTED]>; "vijay
gill" <[EMAIL PROTECTED]>;
Sent: Tuesday, May 24, 2005 1:44 AM
Subject:
* Steven M. Bellovin:
> Fundamentally, the answer to this question is this: how accurate do you
> think the routing registries are?
I don't think it's important how accurate they are *now*, but how
accurate they will be when some "secure" BGP version makes them (or,
more precisely, the route re
[EMAIL PROTECTED]>
Cc: "Geoff Huston" <[EMAIL PROTECTED]>; "Daniel Golding"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, May 23, 2005 10:25 PM
Subject: Re: soBGP deployment
>
>
> > -- You must not rely on
> -- You must not rely on routing to secure routing.
I would like to point out that this goal is unnecesary.
First, we need to understand that for ANY solution to be deployable, it
must be incrementally deployable. We do not get an Internet-wide flag
day for BGP. The Internet must continue t
> i receive a bgp announcement from a new peer, but the announcement
> was originated two weeks ago (shockers! a stable route); was the
> asserted path to my new peer valid when the announcement was
> originated two weeks ago? once your mind starts down such paranoid
> paths, the void opens befo
>>the certificates are carried ... in soBGP in a new BGP message.
>
>
> btw, am i supposed to be cheered by yet another overloading of
> bgp?
Well gee Randy, I think you would have been happy. Here we are carrying
related data in the same place. And, in the long run, the
authentication inf
On Mon, May 23, 2005 at 11:06:23PM -0400, Randy Bush wrote:
> >> I suspect the right thing to do is to ask why soBGP and sBGP
> >> have failed?
> > Or maybe, jut maybe, because we've never had the tools to deploy
> > it.
>
> actually, we had a small workshop with sbgp tools at the last
> eugene n
>> I suspect the right thing to do is to ask why soBGP and sBGP
>> have failed?
> Or maybe, jut maybe, because we've never had the tools to deploy
> it.
actually, we had a small workshop with sbgp tools at the last
eugene nanog. perhaps it's time for another? bill, can you host
at he next nanog
On 5/24/05, Brad Knowles <[EMAIL PROTECTED]> wrote:
> If you're talking about users, then all you have to do is
> implement SPF at a few large sites like AOL, where they don't support
> forwarding and therefore they don't care if they break forwarding,
> where they want to force everyone t
> the certificates are carried ... in soBGP in a new BGP message.
btw, am i supposed to be cheered by yet another overloading of
bgp?
randy
>> o with sbgp, the assertion of the validity of asn A announcing
>> prefix P to asn B is congruent with the bgp signaling itself,
>> A merely signs the assertion in the bgp announcement.
>
>> o with sobgp, the assertion is in an external database with
>> issues such as
>
> This i
You do need "trusted third party" to act as PKI root signer. We're lucky
because unlike other places, we do have hierarchy with ip addresses and
ASNs and NIR is the "root" organization.
Don't confuse cryptography with security.
You need one trusted third party to arrange for the cryptography
At 3:24 PM -0400 2005-05-23, Daniel Golding wrote:
A bizarre assertion was made that only a "few" are implementing SPF, which
is demonstrably untrue.
It depends on whether you're talking about "few" relative to the
number of mail systems in the world, or "few" relative to the number
of u
The essential difference as far as I can see today between soBGP and sBGP
in this space is that, as a 2 liner:
- sBGP allows the receiver to validate that the update indeed traversed
the path described in the AS Path Update as part of the local acceptance
of the update.
- soBGP allows t
1) Keep the security ancillary data nearby. You might need it when the
source of the data is unreachable (perhaps because of an incident like a
flood).
That is why in my view soBGP is something that can only be deployed as an
after-filter (i.e. ones full BGP mesh is in for decisions about
o with sbgp, the assertion of the validity of asn A announcing
prefix P to asn B is congruent with the bgp signaling itself,
A merely signs the assertion in the bgp announcement.
o with sobgp, the assertion is in an external database with
issues such as
- data correctness & compl
It seems to me that a more workable solution in today's Internet, is to
decouple the definition of the information exchanged by network operators
from the protocol used to exchange the information. It should be possible
to design a system in such a way that a network operator can choose
whet
On Mon, May 23, 2005 at 02:00:12PM -0400, Daniel Golding wrote:
> One of the Internetworking community's biggest problems is a fixation on the
> perfect solution. Its natural - we're engineers, after all. We want an
> elegant 100% solution to our ills. This often leads to something that never
> ge
On Mon, 23 May 2005 15:24:20 EDT, Daniel Golding said:
> A bizarre assertion was made that only a "few" are implementing SPF, which
> is demonstrably untrue. Its getting implemented because its easy, not
"It's easy to deploy an incomplete solution". Why does my Spidey-sense scream
that this is a
One correction: I shouldn't have said: "The RIRs are iffy". It should have
been "The IRRs are iffy". A world of difference.
I understand the limitations. However, no one is rushing to implement most
of the things that folks in this thread are obsessing over: DNSSec, IPV6,
sBGP, soBGP.
A bizarr
At 04:00 AM 24/05/2005, Daniel Golding wrote:
I suspect the right thing to do is to ask why soBGP and sBGP have failed?
And yes, they've failed. Just like DNSSec, we aren't seeing even limited
adoption. Why? Too complex, too many moving parts, too much reliance on iffy
third parties and requi
At 14:00 -0400 5/23/05, Daniel Golding wrote:
My reply is mostly tongue-in-cheek. I think it's always healthy to
explore alternatives.
Why not do something simple? The in-addr.arpa reverse delegation tree is
pretty accurate. We use it for lots of different things. Why not just give
IP addre
On Mon, May 23, 2005 at 08:15:15PM +0200, Jeroen Massar wrote:
> On Mon, 2005-05-23 at 14:00 -0400, Daniel Golding wrote:
> >
> > I suspect the right thing to do is to ask why soBGP and sBGP have failed?
> >
> > And yes, they've failed. Just like DNSSec, we aren't seeing even limited
> > adoptio
On Mon, 2005-05-23 at 14:00 -0400, Daniel Golding wrote:
>
> I suspect the right thing to do is to ask why soBGP and sBGP have failed?
>
> And yes, they've failed. Just like DNSSec, we aren't seeing even limited
> adoption. Why? Too complex, too many moving parts, too much reliance on iffy
> thir
I suspect the right thing to do is to ask why soBGP and sBGP have failed?
And yes, they've failed. Just like DNSSec, we aren't seeing even limited
adoption. Why? Too complex, too many moving parts, too much reliance on iffy
third parties and requires mass adoption.
I suggest that the community
At 10:37 -0700 5/23/05, william(at)elan.net wrote:
You do need "trusted third party" to act as PKI root signer. We're lucky
because unlike other places, we do have hierarchy with ip addresses and
ASNs and NIR is the "root" organization.
Don't confuse cryptography with security.
You need one
for the old-timers this is not quite sBGP or soBGP, but does
have many of the desirable traits for the new kids on the block,
if ISPs want to do this, its something they can do themselves, w/o
centralized coordination, on an incremental basis.
http://www.isoc.org/inet98/proceedings/6h/
On Mon, 23 May 2005, Edward Lewis wrote:
1) Keep the security ancillary data nearby. You might need it when the
source of the data is unreachable (perhaps because of an incident like a
flood).
That is why in my view soBGP is something that can only be deployed as an
after-filter (i.e. one
In message <[EMAIL PROTECTED]>, Iljitsch van Beijn
um writes:
>
>On 23-mei-2005, at 17:39, Randy Bush wrote:
>
>> o with sbgp, the assertion of the validity of asn A announcing
>> prefix P to asn B is congruent with the bgp signaling itself,
>> A merely signs the assertion in the bgp ann
> Security ought to not make the system being protected brittle. Like
> the example of routing changes being held up until the paperwork went
> through - maybe an improvement in tools will enable this.
It should be possible for a network operator to make
their own policy decisions on this. Som
At 11:27 -0400 5/23/05, Larry J. Blunk wrote:
I suspect this was due to the fact that template submissions
were not fully automated at the time and required human
review (disclaimer: I worked for the MichNet side of Merit
back then and was not intimately familiar with PRDB
operations).
It
> but this just underscores the difference here
> its the old simplicity vs complexity game yet again
Why should the IETF be making the tradeoff decision
here rather than the operators?
It seems to me that a more workable solution in today's
Internet, is to decouple the definition of the infor
On 23-mei-2005, at 17:39, Randy Bush wrote:
o with sbgp, the assertion of the validity of asn A announcing
prefix P to asn B is congruent with the bgp signaling itself,
A merely signs the assertion in the bgp announcement.
o with sobgp, the assertion is in an external database wi
my weak memory, it was due to a number of factors, some in the
database update workflow, some in the uneven usage workflow,
e.g. ans updating once, or was it twice, a week.
but this just underscores the difference here
o with sbgp, the assertion of the validity of asn A announcing
prefix
On Mon, 2005-05-23 at 10:11 -0400, Randy Bush wrote:
> > If you look back to the NSFNet days (prior to a decade ago) and
> > the PRDB (Policy Routing Database), you might very well draw a
> > different conclusion.
>
> indeed, one of utter disaster. it would take days or weeks
> before one could
> If you look back to the NSFNet days (prior to a decade ago) and
> the PRDB (Policy Routing Database), you might very well draw a
> different conclusion.
indeed, one of utter disaster. it would take days or weeks
before one could route a prefix.
randy
On Sat, 2005-05-21 at 16:03 -0400, Steven M. Bellovin wrote:
> Look at it this way: do you think that (a) most
> sites will publish their policies in the registry, and (b) they'll
> remember to update them? As Randy has noted, we have a decade of
> experience suggesting that neither is true.
On Sat, 21 May 2005, Pekka Savola wrote:
There's nothing to say the functional equivalent of certificate could also
not be passed in an option or some other means as well when needed. My
assumption would be that being able to use public databases would be a
protocol optimization.
I think
On 21-mei-2005, at 20:25, Randy Bush wrote:
If you are an operator, would you deploy soBGP or something like
it? If
not, why not.
[skip to the bottom for my reaction to Randy's post]
I think it would be a very good idea to start experimenting with this
as soon as there are decent impleme
Note that the original soBGP didn't require any updates when the
peering relationships changed; based on a quick look, a later
extension has probably changed this.
one of the 29 hacks to sobgp to try to fix this and that (kinda like w's
social security program). this one was to address the
With SBGP, each node signs the BGP statements it's about to send out. The
accuracy of the security statement is thus linked to the transmission
process. With SO-BGP, the security against in-path attacks (or
cut-and-paste attacks; see below) relies on a secure version of the
routing registry
> Yet, what is the (SBGP) alternative?
that the assertion of as-path is produced by the very bgp
sessions themselves. simple and congruent, relying on no
other data, and can vary in real-time.
> I don't think we have much success distributing this kind of
> certificates in similar scenario eit
On Sat, 2005-05-21 at 16:03 -0400, Steven M. Bellovin wrote:
> Let me add a word about cut-and-paste attacks. A signed origin
> statement asserts that some AS owns some prefix. That statement will
> be readily available. A nefarious site could cut that statement from
> some actual BGP sess
On Sat, 21 May 2005, Steven M. Bellovin wrote:
With SBGP, each node signs the BGP statements it's about to send out.
The accuracy of the security statement is thus linked to the
transmission process. With SO-BGP, the security against in-path
attacks (or cut-and-paste attacks; see below) relies
In message <[EMAIL PROTECTED]>, Pekka Savola writes:
>
>On Sat, 21 May 2005, Randy Bush wrote:
>> something like it, for sure. but i vastly prefer the s-bgp
>> approach as it maps closely to bgp operational reality, and does
>> not rely on a published policy database, which we have seen fail
>> f
On Sat, 21 May 2005, Randy Bush wrote:
something like it, for sure. but i vastly prefer the s-bgp
approach as it maps closely to bgp operational reality, and does
not rely on a published policy database, which we have seen fail
for over a decade, etc.
So, can someone point out the important o
> If you are an operator, would you deploy soBGP or something like it? If
> not, why not.
as smb has said for years, routing and dns are the two largest
vulnerabilities.
something like it, for sure. but i vastly prefer the s-bgp
approach as it maps closely to bgp operational reality, and doe
At 02:31 PM 5/20/2005 -0400, Christopher Woodfield wrote:
>
>As far as answering the "First Goal" of the article, I really don't
>see much here that isn't handled today by route registries, except
>for the TLS certificate stuff. Not sure how much security that adds,
>practically; how often d
On Fri, 20 May 2005, Christopher Woodfield wrote:
> implemented realistically at the single-peer level the paper
> mentions. Just don't ask me to run it on a GRP-B.
I think it'd be running on even your customer's 2500... and your 7500 and
your 7200. :) hurray! :)
As far as answering the "First Goal" of the article, I really don't
see much here that isn't handled today by route registries, except
for the TLS certificate stuff. Not sure how much security that adds,
practically; how often do people see their route objects jacked by
hax0rs?
For the "Se
74 matches
Mail list logo
