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

2017-01-03 Thread Randy Bush 
>> 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

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

2017-01-03 Thread David Farmer 
On Mon, Jan 2, 2017 at 9:32 AM, Borchert, Oliver (Fed) <
oliver.borch...@nist.gov> wrote:
>
> 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
>

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:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
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)

2017-01-02 Thread Sriram, Kotikalapudi (Fed) 
>From: Randy Bush 
>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
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)

2017-01-02 Thread Borchert, Oliver (Fed) 
See my comments inline

On 12/29/16, 6:23 PM, "sidr on behalf of Randy Bush"  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 

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

2016-12-29 Thread 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] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

2016-12-29 Thread 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)

2016-12-29 Thread 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

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

2016-12-21 Thread Randy Bush 
> IOW, AS65003 doesn’t necessarily always know that AS65001 is also AS2.
> It may not know the confederation ID at all, or it may even think that
> AS65001 is also some other AS.

and this is within spec.  we have no measure of how common this is, and
it would be hard to measure due to the problem of vantage points.  such
is life with bgp.

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)

2016-12-21 Thread Alvaro Retana (aretana) 
On 12/21/16, 12:47 PM, "Sriram, Kotikalapudi (Fed)" 
 wrote:



Sriram:



Hi!



| I said in my previous post:

| "(2) It also keeps confed ASes from failing to validate properly the 
signature injected at the boundary."

|

| I retract my observation…

…

|

| So let us focus back on only your original concern.

| If we need the solution of "confed AS signing to itself with  pCount = 0",

| it would be only to address your original concern of an apparent 
discontinuity.

| I looked at the implications of the solution once again.

| While it may be easy to describe it in terms of sender actions,

| the solution would have ripple effects in several places in the document.

|

| So I wish to take another fresh look at your concern with your help,

| and try to understand if there isn't another way to address it.

|

| The example scenario is:

| AS1 -> AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and 
AS65001 and AS65002 are Members)

|

| With the current specification, we have the following sequence of signed 
updates:

| (Notation: (S-i-j) means signature from AS i to AS j,

| P is the prefix; and most recent AS appears in the right most position)

|

| #1  AS1 to AS2/AS65001:  P [AS1 {(S-1-2)}]

|

| #2  AS2/AS65001 to AS2/AS65002:  P [AS1, AS65001 {(S-1-2), (S-65001-65002)}],

|

| #3  AS2/AS65002 to AS3:  P [AS1, AS2, {(S-1-2), ( S-2-3)}]

| (Secure_Path Segment and Signature within the confed are stripped)

|

| The discontinuity you are concerned about is in the middle (2nd) update 
above, i.e.,

| the first signature is from AS1 to AS2 while the second signature is from 
AS65001 to AS65002.

| Am I right?



Yes.





| But then you have observed the following earlier:

|

| "Well, the PE with both AS2 and AS65001 *is* both AS2 *and* AS65001…so I 
don’t see it as a proxy."

| https://www.ietf.org/mail-archive/web/sidr/current/msg08107.html

|

| Given this observation, would you accept that there is no discontinuity in 
update #2 above

| since AS65001 is AS2?

|

| If this is acceptable, then can we assert that the security guarantee is 
Section 8.1

| is good inside confederations as well with the understanding that each member 
AS

| is also the public AS of the confed? For instance, AS65002 is cognizant that

| AS65001 is also AS2. So AS65002 does not see a discontinuity.



No, it is not ok to me.



Even though in theory all the routers in a confederation know the confederation 
ID, in practice the only reason that it is needed is if an external (to the 
confederation) peering session exists in that member AS.  In other words, it is 
possible to configure a router to be an “internal” member (i.e. not having any 
external-to-the-confederation peers) by only indicating the confederation peers 
and not the confederation ID.



For example, extending the network above:



AS1 -> AS2/AS65001 -> AS65003 -> AS65004 -> AS65002/AS2 -> AS3

(AS2 is the Confederation ID and AS65001, AS65002 AS65003, AS65004 are Members)



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.  In fact, if AS65003 was configured with the 
wrong confederation ID (AS4, for example), everything would still work with no 
issues, because the confederation ID wouldn’t be used in the existing peering 
sessions.



IOW, AS65003 doesn’t necessarily always know that AS65001 is also AS2.  It may 
not know the confederation ID at all, or it may even think that AS65001 is also 
some other AS.



