Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018

Job Snijders <> Wed, 05 September 2018 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD81A130DE1 for <>; Wed, 5 Sep 2018 00:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M39XcKp1NfV6 for <>; Wed, 5 Sep 2018 00:34:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F6E2128CB7 for <>; Wed, 5 Sep 2018 00:34:57 -0700 (PDT)
Received: by with SMTP id l5so5261568edw.9 for <>; Wed, 05 Sep 2018 00:34:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GMMjTMeKWvGjrLhlceglpFNpJXzL2Rs5bdoPfoTfzlU=; b=Vh+mmvalm1PFRlrYCvnTRR1gUKzO5kbo2VOsy/NCysZ+Xsm5ozryUh36CFQaoK3arl w7UmmJHArgD5advtixZ4jgz/0OniYAyDC3nALdEAZRk6K9/d2K5KrafLXaj58bctT6JN 06U0rppiISlZVDpoE/rfGG8rus2Fw7jmyTu13zAYVK2RGX1vSboL0WpvtlciSuE3iOSl ZHxFDDNb6E9992RMdtQ7bbC5NFjKl+4vU9HWbBtKRSf5FkE6q4cC/RtmxyN6lylPEmH2 ctWA4K7ZMZJb0sdp2rHM1o4cJqx1/Rlv3oApKfovujvSDBqjeN8kkD/HXggOdGFwXmNh XMwg==
X-Gm-Message-State: APzg51Awf9GGvupzw/UVVQ6kuOmCnOGuhzFZ54OeQObrtw/MWfWI5C/5 c3jvnW/86h4GBzf1chzg2d0Ldg==
X-Google-Smtp-Source: ANB0Vdb5sbXavtsfq9wZ8H5Q9dIHDyjKbWDBAR6IhRGahBg5AZ3NxEG2KJo5D/M7I3wgGmpe/gl8kw==
X-Received: by 2002:a50:cb8c:: with SMTP id k12-v6mr40758858edi.171.1536132896041; Wed, 05 Sep 2018 00:34:56 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id j10-v6sm776957ede.5.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 00:34:55 -0700 (PDT)
Date: Wed, 05 Sep 2018 09:34:54 +0200
From: Job Snijders <>
To: Randy Bush <>
Cc: Christopher Morrow <>, SIDR Operations WG <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Sep 2018 07:35:00 -0000

On Tue, Sep 04, 2018 at 11:07:29PM -0700, Randy Bush wrote:
> >   1) "route origin validation is not as hard to see deploying today"
> see draft-ietf-sidrops-ov-clarify-05.txt.  essentially vendors'
> implementations are funky and so it is hard for me to do it myself.
> and it is not only ov-clarify.  test whether your fave implementation
> re-evaluates a bgp prefix when a roa change comes in over rpki-rtr.  the
> messy story goes on.

the IXP route server software (that is used in practise) is provided by
a single vendor. Perhaps this single vendor got it right, but from a
conceptual point of view they wouldn't be exempted and may still need

> >   2) "just introducing an IXP lan/RS that simply implements the validation
> > and takes action(s) is the right course of action"
> s/the right course/one right course/
> what is nice is that the ixp-provided filter does not have the same
> problems as above.

because of the single vendor? or because of some other reason? how
exactly is their bgp more magic than others?

> so it is a leapfrog while hardware vendors catch up.  it is driving
> origin validation deployment.

except that we cannot point at a single instance where the approach has
driven origin validation. on the other side, i can point at many
instances where IXP route servers have negatively impacted businesses
because they propagated/amplified incorrect routing information.

What /actually/ drives origin validation is customers asking their
providers (be it ISPs or IXPs) to implement origin validation. This
approach has already been succesfully tested at FranceIX, AMS-IX, and
later this year will be yield positive results at DE-CIX and LINX.

I have to ask, (given the author's affiliations) - if this draft is
published as an RFC, will you turn back the clock and start propagating
invalid route announcements to your customers (marked with an extended

Kind regards,