What is the Major difference in SNMP over DTLS and SNMPv3 USM model, which one to prefer.
TLS and DTLS make use of the Transport Security Model (TSM) security model, defined in RFC5591 which was created as an alternative to the USM security model
The difference is what is the problem each of them wants to resolve.
SNMP v3 USM enhances the SNMP message format itself to add proper integrity check and encryption, so that it can be transferred on probably unsafe wires.
SNMP over DTLS uses another approach that it tries to build safe channels on unsafe wires, and allows the messages to be transferred safely.
You can prefer either of them to achieve significant security improvements over the original SNMP, but please analyze your scenarios carefully and put the following into consideration,
What are the devices in your whole solution?
Whether they support both models? Which one of them only supports one of the model?
Then you can make a decision on which model to choose. As far as I know SNMP v3 USM is more widely supported, but I might be wrong.
Related
Substrate uses libp2p to do peer discovery and transport.
Is there functionality to advertise additional information from peers using this layer? Or alternatively, use substrate to advertise information without needing to sink that information to the chain?
For instance, the location of additional RPC endpoints attached to the light clients.
Re: shawntabrizi
one big issue about light clients and not storing that data to chain is that light client inherently depend on merkle proofs and this merkle trie is where all the overhead of runtime storage comes from practically speaking, so if you want some light-client verifiable content using only the runtime state, then you are basically stuck with this but you could store only a hash of some file
and then use any other p2p protocol to share that file
and let the light client verify based on the hash
but this would be a third party tool or possibly an offchain worker on top of a substrate client|
You should be able to make modifications to networking to enable different kinds of gossiping for your needs. AFAIK, Polkadot does this: https://github.com/paritytech/polkadot/tree/master/network
a few parties use IPFS, including ourselves at parity, that have investigated IPFS integration. I am not to certain on the latest progress from 3rd party teams, but we had a very old branch that adds an IPFS node along side the Substrate node. Because Substrate and IPFS use LibP2P, this was relatively painless from what I understand.
SNMP is generally used to monitor the health of components in network.
For SDN [Software Defined network], is it desirable to use SNMP . I am having doubt like is it better to use some other protocol like NETCONFIG
In general SNMP can be used for configuration of a device, however personally I will not stretch it too far specifically when network configuration operation potentially spans across multiple devices and as a result will have higher order transaction requirements.
RFC3512 provides good perspective around configuration using SNMP. Reading through the RFC it will become apparent that within a device transaction relies on how well the MIBs (the objects used via SNMP for performing configuration changes) are designed and implemented. For configuration spanning across multiple devices the device transaction alone will not suffice, if rolling back the configuration is a requirement (this depending on the nature of service/use-case being addressed by your SDN controller). I would recommend reading the Transaction Control in MIB Objects further to understand the requirements on the protocol and eventually the capabilities of the MIB modules that one will be using for configuration.
Netconf was created with configuration of devices in mind and it offers various capabilities that are of use in this regard. These are covered in detail in the IETF standard for Netconf Protocol RFC under Capabilities section. The capabilities such as Candidate Configuration, Validate Configuration, Confirmed Commit, Rollback on Error and other such are specified in the standard which shall further aid in orchestration of a transaction across multiple device.
If I want to write a node for a P2P application (like Bitcoin, Bitorrent, etc.) there are a lot of parts that are the same:
I need to bootstrap to the network (discover other peers)
I need to manage a list of peers, and monitor their states
I need to retrieve lists of more peers from my neighbour peers
Etc, etc.
Since I don't want to re-invent the wheel, is their a framework that I could as a sort of base library to build on?
You mention both bitcoin and bittorrent, which are quite different, so I'm assuming you don't want to be bound to any specific protocol or even serialization format.
And yet you mention peer-discovery and stats-management which are high-level concerns, be built on top of some network protocol.
But the protocol dictates how such a mechanism would work.
It sortof sounds like you're asking if there are pre-built roofs that would fit on skyscrapers just as well as on a wood cabin.
So if you actually want to design your own protocol you probably should look more at the foundation first.
which language do you want to use
what IO / event processing libraries are available
what protocol parsers and serializers are available
do you aim for throughput? low memory footprint? low latency? minimal amount of programmer-hours spent?
what kind of security is needed? heavy crypto use at the protocol level will need a trustworthy crypto library (don't roll your own!)
what kind of auxiliary things do you need (where does the data go? filesystem? databases? do you need a UI?)
Alternatively, depending how one interprets your question, if you want to write a client for a specific network then you should simply look for a library implementing the core concepts of that specific network while freeing you up to implement the rest of the application.
In bittorrent's case such an example would be libtorrent
Forgive my ignorance if this is a trivial question. I am writing some code to support communication over SNMPv3; our application only supports SNMPv2c currently.
The response object when communicating using SNMPv3 is blank unless I match community strings. I was under the impression that community strings were an "SNMPv2/1 thing" and that "the new way" was to use a username/authentical protocol/privacy protocol.
Wikipedia states that:
Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, it looks much different due to new textual conventions, concepts, and terminology.[1]
This statement leads me to believe that I do, in fact, need to supply community strings, too.
I just wanted to confirm this because it is difficult for me to tell whether I am getting data back because I fulfilled the SNMPv2 requirement or because I successfully fulfilled all the SNMPv3 requirements.
I'm using Dart's SNMP library to communicate with the other device and I have specified that my request should user SNMP version three -- but perhaps it falls back to SNMPv2 behind-the-scenes when given valid SNMP communities?
No, you don't. The internal packet structure changes to a number of new concepts, like the above quote tries to indicate. The protocol side that the above is stating is the same has to do with PDU operations, etc. IE, technically there are 3 versions of SNMP:
version 1: community string based authentication with SMNPv1 PDUs
version 2c: community string based authentication with SNMPv2 PDUs
(the SNMPv2 PDUs add GETBULK, INFORM, and REPORT PDUs)
version 3: modular security with SNMPv2 PDUs
IE, version 3 didn't touch how the actual operations work (it's still using the PDU types from version 2), but merely adds other header-stuff around them (like better and more modular security; in fact we now have 3 different security types to pick from at this point: USM, SSH, and (D)TLS).
I've implemented an SNMP agent using SNMP4J. I've read in various places (including in SNMP4J javadoc) that there is support for a 'getSubtree' operation, but it always seems to be done from the client side, using getNext and/or getBulk. What I'm trying to do, though, is define a new PDU for 'getSubtree', and implement the server-side agent support for it.
Has anyone successfully (a) implemented a new PDU type (beyond the 7 standard ones) using SNMP4J, and/or (b) implemented 'getSubtree' support within an agent (I already know how to simulate it from a client.) Is either (a) or (b) even possible? Any pointers on how to do either would be GREATLY appreciated!
SNMP is not an extensible protocol that allows you to add new operations to it. So legally, you can't actually do that. The RFCs restrict the PDUs to the existing ones. GETBULK is the most efficient way to gather a bunch of information from an agent, even though it has its own issues with using it (data overrun for example).