Yes, I have to admit that we could argue whether either case/or both (of not 
knowing the proper confederation ID) is a misconfiguration…but the fact 
persists that there is no explicit indication that AS2 intended to send the 
Update to AS65001 (even if they are, or should be, the same box).





This is where I think we’re again at a place where we’re probably agreeing to 
disagree – and where more input from the WG would be great.   I am happy to be 
in the rough if the WG agrees with you.





Thanks!



Alvaro.
___
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)

2016-12-21 Thread Sriram, Kotikalapudi (Fed) 
Hi Alvaro,



I said in my previous post:

"(2) It also keeps confed ASes from failing to validate properly the signature 
injected at the boundary."




I retract my observation that the document had a problem in that

"confed ASes fail to validate properly the signature injected at the boundary."

The document does not have that problem. My apologies for not being careful 
earlier.

Confed ASes do validate properly the signature injected at the boundary :)

Because the document says the following in Section 4.3 (page 18):



When validating a received BGPsec update message, confederation
   members need to make the following adjustment to the algorithm
   presented in Section 
5.2.
  When a confederation member processes
   (validates) a Signature Segment and its corresponding Secure_Path
   Segment, the confederation member must note the following.  For a
   signature produced by a peer BGPsec speaker outside of a
   confederation, the 'Target AS Number' will always be the AS
   Confederation Identifier (the public AS number of the confederation)
   as opposed to the Member-AS Number.


So let us focus back on only your original concern.
If we need the solution of "confed AS signing to itself with  pCount = 0",
it would be only to address your original concern of an apparent discontinuity.
I looked at the implications of the solution once again.
While it may be easy to describe it in terms of sender actions,
the solution would have ripple effects in several places in the document.


So I wish to take another fresh look at your concern with your help,
and try to understand if there isn't another way to address it.


The example scenario is:
AS1 -> AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and 
AS65001 and AS65002 are Members)


With the current specification, we have the following sequence of signed 
updates:
(Notation: (S-i-j) means signature from AS i to AS j,
P is the prefix; and most recent AS appears in the right most position)


#1  AS1 to AS2/AS65001:  P [AS1 {(S-1-2)}]


#2  AS2/AS65001 to AS2/AS65002:  P [AS1, AS65001 {(S-1-2), (S-65001-65002)}],


#3  AS2/AS65002 to AS3:  P [AS1, AS2, {(S-1-2), ( S-2-3)}]
(Secure_Path Segment and Signature within the confed are stripped)


The discontinuity you are concerned about is in the middle (2nd) update above, 
i.e.,
the first signature is from AS1 to AS2 while the second signature is from 
AS65001 to AS65002.
Am I right?


But then you have observed the following earlier:


"Well, the PE with both AS2 and AS65001 *is* both AS2 *and* AS65001...so I 
don't see it as a proxy."
https://www.ietf.org/mail-archive/web/sidr/current/msg08107.html


Given this observation, would you accept that there is no discontinuity in 
update #2 above
since AS65001 is AS2?


If this is acceptable, then can we assert that the security guarantee is 
Section 8.1
is good inside confederations as well with the understanding that each member AS
is also the public AS of the confed? For instance, AS65002 is cognizant that
AS65001 is also AS2. So AS65002 does not see a discontinuity.


Thank you.


Sriram

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

2016-12-20 Thread Alvaro Retana (aretana) 
Hi!

I am (obviously) fine with it.

Thanks!

Alvaro.

Thumb-typed and autocorrected..

> On Dec 20, 2016, at 5:56 PM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> If we agree and others on the WG list express no objection or find no fault 
> in this solution, I will be happy to go ahead and add this solution for the 
> confederation case (it requires just a couple of sentences to be added the 
> spec).

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

2016-12-20 Thread Sriram, Kotikalapudi (Fed) 
Thinking about it some more, I now find that your proposed solution of adding a 
signature with pCount = 0 at the border of the confederation works well and 
fully addresses these two concerns (the second concern is new).

(1) Your proposed solution addresses the concern you brought up in an earlier 
message -

https://www.ietf.org/mail-archive/web/sidr/current/msg08081.html

(2) It also keeps confed ASes from failing to validate properly the signature 
injected at the boundary.  This is explained below.

