Re: soBGP deployment

[Daniel Golding <dgolding () burtongroup com>]

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 possible, lets implement
it (because everyone sees the problem) than we can either iteratively
improve the solution or start working on the next solution.

Steve's attitude (and mine) is pretty close to universal amongst operators.
We don't need complexity to solve problems that aren't there. There has been
a bit of a historic issue with vendors and IETF folks (congruent sets, yes),
telling operators what their problems are and how to fix them. I won't
enumerate the various "problems". Hijacked IP address space is a real
problem. Simple solution please :)

- Dan

On 5/26/05 6:33 AM, "Todd Underwood" <todd () renesys com> wrote:

> 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 never been a major
> > > cause of problems for me.
> >
> > That's what we can say so far.  Do you really want to wait until we have
> > a major problem?
>
> i want to agree with tony here.  i find steve's attitude troubling and
> unfortunately common.  i hear about hijackings that cause *major*
> problems on a regular basis (several times per month) and i hear a lot
> of frustration from major *edge* ASes about the inability to do much
> about it.  in the past two years i've presented at least one, very
> interesting, high-profile hijacking at some public event (NOTA peering
> forum, S&D peering forum, LINX members meeting, nanog, etc) every 3
> months or so, and i'm not spending *any* time looking for them.
>
> i also hear a lot of nonchalance on the part of transit and SP ASes
> about the problem.  and i can understand that.  because the current
> tools don't give you many options and the current customers want
> *cheap* and not *good*.  depressing but true.
>
> i also hear steve's point about not making things work *less* well.
> if we've learned anything from the md5 debacle it is that it is easy
> to create a new vulnerability or attack vector while preventing a
> non-problem.  so it's prudent to be cautious.
>
> but i would suggest that doing anything that could *delay* a *new*
> announcement on a *new* path is completely acceptable.  it's already
> happening now for edge ASes.  you get new space.  you contact your
> providers and peers and tell them to accept it.  they do the same
> thing.  and after a little while (usually more than a day but less
> than a week) the advertisements reach some plausible imitation of the
> "global" table and you call it good enough.
>
> so why not seriously consider options that don't impact existing
> routes on existing paths, but make it more difficult to get a new
> prefix working on a never-before-seen origination path pattern?
>
> like steve, i haven't yet formed an opnion on soBGP or sBGP (other
> than the fact that they've obviously been around for a while and
> obviously aren't being implemented by anyone yet).  so my comments are
> more general.
>
> t.

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group