Re: [Idr] BGP Auto-Discovery Protocol State Requirements

[Jeffrey Haas <[e-mail]>]

On Fri, Mar 19, 2021 at 03:00:03PM +0100, Robert Raszuk wrote:
> > I think a point lacking in most of the proposals is how they're intending
> > the feature to be used.  That's setting a number of conflicting
> > expectations
> > in the heads of the authors.
> >
> > Examples:
> > 1. Whatever you plug into this port will be fine, just connect me!
> > 2. I'm willing to only connect to peers over ipv6 link local, or some
> >    specific family.
> > 3. I'm only interested in peers that support specific AFI/SAFI
> > 4. I'll only connect to peers that acceptable ASes in this range.
> > 5. I only want one peering session with a given router.
> > etc.
> >
> 
> Most if not all of that can be expressed in the auto peering policy
> template.
> If needed, operators can define rules managing auto peering and placing
> some additional controls on it.

See Section 2.5.

> Also part of such a template maybe limiting one side to be passive only.

Agreed.

> >  This is generally not a problem for existing BGP speakers because you
> > don't
> > configure what you don't want to use.  But once you introduce
> > auto-configuration, you end up with the same problem as hundreds of
> > sessions
> > that are misconfigured trying to get into your box every X seconds.
> 
> 
> If you do not expose port 179 to those 100s of peers no one will ring your
> door bell from that side. If you do then it is no different then today ...
> anyone can send TCP OPEN on that port which you need to respond to in some
> way.
> 
> But again is that really a real risk if we scope it for DC use case ?

See Section 5.2.

Minimally, the Security ADs will require this stuff to be discussed.

While we can think it foolish to do auto-discovery for "interface all",
it'll probably happen.  Knowing what occurs when it does will be one of
their questions.

Even for DC.

-- Jeff