[Idr] [Technical Errata Reported] RFC4724 (6217)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 29 June 2020 19:30 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 8B4A43A0CBE for <idr@ietfa.amsl.com>; Mon, 29 Jun 2020 12:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 vJQ6PJQZnCFn for <idr@ietfa.amsl.com>; Mon, 29 Jun 2020 12:30:23 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAB73A0CA9 for <idr@ietf.org>; Mon, 29 Jun 2020 12:30:23 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id B3D87F4075F; Mon, 29 Jun 2020 12:30:05 -0700 (PDT)
To: rsrihari@cisco.com, enkechen@cisco.com, rex@juniper.net, jgs@juniper.net, yakov@juniper.net, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, jgs@juniper.net, shares@ndzh.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: nir.chako@CyberArk.com, idr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200629193005.B3D87F4075F@rfc-editor.org>
Date: Mon, 29 Jun 2020 12:30:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BTQB6Eh--LCNS39jlf0AIJKWs9c>
X-Mailman-Approved-At: Mon, 29 Jun 2020 12:31:58 -0700
Subject: [Idr] [Technical Errata Reported] RFC4724 (6217)
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, 29 Jun 2020 19:30:28 -0000
The following errata report has been submitted for RFC4724, "Graceful Restart Mechanism for BGP". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6217 -------------------------------------- Type: Technical Reported by: Nir Chako <nir.chako@CyberArk.com> Section: 7 Original Text ------------- Since with this proposal a new connection can cause an old one to be terminated, it might seem to open the door to denial of service attacks. However, it is noted that unauthenticated BGP is already known to be vulnerable to denials of service through attacks on the TCP transport. The TCP transport is commonly protected through use of [BGP-AUTH]. Such authentication will equally protect against denials of service through spurious new connections. If an attacker is able to successfully open a TCP connection impersonating a legitimate peer, the attacker's connection will replace the legitimate one, potentially enabling the attacker to advertise bogus routes. We note, however, that the window for such a route insertion attack is small since through normal operation of the protocol the legitimate peer would open a new connection, in turn causing the attacker's connection to be terminated. Thus, this attack devolves to a form of denial of service. It is thus concluded that this proposal does not change the underlying security model (and issues) of BGP-4. We also note that implementations may allow use of graceful restart to be controlled by configuration. If graceful restart is not enabled, naturally the underlying security model of BGP-4 is unchanged. Corrected Text -------------- Since with this proposal a new connection can cause an old one to be terminated, it might seem to open the door to denial of service attacks. However, it is noted that unauthenticated BGP is already known to be vulnerable to denials of service through attacks on the TCP transport. The TCP transport is commonly protected through use of [BGP-AUTH]. Such authentication will equally protect against denials of service through spurious new connections. If an attacker is able to successfully open a TCP connection impersonating a legitimate peer, the attacker's connection will replace the legitimate one, potentially enabling the attacker to advertise bogus routes. We note, however, that the window for such a route insertion attack is small since through normal operation of the protocol the legitimate peer would open a new connection, in turn causing the attacker's connection to be terminated. Thus, this attack devolves to a form of denial of service. However, it is possible to downgrade the session so it will be devoided of capabilities via the NOTIFICATION message for OPEN messages with an Unsupported Optional Parameter subcode. RFC5492 specifies that if a peer receives this type of NOTIFICATION message, it SHOULD try to re-establish the BGP connection without capabilities and, among other things, reduce the use of Graceful Restart Capability. Therefore, in this situation, if the attacker is the first to establish a BGP connection with the peer, he might secure his route advertising position. This time, the legitimate peer won't be able to open a new connection and terminate the attacker's connection. Thus, this attack devolves into a form of a man-in-the-middle attack. It is thus concluded that this proposal does not change the underlying security model (and issues) of BGP-4. We also note that implementations may allow use of graceful restart to be controlled by configuration. If graceful restart is not enabled, naturally the underlying security model of BGP-4 is unchanged. Notes ----- The change in this section is the addition of a paragraph between paragraph 2 and paragraph 3 in the original section which describes an attack process where the attacker can gain a permanent grip on the connection Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4724 (draft-ietf-idr-restart-13) -------------------------------------- Title : Graceful Restart Mechanism for BGP Publication Date : January 2007 Author(s) : S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG
- [Idr] [Technical Errata Reported] RFC4724 (6217) RFC Errata System
- Re: [Idr] [Technical Errata Reported] RFC4724 (62… John Scudder
- Re: [Idr] [Technical Errata Reported] RFC4724 (62… Alvaro Retana
- Re: [Idr] [Technical Errata Reported] RFC4724 (62… John Scudder