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

[Randy Bush]

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

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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (An Out-Of-Band Setup Protocol For RPKI Production Services) to Proposed Standard

[Rob Austein]

At Wed, 28 Dec 2016 10:55:15 +, tom p. wrote:
> 
> When I saw BPKI in the Abstract, I thought 'typo'!  Reading on, it
> isn't; in which case, it needs expanding in the Abstract.
> 
> Appendix A is in RelaxNG; I would like a reference for that language.
> 
> Is Appendix A Normative?  i.e. in the event of a mismatch between the
> body of the I-D and Appendix A, which wins?  If Appendix A, then that
> reference should be Normative.

Thanks for the review!  I agree with all of the above, will post
revisions post-LC unless there is reason to update sooner.

Yes, I think the RelaxNG schema had best be normative.  We already
found and fixed one minor disagreement between text and schema;
unsurprisingly, running code in that case agreed with the schema.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Randy Bush]

>> 2. Private ASNs (as pointed out in the SecDir review) are commonly
>> used for stubs.
> This document should include something (I’m thinking in the Ops
> Section) about the protocol considerations: there must be a ROA from
> the resource owner for the ISP to properly re-originate the Update,
> etc..

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

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Sriram, Kotikalapudi (Fed)]

Hi Alvaro,

Please see my comments inline below.

>From: Alvaro Retana (aretana) [mailto:aret...@cisco.com] 
>Sent: Friday, December 09, 2016 5:00 PM
….

>Hi!  I think the only item left is the Confederations one…
….

>Yes, I agree that the collusion problem is one that (as you mentioned below) 

>is out of the scope of BGPsec.  You are right that pCount=0 (as proposed 
>below) 

>doesn’t solve the collusion problem – but it does address the following 

>security guarantee that is currently not met in the Confederations case (from 
>8.1):
….

In the latest version-21 of the draft that I uploaded last Friday, 
I have incorporated the solution that you have proposed, 
namely, adding a signature with pCount = 0, 
at the border of the confederation (see 2nd, 3rd, and 4th paragraphs 
added newly in Section 4.3, page 18).

As I see it, this solution offers the following three benefits:

1. It eliminates the discontinuity issue at the confederation boundary and 
hence facilitates maintaining the security guarantee within confederations as 
well.

2. It allows for tolerance to lack of proper configuration in a BGPsec speaker
in an interior AS in a confederation, i.e. when such a BGPsec speaker
is not configured to know its confederation’s public AS number.

So it addresses the following comment you made earlier:
“In this network AS65003 (for example) only needs to know (i.e. be configured) 
that AS65001 and AS65004 as confederation peers, 
and not the specific knowledge of which is the confederation ID.”
https://www.ietf.org/mail-archive/web/sidr/current/msg08126.html 

(Randy’s post also seemed to hint that this tolerance would be useful:
https://www.ietf.org/mail-archive/web/sidr/current/msg08127.html )

3. A common description of the validation algorithm (Section 5.2) applies to
all BGPsec speakers. That is, no exceptions need to be stated for 
BGPsec  speakers inside a confederation.
(Previously we had described such exceptions in Section 4.3,
but now they are not needed any more and hence deleted.)

>Related to the above, is the support for private ASNs --- 
this topic also came up in the review of draft-ietf-sidr-bgpsec-ops, 
and the GenArt/SecDir reviews.  There are two related points:

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

> 2. Private ASNs (as pointed out in the SecDir review) are commonly used for 
> stubs.  
This document should include something (I’m thinking in the Ops Section) 
about the protocol considerations: there must be a ROA from 
the resource owner for the ISP to properly re-originate the Update, etc..

There are two new paragraphs in the ops and mgmt. section (Section 7, page 30)
that discuss proper handling of private ASNs that may be used for stub ASes 
or inside confederations.

Please let me know if I missed anything or if you would like to suggest 
any wording improvements.

Thank you.

Sriram

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr