RE: Status of the WG
"Harrington, David" <[email protected]> Thu, 13 Feb 2003 17:15:42 -0500
| Newsgroups | gmane.ietf.sming,gmane.ietf.eos |
|---|---|
| Message-ID | <6D745637A7E0F94DA070743C55CDA9BA4893E1@NHROCMBX1.ets.enterasys.com> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D3AD.7255DF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a slightly different viewpoint.=20 =20 Both eos and sming are developing add-ons to SNMPv3. And I think SNMPv3 = is the problem. SNMPv3 is incomplete, and the things it needs are not = new mib syntax or compressed PDUs or TCP support. What it needs is some = guidance about how to deploy it, and how to migrate a network, and = network management tools, from SNMPv1 to SNMPv3. =20 SNMPv3, as currently defined, is difficult to deploy. There is no = standardized initial key distribution mechanism, only an experimental = Diffie-Hellman approach. There is no integration with centralized key = management and authorization, such as RADIUS; one approach exists for = Kerberos, but that has been labeled experimental, and Kerberos does not = seem to be in wide commercial use. There has been no official work to = standardized the widely desired AES support. There has been no work to = guide operators/vendors how to provide support for VACM views, given the = design of existing mibs. There has been no work to guide mib writers how = to write VACM-friendly mibs. There has been no work to define an = easier-to-deploy access control model.=20 =20 The five leading network/systems management frameworks - HPOV, BMC = Patrol, CA-Unicenter, Tivoli TME, and Spectrum - offer little support = for SNMPv3 messaging, and no support for managing the elements of SNMPv3 = such as users, views, and groups. Best-of-breed application vendors such = as Concord Communications and Micromuse do not offer SNMPv3 support. = Equipment vendors have provided support for SNMPv3 in their devices, but = even their own applications, such as CiscoWorks, hide the details of the = underlying SNMPv3 systems, and do not take advantage of the power of = SNMPv3 concepts. =20 No SNMP applications have been developed to manage SNMPv3 key = distribution in-band between multiple agents and multiple applications. = I have seen no applications to provide an easy graphical way to define = and distribute VACM views.=20 =20 There are a number of applications that do policy-based management, = including assigning roles to users, but they have not been integrated = with SNMPv3 users and groups. Different operators often manage different = aspects of networks, such as routing or security, but no standards have = been developed to define policy-based division of labor for Network = Management protocols. =20 No standards have been defined for integrating the security models of = SNMPv3 and CLI and web-based management. Securing one interface but not = the others makes no sense. No work has been done to define how one = should distribute SNMPv3 keys in CLI command scripts. =20 EOS and SMING are interesting research projects, but they aren't very = practical because they depend on a protocol and a security design that = nobody can deploy reasonably. Before EOS and SMING become truly = relevant, we need to help the industry get SNMPv3 deployed. =20 We really need to decide whether we believe SNMPv3 is worth the effort = to help get it deployed. If not, we should declare it Historic, pick an = alternative, and move on. If we want it to be accepted, then we need to = help the industry understand how to deploy it. So far, we have simply = chosen to not get involved. If we don't believe it's worth the work, why = should operators and vendors believe it's worth the work? =20 I propose we deactivate EOS and SMING, and combine our efforts in an = SNMPv3 deployment WG. This would be a good opportunity to have the = network management experts and the operations experts work together to = develop some recommended practices and the necessary missing pieces to = make SNMPv3 a deployable secure network management protocol. =20 dbh =20 -----Original Message----- From: Andy Bierman [mailto:[email protected]] Sent: Thursday, February 13, 2003 4:06 PM To: Durham, David Cc: Wijnen, Bert (Bert); Sming (E-mail); Randy Bush (E-mail) Subject: RE: Status of the WG At 09:39 AM 2/13/2003 -0800, Durham, David wrote: >The silence is deafening, and says it all. It seems that while most are >in agreement that SMI is seriously antiquated, convoluted, and requires >several maintenance fixes, there is very little (apparently zero now) >interest in fixing it and improving it. It would seem people are >satisfied with SNMP being regulated to a legacy systems management >interface. > >There is the realization that up-to-date data modeling languages are >already widely used and available (e.g. XMLSchema), and that the IETF >should not be engaged in the task of inventing yet another = idiosyncratic >data modeling language... Particularly given that it will seriously >languish behind those that are commonly available today. > >Looking at the ROI on this effort, there are those who are asking why >not just adopt what is already available and stop beating a dead horse >in the hopes it will rise. I agree with this assessment. It would be a large development effort to move from SMIv2 to any new syntax. The key question is how much benefit will be realized by making a particular change. While I still believe there is enough benefit in the data modeling features of SMI-DS to make it worthwhile, I no longer believe that SNMP vendors and customers are willing to incur any significant cost to get this benefit. I think the resources devoted to SNMP development are diminishing quickly (as expected for a legacy technology), and developers and customers believe SMIv2 is good enough, for the amount of effort they are willing to invest in SNMP. The cost/benefit ratio for SMIv2.1 seems worthwhile. The need for HC data types has been known since (at least) 1992. Mandatory maintenance of SMIv2 is something that should already be done, so better late than never. Keep in mind that the decision to abandon SMIv3 (and EOS) sends a clear message to vendors and customers that SNMP technology has reached its peak. What we have now is as good as its ever going to get. Those that are happy with SNMPv3/SMIv2 will continue to use it. Those looking for something better will accelerate their efforts to transition to something else. >-Dave Andy >> -----Original Message----- >> From: Wijnen, Bert (Bert) [ mailto:[email protected]] >> >> So... not much (if anything) seems to be happening. >> ------_=_NextPart_001_01C2D3AD.7255DF50 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: Status of the WG</TITLE> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2>Hi,</FONT></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2>I have=20 a slightly different viewpoint. </FONT></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2>Both=20 eos and sming are developing add-ons to SNMPv3. And I think SNMPv3 is = the=20 problem. </FONT></SPAN><SPAN class=3D085282121-13022003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>SNMPv3 is incomplete, and the things it needs = are not new=20 mib syntax or compressed PDUs or TCP support. What it needs is some = guidance=20 about how to deploy it, and how to migrate a network, and network = management=20 tools, from SNMPv1 to SNMPv3.</FONT></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2><SPAN=20 class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2>SNMPv3, as=20 currently defined, is difficult to deploy. = </FONT></SPAN></FONT></SPAN><SPAN=20 class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2>There is no=20 standardized initial key distribution mechanism, only an experimental=20 Diffie-Hellman approach. </FONT></SPAN><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>There is no integration with = centralized key=20 management and authorization, such as RADIUS; one approach exists for = Kerberos,=20 but that has been labeled experimental, and Kerberos does not seem to be = in wide=20 commercial use. There has been no official work to standardized the = widely=20 desired AES support. </FONT></SPAN><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>There has been no work to guide=20 operators/vendors how to provide support for VACM views, given the = design of=20 existing mibs. </FONT></SPAN><SPAN class=3D085282121-13022003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>There has been no work to guide mib writers how = to write=20 VACM-friendly mibs. There has been no work to define an easier-to-deploy = access=20 control model. </FONT></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2>The=20 five leading network/systems management frameworks - HPOV, BMC = Patrol,=20 CA-Unicenter, Tivoli TME, and Spectrum - offer little support for SNMPv3 = messaging, and no support for managing the elements of SNMPv3 such = as=20 users, views, and groups. Best-of-breed application vendors such as = Concord=20 Communications and Micromuse do not offer SNMPv3 support. <SPAN=20 class=3D085282121-13022003><SPAN class=3D085282121-13022003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Equipment vendors have provided support for = SNMPv3 in their=20 devices, but even their own applications, such as CiscoWorks, hide = the=20 details of the underlying SNMPv3 systems, and do not take advantage of = the power=20 of SNMPv3 concepts.</FONT></SPAN></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>No SNMP applications have been = developed to=20 manage SNMPv3 key distribution in-band between multiple agents and = multiple=20 applications. I have seen no applications to provide an easy graphical = way to=20 define and distribute VACM views. </FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>There are a number of applications = that do=20 policy-based management, including assigning roles to users, but they = have not=20 been integrated with SNMPv3 users and groups. Different operators often = manage=20 different aspects of networks, such as routing or security, but no=20 standards have been developed to define policy-based division of labor = for=20 Network Management protocols.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>No standards have been defined for = integrating=20 the security models of SNMPv3 and CLI and web-based management. Securing = one=20 interface but not the others makes no sense. No work has been done to = define how=20 one should distribute SNMPv3 keys in CLI command=20 scripts.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><SPAN=20 class=3D085282121-13022003></SPAN></SPAN><SPAN = class=3D085282121-13022003><SPAN=20 class=3D085282121-13022003><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>EOS and SMING are interesting = research projects,=20 but they aren't very practical because they depend on a protocol and a = security=20 design that nobody can deploy reasonably. </FONT></SPAN></SPAN><SPAN=20 class=3D085282121-13022003><SPAN class=3D085282121-13022003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Before EOS and SMING become truly relevant, we = need to help=20 the industry get SNMPv3 deployed.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>We really need to decide whether = we believe=20 SNMPv3 is worth the effort to help get it deployed. If not, we should = declare it=20 Historic, pick an alternative, and move on. If we want it to be = accepted,=20 then we need to help the industry understand how to deploy it. So far, = we have=20 simply chosen to not get involved. If we don't believe it's worth the = work, why=20 should operators and vendors believe it's worth the=20 work?</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>I propose we deactivate EOS and = SMING, and=20 combine our efforts in an SNMPv3 deployment WG. This would be a good = opportunity=20 to have the network management experts and the operations experts work = together=20 to develop some recommended practices and the necessary missing pieces = to make=20 SNMPv3 a deployable secure network management=20 protocol.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></SPAN> </DIV> <DIV><SPAN class=3D085282121-13022003><SPAN = class=3D085282121-13022003><FONT=20 face=3DArial color=3D#0000ff size=3D2>dbh</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D085282121-13022003><SPAN=20 class=3D085282121-13022003></SPAN></SPAN><FONT face=3DTahoma><FONT = size=3D2><SPAN=20 class=3D085282121-13022003><FONT face=3DArial=20 color=3D#0000ff> </FONT></SPAN></FONT></FONT></DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 class=3D085282121-13022003> </SPAN>-----Original = Message-----<BR><B>From:</B>=20 Andy Bierman [mailto:[email protected]]<BR><B>Sent:</B> Thursday, = February 13,=20 2003 4:06 PM<BR><B>To:</B> Durham, David<BR><B>Cc:</B> Wijnen, Bert = (Bert);=20 Sming (E-mail); Randy Bush (E-mail)<BR><B>Subject:</B> RE: Status of the = WG<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>At 09:39 AM 2/13/2003 -0800, Durham, David = wrote:<BR>>The=20 silence is deafening, and says it all. It seems that while most = are<BR>>in=20 agreement that SMI is seriously antiquated, convoluted, and=20 requires<BR>>several maintenance fixes, there is very little = (apparently=20 zero now)<BR>>interest in fixing it and improving it. It would seem = people=20 are<BR>>satisfied with SNMP being regulated to a legacy systems=20 management<BR>>interface.<BR>><BR>>There is the realization = that=20 up-to-date data modeling languages are<BR>>already widely used and=20 available (e.g. XMLSchema), and that the IETF<BR>>should not be = engaged in=20 the task of inventing yet another idiosyncratic<BR>>data modeling=20 language... Particularly given that it will seriously<BR>>languish = behind=20 those that are commonly available today.<BR>><BR>>Looking at the = ROI on=20 this effort, there are those who are asking why<BR>>not just adopt = what is=20 already available and stop beating a dead horse<BR>>in the hopes it = will=20 rise.<BR><BR>I agree with this assessment. It would be a large=20 development<BR>effort to move from SMIv2 to any new syntax. The = key=20 question<BR>is how much benefit will be realized by making a = particular=20 change.<BR><BR>While I still believe there is enough benefit in the = data=20 modeling<BR>features of SMI-DS to make it worthwhile, I no longer = believe=20 that<BR>SNMP vendors and customers are willing to incur any = significant=20 cost<BR>to get this benefit. I think the resources devoted to=20 SNMP<BR>development are diminishing quickly (as expected for a=20 legacy<BR>technology), and developers and customers believe SMIv2 = is<BR>good=20 enough, for the amount of effort they are willing to<BR>invest in=20 SNMP.<BR><BR>The cost/benefit ratio for SMIv2.1 seems = worthwhile. =20 The<BR>need for HC data types has been known since (at least)=20 1992.<BR>Mandatory maintenance of SMIv2 is something that should = already<BR>be=20 done, so better late than never.<BR><BR>Keep in mind that the decision = to=20 abandon SMIv3 (and EOS)<BR>sends a clear message to vendors and = customers that=20 SNMP<BR>technology has reached its peak. What we have now is<BR>as = good as its=20 ever going to get. Those that are happy<BR>with SNMPv3/SMIv2 = will=20 continue to use it. Those looking<BR>for something better will=20 accelerate their efforts to<BR>transition to something=20 else.<BR><BR><BR>>-Dave<BR><BR>Andy<BR><BR><BR><BR>>> = -----Original=20 Message-----<BR>>> From: Wijnen, Bert (Bert) [<A=20 = href=3D"mailto:[email protected]">mailto:[email protected]</A>]<BR>>= ><BR>>>=20 So... not much (if anything) seems to be=20 = happening.<BR>>><BR><BR><BR></FONT></P></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C2D3AD.7255DF50--