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

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Mon, 2 Jan 2017 15:32:48 +0000

See my comments inline

On 12/29/16, 6:23 PM, "sidr on behalf of Randy Bush" <[email-masked] on behalf of [email-masked]> wrote:

    >>> 1. It is common to use private ASNs in Confederations, 
    >> but the global RPKI can’t support that.  draft-ietf-sidr-slurm seems
    >> to address the issue of local management of private resources in the
    >> RPKI.  …
    
    >the issue is not how the confed AS validates ROAs of the private ASs in
    >the confed.  that is trivial and supported by existing software.  my
    >questions revolve around path processing.

I believe the answer to your question is found in section 7, paragraph #8 and following. 
There I see explanation on how to process the path using private AS numbers, etc.

    >4.3 confuses me by using 'private' ambiguously.  i have tried to read
    >that section yet again and drowned in the mass of words.  perhaps more
    >coffee will help; but i am not optimistic.  i pity the implementors. 
    >
    >randy    

Revisiting Section 4.3, I made the following observations:
In my opinion the second Paragraph explains clearly the process of the ingress BGPSec 
router at the confederation boundary. I believe the process described of adding a 
signature with pCount=0 will resolve the issue that Alvaro observed.

Said that, I feel that the explanations in paragraphs #3 and #4 are not very helpful. 
There I do agree with Randy's "mass of words" comment. I suggest to either shorten 
them or completely remove them. These two paragraphs are not needed, in contrary 
they might add unnecessary confusion.

When removed the following current paragraphs 5 and following do explain clearly the
process in the intermediate AS-members and the egress BGPSec router of the 
confederation.

In short I think paragraphs #3 and #4 disrupt the flow and are not so helpful,
so I propose to remove them.

To avoid unnecessary confusion with the ambiguity of the word private, I would change 
the wording of “the (private) Member-AS Number” to “the Member-AS Number” by 
removing the wording of “(private)” within parenthesis. 
This leaves the usage of private only for the signing parties private key which I think 
is well understood.

Oliver

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 3 Jan 2017 07:17:32 +0000

>From: Randy Bush <[email-masked]>
>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

---

From: David Farmer <[email-masked]>
Date: Tue, 3 Jan 2017 16:33:54 -0600

> This leaves the usage of private only for the signing parties private key

I'd suggest the use of "private use" in the parenthesis instead of
eliminating the word "private", and maybe add an informational reference to
RFC6996 as well.  If the intent that a "Member-AS Number" is to be from the
private use range as defined in RFC6996, then that should be stated some
place.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Jan 2017 12:04:50 +0900

>        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