First let us take note of the following two instructions that are in the spec:

(a)  From page Section 4.3 (page 16):

"When a confederation

   member sends a BGPsec update message to a peer that is a member of

   the same confederation but is a different Member-AS, the

   confederation member puts its (private) Member-AS Number (as opposed

   to the public AS Confederation Identifier) in the AS Number field of

   the Secure_Path Segment that it adds to the BGPsec update message."

(b)  From Section 5.2 (page 25):  (note: this one is part of the method of 
identifying the Target AS while assembling the data to be hashed for signature 
validation)

"For each other Signature Segment (N smaller than K), the 'Target

  AS Number' is AS(N+1), the AS number in the Secure_Path segment

  that corresponds to the Signature Segment added immediately after

  the one being processed."

Now I will explain what I mean by (2) above using the same example that you 
presented earlier:

AS1 -> AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and 
AS65001 and AS65002 are Members)

In this example, by "signature injected at the boundary", we mean the signature 
of AS1 to AS2 (in the update received by AS65001). Let us think about the step 
where AS65002 is processing the update from AS65001 and validating the 
"signature injected at the boundary". Following step (a) above, AS65001 put in 
its own private AS number (i.e. AS65001) in the Secure_Path Segment that it 
added to the BGPsec update message forwarded to AS65002. Therefore, following 
step (b), AS65002 identifies AS65001 to be the 'Target AS Number' for the data 
to be hashed for validating the signature. However, this would falsely result 
in 'Invalid' outcome for the signature being validated by AS65002. Because AS1 
actually signed to AS2 (the public AS number), and hence the 'Target AS Number' 
is actually AS2.

Now the solution: Your suggested solution says that AS65001 should add a 
signature where it uses the private key of the public AS (i.e. AS2) to sign and 
forward the update to itself (AS65001) with pCount = 0. Correspondingly, 
AS65001 also puts in the public AS number (i.e. AS2) in the Secure_Path Segment 
that it adds to the BGPsec update message sent to itself. (Please correct me if 
I misunderstood.) This helps to fully address the problem identified above. 
(Note that AS65001 follows instruction (a) when it subsequently forwards the 
update to AS65002, and AS65002 follows instruction (b) while validating. The 
validation now works without the error identified above.)

If we agree and others on the WG list express no objection or find no fault in 
this solution, I will be happy to go ahead and add this solution for the 
confederation case (it requires just a couple of sentences to be added the 
spec).

Thank you.

Sriram
___
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)

2016-12-15 Thread Alvaro Retana (aretana) 
On 12/13/16, 7:26 AM, "Sriram, Kotikalapudi (Fed)" 
 wrote:



> [Sriram-3] I understand now your main comment about confederation. I think 
> there are

> two ways to address it (of course I hope other people chime in as well):

>

> Choice A: The pCount = 0 solution that you have suggested.

>

> But I feel that this is somewhat a cosmetic solution. In your example, it can 
> be perhaps

> questioned whether the signature with pCount = 0 from AS2 to AS65001 does 
> actually fit

> the security guarantee from Section 8.1 that you’ve cited.  Because AS2 (the 
> AS with the

> public ASN) did not produce that signature directly. Instead AS65001 played 
> proxy for

> AS2 -- which is of course part of the original solution anyway. So we may 
> consider choice

> B below.



Well, the PE with both AS2 and AS65001 *is* both AS2 *and* AS65001…so I don’t 
see it as a proxy.



> Choice B: Include a caveat to the statement in Section 8.1. For instance, we 
> modify it as

> follows:

>

> For each AS in the path, a BGPsec speaker authorized by the holder

>  of the AS number intentionally chose (in accordance with local

>  policy) to propagate the route advertisement to the subsequent AS

>  in the path (except for a minor caveat that applies in the case of 
> BGPsec speakers

>   in a  confederation). The caveat applies because a BGPsec speaker

>   in a confederation-member AS can be a proxy receiver and signer for the 
> public AS

>   (identified by the public AS number of the confederation). Therefore, a 
> signature that > appears to

>  correspond to an AS with the public AS number may actually

>  be proxy produced by a member AS that has an internal AS number

>  not matching the public AS number. The confederation-member ASes

>  are cognizant of this and hence it poses no security concern

>  within the confederation, and it is transparent to ASes outside

>  the confederation (see Section 4.3).

