Helpers for SNMP engine_id

[jsatchell]

I have some helper code for working with SNMP v3 engine_id values, in line with RFC3411. The code calls in some stuff from std::net to parse IPv4 and IPv6 addresses, and uses a couple of things from std::str. This makes it unsuitable for inclusion in rasn_snmp, but I would argue that if you are interested in engine ids, you almost certainly are doing network IO, so will need at least the same imports.

At present, the code defines one constant, LOCAL_ENGINE_ID, the magic value from RFC5356, 6 construction functions for the different cases in RFC3411 which return OctetStrings, and a formatting function which gives a human readable breakdown of an engine_id.

What would be the best way to exploit this? A standalone crate? Add to rasn_snmp behind a feature flag? Would it be better to define a NewType for engine_id, and make these methods on the type?

[XAMPPRocky]

Thank you for your question!

The code calls in some stuff from std::net to parse IPv4 and IPv6 addresses, and uses a couple of things from std::str

Can you provide a more complete list of the APIs needed? Most IP stuff is available in core so it could work with that directly.

[jsatchell]

use std::net::{Ipv4Addr, Ipv6Addr}; use std::str::{from_utf8, FromStr}; <snip> let ipv4 = Ipv4Addr::from_str(address).unwrap(); <snip> let ipv6 = Ipv6Addr::from_str(address).unwrap(); <snip> let text = from_utf8(&bytes).unwrap();

…

On Wed, Jan 22, 2025 at 9:48 AM XAMPPRocky ***@***.***> wrote: Thank you for your question! The code calls in some stuff from std::net to parse IPv4 and IPv6 addresses, and uses a couple of things from std::str Can you provide a more complete list of the APIs needed? Most IP stuff is available in core so it could work with that directly. — Reply to this email directly, view it on GitHub <#408 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4N6MHAOLIMUBCYWSQNL3D2L5SPHAVCNFSM6AAAAABVUPWN6GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJRGQYDEOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jsatchell]

Superficially, all that is in core. Quick experiment of changing std:: to core:: works OK, and gives the same results. So the question is now: Do you want some helper functions or a new type (new type is more intrusive, and maybe would need changes elsewhere)? In either case, where should they live in rasn_snmp, if a satisfactory PR was developed?

[XAMPPRocky]

Hmm, I'm not sure I know enough about the specifics, could you provide a motivation of the one you think would be the best solution with some examples of how you'd use it?

[jsatchell]

The helper function case is easy enough. When I am setting up my snmp agent (server), I pass in an engine_id. Rather than put in an opaque byte string, I can say instead let engine_id = ipv4_engine_id(32473, "10.1.1.73"); where the number is an IANA private enterprise number. There are several other schemes as well. In a manager (client), i might use the format_engine_id to present the user with a better description of the end point than just some bytes. The wireshark SNMP dissector seems to have comparable functionality. If we made it distinct type say EngineID, and adjusted the corresponding v3 APIs to require an EngineID rather than OctetString, the compiler can catch a few mistakes. I guess we could use the format_engine_id code as some sort of display method in the type. I think the advantages of a new type are modest, and it requires breaking changes, admittedly of code that is not widely used yet. Maybe some body else has an opinion?

…

On Wed, Jan 22, 2025 at 6:05 PM XAMPPRocky ***@***.***> wrote: Hmm, I'm not sure I know enough about the specifics, could you provide a motivation of the one you think would be the best solution with some examples of how you'd use it? — Reply to this email directly, view it on GitHub <#408 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4N6MA4X3YWCUGLTUT3IXT2L7MU5AVCNFSM6AAAAABVUPWN6GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJRHE4TONQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[XAMPPRocky]

Ah I think it makes sense that it is its own type, and that you get it through a method on the types with engine_id, this allows for the data types to still allow for arbitrary octet strings (which makes it good for testing/fuzzing your implementation.), but offers a strong type.

impl ScopedPdu {
  fn engine_id(&self) -> Result<EngineId> {
    EngineId::try_from(&self.engine_id)
  }
}