Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

Christopher Morrow <morrowc.lists@gmail.com> Wed, 26 April 2017 14:14 UTC

Return-Path: <christopher.morrow@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BE312EAB3 for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 07:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX8bC34OluNp for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 07:14:27 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07CB12EB1B for <idr@ietf.org>; Wed, 26 Apr 2017 07:08:46 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id m36so1443626qtb.0 for <idr@ietf.org>; Wed, 26 Apr 2017 07:08:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2HjwTTZrbhWxDHPs1AKMp/I3zGFHy2TRdzLXuYep8tY=; b=cRCi4WCGZACSCA6l0HH0YuTCf3ITHJTaqQ87G5xtGJMDSg3qvVkWefvqV0fRAEISE3 r4Ntcn8LuV3MM+g8iDQokA4xBKituQpi5CqwJGUW/WSO9q5VaYsisgeDFIkjVM/8cRMj ZxyqdbnCEJ4L9HiuIf7ODUeAPv9K5ip8nWbt3GfEKkvxsg76ZS1LvjA4ds7UDCJxDG3V c76wmPGjDUN3EeWNuChduCE+2CaUYgjYzICdF0cqnwSqv5VABeRf725RiFjHTb+nnKRm Ta35ETkJP9zgW8P7YBg8NF7NNe8ft/CJgNbrwjL/Vdpvg5I3EQaF3Mk8T0H38cBs3Dkx +pAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2HjwTTZrbhWxDHPs1AKMp/I3zGFHy2TRdzLXuYep8tY=; b=mnhRNJpD1Mj/Hjp+1MtDvNa0hu27mR4QzRPFgK3ZPsTujcUIsmFWwwCFjOEPV0hoec O/PLRIscGZqd05pXwxCl+AzxxZZh4nN9mc2gb6bzwu+iQ51mzsVrO2MeyrDN480FagHO ebR/cTkrMTAFcMp6hRdjXjPb1rvpUr8qASQsVDhgQYOCTWS7B5cPH+fT3/TkMrcyy3Nf TjzNyRYKT0jfI+2GR5A9pjWT/5fjTz91NhS3n9TiVJltqxOTe0ffbWSkvRmNegbJFuWC m072BFYmyaOX5LV7MRVY4jdT3dHnCzrvaoGkH02XJHjGOP58p9KcBP0cpV+tmBH9zmY8 hbQA==
X-Gm-Message-State: AN3rC/4REZEKZ2c8JPGJV0SvpS6/fD7QipTowN51Zm9BPxDKjtsPJO4Y MquprMyYtqVF4qCQ00CT68J2uZqZYw==
X-Received: by 10.237.59.150 with SMTP id r22mr35251921qte.100.1493215725939; Wed, 26 Apr 2017 07:08:45 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.93.5 with HTTP; Wed, 26 Apr 2017 07:08:44 -0700 (PDT)
In-Reply-To: <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com>
References: <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com> <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com> <50353B76-1323-4828-88D6-25954DA1E344@puck.nether.net> <20170425221104.GS30063@pfrc.org> <023e01d2be72$031ac180$4001a8c0@gateway.2wire.net> <20170426095547.GP25069@Space.Net> <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com> <20170426113954.GA18318@puck.nether.net> <CA+b+ER=Ej7G1EEOQ7uBU-z7LeBAGNSfPkE5yGmo+z52ncKhVdg@mail.gmail.com> <20170426125417.GU25069@Space.Net> <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Wed, 26 Apr 2017 10:08:44 -0400
X-Google-Sender-Auth: tsvsTJnUG5o5JJY9c6ORLahhia4
Message-ID: <CAL9jLaabkYUO+7jsRbfZg1fXXLHXaWr88AxGyNF+AVTLquyxTQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Gert Doering <gert@space.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a114dc346eb06b8054e1260ac
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dLuhU6ZLLsauk_5xAJQ4boWMjQE>
Subject: Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2017 14:14:33 -0000

On Wed, Apr 26, 2017 at 9:56 AM, Robert Raszuk <robert@raszuk.net>; wrote:

> > And if you are customer and have 4 prefixes in BGP table thing are fine.
>> If
>> > you by accident become transit and advertise fulm table around I think
>> we
>> > can do better in BGP to protect from it then mandate policy.
>>
>> Evidence shows that, as of today, we can not.
>>
>
> ​Have anyone actually tried ?​
>
> The BGP origin validation was at least one attempt.
>
>
origin validation doesn't protect against 'accidentally i became transit,
whoops!' mistakes.

bgpsec also doesn't protect against this scenario.

There have been a few years worth of papers/analysis out of academia (and
at least 2 drafts in the ietf) talking about the above.


> The other one could be as simple as *"ebgp policy auto"* where based in
> the IRRDB and your peer's AS router can build a policy automagically using
> say BGPQ3.
>
>
are you suggesting that the router build it's filtering directly (on it's
own) from an IRRdb? that seems interesting, but also fraught with peril...

I also see problems in setting up the configuration parts for this, for a
single network it probably isn't rough, but for a more generic solution
it's going to involve more configuration toggling than just enabling a
policy on the peerings. At least you'd need to account for:
  1) which irrdb to pull content from
  2) which protocol to use to do that pulling
  3) authentication?
  4) results qualifications (larger than X, smaller than Y, general content
sanity)
  5) how to match/query the irrdb for the particular peerings on this device
  6) timeouts for operations
  7) scheduling of operations
  8) security bits around the new 'service' enabled on this device

there are other things to account for as well...


> http://snar.spb.ru/prog/bgpq3/
>
>
that's very vendor specific :(


> Otherwise while Jared, you and perhaps most folks on this list already
> have automated ways to build nice and accurate policies I suspect they are
> those which do not. And those would either put "allow all" or will now
> start looking for hints "what do I put in".
>
>
vendors who sold gear could probably offer solutions in this space.


> And if the end result is what you are doing twice a day why router's can't
> do it themselves assuming IRRDB or any other src of truth is accurate ?
>
>
'how often does this data change?'
'how often do I want to refresh peering data on devices (from neighbors)'
'what is the sla for this part of the service'

Some folk do it more 'dynamically' (some providers update 4 or 6 times
day), some folk do it 'less dynamically' (email nacr-list@uu.net .. data
updated in 24hrs)

'why not do it more!' has lots of reasons in both directions, but really
that's not the point of this draft anyway.