Re: [Idr] Unknown Attributes seen in the wild

Robert Raszuk <robert@raszuk.net> Sun, 30 October 2016 20:37 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 C8D7512948E for <idr@ietfa.amsl.com>; Sun, 30 Oct 2016 13:37:35 -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 jqBASwcwkbcz for <idr@ietfa.amsl.com>; Sun, 30 Oct 2016 13:37:33 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 2A4F3129440 for <idr@ietf.org>; Sun, 30 Oct 2016 13:37:33 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id t79so18069559wmt.0 for <idr@ietf.org>; Sun, 30 Oct 2016 13:37:33 -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=yFxr00O7lze5dyRJUm49aG8oSuKGo49UPV6QW30eKUM=; b=OTYQYIVnoN9f/h8SGr4rzPBhkK+hQViB22bITQ6oBDDgAn9pvd7q+LTr53/rqmSllV wcw9H9agObZdx/cqv39Hs+hk6zz+085YHKKs7/FYrrQD4Zf8P4xddx+lwDQ9bLIRn8ez 6ZeA1L95I7O5RS8YdulCutkhXdBgaI6esWsJ9upT38qD7wbfZiyoS7Deb5P7vbrYI3h/ lc9/JFo4ygp0fEgX9wzifBr9mfaSzVo/1fNoK6jXszN5Sh3YqiVnBXJbdjYge3+orHvX tHynMJ6jzxgz9uo7UMcP8MhfkA0bHWgH9jL17EV9pRwvKu8cUwD7NubmxxQ1IjE7mPwV 93GA==
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=yFxr00O7lze5dyRJUm49aG8oSuKGo49UPV6QW30eKUM=; b=J78uzoxQOHlXZUmisvb57/URY6FoGmIoABttabwHitAu2jVRqPqy2OwR50jpOuBcLf 63/xamDTK367KuyO+wlZEY9QafhblRyEGvZVAjnHyNMfgIksgYo78r1u3sCCWPrn26a5 XcWGeasqU/IiPVYrqTS6t8mo/eSc14AH35V8RGI7KHyRQ5zvPqiJqNdLlWmWo/J5r0Bn pxA9+JMxnfWOf3+63gejWE0TWViiwCBxHJbZC4thQnCprBcygL5XCqiNyVJ+2vKznkyt 96wfYjSRf4ypoPrt9n3T3INTnCBYybphxc6mweE01XxgVhgllEwOTfELlNY5qLWDyX/U ei8A==
X-Gm-Message-State: ABUngvdT0EmZ4R0MysNGKwzZ386KtPwhwDvqpiGpeL3l+DGQs3NmxxrnSJ72aHhso4AqAnJgAA1NdwqE64Ib5Q==
X-Received: by 10.194.56.69 with SMTP id y5mr19569924wjp.4.1477859851636; Sun, 30 Oct 2016 13:37:31 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sun, 30 Oct 2016 13:37:30 -0700 (PDT)
In-Reply-To: <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> <70003119-429D-49AE-8126-3B462E179E71@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 30 Oct 2016 21:37:30 +0100
X-Google-Sender-Auth: NzHqiGFLfawu-uyTYXaJvvP4ihs
Message-ID: <CA+b+ERmHb_pdpJ2XeAKic_usg3Qc1KLJPD862cDOOdSz0pyV7Q@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Content-Type: multipart/alternative; boundary="047d7b86ef847c165205401b0f9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fjDhOr3-FH2NZ87KgYa3iL3sSck>
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:37:36 -0000

Those self invented attributes will not be passed/leaked as such safi they
are to be part of will not be capability negotiated in the first place with
any Internet router.

Thx,
R.

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

> 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> 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>
> 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
>>
>
>