IETF Logo Mail Archive

Re: [Idr] Unknown Attributes seen in the wild

Robert Raszuk <robert@raszuk.net> Sun, 30 October 2016 20:05 UTC

Return-Path: <rraszuk@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 0FD16129436 for <idr@ietfa.amsl.com>; Sun, 30 Oct 2016 13:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Eqdi5NBgKb-L for <idr@ietfa.amsl.com>; Sun, 30 Oct 2016 13:05:08 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 E7E791279EB for <idr@ietf.org>; Sun, 30 Oct 2016 13:05:05 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id t79so17302018wmt.0 for <idr@ietf.org>; Sun, 30 Oct 2016 13:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NG7NjGOAzGLxOkhTJ8b5k9XHr/Qm0fP0KtJy/x805NE=; b=KIRfayRRCy41Ng5Bwsh7gwj5omlwFrj43jKDv/5V6J3r5gtbf3f+lOHbmH5Af89CgM RAEhp0idnPOUvHjGHP9boTt4fwtZCvjzPmz6Fi7vmwAt3yeS/hHuAC1z3/iJRqDOJbe5 GbVwPR8ks2Y9rteP5Er7JSFZB9Zz23zEslc1T+poVw/6v0H6hE1pKxzdrOuzCMe16gz5 m4c0bzp+k1Rf2628ROirWseWsWMi1NQQBfjOlY35pHrrzsRXbEY+RA0Dim92YbpZLhmX NLmX2T9NZOoeVeqryJTuY2i2rRs9yK4VJGsok9YGplGxmGlDVErzQCwkSJfzSgLnJ7TE WlIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NG7NjGOAzGLxOkhTJ8b5k9XHr/Qm0fP0KtJy/x805NE=; b=Rev5qaXaUJ+1qXdO3NmAoC2cAwb/YEjObtG3HcGIAyTsQgcPskHTP/TEJt5ysHEa2A dKZKxUBeCD4KZ/96tbT+GlCs1twDJ4WIZgDCbqfDIG8O1rchqlOqtCXWodn3HfuMprGh /RRSf3o92fw4bZrqUxQbC+VLjLGJ5y5UOQS6Mc4nodtzhme2anjlP9zCSSEpInDUPN9j AXwu7fO8eFBOgFptCJ8G5/m6e3w5aSKfZeipq4RXlWxluMXpq8Oaq09kRrc6vAumNS/Q 43u1sm9e5m2Uo2OKgndSW2XLl1A8/QzvByEJRyYwml3+bqzJuOohLdlIHN1SN8iahmsn sYpg==
X-Gm-Message-State: ABUngvdCVkSmc3m9K1VuYpZudDk/gUkjNXIPGrmKHZ4mIv1TGi8WAZo1bpBeDKpg4EL5GTz7/ZptjtonsinrpA==
X-Received: by 10.28.185.203 with SMTP id j194mr3899611wmf.73.1477857904320; Sun, 30 Oct 2016 13:05:04 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sun, 30 Oct 2016 13:05:03 -0700 (PDT)
In-Reply-To: <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <alpine.LRH.2.20.1610212230270.31112@espargaro.jakma.org> <b65b4b10-6635-05f5-035c-66b94f0c8b84@spakka.net> <CA+b+ERk5=rbUGXk32cgjW=cOQDg+O+k4jK4hK1HpX7S0M34QTA@mail.gmail.com> <efe998a5-869e-dcb7-e51f-a28a1a16c70b@spakka.net> <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 30 Oct 2016 21:05:03 +0100
X-Google-Sender-Auth: xxVsh7f0f3M9APzb5e96_59goZE
Message-ID: <CA+b+ERk7mbTTFUkDvJzLgPR8+G1dq5svGgJxpn1gQKBu6VnVXw@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Content-Type: multipart/alternative; boundary="001a1148ebca6a658105401a9b11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/h13JCNG4XMjYJybtkEO72zfjsBw>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] Unknown Attributes seen in the wild
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 30 Oct 2016 20:05:10 -0000

Jakob,

contained != restricted

Moreover there is number of overlay solutions in the wild which run under
the cover BGP with various self defined attributes and safis. Just think
about SD-WAN or DC overlay solutions.

Some of them tried to take IETF path some never bothered seeing how hard is
to get early IANA allocations or being aware of multiple implementation
requirement.

Some are limited to contained deployments some are encrypted. It is close
to impossible to now list all of those.

It was pretty clear this is coming ... one strategic solution was an
attempt 6 years back to separate BGP into BGP used for transport for all of
the application and services (new BGP port) and BGP used for Internet
routing (179). That would allow complete separation of the two.

https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

Thx,
r.

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> There is no concept of a BGP attribute being "restricted" to a safi. If
> that were the case, then you could use a single attribute code for
> completely different attributes in different safis. An attribute that is
> understood in one safi, but nonsense in a second safi will cause a
> malformed update rather than an unknown attribute when received in the
> second safi.
>
> Thanks,
> Jakob.
>
> > On Oct 30, 2016, at 12:16 PM, Colin Petrie <colin@spakka.net> wrote:
> >
> >> On 30/10/16 19:05, Robert Raszuk wrote:
> >> The good news is that they should not be leaked as they are to be send
> >> in their dedicated SAFIs so unless peer exchanges right capabilities
> >> they should be quite contained.
> >
> > In this case, we see them appear on BGP sessions that only negotiate
> > IPv4/Unicast or IPv6/Unicast.
> >
> > Cheers,
> > Colin
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email