Matthias Wichtlhuber wrote on 07/01/2025 15:17:
Hi Tobias, grow,
> I believe that _something_ should be done to prevent this from going further.
Agreed. Thisrecommendationcan in fact create a security hole by
opening the peering LAN to third parties. I would really appreciate if
we could get rid of thisquickly.
At best, this section is a lot less compelling than it might seem on
cursory inspection. Many mid-sized IXPs and larger have direct or nearby
connectivity to significant chunks of the DFZ, and many networks don't
use next-hop-self on their internal networks. In practice this means
that regardless of whether the IXP advertises the prefix or not, it will
find its way around large chunks of the internet anyway.
Putting data on this, INEX's route-collector has visibility to 350k
prefixes, i.e. around 1/3 of the DFZ, and INEX is by no means the
largest IXP out there. The larger IXPs have visibility of > 80% of the
DFZ. Although network A having visibility of network B isn't the same as
the other way around, it would be fair to assume that many IXPs will
have significantly wider visibility of their peering LAN prefix than
might be immediately apparent, and in particular in ways which cannot be
controlled by the IXP.
I'd prefer the section to be dropped completely, and to leave it to
individual IXPs to make their own minds up about what their routing
policy should be for their address space.
Nick
I will send some feedback to the authors.
Matthias
On 07.01.25, 14:15, "Tobias Fiebig"
<tobias=40fiebig...@dmarc.ietf.org> wrote:
Moin,
NIST just published a draft document on BGP Security & Resillience:
https://doi.org/10.6028/NIST.SP.800-189r1.ipd
<https://doi.org/10.6028/NIST.SP.800-189r1.ipd>
<https://doi.org/10.6028/NIST.SP.800-189r1.ipd%3e>
In the past I had suggested that it might be good to move forward with
draft-ietf-grow-bgpopsecupd (considering the adoption of draft-fiebig-
grow-routing-ops-terms / draft-fiebig-grow-routing-ops-sec-inform so
they can be appropriately referenced therein), as otherwise standards
bodies might pick up BCP194 and derive requirements that 'might not be
ideal'.
The above document now does that, stating on Page 25:
"""
Security Recommendation 27: An Internet exchange point (IXP) should
announce—from its route server to all its member ASes—its LAN prefix or
its entire prefix, which would be the same as or less specific than its
LAN prefix. Each IXP member AS should, in turn, accept this prefix from
the IXP and reject any more-specific prefixes (of the IXP announced
prefix) from any of its eBGP peers.
"""
I believe that _something_ should be done to prevent this from going
further.
I see four options here:
- Move ahead _quickly_ with replacing RFC7454 in BCP194
- Move ahead _quickly_ with a -bis just dropping the IXP-LAN related
text
- Move ahead _quickly_ and write a short document saying 'no IXP prefix
in the GRT, set ROAs for AS0' (This, though, might make some non-
friends among some IXes as well, as it takes away choice to a degree)
- Accept that we will all need way more space in our FIB and RIB.
Furthermore, the authors are requesting input via email to:
sp800-...@nist.gov <mailto:sp800-...@nist.gov>
The comment period is: January 3, 2025 - February 25, 2025
I would argue that some input for them on the matter might be
beneficial.
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl <mailto:tob...@fiebig.nl>
_______________________________________________
GROW mailing list -- grow@ietf.org <mailto:grow@ietf.org>
To unsubscribe send an email to grow-le...@ietf.org
<mailto:grow-le...@ietf.org>
_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