>

> [Sriram-3] Do you feel Choice B makes sense?



Personally, I don’t like Choice B because it reads: “we guarantee X, except in 
a scenario where the signatures are not what they seem”…   It doesn’t give me a 
warm a fuzzy feeling, especially when we’re talking about a security-related 
document.



This is where I would like the Chairs/rest of the WG to pitch in.



…

> [Sriram-3]  Perhaps I should wait for some more IESG LC reviews to roll in 
> before I include

> this set of changes and those from Russ (Gen-ART) and Nevil (OPS-DIR)? Please 
> advise.



The IETF LC ends tomorrow.  Include the changes with anything you receive by 
tomorrow.



Thanks!



Alvaro.
___
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)

2016-12-13 Thread Sriram, Kotikalapudi (Fed) 
>Hi!  I think the only item left is the Confederations one…and we might be 
>speaking past each other.



Thanks, Alvaro. My comments are marked with [Sriram-3].



[Sriram-3] I understand now your main comment about confederation. I think 
there are two ways to address it (of course I hope other people chime in as 
well):



Choice A: The pCount = 0 solution that you have suggested.



But I feel that this is somewhat a cosmetic solution. In your example, it can 
be perhaps questioned whether the signature with pCount = 0 from AS2 to AS65001 
does actually fit the security guarantee from Section 8.1 that you’ve cited.  
Because AS2 (the AS with the public ASN) did not produce that signature 
directly. Instead AS65001 played proxy for AS2 -- which is of course part of 
the original solution anyway. So we may consider choice B below.



Choice B: Include a caveat to the statement in Section 8.1. For instance, we 
modify it as follows:



For each AS in the path, a BGPsec speaker authorized by the holder

  of the AS number intentionally chose (in accordance with local

  policy) to propagate the route advertisement to the subsequent AS

  in the path (except for a minor caveat that applies in the case of BGPsec 
speakers

  in a  confederation). The caveat applies because a BGPsec speaker

  in a confederation-member AS can be a proxy receiver and signer for the 
public AS

  (identified by the public AS number of the confederation). Therefore, a 
signature that appears to

 correspond to an AS with the public AS number may actually

 be proxy produced by a member AS that has an internal AS number

 not matching the public AS number. The confederation-member ASes

 are cognizant of this and hence it poses no security concern

 within the confederation, and it is transparent to ASes outside

 the confederation (see Section 4.3).



[Sriram-3] Do you feel Choice B makes sense?



[Sriram-3] Please see inline below for the rest of my comments (all marked with 
[Sriram-3]).





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



>   o  For each AS in the path, a BGPsec speaker authorized by the holder

  of the AS number intentionally chose (in accordance with local

  policy) to propagate the route advertisement to the subsequent AS

  in the path.



>In the case of Confederations, it cannot be (currently) verified that all the 
>ASNs in the path intentionally chose to send the update to the next ASN 
>because there is a discontinuity at the border.  For a topology like this: AS1 
>-> AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and AS65001 
>and AS65002 are Members), it can be verified that AS1 intentionally sent the 
>Update to AS2, but there is no explicit indication (even if symbolic: 
>pCount=0) of the intention for AS65001 to “receive” the update, and then be 
>able to send it to AS65002.



>I still think that this continuity issue should be addressed; it nothing more 
>just because the intentionality is mentioned as a security guarantee of BGPsec.



[Sriram-3] Please see solution choices and A and B above and the related 
discussion.



Chairs: Please poll the WG or make a decision of whether there is consensus (or 
not) to not solve this continuity issue (maybe from prior discussions on the 
list).  If the WG decides not to solve this issue (or if it was already 
discussed), I’m ok with being in the rough.



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.  Given that the signing of Updates 
is mandated, I think that support of draft-ietf-sidr-slurm is necessary; IOW, I 
think that draft-ietf-sidr-slurm should be a Normative reference.



[Sriram-3]  OK, will include draft-ietf-sidr-slurm as a normative reference.



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



[Sriram-3]  Agree. I’ll factor in your inputs and those from Joel, Russ, and 
Randy to include a paragraph on this topic in the ops and mgmt. section.



[Sriram-3]  Perhaps I should wait for some more IESG LC reviews to roll in

before I include this set of changes and those from Russ (Gen-ART)

and Nevil