net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

SNMPv3 GET/SET issue due to OpenSSL dependency

[prabu v. <pra...@gm...>]

Dear All,

I'm using Net-SNMP-5.4.4 package with OpenWRT SDK to develop my Agent for
Armv7l.

While building the image in a build server(Alice) I'm facing one issue
like *SNMPv3
Requests with AES/DES are not working properly*. And I observed that the
summary states the Agent is not configured with AES/DES.

  SNMP Versions Supported:    1 2c 3
  Net-SNMP Version:           5.4.4
  Building for:               linux
  Network transport support:  Callback UDP UDPIPv6
  SNMPv3 Security Modules:     usm
  Agent MIB code:             <Removed to reduce the number of lines>
  Embedded Perl support:      disabled
  SNMP Perl modules:          building -- not embeddable
  SNMP Python modules:        disabled
  Authentication support:     MD5
  Encryption support:

I have tried a lot of combination to link the libcrypto but not able to
achieve it. Whereas in the same build server(Alice) I built another Agent
with Net-SNMP-5.5 for x86_64 it is working fine.

FYI, in that build server(Alice), I have upgraded the OpenSSL v1.0.2g to
v1.1.0g then again downgraded to OpenSSL v1.0.2g. Does it cause this issue?
Because *before doing the version upgrade/downgrade the Agent with v5.4.4
was working fine in the same build server(Alice).*

Please help me to resolve this issue as I'm not able to grab the exact Root
Cause.

Note: The same Agent built with Net-SNMP-5.4.4 for Armv7l is *working fine
if build the image in some other build server(Bob)*. It has OpenSSL
v1.0.2g. Following is the summary of working Agent configuration.

  SNMP Versions Supported:    1 2c 3
  Net-SNMP Version:           5.4.4
  Building for:               linux
  Network transport support:  Callback UDP UDPIPv6
  SNMPv3 Security Modules:     usm
  Agent MIB code:             <Removed to reduce the number of lines>
  Embedded Perl support:      disabled
  SNMP Perl modules:          disabled
  SNMP Python modules:        disabled
  Authentication support:     MD5 SHA1
  Encryption support:         DES AES


Please let me know if any other configuration/platform details required.
-- 
With Best Regards,
Anandaprabu V <https://www.linkedin.com/in/anandaprabu-v-10867671/>
VVDN Technologies Pvt. Ltd <http://www.vvdntech.com/>, Chennai
Cell : +91 9500650885 | Skype : prabuvaradharajan

Re: Netsnmpv5.8 possible security flaw

[Robert S. <rs...@fr...>]

Hi Madhusudhana,

Did you go back and confirm Wes' theory? Did you see an authPriv
request which failed, followed by and auth request that succeeded?

Robert


