Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export
draft-ietf-sidrops-ov-egress-04

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

"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.

(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.

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")?

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"?