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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

>From: Randy Bush <[e-mail]>
>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