Hi all.
Just to let this group know that we’ve started the process of activating the dropping of Invalids for all our eBGP customers.
We’re starting off with our Juniper edge routers. Once those are done, we’ll move on to our Cisco ASR1006 routers, finishing off with our Cisco ASR920 routers.
I’ll let you know if anything catches fire :-).
Mark.
mark,
Just to let this group know that we've started the process of
activating the dropping of Invalids for all our eBGP customers.
cool. any stats and lessons appreciated.
randy
Mark
Invalid according to RPKI or IRR? Or both?
Regards
as
Dear Arturo, group,
Invalid according to RPKI or IRR? Or both?
In this context the use of the word “invalid” refers to the result of validation procedure described in RFC 6811 - which is to match received BGP updates to the RPKI and attach either of “valid”, “invalid”, or “not-found”.
In IRR, the challenge has always been that “route:” objects describe a state of the network that may exist, but the semantics of “route:” objects don’t allow extrapolation towards what should definitely not exist in the BGP Default-Free Zone.
RPKI ROAs (compared to IRR objects) carry different meaning: the existence of a ROA (both by definition and common implementation) supersedes other data sources (IRR, LOAs, or comments in whois records, etc), and as such can be used on any type of EBGP session for validation of the received Internet routing information.
Kind regards,
Job
RPKI ROAs (compared to IRR objects) carry different meaning: the existence of a ROA (both by definition and common implementation) supersedes other data sources (IRR, LOAs, or comments in whois records, etc), and as such can be used on any type of EBGP session for validation of the received Internet routing information.
Which brings me to my favorite possible RPKI-IRR integration: a ROA that says that IRR objects on IRR source x with maintainer Y are authoritative for a given number resource. Kinda like SPF for BGP.
Rubens
Is this required? or a crutch for use until a network can publish all
of their routing data in the RPKI?
-chris
Will do, Randy.
Mark.
According to RPKI.
Mark.
Which brings me to my favorite possible RPKI-IRR integration: a ROA that says that IRR objects on IRR source x with maintainer Y are authoritative for a given number resource. Kinda like SPF for BGP.
Is this required? or a crutch for use until a network can publish all
of their routing data in the RPKI?
It provides an adoption path based on the information already published in IRRs by operators for some years. It also covers for the fact that RPKI currently is only origin-validation.
Rubens
it sounds like a great idea which is a terrible idea. Each operator will make their own choice about what RPKI TALs to accept. Once they're loaded up on the rpki caches, do you really want to push more complexity down to the router control plane with and start making per-device choices about how to handle the trust level of each individual ROA? The internet dfz is already being killed with complexity. Configuring per-prefix trust levels at a per-device level is nuts - and wholly non-scalable.
If you don't want to see ROAs from a specific source, then don't import their TAL.
Nick
I would think that if you(royal you) already are publishing:
"these are the routes i'm going to originate (and here are my customer lists)"
and you (royal you) are accepting the effort to publish 1 'new' thing
in the RPKI.
you could just as easily take the 'stuff I'm going to publish in IRR'
and 'also publish in RPKI'.
Right? So adoption path aside, because that seems like a weird
argument (since your automation to make IRR data appear can ALSO just
send rpki updates), your belief is that: "Hey, this irr object is
really, really me" is still useful/required/necessary/interesting?
-chris
Right, but you’re also taking a strong, cryptographically-authenticated system and making it sign non-authenticated data. Please don’t do that. If you want to add the data to RPKI, there should be a way to add the data to RPKI, not sign away control of your number resources to unauthenticated sources.
The history of development of BGP path-validation standards does not give much hope so far… people never seen to be able to agree on how to do it.
OTOH, people seem comfortable publishing those relations in IRR… and some using that for prefix-filter building, including AS 15169 that presented yesterday on an IX conference and said preferring using IRR over RPKI to automate prefix filtering.
Frankly, I’ll take any form of authenticated path-validation that gets traction in the DFZ, whether it’s pretty or not. Pure RPKI for both origin and path validation looks much better to me, but will it fly ?
Rubens
Right, but you’re also taking a strong, cryptographically-authenticated system and making it sign non-authenticated data. Please don’t do that. If you want to add the data to RPKI, there should be a way to add the data to RPKI, not sign away control of your number resources to unauthenticated sources.
I don't think that's what I was saying, at all, actually.
I was saying:
"I assume you must have some system to create IRR data, that system
knows: '1.0.1.0/24 ASFOO MAINT-FOOBAR' is ok."
that system could now add '1.0.1.0/24 ASFOO' to the RPKI.
Where does that say: "make it sign unauthenticated data" ?
>
>
>>
>> > Which brings me to my favorite possible RPKI-IRR integration: a ROA that says that IRR objects on IRR source x with maintainer Y are authoritative for a given number resource. Kinda like SPF for BGP.
>> >
>>
>> Is this required? or a crutch for use until a network can publish all
>> of their routing data in the RPKI?
>>
>
> It provides an adoption path based on the information already published in IRRs by operators for some years. It also covers for the fact that RPKI currently is only origin-validation.I would think that if you(royal you) already are publishing:
"these are the routes i'm going to originate (and here are my customer lists)"and you (royal you) are accepting the effort to publish 1 'new' thing
in the RPKI.you could just as easily take the 'stuff I'm going to publish in IRR'
and 'also publish in RPKI'.
Right? So adoption path aside, because that seems like a weird
argument (since your automation to make IRR data appear can ALSO just
send rpki updates), your belief is that: "Hey, this irr object is
really, really me" is still useful/required/necessary/interesting?The history of development of BGP path-validation standards does not give much hope so far... people never seen to be able to agree on how to do it.
I think path-validation is .. BGPSec - rfc8206
right? so clearly some folks agreed on the process/path/etc for
validating paths in bgp.
Will that get deployed? unclear to me... To get it deployed though
we'd need to start at the beginning of the story and get RPKI data
published.
OTOH, people seem comfortable publishing those relations in IRR... and some using that for prefix-filter building, including AS 15169 that presented yesterday on an IX conference and said preferring using IRR over RPKI to automate prefix filtering.
oh, someone presented yesterday, cool... err... I think their
presentation says (or should have said?) something like:
"today we plan to use IRR data, we'll be adding RPKI data as it's
available and we're comfy with the integration efforts..."
(that's what this preso said anyway:
Science project - Google Slides
when i presented it 2x)
I think that's still the project plan...
Frankly, I'll take any form of authenticated path-validation that gets traction in the DFZ, whether it's pretty or not. Pure RPKI for both origin and path validation looks much better to me, but will it fly ?
<insert will it blend meme>
I think the RPKI adoption and usage in the DFZ and near-to-dfz is
picking up (says the graphs, etc).
I'd love to see it more picked up, but folk don't REALLY have a need
for it 'yet', once more large players start publishing and requiring
though 
the goal of the slide deck above, and job's efforts and mark's efforts
and jay/nimrod's efforts (and cloudflare/maaaaahtin/jerome/etc .. plus
a host of others) is to make it apparent: "Hey, get your data
straight, publish in RPKI, start validating!"
-chris
Ah, right. Fair. I was responding, I suppose, to Rubens' original
description, which was exactly this.
[ found in old emacs buffer. might have already been sent ]
Invalid according to RPKI or IRR? Or both?
In this context the use of the word “invalid” refers to the result of
validation procedure described in RFC 6811 - which is to match received BGP
updates to the RPKI and attach either of “valid”, “invalid”, or “not-found”.In IRR, the challenge has always been that “route:” objects describe a
state of the network that may exist, but the semantics of “route:” objects
don’t allow extrapolation towards what should definitely *not* exist in the
BGP Default-Free Zone.RPKI ROAs (compared to IRR objects) carry different meaning: the existence
of a ROA (both by definition and common implementation) supersedes other
data sources (IRR, LOAs, or comments in whois records, etc), and as such
can be used on any type of EBGP session for validation of the received
Internet routing information.
do not disagree with your pedantry. but ...
as i am pretty sure arturo knows all that. i suspect he was wondering
if mark is gonna throw irr data in the mix the way chris says google
will (or does?). and if so, how? seems a useful question.
irr acls scale poorly in routers. but mark said customer-facing, which
could be reasonable depending on the platform. e.g. ntt uses irr-based
acls toward customers.
but i am cheered if mark is dropping rpki-based origin validation
invalids. it's a big step.
randy
as i am pretty sure arturo knows all that. i suspect he was wondering
if mark is gonna throw irr data in the mix the way chris says google
will (or does?). and if so, how? seems a useful question.
No, we'll be focusing solely on RPKI.
irr acls scale poorly in routers.
One of the reasons we have been putting all our energy into RPKI since 2014.
but mark said customer-facing, which
could be reasonable depending on the platform. e.g. ntt uses irr-based
acls toward customers.
So we have 4 main systems for customer edge termination:
\- MX480's, primarily used in the data centre\.
\- ASR1006's, also primarily used in the data centre for non\-Ethernet
customers (waning, over time).
- ASR920's, used in the Metro.
- MX204's, used in the Metro.
Mark.
but mark said customer-facing, which
could be reasonable depending on the platform. e.g. ntt uses irr-based
acls toward customers.So we have 4 main systems for customer edge termination:
\- MX480's, primarily used in the data centre\. \- ASR1006's, also primarily used in the data centre for non\-Ethernetcustomers (waning, over time).
- ASR920's, used in the Metro.
- MX204's, used in the Metro.
so junos and xr support rov sufficiently for production. cool!
randy
And IOS XE too...
Mark.