Re: [Idr] Unknown Attributes seen in the wild

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Sun, 30 October 2016 20:26 UTC

Return-Path: <jheitz@cisco.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 D865B1293EE for <idr@ietfa.amsl.com>; Sun, 30 Oct 2016 13:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level:
X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 HKUJYS5UksXO for <idr@ietfa.amsl.com>; Sun, 30 Oct 2016 13:26:15 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1B512711D for <idr@ietf.org>; Sun, 30 Oct 2016 13:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7760; q=dns/txt; s=iport; t=1477859175; x=1479068775; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YVsdhSQJD1uaI8/oZYSpqWIGt2pwFvwmW9H2H33pgRw=; b=VFthATCVHoZ3WpmsmW+ec0SKa3uI0BuxHZO9gei5DLJzWm1y+SrGX4wb XUsxwJkGWPCoND7Odoe7umUiq8/suVeQbbl2obsrwf2om8WG7stGaLB1m a8qKmzdtOc/VV8UE9f2nSkXkxeALvavnSV/Q75+ppJC07cHUMo+8WUwYC g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A2AgC1VhZY/5pdJa1dGgEBAQECAQEBAQgBAQEBgyoBAQEBAR9YfY02ln6PKIUWggcdAQqFewKCAT8UAQIBAQEBAQEBYiiEYgEBAQMBAQEBawsFCwIBCBgnBycLFBECBA4FGgGIMQgOvzkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY9gX0IglCEI4NVgi8FmhgBhi+KAIFujhaHIIVxhAEBHjZggmiCKnKFFAeCMQEBAQ
X-IronPort-AV: E=Sophos;i="5.31,423,1473120000"; d="scan'208,217";a="165462322"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2016 20:26:14 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9UKQEqx031634 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 30 Oct 2016 20:26:14 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Oct 2016 15:26:14 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 30 Oct 2016 15:26:13 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] Unknown Attributes seen in the wild
Thread-Index: AQHSKWSs7BkiNd6f2ECx5wzihKhK2KCu0JwAgAT1t4CADaRlgIAARs2AgAATqgD//7LrNIAAWruA//+yGXE=
Date: Sun, 30 Oct 2016 20:26:13 +0000
Message-ID: <70003119-429D-49AE-8126-3B462E179E71@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>, <CA+b+ERk7mbTTFUkDvJzLgPR8+G1dq5svGgJxpn1gQKBu6VnVXw@mail.gmail.com>
In-Reply-To: <CA+b+ERk7mbTTFUkDvJzLgPR8+G1dq5svGgJxpn1gQKBu6VnVXw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_70003119429D49AE81263B462E179E71ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-2aqoNqMDmV9n4mpcVTPLkq883E>
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:26:17 -0000

Send them one of those attributes in a different safi. What do you think will happen?
Will they pass it on harmlessly, like any unknown optional transitive attribute?

Thanks,
Jakob.

On Oct 30, 2016, at 1:05 PM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

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<mailto: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<mailto: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<mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr