Hello,
I support addoption of these drafts.
For draft-fiebig-grow-routing-ops-terms I do wonder if the document
should provide definitions, detailed explanations, pointers to RFCs that
already define terms, or all three. Currently it is a mix.
For example:
- DFZ is defined but not explained
- ASN is defined and explained without a reference
- BFD is not in the list of acronyms, but explained in detail with
references
Acronyms found in draft-fiebig-grow-routing-ops-sec-inform-01 that are
not defined in draft-fiebig-grow-routing-ops-terms-03, section 3:
ISP, BGP, MSS, GTSM, SIDR, ASPA, RS, MED, GSHUT
Some comments and edits for draft-fiebig-grow-routing-ops-sec-inform-01:
Abstract
--------
"The Border Gateway Protocol (BGP) is the protocol is a critical
component in the Internet to exchange routing information between
network domains. Due to this central nature, it is an accepted best
practice to ensure basic security properties for BGP and BGP speaking
routers. While these general principles are outlined in BCP194, it
does not provide a list of technical and implementation options for
securing BGP."
->
"The Border Gateway Protocol (BGP) is a critical
component in the Internet to exchange routing information between
network domains. It is an accepted best
practice to ensure basic security properties for BGP and BGP speaking
routers. While these general principles are outlined in BCP194, the BCP
does not provide a list of technical and implementation options for
securing BGP."
-
"This document lists available options for securing BGP, serving as a
contemporary, non-exhaustive, repository of options and methods. The
document explicitly does not make value statements on the efficacy of
individual techniques, not does it mandate or prescribe the use of
specific technique or implementations."
->
"This document lists available options for securing BGP, serving as a
contemporary, non-exhaustive repository of options and methods. The
document explicitly does not make value statements on the efficacy of
individual techniques, not does it mandate or prescribe the use of
specific techniques or implementations."
-
"Operators are advised to carefully consider whether the listed
methods are applicable for their use-case to ensure best current
practices are followed in terms of which security properties need to
be ensured when operating BGP speakers."
I cannot parse this sentence.
3.
--
"The BGP speaker needs to be protected from external attempts to
subvert the BGP session."
->
"The BGP speaker needs to be protected from external attempts to
subvert BGP sessions."
-
"Furthermore, access to management services of the BGP speaker should be
limited to neighbors"
Limited to authorized hosts?
3.1
---
"Experience has shown that the natural protection TCP should offer is
not always sufficient, as it is sometimes run in control-plane software"
What is the "natural protection" and how does running it "in
control-plane software" make this insufficient?
-
"it is possible to attack a BGP speaker" -> "it is possible to overwhelm
a BGP speaker"
-
"an ACL specific to the control plane of the router SHOULD be used [..]
to avoid configuration of data-plane filters [..]."
This is very confusing. I suggest removing "to avoid [..]."
-
"Some routers automatically program such an ACL upon BGP
configuration. On other devices, this ACL should be configured and
maintained manually or using scripts."
Not sure if it has value to add this.
-
"non-gloablly" -> "non-globally"
3.2
--
"This network" -> "The out-of-band management interface"
4.1.1
-----
"The drawback [..] as well."
Section 2 already says that operators should weigh trade-offs. I suggest
removing this.
-
"Aside of this, most vendors use simple, reverse-decryptable password
hash algorithm [..]"
Not sure if this should be in scope for this document.
4.1.2
-----
"In 2018 [..] To mitigate this attack,"
->
"Packet fragmentation may be used to bypass standard TCP protection
mechanisms, so routes can be injected into an established BGP session."
5.
--
"a combination of Prefix and AS paths (see )"
Empty reference.
-
"BGP roles as" -> "BGP roles"
5.3
---
"see Section 5.3"
Refers to itself
-
"Rule 11"
Which rule is meant here?
-
"Routes of this type SHOULD be annotated in away that ensures they are
not re-exported to other neighbors (see Section 6.5.2)."
6.5.2 does not describe this. Instead of a reference, explicitly mention
non-export?
-
"Several operators currently limit the smallest prefix size for IPv6 to
/16."
Do you have a reference for this?
6.1
---
"Furthermore, especially IRRs not operated by RIRs regularly list
conflicting information, see Section 6.1."
Section 6.1 refers to itself.
Add an explicit recommendation to rely on RIR-provided IRRs where available.
6.1.2
-----
"Recently, an attack was observed [..]"
Describe the generic risk, rather than the specific details and
circumstances of a single attack.
6.1.3
-----
"With these two mechanisms, a script can build, for a given
neighbor, that lists allowed prefixes and the AS number from which they
should be originated."
->
"With these two mechanisms, a script can build, for a given
neighbor, a list of allowed prefixes and the AS number from which they
should be originated."
-
"When doing requests inside such an IRR, it is possible to specify the
source of information"
->
"When doing requests inside such an IRR, it is RECOMMENDED to specify
the source of information"
-
"One could check a popular IRR [..] and only select [..]"
->
"When using an IRR containing many sources, it is RECOMMENDED to only
select [..]"
6.2
---
"Also, note that the SIDR infrastructure is complementing (not
replacing) the security best practices listed in this document."
->
"Also, note that the SIDR infrastructure is complementing (not
replacing) the other security best practices listed in this document."
6.4
---
"not filtering prefixes originated by downstreams on sessions with other
ASes solely based on the prefix is NOT RECOMMENDED."
->
"filtering [..] is NOT RECOMMENDED." or "not filtering [..] is RECOMMENDED."
6.5.1.1 / 6.5.1.2
-----------------
Remove. These sections duplicate text from RFC9234 (referred to in
6.5.1.) in slightly different wording.
6.5.2
-----
If the goal here is to filter based on roles, it is not needed to encode
neighbor ASNs in the communities. Standard BGP communities suffice for this.
6.6.2
-----
"Alternative, MAY [..]" -> "Alternative, routers MAY be configured to [..]"
7.2.1
-----
"relationshipt" -> "relationship"
-
"It is RECOMMENDED to include additional headroom of 20% when utilizing
an inferred prefix limit."
Why 20%?
-
"trigger a log" -> "trigger a warning"
7.2.2
-----
I think this whole section could be replaced with an additional sentence
in the last paragraph of 7.2.1:
"It is RECOMMENDED that operators implement continuous monitoring of all
prefix limits configured on BGP sessions."
7.3.1
-----
"In any case, operators SHOULD NOT re-export prefixes with AS_PATHs
containing private AS numbers."
->
"In any case, operators SHOULD NOT re-export these prefixes with an
AS_PATH containing private AS numbers."
-
"Private AS numbers are conventionally used [..]"
Partially duplicates the second bullet point.
-
"Overly long AS_PATH, i.e., longer than 64 entries [..]"
Where does the number 64 come from?
7.3.2
-----
There is a lot of background text in this section that could potentially
be removed, keeping only the last paragraph.
Reference draft-ietf-grow-as-path-prepending-12 for the prepend count
recommendation.
7.6
---
"While there is a list of well-known and defined transitive BGP
attributes [..]"
Add reference.
7.6.1
-----
"[..] scrub attributes they added which are not in public use before
exporting NLRI."
->
"[..] scrub non-public attributes they added before exporting NLRI."
7.6.2
-----
"The Attribute Type field [..] etc."
Seems to be superfluous information. Could be removed.
-
"Operators MAY use such, [..]" -> "Operators MAY use such [..]"
7.7
---
"oscilation" -> "oscillation"
7.8
---
"Hence, this section documents best practices when connecting to an IXP
that inflict on the reliability of the global routing ecosystem."
->
"This section documents best practices pertaining to the reliability of
the global routing ecosystem when connecting to an IXP."
8.1.2
-----
"Hence, it is RECOMMENDED that operators structure rulesets in a way
that prioritized early decisions on the majority of routes."
Refer to 8.2, mentioning that this specifies a suggested ordering for
different scenarios.
8.1.5
-----
"perfixes" -> prefixes
8.1.6
-----
"Before applying a generated ruleset, an operator should check it for
obvious errors and potentially require manual intervention to remediate
the issue."
->
"Before applying a generated ruleset, the automation should check it for
obvious errors and issues that require manual intervention to remediate."
8.2.2.1
-------
"However, additionally [..] also conform" -> "Additionally [..] conform"
8.5
---
"11. [..]" -> "10. [..]"
---
Kind regards,
Martin
_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
