There have been suggestions that a key-per-AS is easier to manage than a
key-per-router, like in provisioning.
Two points --
First, if a single person with console access leaves the company, I must
roll the key for all my BGP routes, with the attendant churn, etc. I can't
imagine anyone
Not liking the solution is not a reason to abandon the problem. This
sounds
like I don't like eating right and exercising, so keeping my weight under
control is the wrong question
Two points.
First, I did NOT say, I don't like this. What I did say was technically
precise, and, I think,
On 2015-06-11 07:30, Russ White wrote:
There have been suggestions that a key-per-AS is easier to manage
than a
key-per-router, like in provisioning.
Two points --
First, if a single person with console access leaves the company, I
must
roll the key for all my BGP routes, with the attendant
On Thu, Jun 11, 2015 at 3:10 PM, David Mandelberg da...@mandelberg.org wrote:
On 2015-06-11 07:30, Russ White wrote:
There have been suggestions that a key-per-AS is easier to manage than a
key-per-router, like in provisioning.
Two points --
First, if a single person with console access
rtfm. bgpsec key aggregation is at the descretion of the operator.
they could use one key to cover 42 ASs.
I've been reading the presentations and the mailing lists, both of which
imply you should use one key per router for security reasons. I would tend
to agree with that assessment, BTW.
Crypto = more overhead. Less priority to crypto plus DDoS = routing
update issues.
I don't think there's an update issue here. The crypto verification is
probably
going to be deferred in addition to being low priority. If I understand it
correctly, this means that a route can be
The keys are per router, not per AS.
rtfm. bgpsec key aggregation is at the descretion of the operator.
they could use one key to cover 42 ASs.
randy
rtfm. bgpsec key aggregation is at the descretion of the operator.
they could use one key to cover 42 ASs.
I've been reading the presentations and the mailing lists, both of
which imply you should use one key per router for security reasons.
I would tend to agree with that assessment, BTW.
folk have different threat models. yours (and mine) may be propagation of
router compromise. for others, it might be a subtle increase in
disclosure of
router links. contrary to your original assertion, the protocol supports
both.
The increased disclosure is not subtle. The alternate --
On Jun 10, 2015, at 7:51 AM, Russ White ru...@riw.us wrote:
I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying
it's is too heavyweight given the tradeoffs, and that we probably started
with the wrong questions in the first place.
What's needed is to spend some
There have been suggestions that a key-per-AS is easier to manage than a
key-per-router, like in provisioning.
Key-per-router was brought up as providing the means to excise one misbehaving
router that is in some risky sort of environment, which is a different
management pain.
In terms of
On 2015-06-05 02:40, Roland Dobbins wrote:
On 5 Jun 2015, at 10:56, David Mandelberg wrote:
Could you elaborate on your enumeration and DDoS concerns?
Crypto = more overhead. Less priority to crypto plus DDoS = routing
update issues.
I don't think there's an update issue here. The crypto
On Tue, 09 Jun 2015 19:09:45 -0400, David Mandelberg said:
I don't think there's an update issue here. The crypto verification is
probably going to be deferred in addition to being low priority. If I
understand it correctly, this means that a route can be passed along
right away without
On Tue, 09 Jun 2015 21:19:23 -0400, valdis.kletni...@vt.edu said:
Didn't we have a very amusing afternoon a number of years ago when $VENDOR
did exactly that with some invalid routing data? Or am I mis-remembering
history, and therefor doomed to mis-repeat it?
Actually, it was collusion.
On 5 Jun 2015, at 10:56, David Mandelberg wrote:
Could you elaborate on your enumeration and DDoS concerns?
Crypto = more overhead. Less priority to crypto plus DDoS = routing
update issues.
One can infer peering relationships in a way not possible before.
What about bogus signatures?
On 06/02/2015 10:04 PM, Ethan Katz-Bassett wrote:
The same folks also followed up that workshop paper with a longer paper on
the topic:
https://www.cs.bu.edu/~goldbe/papers/sigRPKI.pdf
And a different set of folks (including me) are working on a different
mechanism to protect against attacks
On 06/03/2015 04:27 AM, Roland Dobbins wrote:
(not to mention the
enumeration and enhanced DDoS impact of packeting routers doing crypto
for their BGP sessions and which aren't protected via iACLs/GTSM).
Could you elaborate on your enumeration and DDoS concerns? If you're
concerned about the
On 2015-06-01 22:07, Mark Andrews wrote:
If you have secure BGP deployed then you could extend the
authenication
to securely authenticate source addresses you emit and automate
BCP38 filter generation and then you wouldn't have to worry about
DNS, NTP, CHARGEN etc. reflecting spoofed traffic.
On 3 Jun 2015, at 9:04, Ethan Katz-Bassett wrote:
The same folks also followed up that workshop paper with a longer
paper on
the topic:
https://www.cs.bu.edu/~goldbe/papers/sigRPKI.pdf
Thanks to you and to Dale Carter - I was unaware of these papers.
Nonetheless, the risk remains of
On 2 Jun 2015, at 11:07, Mark Andrews wrote:
If you have secure BGP deployed then you could extend the
authenication
to securely authenticate source addresses you emit and automate
BCP38 filter generation and then you wouldn't have to worry about
DNS, NTP, CHARGEN etc. reflecting spoofed
the possibility of building a true 'Internet kill switch' with effects far
beyond what various governmental bodies have managed to do so far in the DNS
space.
Could you elaborate ? I don't see how it could be worse.
Comparing with DNS is not relevant IMHO. Everyone is managing its own
On 2 Jun 2015, at 15:46, Denis Fondras wrote:
Everyone is managing its own routing policy, not everyone is managing
its own DNS root.
Everyone CAN manage his own DNS root; everyone CAN use /etc/hosts;
everyone CAN switch to an altogether different name resolution such as
PNRP.
Everyone
The same folks also followed up that workshop paper with a longer paper on
the topic:
https://www.cs.bu.edu/~goldbe/papers/sigRPKI.pdf
On Tue, Jun 2, 2015 at 8:16 AM Dale W. Carder dwcar...@wisc.edu wrote:
Thus spake Roland Dobbins (rdobb...@arbor.net) on Tue, Jun 02, 2015 at
03:05:13PM +0700:
In message 20150602151233.ga29...@doit-2nw1mrfy-x.doit.wisc.edu, Dale W. Car
der writes:
Thus spake Roland Dobbins (rdobb...@arbor.net) on Tue, Jun 02, 2015 at 03:05:
13PM +0700:
On 2 Jun 2015, at 11:07, Mark Andrews wrote:
If you have secure BGP deployed then you could extend the
Thus spake Roland Dobbins (rdobb...@arbor.net) on Tue, Jun 02, 2015 at
03:05:13PM +0700:
On 2 Jun 2015, at 11:07, Mark Andrews wrote:
If you have secure BGP deployed then you could extend the authenication
to securely authenticate source addresses you emit and automate
BCP38 filter
On 1/Jun/15 17:04, Mike Hammett wrote:
Actually, that's the level of attention given to all kinds of infrastructure
just about everywhere. ;-)
The difference is that there are standardized (global) guidelines for
those infrastructures within their own industry, that lack of compliance
can
On 1/Jun/15 17:00, Jared Mauch wrote:
This can have catastrophic effects if one does that with your sewers,
septic fields, etc but we accept it in the BGP and routing universe
for some reason.
Because our industry (for better or worse) is not as regulated as other
life-concerning things in
On 1 Jun 2015, at 22:31, Ca By wrote:
scrubbers on the other)... which is a very dangerous arms race with
real money on both sides
looking to escalate the harm / fix.
My fondest wish is for there to cease to be a need for DDoS mitigation
tools and techniques, and I do my best to try and
On 1 Jun 2015, at 22:21, Mark Tinka wrote:
The difference is that there are standardized (global) guidelines for
those infrastructures within their own industry, that lack of
compliance
can lead to serious fines, jail time or both.
1. Ensuring insurance underwriters understand the amount
@nanog.org
Sent: Monday, June 1, 2015 10:00:38 AM
Subject: Routing Insecurity (Re: BGP in the Washington Post)
On Jun 1, 2015, at 10:08 AM, Ca By cb.li...@gmail.com wrote:
The article left me with the feeling that there was a secure version of BGP
that is available but network operators
On Mon, Jun 1, 2015 at 8:21 AM, Mark Tinka mark.ti...@seacom.mu wrote:
On 1/Jun/15 17:04, Mike Hammett wrote:
Actually, that's the level of attention given to all kinds of
infrastructure just about everywhere. ;-)
The difference is that there are standardized (global) guidelines for
On Jun 1, 2015, at 10:08 AM, Ca By cb.li...@gmail.com wrote:
The article left me with the feeling that there was a secure version of BGP
that is available but network operators are too short-term-focused and
foolish to deploy it.
I believe the situation is more complicated than that, no?
In message cad6ajgqws-akd8axgiryayxpb564mswkzsuaouhjun--kjx...@mail.gmail.com
, Ca By writes:
On Mon, Jun 1, 2015 at 8:21 AM, Mark Tinka mark.ti...@seacom.mu wrote:
On 1/Jun/15 17:04, Mike Hammett wrote:
Actually, that's the level of attention given to all kinds of
infrastructure
33 matches
Mail list logo
