Why should organization not be both orderer and peer?


Si Chen
 

Hello,

I saw in 

Question: | Can I have an organization act both in an ordering and application role?

Answer: Although this is possible, it is a highly discouraged configuration. ...


Would someone please explain a little more why that is?


Thank you.


--
-----
Si Chen
Open Source Strategies, Inc.

Join our Hyperledger Open Source Carbon Neutral Certification Working Group


Bram Dufour
 

Hi Si Chen, I think it was only the case for the Kafka orderer in earlier versions, in which only one org could run the Kafka ordering service.
 
With the raft orderer implementation, you can have a cross-organizational orderer cluster and so different orgs can have an orderer and be an application channel organization at the same time without problems.
With raft, for latency the orderer cluster shouldn't be that big though, so you can let some organizations that have the technical and financial capacity run their orderer (like miners in Bitcoin) and have other organizations only run peers (like full nodes in Bitcoin).
But like this, organizations can have orderers and application peers without problems, so I think it would be good to check the ordering service with raft and the newer Fabric versions v2.2, because the link you sent is still from v1.4 I see...
 


Pam Andrejko
 

See the topic on How many CAs are required in the CA documentation.

Because this is a distributed ledger, the ordering service should not be part of the same organization as the peers, so you will need separate organizations (and therefore CAs) for your peer organizations and ordering service organization. When multiple organizations contribute nodes to an ordering service, each ordering node would have its own organization CA. All of this separation is crucial for distributed management of the ordering service and channels and defeats the ability of a bad actor to disrupt the network.

Pam


Jason Yellick
 

----- Original message -----
From: "Pam Andrejko" <pama@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Why should organization not be both orderer and peer?
Date: Mon, Aug 17, 2020 7:40 AM
 
See the topic on How many CAs are required in the CA documentation.

Because this is a distributed ledger, the ordering service should not be part of the same organization as the peers, so you will need separate organizations (and therefore CAs) for your peer organizations and ordering service organization. When multiple organizations contribute nodes to an ordering service, each ordering node would have its own organization CA. All of this separation is crucial for distributed management of the ordering service and channels and defeats the ability of a bad actor to disrupt the network.

Pam
 


Bram Dufour
 

Thanks a lot Jason, I hadn't thought about those attacks yet.

But isn't it possible for the organizations with orderer to use the OU roles, set the following policies and just run orderer and peers within the same organization? Isn't this possible or do you still see some vulnerabilities with this approach?

Policies: &OrgPolicies
            Orderer:
                Type: Signature
                Rule: "OR('org.orderer')"

```


And then also set the BlockValidation policy like this:

```
BlockValidation: Type: ImplicitMeta Rule: "ANY Orderer"

 

Thanks a lot in advance, it is a very interesting and important topic.


Jason Yellick
 

Yes, the BlockValidation policy is the key element to protect.  And, we should probably change the default away from 'ANY Writers' to something more specific -- but any such changes create pains for existing users so need to be weighed carefully.

As the SO post mentions, it's possible to do things securely, it's just trickier, especially given some of the legacy concerns.  If you are using node OUs, the whole thing becomes much easier to accomplish safely, but, operationally dealing with having two copies of the same MSP definition can be a bit tricky.  You'll have to do updates keeping them completely in sync.

I'd still suggest sticking to separate organizations, even if they share the same CA.  You can use a common CA but distinguish MSP definition by setting an OU for that MSP which must be satisfied.  This is similar to, but different from NodeOUs.  Where NodeOUs differentiate the role of an identity based on the OU, setting OUs for the MSP overall will require for any identity to be valid, the certificate must contain some OU authorized by the MSP.  This can be especially useful when an organization wishes to use public CA infrastructure which might even be shared across organizations.

Thanks,
~Jason
 

----- Original message -----
From: "Bram Dufour" <bram.dufour8@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Why should organization not be both orderer and peer?
Date: Mon, Aug 17, 2020 12:40 PM
 

Thanks a lot Jason, I hadn't thought about those attacks yet.

But isn't it possible for the organizations with orderer to use the OU roles, set the following policies and just run orderer and peers within the same organization? Isn't this possible or do you still see some vulnerabilities with this approach?

Policies: &OrgPolicies
            Orderer:
                Type: Signature
                Rule: "OR('org.orderer')"
```


And then also set the BlockValidation policy like this:

```BlockValidation:
            Type: ImplicitMeta
            Rule: "ANY Orderer"

 

Thanks a lot in advance, it is a very interesting and important topic.

 


Si Chen
 

Thanks everybody for your feedback on this!  We'll discuss this in our group as well.
-----
Si Chen
Open Source Strategies, Inc.

Join our Hyperledger Open Source Carbon Neutral Certification Working Group



On Mon, Aug 17, 2020 at 11:25 AM Jason Yellick <jyellick@...> wrote:
Yes, the BlockValidation policy is the key element to protect.  And, we should probably change the default away from 'ANY Writers' to something more specific -- but any such changes create pains for existing users so need to be weighed carefully.

As the SO post mentions, it's possible to do things securely, it's just trickier, especially given some of the legacy concerns.  If you are using node OUs, the whole thing becomes much easier to accomplish safely, but, operationally dealing with having two copies of the same MSP definition can be a bit tricky.  You'll have to do updates keeping them completely in sync.

I'd still suggest sticking to separate organizations, even if they share the same CA.  You can use a common CA but distinguish MSP definition by setting an OU for that MSP which must be satisfied.  This is similar to, but different from NodeOUs.  Where NodeOUs differentiate the role of an identity based on the OU, setting OUs for the MSP overall will require for any identity to be valid, the certificate must contain some OU authorized by the MSP.  This can be especially useful when an organization wishes to use public CA infrastructure which might even be shared across organizations.

Thanks,
~Jason
 
----- Original message -----
From: "Bram Dufour" <bram.dufour8@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Why should organization not be both orderer and peer?
Date: Mon, Aug 17, 2020 12:40 PM
 

Thanks a lot Jason, I hadn't thought about those attacks yet.

But isn't it possible for the organizations with orderer to use the OU roles, set the following policies and just run orderer and peers within the same organization? Isn't this possible or do you still see some vulnerabilities with this approach?

Policies: &OrgPolicies
            Orderer:
                Type: Signature
                Rule: "OR('org.orderer')"
```


And then also set the BlockValidation policy like this:

```BlockValidation:
            Type: ImplicitMeta
            Rule: "ANY Orderer"

 

Thanks a lot in advance, it is a very interesting and important topic.