Found 3 records.

Status: Verified (1)

RFC 4724, "Graceful Restart Mechanism for BGP", January 2007

Note: This RFC has been updated by RFC 8538

Errata ID: 7915
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Haas
Date Reported: 2024-04-29
Verifier Name: John Scudder
Date Verified: 2024-10-09

Throughout the document, when it says:

(See corrected text.)

It should say:

Please add the "Updates: 4271" metadata.

RFC 4724 updates the BGP Finite State Machine (FSM) for RFC 4271, the base BGP-4 specification.  This RFC should UPDATE RFC 4271.

Notes:

Nick Hilliard points out that we are missing this "updates" for the RFC.

Status: Held for Document Update (2)

RFC 4724, "Graceful Restart Mechanism for BGP", January 2007

Note: This RFC has been updated by RFC 8538

Errata ID: 6217
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nir Chako
Date Reported: 2020-06-29
Held for Document Update by: Alvaro Retana
Date Held: 2020-07-21

Section 7 says:

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.

It should say:

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

Errata ID: 4193
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2014-12-04
Held for Document Update by: Alia Atlas
Date Held: 2014-12-04

Section 4.2 says:

See Section 8 for a description of this behavior

It should say:

See Section 5 for a description of this behavior

Report New Errata