Document: draft-ietf-grow-bgpopsecupd
Title: BGP Operations and Security
Reviewer: Daniel Migault
Review result: Not Ready
Hi,
I have reviewed this document as part of the Internet directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the internet area directors.
Document editors and WG chairs should treat these comments just like any other
comments.
I must first clarify that I am not an expert in BGP, so I may be lacking some
context. I have included my comments inline.
Yours,
Daniel
Global Routing Operations T. Fiebig
Internet-Draft MPI-INF
Obsoletes: 7454 (if approved) N. Hilliard
Intended status: Best Current Practice INEX
Expires: 10 April 2026 7 October 2025
BGP Operations and Security
draft-ietf-grow-bgpopsecupd-11
Abstract
...
1. Introduction
...
3. Protection of the BGP Speaker and Session
The BGP speaker, i.e., the node running BGP to exchange routing
information, needs to be protected from external attempts to taint
integrity or availability of the BGP session and node alike.
3.1. BGP Session Protection
To protect a BGP speaker on the network layer, an operator MUST
ensure the following properties using technical or organizational
measures:
* Prevent off-path attackers from injecting BGP messages into
existing sessions.
mglt: It is my belief that protection does not consist in preventing off-path
attacker, but instead to prevent injection from off path attacker. My
understanding of on off path attacker is that the attacker while not being able
to access the link is able to send some message. I do not necessarily see the
need to specify this is a off-path attacker as the same should be true for an
on-path attacker. At last injection may not only consists of BGP messages, but
any type of messages. As a result, I would reformulate the requirement above as
: Prevent traffic injection into BGP session
* Prevent off-path attackers from interrupting existing sessions.
mglt: I have the impression interrupting existing session will require somehow
the injection of packet in the session or in a kind of control plane. Unless I
misunderstand it this requirement is covered by the one above.
* Prevent off-path attackers from preventing the establishment of
new sessions.
mglt: I have similar comment as above.
Fiebig & Hilliard Expires 10 April 2026 [Page 3]
Internet-Draft BGP OPSEC October 2025
* Prevent remote systems from overwhelming the BGP speaker by
sending large volumes of unsolicited packets or BGP messages.
mglt: I think this requirement is to protect the BGP speaker from resource
exhaustion due to large volumes of unsolicited packets or BGP messages.
* Ensure that unstable sessions do not threaten the availability of
BGP speakers within the network.
mglt: this requirement seems covered by the previous requirement.
Example technologies to accomplish this include GTSM/TTL-security
[RFC5082], BGP-MD5 / TCP-AO [RFC5925], limiting traffic to the
control plane via Control Plane Policing (CoPP), and setting maximum
prefix limits for the number of prefixes a neighbor may send.
3.2. BGP Speaker Management Interface Protection
In addition to the control plane / exchange of BGP protocol messages,
the management plane of BGP speakers must be appropriately secured.
Hence, operators MUST ensure that:
* No unauthorized third-parties can obtain access or connect to the
management interface of a BGP speaker.
mglt: I do not see what the text below adds. Whatever way could be used this
MUST NOT happen.
in a way that allows
tainting confidentiality, integrity, or availability.
* External activity towards the management interface does not
interfere with the integrity or availability of BGP sessions.
mglt: my understanding of the management plane is that one can switch off the
router. If the requirement is that each external user is being provided some
fucntionnalities
4. NLRI Filtering
The purpose of BGP is exchanging routing information, i.e., NLRI.
Importing or exporting incorrect or malicious NLRI is a security risk
for networks themselves, but may also form a threat for connected
and/or remote networks. As such, operators MUST ensure the following
properties when importing or exporting routing information from their
neighbors.
4.1. Importing NLRI
When importing NLRI from a neighbor, an operator MUST ensure that all
imported NLRI conform to the following properties by implementing
technical or organizational measures:
* The AS originating NLRI for a prefix MUST be globally authorized
to originate that prefix. Operators MAY deviate from this for
default routes (::/0 and 0.0.0.0/0), if they granted the specific
neighbor permission to announce default routes towards them.
Fiebig & Hilliard Expires 10 April 2026 [Page 4]
Internet-Draft BGP OPSEC October 2025
* For received NLRI with an AS_PATH = {AS1, AS2, ..., ASn}, where
AS1 is the neighbor that sent the UPDATE and ASn is the
originator, for each k in 1..n−1, AS(k+1) MUST be authorized to
export the NLRI to ASk according to their bilateral routing policy
(e.g., provider–customer, peer, or lateral-peer).
* The AS_PATH MUST NOT contain AS numbers reserved for private
[RFC6996] or special-use cases, except for those AS numbers
explicitly dedicated to a special-use that requires their presence
in the global routing table [IANAASNSpec].
* The number of NLRI received from a neighbor MUST NOT exceed the
resources of the local router.
mglt: In my opinion checking the information is authorized / legitimate is
essntial BUT this is not sufficient. We also need to check it has actually be
sent BY the legitimate origin which is done via signataure.
4.2. Originating and Redistributing NLRI
When originating NLRI or redistributing NLRI received from a
neighbor, an operator MUST ensure that all NLRI they export conform
to the following properties by implementing technical or
organizational measures:
* The redistributing AS MUST be authorized to redistribute NLRI for
the specific prefix when received from the AS directly to its
right in the AS_PATH. Additionally, each AS in the AS_PATH not
originating the prefix MUST be authorized to redistribute the
prefix when receiving it from the next AS to its right.
* The AS originating NLRI for a prefix MUST be globally authorized
to originate that prefix. Operators MAY deviate from this for
default routes (::/0 and 0.0.0.0/0), if they originate the default
route and the specific neighbor granted them permission to
announce default routes towards them.
* The AS_PATH MUST NOT contain AS numbers reserved for private
[RFC6996] or special-use cases, except for those AS numbers
explicitly dedicated to a special-use that requires their presence
in the global routing table [IANAASNSpec].
mglt: same redistributor or origin MUST be authenticated to ensure the action
is not only legitimate BUT is requested.
4.3. Altering NLRI
When processing NLRI, an operator MUST ensure that basic properties
of these NLRI are not altered:
Fiebig & Hilliard Expires 10 April 2026 [Page 5]
Internet-Draft BGP OPSEC October 2025
* An operator MUST NOT change or remove immutable transitive BGP
attributes, e.g., ORIGIN as per [RFC4271]. If an attribute is
unknown to the operator it must be considered immutable. In
selected cases, if a specific attribute is known to be malicious,
an operator MAY either temporarily remove that specific attribute
from NLRI when importing them or filter NLRI carrying the
attribute.
* NLRI carried on BGP MUST NOT be enriched with transitive
attributes subject to change independent of the underlying NLRI,
e.g., encoding RPKI validation state in transitive attributes
[I-D.ietf-sidrops-avoid-rpki-state-in-bgp].
5. IANA Considerations
This document does not require any IANA actions.
6. Security Considerations
This document is entirely about BGP operational security. It lists
requirements and properties operators MUST ensure using technical or
organizational measures when operating BGP routers in the DFZ.
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
