>> that is not the core of the problem. the bgpsec protocol doc has to >> specifically say that the public AS upon receiving the update from the >> private AS >> o if the private signed to the public, public should check sig, then >> strip it and then might sign as the originating AS or might not. on >> what criteria does it decide? >> o if the private did not sign, the public might sign or it might not. >> on what criteria does it decide? > >> as i said, once you burn that in, i will hack the ops doc > > Does this change (in Section 7 in the document) work for you? > > [OLD] > > It is possible that a stub customer of an ISP employs a private AS > number. Such a stub customer cannot publish a ROA in the global RPKI > for the private AS number and the prefixes that they use. Also, the > stub customer cannot become a BGPsec speaker. If a BGPsec speaker in > the ISP's AS receives an announcement for a prefix from the stub > customer and chooses to propagate it to BGPsec peers, then it MUST > strip the private AS and re-originate the prefix. In order to do > this, the prefix MUST have a ROA authorizing the ISP's AS to > originate it. > > [NEW] > > It is possible that a stub customer of an ISP employs a private AS > number. Such a stub customer cannot publish a ROA in the global RPKI > for the private AS number and the prefixes that they use. Also, the > global RPKI cannot support private AS numbers for issuing router > certificates for eBGP routers in the private AS. For interactions > between the stub customer and the ISP, the following two scenarios > are possible: > > 1. The stub customer sends an unsigned BGP update for a prefix to > the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose > to propagate the prefix to its non-BGPsec and BGPsec peers. If > so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the > private AS number, and then (a) re-originate the prefix without > any signatures towards its non-BGPsec peer and (b) re-originate > the prefix including its own signature towards its BGPsec peer. > In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in > the global RPKI authorizing the ISP's AS to originate it. > > 2. The ISP and the stub customer may use a local RPKI repository > (using a mechanism such as described in [I-D.ietf-sidr-slurm]). > Then there can be a ROA for the prefix originated by the sub AS, > and the eBGP speaker in the stub AS can be a BGPsec speaker > having a router certificate, albeit the ROA and router > certificate are valid only locally. With this arrangement, the > stub AS sends a signed update for the prefix to the ISP's AS. An > edge BGPsec speaker in the ISP's AS validates the update using > RPKI data based the local RPKI view. Further, it may choose to > propagate the prefix to its non-BGPsec and BGPsec peers. If so, > the ISP's edge BGPsec speaker MUST strip the Secure_Path and the > Signature Segment received from the stub AS with the private AS > number, and then (a) re-originate the prefix without any > signatures towards its non-BGPsec peer and (b) re-originate the > prefix including its own signature towards its BGPsec peer. In > both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the > global RPKI authorizing the ISP's AS to originate it.
i am easily confused. can this be said with significantly less words so i have a chance to actually understand it? randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
