Re: [Idr] Question about the magic bits resulting in 179

Robert Raszuk <robert@raszuk.net> Mon, 06 April 2020 20:32 UTC

Return-Path: <robert@raszuk.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 ECE993A05A0 for <idr@ietfa.amsl.com>; Mon, 6 Apr 2020 13:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=raszuk.net
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 8l5KP--B133U for <idr@ietfa.amsl.com>; Mon, 6 Apr 2020 13:32:40 -0700 (PDT)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 1CD703A0593 for <idr@ietf.org>; Mon, 6 Apr 2020 13:32:23 -0700 (PDT)
Received: by mail-oi1-x22d.google.com with SMTP id k18so14373887oib.3 for <idr@ietf.org>; Mon, 06 Apr 2020 13:32:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IunMdbhH12f9qucY+ozrZzenGInrAmP/cWTfbsd4MkY=; b=Kz0I+vy4jmYkPrA6kejrJYTX+Yu5jsxYw1XmuSIXvTZqZjt/UFt0qavdqZqJimUFew +pqbluiC1sHTEy/cux5cNVFJjAV/2COwcGdbL4/lJ6bBcyF0cQo94Q9pv2MAbWUOM4GL 7cPNlHY+DWu50tv3JAF2ZZC6CyMjeN7NsGvDSNVT4wX/MHzet4MRx5rakD29BrMZNXkb NYR36HCXZfmK2NgKWL8+oLp8qmCpz7UPnCEKj3wzyUymyr2jlnudMK5uTVHGPCxYFgrB DrRo1YSAH1z9gAGAXIivMet+xqBdrE8g8hif9u2+8UKoPqPbWl90osuTneLJ5aF8Jjh8 ud+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IunMdbhH12f9qucY+ozrZzenGInrAmP/cWTfbsd4MkY=; b=N7sBfEzefdzWs1nY/j4RoLpxVt8IqD94OUcmLZjnYkutE11HLrPX2lP8Gaq1iEzuX5 E62i2xogKrTDGm+6ee82yq/yU+71jh/8YvDkwNz+JQhytkOG684+y/UeXhB/NCCsHZTs vpGpq2suYDChacN7SyaeF+eZymaNb/84QoAfCWkahTwUOi98h6cOjLD1P4eRVIUEd9xA 2rSxEtCv1bhlZyShNVaBhyBXChi/HN+5PX/ExatoGfm9RH1Fb3iqqMNU7Ty2h/y6AkPw zW9BGEGsn8Otfo2KIgl/t58OqriiWtj3qrlDStAnaFcRwaEa7Fc7j1qPcStB/fv92zUV i1CQ==
X-Gm-Message-State: AGi0PuZV4z9PT5DJtR7BoPKdqt81VOciISGhCf26SZel1qR+OkWhUbNS Cfem1yqofeetuNq6B6OnGlVgJlxM8JS1KLKRjWqOFXWAwMc=
X-Google-Smtp-Source: APiQypIHYn7eu1osbNkGcGTW+bN2Kb0A2SEaYQJ834R6Y9Kht/09zylOl+xcrtZlcuB/rZXg3eOxP/pgCJW/SqZIbAo=
X-Received: by 2002:aca:3046:: with SMTP id w67mr926015oiw.54.1586205142236; Mon, 06 Apr 2020 13:32:22 -0700 (PDT)
MIME-Version: 1.0
References: <20200406151801.55d2550c@p50.localdomain>
In-Reply-To: <20200406151801.55d2550c@p50.localdomain>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 06 Apr 2020 22:32:12 +0200
Message-ID: <CAOj+MMHgmdUPFDqsK-161otdktmObT+dYZBQ2Znm0Dzv9LSQZw@mail.gmail.com>
To: John Kristoff <jtk@depaul.edu>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000b544b05a2a52a64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OShgz8mCjMrYDLKx5Dzj6YyNzXs>
Subject: Re: [Idr] Question about the magic bits resulting in 179
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: Mon, 06 Apr 2020 20:32:43 -0000

Hi John,

Brilliant observation. I fully support your summary.

Just FYI a bit related 10 years ago I published a draft
https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 which asked for new
single port assignment to BGP. The main reason was to separate routing
and non routing related BGP processes on any BGP speaker.

The main objection at that time was that we do not need it as we have a
wonderful BGP multi sessions idea which can easily split all incoming
updates on port 179 to different sub-processes. Well those who followed BGP
multi sessions history do know by now that it never took off. And even if
some implementations tried it did not go too far.

So yes BGP port should be either a local decision of a network operator or
when using EBGP choice of peers.

Kind regards,
R.


On Mon, Apr 6, 2020 at 10:18 PM John Kristoff <jtk@depaul.edu> wrote:

> Friends,
>
> In many software BGP implementations (e.g. BIRD, FRR, GoBGP) the BGP
> listening process and remote peer may be specified with a port other
> than 179. However, in hardware-based routers such as Cisco and Juniper,
> when I went to use a non-standard port on one of them, I noticed no
> such knob to change the default port.  It had never really occurred to
> me this was a big deal before, but now it seems sort of unusual given
> that practically all Internet services these days permit non-default
> port usage.  Note, it really is not important why I or anyone would
> want to do this, it really is beside the point.
>
> When I asked some other operators about this I got a lot of push back
> such as questioning the motive, suggesting this is nonsensical, and
> that is would not be BGP.
>
> The last idea I'd like to pose as a question to this group and use the
> resulting consensus as something that might be reference material for my
> operator friends that I think are essentially wrong.  :-)
>
> From my reading of IETF RFC 4271 - A Border Gateway Protocol 4 (BGP-4),
> 179 support is clearly required for an implementation following the
> specification. From section 8.2.1:
>
>   A BGP implementation MUST connect to and listen on TCP port 179 for
>   incoming connections in addition to trying to connect to peers.
>
> However, the requirement that an operator must use port 179 seems less
> strict and as far as I can tell is ultimately a local decision if an
> implementation support changing it. In the Administrative Events
> sections there is this (sorry for extensive quoting, but context is
> required):
>
>       Event 14: TcpConnection_Valid
>
>          Definition: Event indicating the local system reception of a
>                      TCP connection request with a valid source IP
>                      address, TCP port, destination IP address, and TCP
>                      Port.  The definition of invalid source and invalid
>                      destination IP address is determined by the
>                      implementation.
>
>                      BGP's destination port SHOULD be port 179, as
>                      defined by IANA.
>
>                      TCP connection request is denoted by the local
>                      system receiving a TCP SYN.
>
> Furthermore, from an unfinished draft-ietf-idr-bgp-issues-06
> summarizing discussion when the RFC was being finished I found this
> that drew consensus:
>
>    Sue replied that this is local policy and is implementation
>    dependent.  Siva agreed regarding the source port & IP address, but
>    disagreed about the destination port.  He argued that we need to know
>    the destination port for interoperability.
>
>    Sue asked Siva to provide some text.
>
>    After a long lull, Sue replied with:
>
>    I would like to keep the current text of "Should" in the following
>    text "BGP's destination port SHOULD be port 179 as defined by IANA."
>
>    Should indicates that it normally should be 179.  If an
>    implementation allows for an alternative TCP port, it is still valid
>    as the "MUST" is not indicated.
>
> That seems to clearly allow for an implementation or operator to use
> a port other than 179 if they choose to, and there is nothing that would
> constitute this as somehow invalid BGP or particularly wrong, if not
> uncommon or unusual. Fair assessment?
>
> Thank you for any feedback,
>
> John
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>