Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

[Randy Bush <[e-mail]>]

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