RE: the future of SNMP
"Harrington, David" <[email protected]> Mon, 3 Mar 2003 12:11:58 -0500
| Newsgroups | gmane.ietf.eos |
|---|---|
| Message-ID | <6D745637A7E0F94DA070743C55CDA9BA489420@NHROCMBX1.ets.enterasys.com> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C2E1A7.FFB2A918 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I guess this as good a place as any to jump into this thread. =20 #1 For any solution to work effectively, it will need to be supported by = both the agent and the manager. Fixing it on one side only is not an = option.=20 =20 #2 It isn't enough to deliver a large blob of data to an NMS; the NMS = needs to be able to break it out and process it to display and/or = convert the raw data into information to make the blob of data = meaningful to an operator. Without that step it is not a useful = solution. =20 #3 using another protocol to transport gathered data requires defining = some mappings to coordinate that usage. It is not as simple as defining = a mib and then just saying "send it over FTP". What are the possible = error conditions that could occur, and how should they be handled? There = have been earlier attempts to send file of gathered data, such as = RFC2513, and these have not been widely deployed to my knowledge. I = would assume that if this design brought great beneift to the SNMP = community, the approach would have been extended for use in other = scenrios. Do we know why this never gained much acceptance? =20 #4 As Juergen pointed out, the security mapping between FTP and SNMPv3 = will be non-trivial. As a vendor, it is difficult for me to convince a = customer they should buy our products because we have SNMPv3-strength = security and then suggest they should use a non-secure protocol like FTP = to ship bulk data. Even if the file could be transported over SSH or SSL = or a VPN or IPSec, no mappings have been proposed about how to do that = in a standardized manner, or what rules need to be followed to balance = the security between the two. Which security precautions must be = follwoed sending bulk responses to a noAuthNoPriv request? which are = acceptable for an authPriv response? Can they be mixed into the same = buffer? =20 #5 Even if the file can be transported securely using the correct = message security level, a file-based transfer does not have = user-specific access control like VACM. I haven't read the mib recently; = have mechanisms been defined for coexistence with VACM?=20 =20 #6 As Juergen pointed out, adding new protocol additions may require = nothing more than a recompile, because many agents and applications use = a toolkit and if the toolkit has the extra functionality the agent and = manager will get it by default. However, I will point out that #2 still = applies. Even if I can add a protocol extension with no work, I still = need to modify my code to take advantage of the feature. For an NMS, = this will include probing to determine whether the functionality is = supported by different agents. If the SNMP stack provides the feature if = a developer calls the appropriate API, then the developers need to be = educated about the relative benefits of the new solution so they will = call the new API rather than just continuing to call the getNext() API = for all devices. It is easier to just call the same API for all tables = rather than having to test and debug conditional branches of code. I am = not convinced that GetBulk has seen wide usage by major NMS vendors yet, = for similar reasons.=20 =20 dbh =20 -----Original Message----- From: Wes Hardaker [mailto:[email protected]] Sent: Friday, February 28, 2003 10:43 AM To: B. Levin Cc: Glenn Waters; [email protected] Subject: Re: the future of SNMP >>>>> On Fri, 28 Feb 2003 07:00:45 -0800 (PST), "B. Levin" = <[email protected]> said: B> the MIB solution that I proposed could be implemented B> (at the NMS side) even on a 10 yr antique NMS. I'm confused at why there is an argument over what the NMS could support. That is hardly what I think needs to be optimized for in this case (certainly it's impacted, but I'm much more concerned about the 10000 agents that it's speaking with than the 1 NMS box). -- Wes Hardaker Network Associates Laboratories ------_=_NextPart_001_01C2E1A7.FFB2A918 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <TITLE>Re: the future of SNMP</TITLE> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>Hi,</FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>I=20 guess this as good a place as any to jump into this = thread.</FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>#1 For=20 any solution to work effectively, it will need to be supported by both = the agent=20 and the manager. Fixing it on one side only is not an option.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>#2 It=20 isn't enough to deliver a large blob of data to an NMS; the NMS needs to = be able=20 to break it out and process it to display and/or convert the raw data = into=20 information to make the blob of data meaningful to an operator. Without = that=20 step it is not a useful solution.</FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>#3=20 using another protocol to transport gathered data requires defining some = mappings to coordinate that usage. It is not as simple as defining a mib = and=20 then just saying "send it over FTP". What are the possible error = conditions that=20 could occur, and how should they be handled? There have been earlier = attempts to=20 send file of gathered data, such as RFC2513, and these have not been = widely=20 deployed to my knowledge. I would assume that if this design brought = great=20 beneift to the SNMP community, the approach would have been extended for = use in=20 other scenrios. Do we know why this never gained much=20 acceptance?</FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>#4 As=20 Juergen pointed out, the security mapping between FTP and SNMPv3 will be = non-trivial. As a vendor, it is difficult for me to convince a customer = they=20 should buy our products because we have SNMPv3-strength security and = then=20 suggest they should use a non-secure protocol like FTP to ship bulk = data. Even=20 if the file could be transported over SSH or SSL or a VPN or IPSec, no = mappings=20 have been proposed about how to do that in a standardized manner, or = what rules=20 need to be followed to balance the security between the two. Which = security=20 precautions must be follwoed sending bulk responses to a = noAuthNoPriv=20 request? which are acceptable for an authPriv response? Can they be = mixed into=20 the same buffer?</FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>#5=20 Even if the file can be transported securely using the correct message = security=20 level, a file-based transfer does not have user-specific access control = like=20 VACM. I haven't read the mib recently; have mechanisms been=20 defined for coexistence with VACM? </FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>#6 As=20 Juergen pointed out, adding new protocol additions may require nothing = more than=20 a recompile, because many agents and applications use a toolkit and if = the=20 toolkit has the extra functionality the agent and manager will get it by = default. However, I will point out that #2 still applies. Even if I can = add a=20 protocol extension with no work, I still need to modify my code to take=20 advantage of the feature. For an NMS, this will include probing to = determine=20 whether the functionality is supported by different agents. If the SNMP = stack=20 provides the feature if a developer calls the appropriate API, then the=20 developers need to be educated about the relative benefits of the new = solution=20 so they will call the new API rather than just continuing to call the = getNext()=20 API for all devices. It is easier to just call the same API for all = tables=20 rather than having to test and debug conditional branches of code. I am = not=20 convinced that GetBulk has seen wide usage by major NMS vendors yet, for = similar=20 reasons. </FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D939301716-03032003><FONT face=3DArial color=3D#0000ff = size=3D2>dbh</FONT></SPAN></DIV> <DIV><SPAN class=3D939301716-03032003></SPAN><FONT face=3DTahoma><FONT = size=3D2><SPAN=20 class=3D939301716-03032003><FONT face=3DArial=20 color=3D#0000ff> </FONT></SPAN></FONT></FONT></DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 class=3D939301716-03032003> </SPAN>-----Original = Message-----<BR><B>From:</B>=20 Wes Hardaker [mailto:[email protected]]<BR><B>Sent:</B> Friday, = February 28,=20 2003 10:43 AM<BR><B>To:</B> B. Levin<BR><B>Cc:</B> Glenn Waters;=20 [email protected]<BR><B>Subject:</B> Re: the future of=20 SNMP<BR><BR></DIV></FONT></FONT> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"><!-- Converted from text/plain format --> <P><FONT size=3D2>>>>>> On Fri, 28 Feb 2003 07:00:45 = -0800 (PST),=20 "B. Levin" <[email protected]> said:<BR><BR>B> the MIB = solution=20 that I proposed could be implemented<BR>B> (at the NMS side) even = on a 10=20 yr antique NMS.<BR><BR>I'm confused at why there is an argument over = what the=20 NMS could<BR>support. That is hardly what I think needs to be = optimized=20 for in<BR>this case (certainly it's impacted, but I'm much more = concerned=20 about<BR>the 10000 agents that it's speaking with than the 1 NMS=20 box).<BR><BR>--<BR>Wes Hardaker<BR>Network Associates=20 Laboratories<BR><BR></FONT></P></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C2E1A7.FFB2A918--