Hi all,
Some nits, notes and questions after going through the -15. This is an
interpretation of someone with barely any operational experience,
reading the text in isolation (thus, not comparing it to RFC7454 /
BCP194).
I do think this document is useful, regardless of how much the reader is
involved in operations, or for how long. It seems to be a good basis,
touching upon all the points at an understandable level without the
reader drowning in details. So, I support moving this document forward.
sec 3.1
"exceeding prefix limits, i.e., a loss of an established session"
s/a loss/loss/ ?
sec 4.
"Importing or exporting incorrect or malicious routes is a security risk
for receiving networks"
What is a "receiving network" here, one receiving route information via
BGP? Or receiving traffic based on exchanged ("incorrect or malicious")
routing information?
4.1
"Operators are cautioned to evaluate carefully how accepting a default
route affects their network, as this occludes limitations in forwarding
coverage by the upstream from which the default route was received."
This is hard to parse for me. Reading 'occludes' as 'to block off
something', followed by 'limitations' makes me think this is some kind
of double negative, but I'm really not sure what this is supposed to
tell me.
4.1
bullet point 2, "For received BGP routes with AS_PATH = AS1, AS2, ..."
I interpret this as 'you should do ASPA' without the text explicitly
mentioning ASPA. If that is indeed the message, I suppose this bullet
point is there to future-proof this document while we see ASPA adoption
steadily grow?
Because at this very point in time I feel this is quite a tricky
requirement to fulfil in reality, unless I'm missing something.
Not saying this bullet point should go, as the other requirements in
that list seem to be trivial to tick off, this one stood out.
Hope this helps, thank you for all the work that went into this so far
already,
luuk
On Thu 19 Mar 2026, 19:10, Paolo Lucente wrote:
>
> Dears,
>
> We have just extended the WCLC for this document by another 3 weeks, ending
> on 2026-04-10. This is to allow for further feedback to the document and
> because two new versions of the document were released since starting WGLC.
>
> Encouraging anybody who has read the document to provide feedback or support
> WGLC by replying to this thread.
>
> Paolo
>
>
> On 25/2/26 18:23, Paolo Lucente via Datatracker wrote:
> > This message starts a WG Last Call for:
> > draft-ietf-grow-bgpopsecupd-12
> >
> > This Working Group Last Call ends on 2026-03-13
> >
> > Abstract:
> > The Border Gateway Protocol (BGP) is a critical component in the
> > Internet to exchange routing information between network domains.
> > Due to this central nature, it is important to understand the
> > security and reliability requirements that can and should be ensured
> > to prevent accidental or intentional routing disturbances.
> >
> > Previously, security considerations for BGP have been described in
> > RFC7454 / BCP194. Since the publications of RFC7454, several
> > developments and changes in operational practice took place that
> > warrant an update of these best current practices. This document
> > obsoletes RFC7454, focusing on the overall goals, and providing a
> > less implementation centric set of best practices.
> >
> > This document describes security requirements and goals when
> > operating BGP for exchanging routing information with other networks,
> > and explicitly does not focus on specific technical implementations
> > and requirements.
> >
> > File can be retrieved from:
> >
> > Please review and indicate your support or objection to proceed with the
> > publication of this document by replying to this email keeping [email protected]
> > in copy. Objections should be explained and suggestions to resolve them are
> > highly appreciated.
> >
> > Authors, and WG participants in general, are reminded of the Intellectual
> > Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> > Appropriate IPR disclosures required for full conformance with the
> > provisions
> > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> > Sanctions available for application to violators of IETF IPR Policy can be
> > found at [3].
> >
> > Thank you.
> >
> > [1] https://datatracker.ietf.org/doc/bcp78/
> > [2] https://datatracker.ietf.org/doc/bcp79/
> > [3] https://datatracker.ietf.org/doc/rfc6701/
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-grow-bgpopsecupd/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-grow-bgpopsecupd-12.html
> >
> > A diff from the previous version is available at:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bgpopsecupd-12
> >
> > _______________________________________________
> > GROW mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> GROW mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
