The uses cases listed below pertain to {Prefix, Orgin} validation,
and are not yet included in draft-manderson-sidr-usecases-01
http://tools.ietf.org/html/draft-manderson-sidr-usecases-01
We plan to include them in the next updated revision (as a SIDR WG draft) which
we
(Terry, myself, Russ) expect to submit soon.
Your comments are requested.
These use cases try to systematically enumerate the situations a relying party
may encounter while receiving a BGP update and making use of ROA information to
interpret the validity of the prefix-origin information in the update. We
systematically enumerate the situations or scenarios but do not make a final
recommendation on any RPKI interpretation at this point. We have included some
comments on plausible RPKI recommendations. However, it is fully acknowledged
that these recommended RPKI interpretations can be overridden by ISP’s local
policy. It would generally be up to an ISP to make choices regarding the
interpretation or decision, based on various considerations, including their
view of “Partial Deployment”, “Full Deployment” of RPKI, etc.
Taxonomy:
Update prefix: Prefix seen in an update
ROA prefix: Prefix contained in a ROA
Covering Prefix: When we say that a ROA prefix is a covering prefix for an
update prefix, what is meant is that the ROA prefix in an exact match or a less
specific when compared to the update prefix.
No relevant ROA: It means that there is no ROA that has a covering prefix for
the update prefix.
No other relevant ROA: It means that there is no other ROA (besides any that
is(are) already cited) that has a covering prefix for the update prefix
1. Covering ROA Prefix, Maxlength Satisfied, and AS Match:
ROA: {10.1.0.0/16, maxlength = 20, AS64496}
Update has {10.1.0.0/17, Origin = AS64496}
Recommended RPKI prefix-origin validation interpretation: TBC
Comment: This is a straight forward prefix-origin validation use case; it
follows from the primary intention of creation of ROA by a resource owner.
Recommended RPKI validation interpretation could be: The announced
prefix-origin pair is Valid.
2. Covering ROA Prefix, Maxlength Exceeded, and AS Match:
ROA: {10.1.0.0/16, maxlength = 20, AS64496}
Update has {10.1.0.0/22, Origin = AS64496}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC
Comment: In this case the maxlength specified in the ROA is exceeded by the
update prefix. Recommended RPKI validation interpretation could be: The
announced prefix-origin pair is Invalid.
3. Covering ROA Prefix, Maxlength Satisfied, and AS Mismatch:
ROA: {10.1.0.0/16, maxlength = 24, AS64496}
Update has {10.1.88.0/24, Origin = AS65551}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC
Comment: In this case an AS other than the one specified in the ROA is
originating an update. This may be a prefix or subprefix hijack situation.
Recommended RPKI validation interpretation could be: The announced
prefix-origin pair is Invalid.
4. Covering ROA Prefix, Maxlength Exceeded, and AS Mismatch:
ROA: {10.1.0.0/16, maxlength = 22, AS64496}
Update has {10.1.88.0/24, Origin = AS65551}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC
Comment: In this case the maxlength specified in the ROA is exceeded by the
update prefix, and also an AS other than the one specified in the ROA is
originating the update. This may be a subprefix hijack situation. Recommended
RPKI validation interpretation could be: The announced prefix-origin pair is
Invalid.
5. Covering ROA Prefix Not Found:
Update has {240.1.1.0/24, Origin = AS65551}
No relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC
Comment: In this case there is no relevant ROA that has a covering prefix for
the update prefix. It could be a case of prefix or subprefix hijack situation,
but this announcement does not contradict any existing ROA. During partial
deployment, there would be some legitimate prefix-origin announcements for
which ROAs may not have been issued yet. Recommended RPKI validation
interpretation could be: Announced prefix-origin pair has ‘no ROA’.
6. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set of More
Specifics:
ROA: {10.1.0.0/18, maxlength = 20, AS64496}
ROA: {10.1.64.0/18, maxlength = 20, AS64496}
ROA: {10.1.128.0/18, maxlength = 20, AS64496}
ROA: {10.1.192.0/18, maxlength = 20, AS64496}
Update has {10.1.0.0/16, Origin = AS64496}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC
Comment: In this case the update prefix is an aggregate, and it turns out that
there exit ROAs for more specifics which, if combined, can help support
validation of the announced prefix-origin pair. But it is not recommended that
we apply any leniency in this situation. The announced aggregate prefix should
be required to have a ROA which can be directly used for validation.
Recommended RPKI validation interpretation could be: The announced
prefix-origin pair is Invalid.
7. Update has an AS Set as Origin and ROAs Exist for a Covering Set of More
Specifics:
ROA: {10.1.0.0/18, maxlength = 20, AS64496}
ROA: {10.1.64.0/18, maxlength = 20, AS64497}
ROA: {10.1.128.0/18, maxlength = 20, AS64498}
ROA: {10.1.192.0/18, maxlength = 20, AS64499}
Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498, AS64497]}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC
Comment: In this case the aggregate of the prefixes in the ROAs is a covering
prefix for the update prefix. The ASs in each of the contributing ROAs together
form a set that matches the AS set in the update. An extremely small percentage
(~0.1%) of eBGP updates are seen to have AS set in them as origin; this is
known as proxy aggregation. It is recommended that announcements with an AS set
as origin should be discouraged. Recommended RPKI validation interpretation
could be: The announced prefix-origin pair is Invalid.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
