>From: Randy Bush <[email protected]>
>Sent: Thursday, December 29, 2016 6:02 PM
>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.
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
