[Sidrops] 'tagging' in draft-ietf-sidrops-validating-bgp-speaker

Job Snijders <job@instituut.net> Wed, 24 July 2019 18:49 UTC

Return-Path: <job@instituut.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 56C6C120346 for <sidrops@ietfa.amsl.com>; Wed, 24 Jul 2019 11:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lQvZ7O7g6q-U for <sidrops@ietfa.amsl.com>; Wed, 24 Jul 2019 11:49:25 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 59CAB120338 for <sidrops@ietf.org>; Wed, 24 Jul 2019 11:49:25 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id m14so8862244qka.10 for <sidrops@ietf.org>; Wed, 24 Jul 2019 11:49:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=dn1aZlmoyACalEUbiyM/zkDQPJQhPc6ZnoEurKYTiXw=; b=BpeqVzSl1fxnJtlJHOl9KsGjRPvRaqliPpJf6LXm6qSphneashxq46BofDmjwg7aOb Ga/op6SAEOL+aeM4/L59HdNAPRE1AR3MzWzkSkw6OvFk3I0D4bU+zsD/TkDazDENepSR k4bCmuvG+pqMZtrIgYBx0wbBBgF65sw0pPkSSEARLoNfNW/X60a8Tv7X7Um2gZ8oz3Vj blFhdLfePt+CHCzsKC63KXWL+r8D0DgPmrt+lC6HjbUH5Jhw+CWBao2+dKq8WGpqjduN 4R2OQ1xMdTAnxaBeBM/dSV3ko2RRItyAFMEVGZEe4ZArl8fUg62s7sJUgJqTBW4DCpbh zMjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=dn1aZlmoyACalEUbiyM/zkDQPJQhPc6ZnoEurKYTiXw=; b=Npsio+UN8FVo6bkgyqxv+30fu9gIeOwipGfs7ZMnwsUAAV+Sixoz+n2Ke4vf+rtB47 7RZwozrJb+ZB/gYNtg1GeBGjs7uUWGbWSxAWVSO6nhJM3el0QkaRh6I4Xf6lKLMy3WvK 85tunsz0McTN3shxdFEufSoXGcn9rAKROjg8xrZCReJqyyMuMZ+keVDzsXKoPLgOFIyq gDV54wzwYihzr+zGcyPeM4hvgM+HyV0jR6F+N1I8bIyzdGDvV78ujrdv63ZH+cIeVZOf Pav8cR/Kb9nSJ89sdFf1mNtMArrE8UwznBGg5PcmClK1TO/L9BMVFRN8NYIEkyLcvs22 JMWQ==
X-Gm-Message-State: APjAAAVQqnCsf63Q2BNtR2TY9wBviN0oj2ZUCGQn1hchDtivribsC/WZ xrlFkQEJFDaklwYnKMWDGZer+4a6zyY=
X-Google-Smtp-Source: APXvYqyRj8FVgyqdmkFeg3yJfn2G/C9xSNehWyESoSN5Eh5yO1uAYEDpoEwJi2hjZ3IrlEry1MYIhg==
X-Received: by 2002:a05:620a:16c6:: with SMTP id a6mr19826464qkn.413.1563994164060; Wed, 24 Jul 2019 11:49:24 -0700 (PDT)
Received: from vurt.meerval.net (dhcp-9df9.meeting.ietf.org. []) by smtp.gmail.com with ESMTPSA id r4sm17864758qtt.51.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jul 2019 11:49:23 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 987d43a8; Wed, 24 Jul 2019 18:48:29 +0000 (UTC)
Date: Wed, 24 Jul 2019 18:48:28 +0000
From: Job Snijders <job@instituut.net>
To: sidrops@ietf.org
Message-ID: <20190724184828.GD81521@vurt.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/WUM8-1swy2XJ7S1GYIdWIg8mk3s>
Subject: [Sidrops] 'tagging' in draft-ietf-sidrops-validating-bgp-speaker
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 18:49:28 -0000

Hi all,

Today there was yet another incident related to a BGP hijack of an IXP
Peering LAN Prefix: an ASN originated, which is part
of This /24 route was an RPKI invalid announcement.

This misconfiguration negatively affected the AMS-IX platform, and some
of the authors are associated with this organisation. It is my hope that
a real world example of what I at the IETF 104 SIDROPS meeting
predicted, will help the authors better understand the negative security
implications of the current draft.

To better understand the severity of an event like this, one can
consider the publicly published statistics, here is a screenshot:
http://instituut.net/~job/amsix-rpki-disruption.png You can see an arrow
pointing to a low point in the graph, the graph should've been a
smoother sine-like shape.

The issue is that some BGP implementations will send the BGP packets
destined for via the hijacked route rather than via the
directly connected interface with the less-specific route. For a period
of time a few hunderd gigabit/sec was dropped on the floor; this is of
course problematic.

Now, imagine this route announcement passed through a
BGP speaker that adheres to the 'tagging' option in
draft-ietf-sidrops-validating-bgp-speaker, and instead of rejecting the
route announcement only a BGP Large Community is added to this RPKI
invalid announcement. I can assure everyone that the presence or absense
of that BGP Large Community will do *nothing* to reduce the negative
consequences of the existence of such a invalid more-specific /24.

It is my hope that the authors now recognize that knowingly propagating
RPKI Invalid announcements, even with a specific BGP community attached;
makes no sense from a routing security perspective. 

I propose the "tagging" option is removed from the draft document
entirely, or that the "invalid" community is removed and only the
'valid' and 'not-found' communities are specified. A BGP validating
speaker should not propagate RPKI invalid announcements, instead such
invalid announcements should be rejected; this document can state that.

Kind regards,