On Wed, 9 Jan 2019 04:19:28 +0000 Madhusudhana wrote:
MR> Thanks Wes. 
MR> 
MR> -----Original Message-----
MR> From: Wes Hardaker [mailto:har...@us...] 
MR> Sent: Tuesday, January 08, 2019 10:08 PM
MR> 
MR> Madhusudhana R <mad...@in...> writes:
MR> 
MR> > Can you please let me know whether this feature is added
MR> > newly in v5.8 or it was an existing feature in v5.7.3 ?
MR> > If it is a new feature in v5.8, is there a way to toggle some
MR> > MACRO value to make sure an user with authpriv protocol will
MR> > always responds in encrypted way?  
MR> 
MR> It's not new at all; that behavior has been around since the
MR> creation of the SNMPv3 code within Net-SNMP (which at the time
MR> was called UCD-SNMP, showing how old this concept is).  At the
MR> time, encryption wasn't even possible for everyone deploying
MR> the code (and the only encryption supported was DES).  The
MR> world tended to also believe that authentication (ensuring
MR> packets weren't modified) was a "must have" but encryption was
MR> merely a "would be nice if you could, but it's not critical".

Re: A discussion about moving to GitHub from SF (again)

[Robert S. <rs...@fr...>]

On Tue, 8 Jan 2019 20:37:45 -0800 Bart wrote:
BVA> On 1/2/19 2:28 PM, Wes Hardaker via Net-snmp-coders wrote:
BVA> > [...] Thus, it's time to reconsider whether we should make
BVA> > the move or whether people have concerns worth addressing.
BVA> > 
BVA> > Thoughts?  
BVA> 
BVA> [...] However, SF is still an order of magnitude slower
BVA> than GitHub. Additionally, all continuous integration services
BVA> I'm familiar with support GitHub but none of them support SF.
BVA> So I think there are at least two reasons to reconsider the
BVA> migration of the code base to GitHub. There may be other
BVA> reasons that I overlooked.

I agree with Bart; I think we should move ahead with the transition.

Robert

Re: Change default rwuser default security level

[Robert S. <rs...@fr...>]

On Tue, 08 Jan 2019 08:40:20 -0800 Wes wrote:
WHVNSC> Magnus Fromreide <ma...@ly...> writes:
WHVNSC> 
WHVNSC> > I suppose the default value of the access control is
WHVNSC> > "auth", the man page didn't say what the effects of that
WHVNSC> > was?
WHVNSC> > 
WHVNSC> > I think this is a bad idea as a default since that works
WHVNSC> > against the "secure by default" ideal - if someone want
WHVNSC> > to loosen restrictions then they should have to ask for
WHVNSC> > that.
WHVNSC> > [...]
WHVNSC> I'd push back rather hard against breaking existing
WHVNSC> implementations by changing the default. [...]
WHVNSC> 
WHVNSC> If we want to change the default behavior, I'd suggest we
WHVNSC> instead create a new token and push that out to all
WHVNSC> documentation and examples rather than causing a version
WHVNSC> update to suddenly make everyone's existing deployments
WHVNSC> stop working.

How about a migration path? Add a warning at startup if rwuser is
specified without a level. i.e. "Warning: no securityLevel
specified for rwuser; defaulting to auth".

People will hate it. But even if we add a new token, we should have
a warning that people need to migrate to it, and we'd have to drop
support for it at some point (with a configure option to keep it
enabled).

Now is a good time to consider such things, since (in theory) we
have another release before the next long-term support release.

Robert

SNMPV3 Inform not working on 5.7.3

[Jayashree P. <jay...@gm...>]

Hi Team,
  I'm using  netsnmp 5.5 and INFORMS works perfectly fine. When install
5.7.3, i see some issues with Informs. When there is a inform sent from my
agent , Manager where 5.7 is installed sends a packet with wrong engineID
(looks like some dynamically created engineId) . Bcz of which inform is not
receiveied by Manager.

While netsnmp 5.5 sends correct engineID of Manager in the ack packet.

Is there any known issue ? Is there any fix needs to be added in the agent
side ?

Thanks,
Jayashree

Re: [RFC] Add one line of information in snmpd.conf man page

[Masanari I. <sta...@gm...>]

Hello Bart,
Thanks for the patch.
It is OK for me.
Regards,
Masanari

On Sat, Jan 12, 2019 at 12:17 PM Bart Van Assche <bva...@ac...> wrote:
>
> On 1/11/19 1:20 AM, Masanari Iida wrote:
> > Hello
> > In snmpd.conf man page, in "monitor" option,
> > I would like to see following information.
> >
> > Original:  NAME is an administrative name for this expression, and is
> > Original:  used for indexing the mteTriggerTable (and related tables).
> > Add:       NAME should not be duplicated in snmpd.conf.
> >
> > Background
> > My colleague accidentally configure 2 lines of "monitor" settings
> > with exactly same NAME and saw "duplicated trigger name"
> > messages.
> > I think one line of additional information will help someone in the future.
>
> Thanks for having reported this. How about addressing this with the
> patch below?
>
> Bart.
>
>
> Subject: [PATCH] man/snmpd.conf.5.def: Document that monitor names must
> be unique
>
> Reported-by: Masanari Iida <sta...@gm...>
> ---
>   man/snmpd.conf.5.def | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/man/snmpd.conf.5.def b/man/snmpd.conf.5.def
> index 2c4ddad806eb..eaa904f4b077 100644
> --- a/man/snmpd.conf.5.def
> +++ b/man/snmpd.conf.5.def
> @@ -974,7 +974,9 @@ Note that the event will only be triggered once,
> when the expression
>   first matches.  This monitor entry will not fire again until the
>   monitored condition first becomes false, and then matches again.
>   NAME is an administrative name for this expression, and is used for
> -indexing the \fCmteTriggerTable\fR (and related tables).
> +indexing the \fCmteTriggerTable\fR (and related tables). Each monitor
> +line must have a unique NAME. Monitor lines with a duplicate name are
> +discarded and cause snmpd to log a duplicate index complaint.
>   Note also that such monitors use an internal SNMPv3 request to retrieve
>   the values being monitored (even if normal agent queries typically use
>   SNMPv1 or SNMPv2c).  See the \fIiquerySecName\fP token described above.
> --
> 2.20.1
>

Re: [RFC] Add one line of information in snmpd.conf man page

[Bart V. A. <bva...@ac...>]

On 1/11/19 1:20 AM, Masanari Iida wrote:
> Hello
> In snmpd.conf man page, in "monitor" option,
> I would like to see following information.
> 
> Original:  NAME is an administrative name for this expression, and is
> Original:  used for indexing the mteTriggerTable (and related tables).
> Add:       NAME should not be duplicated in snmpd.conf.
> 
> Background
> My colleague accidentally configure 2 lines of "monitor" settings
> with exactly same NAME and saw "duplicated trigger name"
> messages.
> I think one line of additional information will help someone in the future.

Thanks for having reported this. How about addressing this with the 
patch below?

Bart.


Subject: [PATCH] man/snmpd.conf.5.def: Document that monitor names must 
be unique

Reported-by: Masanari Iida <sta...@gm...>
---
  man/snmpd.conf.5.def | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/man/snmpd.conf.5.def b/man/snmpd.conf.5.def
index 2c4ddad806eb..eaa904f4b077 100644
--- a/man/snmpd.conf.5.def
+++ b/man/snmpd.conf.5.def
@@ -974,7 +974,9 @@ Note that the event will only be triggered once, 
when the expression
  first matches.  This monitor entry will not fire again until the
  monitored condition first becomes false, and then matches again.
  NAME is an administrative name for this expression, and is used for
-indexing the \fCmteTriggerTable\fR (and related tables).
+indexing the \fCmteTriggerTable\fR (and related tables). Each monitor
+line must have a unique NAME. Monitor lines with a duplicate name are
+discarded and cause snmpd to log a duplicate index complaint.
  Note also that such monitors use an internal SNMPv3 request to retrieve
  the values being monitored (even if normal agent queries typically use
  SNMPv1 or SNMPv2c).  See the \fIiquerySecName\fP token described above.
-- 
2.20.1

[RFC] Add one line of information in snmpd.conf man page

[Masanari I. <sta...@gm...>]

Hello
In snmpd.conf man page, in "monitor" option,
I would like to see following information.

Original:  NAME is an administrative name for this expression, and is
Original:  used for indexing the mteTriggerTable (and related tables).
Add:       NAME should not be duplicated in snmpd.conf.

Background
My colleague accidentally configure 2 lines of "monitor" settings
with exactly same NAME and saw "duplicated trigger name"
messages.
I think one line of additional information will help someone in the future.

Masanari

Re: A discussion about moving to GitHub from SF (again)

[Wes H. <har...@us...>]

Bart Van Assche <bva...@ac...> writes:

> Regarding GitHub versus SourceForge: during the past few weeks none of
> my git pushes to SF failed. That's a significant improvement. However,
> SF is still an order of magnitude slower than GitHub. Additionally,
> all continuous integration services I'm familiar with support GitHub
> but none of them support SF. So I think there are at least two reasons
> to reconsider the migration of the code base to GitHub.

Um, I think that last sentence is reversed right?  We were always
considering it, we just postponed the decision with a pause.
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: A discussion about moving to GitHub from SF (again)

[Bart V. A. <bva...@ac...>]

On 1/2/19 2:28 PM, Wes Hardaker via Net-snmp-coders wrote:
> Previously [1] we agreed to moved at least the code base to GitHub, with
> work on moving the wiki and other things as well.  Shortly after that
> decision was made, GitHub was bought out by MS and the consensus changed
> to "hold and wait till we see what the fallout might be".  It appears,
> at least publicly, that no changes are to be made in the near future to
> GitHub's operational model.  Thus, it's time to reconsider whether we
> should make the move or whether people have concerns worth addressing.
> 
> Thoughts?

Hi Wes,

My best wishes for the new year!

Regarding GitHub versus SourceForge: during the past few weeks none of 
my git pushes to SF failed. That's a significant improvement. However, 
SF is still an order of magnitude slower than GitHub. Additionally, all 
continuous integration services I'm familiar with support GitHub but 
none of them support SF. So I think there are at least two reasons to 
reconsider the migration of the code base to GitHub. There may be other 
reasons that I overlooked.

See also https://blog.github.com/2017-11-07-github-welcomes-all-ci-tools/.

Bart.

RE: Netsnmpv5.8 possible security flaw

[Madhusudhana R <mad...@in...>]

Thanks Wes. 

-----Original Message-----
From: Wes Hardaker [mailto:har...@us...] 
Sent: Tuesday, January 08, 2019 10:08 PM
To: Madhusudhana R <mad...@in...>
Cc: Wes Hardaker <har...@us...>; net...@li...
Subject: Re: Netsnmpv5.8 possible security flaw

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Madhusudhana R <mad...@in...> writes:

> Can you please let me know whether this feature is added newly in v5.8 
> or it was an existing feature in v5.7.3 ?
> If it is a new feature in v5.8, is there a way to toggle some MACRO 
> value to make sure an user with authpriv protocol will always responds 
> in encrypted way?

It's not new at all; that behavior has been around since the creation of the SNMPv3 code within Net-SNMP (which at the time was called UCD-SNMP, showing how old this concept is).  At the time, encryption wasn't even possible for everyone deploying the code (and the only encryption supported was DES).  The world tended to also believe that authentication (ensuring packets weren't modified) was a "must have" but encryption was merely a "would be nice if you could, but it's not critical".
--
Wes Hardaker
Please mail all replies to net...@li...

Re: EXTERNAL: Re: 5.7.3 | snmptrap not populating EngineBoots or EngineTime for snmp v3 traps

[Wes H. <har...@us...>]

"Roedersheimer, Drew A. via Net-snmp-coders"
<net...@li...> writes:

> Denis Hainsworth wrote:
> > Dug into this some more.  I see whats happening and not sure if its a bug per se but
> > I do agree that if there is a non-buggy trap sender its all working properly so will
> > close the bug with some comments.
> 
> I have added some comments to bug #2899 and uploaded the proposed patch in Sourceforge.
> 
> Devs: could someone please close bug #2900 and review/merge the patch from bug #2899?

Sorry for the delay...  Good analysis and good patch, so it's applied!
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Change default rwuser default security level

[Wes H. <har...@us...>]

Magnus Fromreide <ma...@ly...> writes:

> I suppose the default value of the access control is "auth", the man
> page didn't say what the effects of that was?
> 
> I think this is a bad idea as a default since that works against the
> "secure by default" ideal - if someone want to loosen restrictions
> then they should have to ask for that.
> 
> Now, I do appreciate that changing this might break the setup for some
> people but on the other hand it probably will close unintended holes
> for others.

I'd push back rather hard against breaking existing implementations by
changing the default.  As mentioned in the other thread, at the time
that code was put into place the only encryption was DES and because the
U.S. was still pushing hard against export controls of even prototcols
like DES, the general consensus of the SNMPv3 world was encryption was a
"nice" but may not be available everywhere.

If we want to change the default behavior, I'd suggest we instead create
a new token and push that out to all documentation and examples rather
than causing a version update to suddenly make everyone's existing
deployments stop working.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Netsnmpv5.8 possible security flaw

[Wes H. <har...@us...>]

Madhusudhana R <mad...@in...> writes:

> Can you please let me know whether this feature is added newly in v5.8
> or it was an existing feature in v5.7.3 ?
> If it is a new feature in v5.8, is there a way to toggle some MACRO
> value to make sure an user with authpriv protocol will always responds
> in encrypted way?

It's not new at all; that behavior has been around since the creation of
the SNMPv3 code within Net-SNMP (which at the time was called UCD-SNMP,
showing how old this concept is).  At the time, encryption wasn't even
possible for everyone deploying the code (and the only encryption
supported was DES).  The world tended to also believe that
authentication (ensuring packets weren't modified) was a "must have" but
encryption was merely a "would be nice if you could, but it's not critical".
-- 
Wes Hardaker
Please mail all replies to net...@li...

Change default rwuser default security level (Was: Netsnmpv5.8 possible security flaw)

[Magnus F. <ma...@ly...>]

On Mon, Jan 07, 2019 at 11:16:02PM -0800, Wes Hardaker via Net-snmp-coders wrote:
> Madhusudhana R <mad...@in...> writes:
> 
> > With Netsnmp v5.8  upgraded to my project (which was already working with v5.7.3), I am finding one
> > problem which is as described below.
> > 
> > An user is created in agent (which is netsnmp v5.8)
> 
> How did you configure the access control of the agent?  Specifically, if
> you have a line like "rwuser NAME" in it, you MUST change it to "rwuser
> NAME priv" to force encryption-only traffic.  Otherwise the agent will
> answer with both encrypted and unencrypted requests (but still
> authenticated).

I suppose the default value of the access control is "auth", the man
page didn't say what the effects of that was?

I think this is a bad idea as a default since that works against the
"secure by default" ideal - if someone want to loosen restrictions
then they should have to ask for that.

Now, I do appreciate that changing this might break the setup for some
people but on the other hand it probably will close unintended holes
for others.

/MF

RE: Netsnmpv5.8 possible security flaw

[Madhusudhana R <mad...@in...>]

Thanks Wes. 

Can you please let me know whether this feature is added newly in v5.8 or it was an existing feature in v5.7.3 ?
If it is a new feature in v5.8, is there a way to toggle some MACRO value to make sure an user with authpriv protocol will always responds in encrypted way? 

Thanks in advance.

Regards,
Madhu


-----Original Message-----
From: Wes Hardaker [mailto:har...@us...] 
Sent: Tuesday, January 08, 2019 12:46 PM
To: Madhusudhana R <mad...@in...>
Cc: net...@li...
Subject: Re: Netsnmpv5.8 possible security flaw

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Madhusudhana R <mad...@in...> writes:

> With Netsnmp v5.8  upgraded to my project (which was already working 
> with v5.7.3), I am finding one problem which is as described below.
>
> An user is created in agent (which is netsnmp v5.8)

How did you configure the access control of the agent?  Specifically, if you have a line like "rwuser NAME" in it, you MUST change it to "rwuser NAME priv" to force encryption-only traffic.  Otherwise the agent will answer with both encrypted and unencrypted requests (but still authenticated).  I suspect that this is your issue, and your network management software is attempting (and succeeding) at falling back to unencrypted.

--
Wes Hardaker
Please mail all replies to net...@li...

RE: Netsnmpv5.8 possible security flaw

[Madhusudhana R <mad...@in...>]

Thanks Wes. 

Can you please let me know whether this feature is added newly in v5.8 or it was an existing feature in v5.7.3 ?
If it is a new feature in v5.8, is there a way to toggle some MACRO value to make sure an user with authpriv protocol will always responds in encrypted way? 

Thanks in advance.

Regards,
Madhu

-----Original Message-----
From: Wes Hardaker [mailto:har...@us...] 
Sent: Tuesday, January 08, 2019 12:46 PM
To: Madhusudhana R <mad...@in...>
Cc: net...@li...
Subject: Re: Netsnmpv5.8 possible security flaw

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Madhusudhana R <mad...@in...> writes:

> With Netsnmp v5.8  upgraded to my project (which was already working 
> with v5.7.3), I am finding one problem which is as described below.
>
> An user is created in agent (which is netsnmp v5.8)

How did you configure the access control of the agent?  Specifically, if you have a line like "rwuser NAME" in it, you MUST change it to "rwuser NAME priv" to force encryption-only traffic.  Otherwise the agent will answer with both encrypted and unencrypted requests (but still authenticated).  I suspect that this is your issue, and your network management software is attempting (and succeeding) at falling back to unencrypted.

--
Wes Hardaker
Please mail all replies to net...@li...

Re: Netsnmpv5.8 possible security flaw

[Wes H. <har...@us...>]

Madhusudhana R <mad...@in...> writes:

> With Netsnmp v5.8  upgraded to my project (which was already working with v5.7.3), I am finding one
> problem which is as described below.
> 
> An user is created in agent (which is netsnmp v5.8)

How did you configure the access control of the agent?  Specifically, if
you have a line like "rwuser NAME" in it, you MUST change it to "rwuser
NAME priv" to force encryption-only traffic.  Otherwise the agent will
answer with both encrypted and unencrypted requests (but still
authenticated).  I suspect that this is your issue, and your network
management software is attempting (and succeeding) at falling back to
unencrypted.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Netsnmpv5.8 possible security flaw

[Madhusudhana R <mad...@in...>]

Hi Coders,

With Netsnmp v5.8  upgraded to my project (which was already working with v5.7.3), I am finding one problem which is as described below.

An user is created in agent (which is netsnmp v5.8)

Username: 'user1'
Hash algo: 'SHA224'
Password: 'password123'
Priv algo: 'AES192'
Password: 'passwordABC'

When I polled from manager(iReasoning MIB Browser) for SNMP get request with below credentials for user

Username: 'user1'
Hash algo: 'SHA224'
Password: 'password123'
Priv algo: 'AES192'
Password: ' ' (a whitespace)
The get request was successful though the privacy protocol password is a white space which means agent responded with a valid get response.

Observation on Wireshark: There was a  get response packet in un-encrypted format(plain text).
Observation on Manager(iReasoning MIB browser): The get response was successful.

This looks like a security flaw since a user is configured with authPriv protocol and with wrong privacy password, the response comes as a plain text.

Please correct me if my observation is wrong anyway. If not, can anyone please comment on this?

Thanks in advance.

Regards,
Madhu

RE: EXTERNAL: Re: 5.7.3 | snmptrap not populating EngineBoots or EngineTime for snmp v3 traps

[Roedersheimer, D. A. <Dre...@le...>]

Denis Hainsworth wrote:
> Dug into this some more.  I see whats happening and not sure if its a bug per se but
> I do agree that if there is a non-buggy trap sender its all working properly so will
> close the bug with some comments.

I have added some comments to bug #2899 and uploaded the proposed patch in Sourceforge.

Devs: could someone please close bug #2900 and review/merge the patch from bug #2899?


Thanks
-Drew

A discussion about moving to GitHub from SF (again)

[Wes H. <har...@us...>]

Previously [1] we agreed to moved at least the code base to GitHub, with
work on moving the wiki and other things as well.  Shortly after that
decision was made, GitHub was bought out by MS and the consensus changed
to "hold and wait till we see what the fallout might be".  It appears,
at least publicly, that no changes are to be made in the near future to
GitHub's operational model.  Thus, it's time to reconsider whether we
should make the move or whether people have concerns worth addressing.

Thoughts?

[1] https://sourceforge.net/p/net-snmp/mailman/message/36314970/
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: EXTERNAL: Re: 5.7.3 | snmptrap not populating EngineBoots or EngineTime for snmp v3 traps

[Denis H. <den...@gm...>]

On Wed, Dec 19, 2018 at 12:39:07AM +0000, Roedersheimer, Drew A. wrote:
> Denis Hainsworth wrote:
> > #2899 - snmptrap bug
> > #2900 - snmptrapd bug
> > 
> > -denis
> 
> Denis,
> 
> Sorry for the delayed response.  I haven't had time to look at this until recently.
>  
> Regarding the snmptrapd bug you created (#2900): I think this is working as expected.
> I compiled and tested v5.7.3 from git source, and snmptrapd is certainly validating the
> msgAuthoritativeEngineBoots value.  Whenever I send a trap with a boot value that is
> the same or greater than the last, the trap is received.  If I send a trap with a
> boot value that is less than a previous trap, I get the following error from snmptrapd:
>  
> usm: USM processing begun...
> usm: match on user testuser
> usm: Verification succeeded.
> usm: Remote boot count invalid.
> 
> 
> As for the msgAuthoritativeEngineTime values, if the delta from the previous trap
> is large enough, the trap is also rejected by snmptrapd.  Here's the message you
> will see (with -Dusm):
> 
> usm: USM processing begun...
> usm: match on user testuser
> usm: Verification succeeded.
> usm: Message too old.
> 
> I haven't dug into the code deep enough to find the threshold, but I suspect it's
> following the RFC.
> 
> The end result is that I think that bug #2900 should be closed as invalid.
> 
> Please let me know your thoughts.

Dug into this some more.  I see whats happening and not sure if its a
bug per se but I do agree that if there is a non-buggy trap sender its
all working properly so will close the bug with some comments.

So per rfc2574 the only requirement is that a trap boots/time be at most
150s behind the last message received.  Plus that boots/time always
starts at 0/0.   So because snmptrap binary we were using was always
setting boots/time to 0/0 that was never less than 150s older so
snmptrapd happily accepts the messages which I though meant it wasnt
checking.   This is namely because Cisco Prime Network snmp trap
receiver throws the "notintimewindow" error for 0/0.  I believe this is
a restriction technically outside the strict reading of the RFC.  I
couldn't find a section that mandated the snmp receiver should error if
boot/time never changes and/or always stays at 0/0.    In this sense i
think snmptrapd is potentially more RFC compliant but less restrictive 
than cisco.   As you noted if I use a functional snmptrap program where
I am able to set the boots/time and advance it to non zero values than I
can see that I get proper errors if I back the time up past 150s prior
to the latest time sent.

So i'll update and close the snmptrapd bug.   nice catch sorry for the
confusion.  

-denis

RE: EXTERNAL: Re: 5.7.3 | snmptrap not populating EngineBoots or EngineTime for snmp v3 traps

[Roedersheimer, D. A. <Dre...@le...>]

Denis Hainsworth wrote:
> #2899 - snmptrap bug
> #2900 - snmptrapd bug
> 
> -denis

Denis,

Sorry for the delayed response.  I haven't had time to look at this until recently.
 
Regarding the snmptrapd bug you created (#2900): I think this is working as expected.
I compiled and tested v5.7.3 from git source, and snmptrapd is certainly validating the
msgAuthoritativeEngineBoots value.  Whenever I send a trap with a boot value that is
the same or greater than the last, the trap is received.  If I send a trap with a
boot value that is less than a previous trap, I get the following error from snmptrapd:
 
usm: USM processing begun...
usm: match on user testuser
usm: Verification succeeded.
usm: Remote boot count invalid.


As for the msgAuthoritativeEngineTime values, if the delta from the previous trap
is large enough, the trap is also rejected by snmptrapd.  Here's the message you
will see (with -Dusm):

usm: USM processing begun...
usm: match on user testuser
usm: Verification succeeded.
usm: Message too old.

I haven't dug into the code deep enough to find the threshold, but I suspect it's
following the RFC.

The end result is that I think that bug #2900 should be closed as invalid.

Please let me know your thoughts.


-Drew

Re: Source Address based Configuration Control in SNMP Agent

[prabu v. <pra...@gm...>]

Thanks for the input Wes.

I'll check it out how the v3 proxy may help in my case.

Or can we consider the security aspects of SNMPv3 and proceed without any
source address filtering whereas we can have the same filter for SNMPv1 and
SNMPv2c only? In this case, I can make sure the User credentials should be
strong one.

FYI, my agent will support any one version at a time.


On Tue 18 Dec, 2018 11:04 pm Wes Hardaker, <har...@us...>
wrote:

> prabu varadharajan <pra...@gm...> writes:
>
> > But as per the design, my agent will be configured with only one user
> > which can be updated as rouser or rwuser. So can you please suggest
> > any other way to achieve this if possible?
>
> You can't have a single user with different access levels, sorry.  There
> are hacky things you could do, like using v2c communities for read-only
> (but that's insecure) or setting up a v3 proxy for the read-only manager
> to proxy through that only allows read access even though the outgoing
> access to the real device is using a read-write user.  But that's a real
> hack and not much better.
> --
> Wes Hardaker
> Please mail all replies to net...@li...
>

Re: Source Address based Configuration Control in SNMP Agent

[Wes H. <har...@us...>]

prabu varadharajan <pra...@gm...> writes:

> But as per the design, my agent will be configured with only one user
> which can be updated as rouser or rwuser. So can you please suggest
> any other way to achieve this if possible?

You can't have a single user with different access levels, sorry.  There
are hacky things you could do, like using v2c communities for read-only
(but that's insecure) or setting up a v3 proxy for the read-only manager
to proxy through that only allows read access even though the outgoing
access to the real device is using a read-write user.  But that's a real
hack and not much better.
-- 
Wes Hardaker
Please mail all replies to net...@li...