Stephen, Please see response below.
>From: sidr <[email protected]> on behalf of Stephen Farrell ><[email protected]> >Sent: Wednesday, January 4, 2017 4:45 PM >To: Montgomery, Douglas (Fed); Russ Housley >Hiya, >On 04/01/17 21:39, Montgomery, Douglas (Fed) wrote: >> The RPKI validating caches *are* the relaying parties for BGPsec, they are >> (a) designed to be run on a separate box than the router itself and (b) >> their behavior WRT exchanges with RPKI repositories is independent of BGP >> message processing by any of the routers that they serve. >Sure. That makes sense. But where's it stated for BGPsec that >the RP ought act that way? I propose adding the following paragraph in Section 7. Please let me know if this would help resolve your concern/comment. The deployment structure, technologies and best practices concerning global RPKI data to reach routers (via local RPKI caches) are described in [RFC6810] [RFC7115] [I-D.ietf-sidr-bgpsec-ops] [I-D.-ietf-sidr-delta-protocol] [rsync]. For example, serial-number based incremental update mechanisms are used for efficient transfer of just the data records that have changed since last update [RFC6810]. Update notification file is used by relying parties (RPs) to discover whether any changes exist between the state of the global RPKI repository and the RP's cache [I-D.-ietf-sidr-delta-protocol]. The notification describes the location of the files containing the snapshot and incremental deltas which can be used by the RP to synchronize with the repository. Making use of these technologies and best practices results in enabling robustness, efficiency, and better security for the BGPsec routers and RPKI caches in terms of the flow of RPKI data from repositories to RPKI caches to routers (in distilled form). If you feel that the following sentence adds additional value, it can be added at the end: In particular, by following these methods, security concerns related to possible correlation of RPKI data access and BGP update events are also mitigated. You may edit/suggesting any wording improvements. I look forward to your further guidance on this. Thank you. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
