Brian,
Thank you for the feedback, comments are in-line below
Brian Dickson wrote:
(Sorry in advance - long post ahead. Please read, however, when you have
time, everyone. There's some valuable operator input here.)
<snip>
I think I understand what you're saying.
However, I am trying to reconcile several things, and am having
difficulty in figuring out what EE/ROA things need to be issued, by
whom, and what the validation methodology is.
I'm specifically considering the BGP default-free zone, and prefixes
seen globally.
Here's how filters can be built today:
* IP allocations are done
o either entire PA blocks to ISPs for reassignment to their
customers, and aggregation to the whole block before global
announcement (at least in theory)
o or PI blocks to end sites who are multi-homed
* IRR registration is made by the originating AS (the ISP or
multi-homed entity, using its own ASN as Origin: attribute for
Route: objects, plus its Aut-num: object)
* IRR registration is made for as-sets (hierarchically, too, to
arbitrary depth) reflecting customer/transit relationships
* IRR registration of peering announcements (who announces what to
whom, in RPSL) is done
* Expansion of IRR contents on a per-peer or per-customer basis is
done, expanding into permitted AS_PATH and PREFIX lists (not
necessarily tied together, unfortunately, and not necessarily as
complete as we would like)
In the "-roa-" drafts, the term "originate" is used consistently, but I
am unclear if that maps 1:1 with "Origin:" in the IRR. Does it mean,
strictly, originate, or does it also mean "announce to a peer", where
the announcer heard it from some third party, i.e. the announcer has the
prefix with a non-empty as-path?
I can see how the first recipient of such an announcement could validate
the prefix based on ROA.
How does someone more than one AS away validate using ROAs, if he/she is
not able to know for certain that the sender is also authorized to send
all prefixes for the remote AS (the alleged originator)?
And/or, presumably, there is the ability to authorize an upstream AS to
announce all of one's AS, and that that is a transitive property.
Is the ROA used for this, or is there some other "thing" that is used
for signing/validating?
[MBL]: It seems that our documents need to define "originate" more
clearly. The intended meaning is that the "originating" AS is the one
who initially injects an advertisement into the routing system (i.e. as
the term is used in Section 5.1.2 of RFC 4271), and does not refer to an
AS that receives an advertisement from a peer and forwards the
advertisement to other peers. I believe this corresponds to the use of
the "Origin:" attribute in the IRR.
[MBL]: Also let me attempt to be clear as to the problem that ROAs are
attempting to solve. The use of validated ROAs as an (additional) input
to the filter generation process allows the prevention of the following
limited class of attacks: Consider an AS who (perhaps accidently due to
mis-configuration) emits a BGP UPDATE message originating a route to a
prefix to which he is not authorized to originate routes (e.g. an ISP
operator in Pakistan mistakenly announces a route to a prefix owned by
youtube.com). Any ISP that receives such an invalid advertisement
(either directly or by way of a peer who propagates the invalid
announcement) can use data from validated ROAs to determine that the
advertisement is invalid.
[MBL]: Note that no one is claiming that the current SIDR work is
sufficient to prevent all attacks on the routing system. Indeed, as you
indicate, ROAs alone are insufficient to detect cases where an
intermediate ISP receives a valid announcement that the ISP is not
permitted to propagate, but (either maliciously or accidently) prorates
the announcement anyway. However, the infrastructure being developed by
SIDR is a necessary first step in creating more comprehensive routing
security solutions (such as S-BGP or SO-BGP) which could be used to
prevent such attacks by intermediaries.
Now, for a use case:
There are classes of allocations which are made in a very particular
method, which I believe the RIRs would like to have means for
restricting their use.
These are "critical infrastructure" assignments, typically /24's to be
used in a PI fashion, which may be assigned en mass, e.g. from larger
ranges of contiguous space (perhaps by coincidence, but contiguous
nonetheless).
These could show up as a sequence of /23,/22,/23,/24 (for a set of 9
prefixes).
Operators of DNS infrastructure, among others, are critically dependent
on the availability and use of these, and having the ability to trust
routing announcements of these prefixes is of first-order importance to
SIDR, IMNSHO.
In these cases, I believe the RIR would want to issue the ROA itself,
and do so in such a way as to only permit /24's to be announced, and
only by a specific ASN originator. I do not believe the RIR would want
to cede control of the larger blocks, only (at best) the individual /24's.
And, in particular, the RIR would not want the recipient ASN to be able
to "glue together" the contiguous pieces, and certainly not to be able
to assign the glued bits to some third party, especially for money.
If it were technically feasible for a large chunk of "critical
infrastructure" space to be (a) aggregated, and (b) sold on the black
market, it would be bad all-around, for operators of critical
infrastructure, for the RIR, and for the processes involved.
That is one use case. However unlikely the scenarios described, they are
of enough concern for me to document. That at a minimum, I would hope,
is sufficient for the WG to give consideration to the security
considerations involved, and to view the minLength issue from that
perspective.
[MBL]: Thank you for the use case. The problem you raise above is not
one that I had envisioned that SIDR would solve, however, is there is a
simple way for the SIDR architecture to be modified to meet additional
RIR requirements then we should certainly consider such modification.
What confuses me in this example, however, is how the aggregation of
"critical infrastructure" space is the problem. If an RIR wishes to
prevent a party receiving IP resources from transferring those resources
to another party (e.g. on the black market) then the RIR could in theory
issue the ROA itself (and not issue a certificate to the party receiving
the addresses) which allows the RIR to maintain control over which AS's
can originate routes to the given address space. (Personally, I don't
know if any RIRs are planning to do this, but it is certainly
technically possible). On the other hand, if an RIR chooses to issue a
certificate to a party receiving IP resources then the mechanisms
specified in SIDR are completely in-capable of preventing the receiving
party from transferring the resources without the RIR's consent (e.g. on
the black market) --- And this seems true regardless of whether there is
a minLength field in a ROA.
In any case, I personally believe that the SIDR Resource PKI is an
inefficient way for the RIRs to enforce policy upon the LIRs. So I'm
personally not inclined to make changes in an attempt to make the
R-PKI suitable for that purpose. With regards to your second example,
if the LIR wants to prohibit a an end-user from announcing prefixes
through another provider (hole punching), then I think the right
answer is for the LIR NOT to issue a certificate to the end-user (this
prevents the end-user from issuing ROAs that grant permissions to
other providers) and instead to issue an appropriate ROA for the
aggregate prefix (which persumably names the LIR's own AS number).
What about BGP MPLS VPNs? If an ISP gives a chunk of space to a customer
to use on the customer's VPN, and wants to run BGP to the customer for
PE-CE routing, and wants to ensure that the customer only announces
prefixes it is supposed to, and to do the filtering per site, the ISP
would ideally want to issue an ROA, with a longer minLength than the
block itself, but not announce the more-specific to the world. The ISP
would not want to have the customer announce any other prefixes. The ISP
would also want to enforce BCP 38, and would want to filter *packets*
based on RPKI (sidr). How else, other than ROA(s) is this possible?
And what if the customer is so big, that they are the only recipient of
an ROA from a large CIDR block? (Hint - think about large global
organizations like IATA, or various DOD departments).
[MBL]: This seems like a good example (which hasn't come up in past
discussions) for us to keep in mind. I don't know whether we can make
the R-PKI work for MPLS VPNs, but I'd certainly like to do so if it can
be done with only minor changes to the architecture (e.g. the addition
of an extra ROA field). I apologize for my ignorance, but f you could be
a little more specific here, it would help me. In particular, I'm
confused here as to what is "the block itself" as compared to the
prefixes that the customer should be advertising.
Not to be too pedantic, but:
The IETF policy is that the mailing list is where things get decided.
Meetings are for useful discussions, and for getting "the sense of the
room".
However, the absence of voices of concern, at a meeting, is not
sufficient reason to discount discussion on technical issues and merits,
on the mailing list.
[MBL]: My apologies, I did not mean to say that we should discount
further discussion of the issue based on what had been said at IETF 72,
I am only saying that the discussion at IETF 72 led me to personally
believe that the existence of use-cases necessitating a minLength field
was unlikely. But I'm happy to continue discussing this issue on the
list, and it may very well turn out that I was mistaken.
There are *definitely* cases where advertising the aggregate prefix can
and will do harm.
Consider Bill Manning's /16 for ep.net (exchange point allocations).
Each of those is used as a /24 (or /23 or /22 for big exchanges).
Announcing the aggregate, or any portion thereof, would likely cause
harm, and at a minimum facilitate wide-scale abuse, like pointing
default at peers on an exchange.
It's one example, but far from the only example.
[MBL]: It seems to me that in order for minLength to be needed, we'd
require a case in which an AS was authorized to originate routes to two
adjacent /24's but it would be harmful if the AS instead initiated a
route to the aggregate /23. Is this such a case?
I'd suggest that however unlikely, the presence of a single extra field,
may save someone's bacon somewhere down the road.
I wouldn't want to be counted among those opposing its inclusion, if not
having it caused someone a real operational problem, just because we
couldn't come up with a big enough example at the time.
I'd rather have it included and never get used, than exclude it and
cause a headache for someone.
It's analogous to free speech. I may disagree vehemently with you, but I
will always fight for your ability to express those insipid comments :-)
Brian
[MBL]: Weighing the potential for future operational problems versus the
added implementation complexity of adding rarely-used features to a
specification is always challenging (see for example, the other current
SIDR thread regarding multiple signatures on a ROA). I'm personally
hesitant to include a feature without understanding the use-cases that
necessitate such a feature, but others in the working group may
disagree. Finally, I very much appreciate your feedback, and please do
not take my response as arguing vehemently against inclusion of a
minLength field (I'm really just trying to better understand the
underlying use-cases).
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
