IETF Logo Mail Archive

Re: [Idr] New BGP capability to advertise running daemon version

Job Snijders <job@ntt.net> Fri, 02 August 2019 15:21 UTC

Return-Path: <job@ntt.net>
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 7F2D0120423 for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 nSdt-7JXh85j for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:21:13 -0700 (PDT)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:1401:17::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCDE12041E for <idr@ietf.org>; Fri, 2 Aug 2019 08:21:13 -0700 (PDT)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <job@ntt.net>) id 1htZMn-0000uN-Ap (job@us.ntt.net) for idr@ietf.org; Fri, 02 Aug 2019 15:21:13 +0000
Received: by mail-oi1-f178.google.com with SMTP id t76so57118106oih.4 for <idr@ietf.org>; Fri, 02 Aug 2019 08:21:13 -0700 (PDT)
X-Gm-Message-State: APjAAAXIS9+Bx0mYe5Umqa3Zc6g2TfaC8b9p2lfXvNRwFnxDIhRtMfII RNNbUYkg0RzujJmyiI//zzeSIrvy5uovYn2VRGw=
X-Google-Smtp-Source: APXvYqzQhbdTXwXgweaZFqgIJKlma/JkIrqagp5xLY1k7wNWFYdQMIn8VxhBA3RqEnRoiF29V2z25IgBCnq8TV4LJMM=
X-Received: by 2002:aca:5dd6:: with SMTP id r205mr3246321oib.17.1564759272725; Fri, 02 Aug 2019 08:21:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAPF+HwV3EEUza3FyiXsd_oSkj80OwY-tE2DgFWnynq1FL2tLHg@mail.gmail.com> <015d56c13d01436890da2b8a7179fac9@turkcell.com.tr> <CAPF+HwV2Df6qcRD+GrE_JFv8W5Yh3OACKZrdv1Bw4PXQbjtDyQ@mail.gmail.com> <20190802150251.GA11217@pfrc.org> <CACWOCC_J6-wMWx7KL2dza5A77KFnoabMt7oAY-xhsGb8Vf3O5w@mail.gmail.com> <CAOj+MMFL7FVciSx1NyCp9zCPXZeRtNn4J-O1vS8btg96ZbDRuA@mail.gmail.com>
In-Reply-To: <CAOj+MMFL7FVciSx1NyCp9zCPXZeRtNn4J-O1vS8btg96ZbDRuA@mail.gmail.com>
From: Job Snijders <job@ntt.net>
Date: Sat, 03 Aug 2019 00:21:01 +0900
X-Gmail-Original-Message-ID: <CACWOCC_+X2bVWa3iFmb6eQ8FVvvn98h_B12HVVundcqCsd+-Lw@mail.gmail.com>
Message-ID: <CACWOCC_+X2bVWa3iFmb6eQ8FVvvn98h_B12HVVundcqCsd+-Lw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Donatas Abraitis <donatas.abraitis@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>, Job Snijders <job@ntt.net>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009c37d5058f23e888"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8IzrJCJeN_PKIJSvyFAxD0qN9AE>
Subject: Re: [Idr] New BGP capability to advertise running daemon version
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 02 Aug 2019 15:21:17 -0000

Perhaps this work should be picked up again.

On Sat, Aug 3, 2019 at 00:19 Robert Raszuk <robert@raszuk.net> wrote:

> Hi,
>
> Just to refresh memory there is an active WG document precisely describing
> how to carry such information between BGP peers. It is called BGP
> Operational Message
>
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>
> The ADVISE TLV there section 3.4.1 and 4 are proposed with the very same
> intention as this discussion is targeting.
>
> Due to no customer push vendors have not implemented it yet. So the draft
> is just hanging waiting for implementations.
>
> I think if there is some new interest please consider to review the linked
> WG doc and possibly augment it with missing elements.
>
> Use of BGP capabilities in current state of implementation of bgp dynamic
> capabilities is really not the right messaging vehicle here.
>
> Thx,
> R.
>
> On Fri, Aug 2, 2019 at 11:09 AM Job Snijders <job@ntt.net> wrote:
>
>> Right now operators use the peer’s MAC address and certain TCP
>> behaviorism (nmap -O) to attempt to conclude what the remote side might be
>> in case of issues.
>>
>> I see value in having this on by default. Security through obscurity
>> isn’t the best defense anyway. I’m assuming a degree of trust exists
>> anyway, why else set up a BGP session in the first place?
>>
>> I think there are valid use cases, i think it is worthwhile exploring how
>> to implement this concept.
>>
>> Kind regards,
>>
>> Job
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>

v2.23.0 | Report a Bug | By Email