Y'all --
Who would I talk to about a gmail server that's apparently on one of the
various sorbs lists? Ping me on my personal email -- r...@riw.us.
:-)
Russ
> >>F
> >> / \
> >> D E
> >> | |
> >> B C
> >> \ /
> >>A
> >>
> >> Suppose A is a customer of B and C.
> >
> > This is possible, but only remotely probable. In the real world, D and
> > E are likely peered, as are B and C.
>
> "likely?" with what probability? any measuremen
> A use case for a longer prefix with the same nexthop:
>
>F
> / \
> D E
> | |
> B C
> \ /
>A
>
> Suppose A is a customer of B and C.
This is possible, but only remotely probable. In the real world, D and E are
likely peered, as are B and C. Further, it's quite possible for
> 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 depl
> 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
> 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 -
> 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
> Authorization is global. (And so it relies on global access to a
statement of
> the authorization, aye, there's the rub.)
The real rub is -- What are you authorizing? Or perhaps -- what can you
actually authorize in BGP, or any other routing protocol? This is the
question that (as of yet) ha
> ³Designing Campus Networks² From Cisco.
> ³Internet Routing Architectures²
> ³Next Generation Network Services² from Cisco Press
I hate to suggest my own book, but -- The Art of Network Architecture, I
think, is pretty good. I know Doyle's Routing TCP/IP is good, I really
appreciate Radia's Int
A couple of thoughts:
1. The IOS specific parts of both Inside Cisco IOS Software Architecture
are still pretty relevant. The RIB is now a separate process, and there
are other changes, but the software architecture (of IOS specifically!)
is pretty close to what's there.
2. The hardware architec
> Yes, recursive dependencies are an issue. I'm really surprised that folks
> are even seriously considering something like this, but OTOH, this sort of
> thing keeps cropping up in various contexts from time to time, sigh.
There are only a couple of ways to get past recursive dependencies.
Y
Randy:
> as i agree that there is a problem, i *very* eagerly await your proposal
Reality: A few years back there were a half a dozen options proposed.
soBGP, pgBGP, IRR based solutions, etc. Just recently PSVs were
discussed and dismissed as a live option.
Why?
1. Only S-BGP/BGP-SEC will solve
>> Neither a DNS based solution nor the RPKI will resolve path attacks,
>
> I want to be sure of the terminology: what is deployed presently is
> the bundle RPKI+ROA. As their name say, ROA can only be used against
> origin attacks. But RPKI can be used for other things than RPKI+ROA,
> including
> free dinner at nanog/van for anyone who can explain how the dnssec
> approach meets the defcon attack. hint: it is a path attack, not an
> origin attack, and the dns pidgeon has no hooks to path attack
> prevention. at ripe, joe gersh asked me for an example of a path attack
> and i told him o
15 matches
Mail list logo
