Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export
Note: This ballot was opened for revision 02 and is now closed.
Erik Kline Yes
Warren Kumari Yes
Comment (2020-03-20 for -02)
Background for IESG Eval: The audience of this document is BGP implementers, not the general public. It is largely a clarification, and intentionally concise to the point of terseness - think of it as a "Warning: It's easy to get this bit of the spec wrong. Here is how to navigate it correctly" document, not a protocol spec or general user document. BGP policies can be applied on egress that change the AS - an obvious example of this is removing a private AS#, or when merging ASN. Because of how / where egress policies are applied, it's very easy for an implementer to forget that this might occur, and so use the "wrong" AS when validating. This document just points that out - it doesn't, and shouldn't, go into too much detail.
(Deborah Brungard) No Objection
(Alissa Cooper) No Objection
Comment (2020-04-06 for -02)
"Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies." The normative language here doesn't quite make sense. "MUST BE" is not a normative keyword and the construction "SHOULD ... which MUST" is a little confusing. I would suggest something like: An origin validation policy that is required to be run after such non-deterministic policies SHOULD be specified.
Roman Danyliw No Objection
Martin Duke No Objection
Benjamin Kaduk No Objection
Comment (2020-04-06 for -02)
Abstract [IIRC the mention of "updates 6811" is queued already.] Section 1 As the origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which will actually be put in the AS_PATH (To the extent that the speaker applies outbound policy at all? Or is that required by being a "validating BGP speaker"?) Section 3 will (or would) be announced to the peer. The effective origin AS may differ from that of the route in the RIB due to commonly available knobs such as: removal of private ASs, AS path manipulation, confederation handling, etc. Do we feel a need to add a "but not limited to"? Feels like overkill to me... nit: earlier we wrote "private AS(s)" Section 4 Configurations may have complex policy where the final announced origin AS may not be easily predicted before all policies have been run. Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies. nit: are complex policies necessarily non-deterministic (vs. "not easily predicted")?
Murray Kucherawy No Objection
(Barry Leiba) No Objection
Alvaro Retana No Objection
Comment (2020-04-06 for -02)
(0) This document should be marked as replacing draft-ymbk-sidrops-ov-egress. (1) The purpose of this document is to clarify "that implementations must use the effective origin AS". The use of "effective" seems deliberate to qualify a specific characteristic of the origin AS. However, the term is not only not defined anywhere (with respect to simply using "origin AS", for example), but there is inconsistency in the language, for example: "origin Autonomous System number which will actually be put in the AS_PATH" or "final announced origin AS". Please be clear in the definition, and consistent in the language used. (2) §1: As the origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which will actually be put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the UPDATE to the peer. (2a) [major] "MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which will actually be put in the AS_PATH" Put where? The assumption in this text seems to be that there will only be one AS number present (even with prepending), in line with §5.1.2/rfc4271. However, rfc7705 (which Updates rfc4271) specifies AS migration mechanisms...some of which may result in more than one AS number placed in the AS_PATH (even at route origination). It is then important to clarify *where* the ASN "will actually be put", or which ASN should the validation be done against. [Note that this is a variation of the initial comment about clearly defining the terms.] (2b) [nit] s/(see [RFC4271] 4.3 Path Attributes:b)/([RFC4271]) Not only is the detailed reference unnecessary, but the format may be confusing. Also, it is §5.1.2 the section that actually talks about the use of the AS_PATH. (3) §1: It would be very nice to add these references: s/confederation, AS migration/confederation [rfc5065], AS migration [rfc7705] Given the comment above, the reference to rfc7705 should be Normative. (4) §3: "BGP implementations supporting RPKI-based origin validation SHOULD provide the same policy configuration primitives for decisions based on validation state available for use in ingress, redistribution, and egress policies." When would it be ok for an implementation not to "provide the same policy configuration"? IOW, why is MUST not used? s/SHOULD/MUST (5) §4: Configurations may have complex policy where the final announced origin AS may not be easily predicted before all policies have been run. Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies. (5a) [major] "SHOULD be possible to specify an origin validation policy" What is an "origin validation policy"? To me it sounds as the ability to either validate or not: as in, "the policy is to validate for this origin AS, but not for a different one". Is that it? Or are you referring to a blanket policy akin to "if the origin AS is X, then the route must always be considered Valid"?? [This piece of text confuses me more given the suggestion to Alissa's comments: "Therefore it SHOULD be possible to specify an origin validation policy which will run after all such non-deterministic policies." A validation policy for *all* policies??] (5b) I know that this next point was discussed on the list...but describing the outcome of complex policy as not "easily predicted" and non-deterministic is causing me a lot of heartburn. I can see how optional information in an Update (communities, etc.) can cause a policy result to be known only at "run time", but that doesn't make the outcome unpredictable or non-deterministic: the outcome of the policy is what it is supposed to be, given the current conditions -- we just didn't know before the Update was received. This is a non-blocking comment and you can consider it a nit...it simply sounds as if the operator was guessing, and I know some are not. ;-) s/...may not be easily predicted before all policies...such non-deterministic policies./...may be determined only after all policies...such policies. (6) §4: "SHOULD be able to list what announcements are not sent to a peer because they were marked Invalid, as long as the router still has them in memory." After reading this text many times, I think I understand that you mean that the operator should be able to use a "show command"...and not that he/she should be able to create a list of announcements (as in a filter). Is that what you mean? Suggestion (maybe something like this)> An implementation SHOULD display announcements that are not sent to a peer because they were marked Invalid, as long as the router still has them in memory.
Martin Vigoureux No Objection
Éric Vyncke No Objection
Comment (2020-04-08 for -03)
Thank you for the document. Randy, thank you for the fix to the the issue found by Jouri in the INTDIR review: https://mailarchive.ietf.org/arch/msg/int-dir/bUWYKX6ey404TmpXdwfdVbWv1yM Thank you Jouri -éric
(Magnus Westerlund) No Objection
Robert Wilton No Objection
Comment (2020-04-06 for -02)
I'm not a BGP expert, but this document seems sensible to me. Some comments: 1) In the first sentence of the introduction: Is it really correct that the "This document does not change semantics of [RFC6811] RPKI-based origin validation"? Given that the 4th paragraph in the introduction then states that "This document clarifies ..." 2) I wasn't entirely sure that section 2 (Suggested Reading) is required at all, given that this is effectively what section 8.1 and 8.2 is listing anyway, but equally I'm okay if the section is left in. 3) The security section is terse, and I agree that this doesn't introduce any new security issues. But I was wondering if the purpose of this clarification is to improve security with more reliable filtering, and if so, would it be helpful to have a sentence in the security section that states that? One nit: 1) In the first sentence of the introduction "of [RFC6811] of RPKI-based origin validation" -> "of [RFC6811] RPKI-based origin validation"?