COMMAND
	    SNMP
SYSTEMS AFFECTED
	    SNMP communities in 3Com HiPer Arcs (other 3Com products?)
PROBLEM
	    Jeff Mcadams found  following.  The  3Com HiPer Arc  cards are the
	    new generation access  server cards for  the Total Control  Access
	    Server system.  These cards use the "Pilgrim" code base for  their
	    software.  Jeff  has been told  by some people  at 3Com that  this
	    code base is going to be  the code that, eventually, all of  their
	    routing  products   will  be   running.    Jeff  has    experience
	    specifically with HiPer Arcs in Total Control racks...but  because
	    the code  base that  is commonly  called "Pilgrim"  is shared with
	    several  other  products  within  3Com   (and  soon  to  be   more
	    apparently) this problem might  be more widespread...   The impact
	    is that anyone  with any SNMP  access to the  box is likely  to be
	    able  to  elevate  their  access  to  the  highest level of access
	    defined on the box.
	    There are three levels of  access on HiPer Arcs...read only,  read
	    write,  and   administrative.   The   crux  of   the  problem   is
	    simple...the usrSnmpCommAccess and  other related SNMP  tables and
	    values are fully readable by  all access levels.  This  means that
	    someone with a read-only  community string can read  the community
	    table and see what read-write and administrative community strings
	    are defined on the system to be used.
SOLUTION
	    There  are  several  workarounds.   First,  the  Arcs allow you to
	    specify specific IP addresses or IP address pools from which  SNMP
	    access will be allowed for  each community string.  Setting  these
	    restrictions will restrict  access for specific  community strings
	    for specific hosts, which...while not being great, is better  than
	    nothing.  This also still allows the other community strings to be
	    readable, if  not useable,  and could  possibly be  used in  other
	    places.   The  other  workaround  is  to  not define any community
	    strings on the Arcs at all.   SNMP access can still be granted  to
	    the Arc,  just not  directly.   The Total  Control access  systems
	    have a Network Management Card which is used for most SNMP  access
	    to the Total Control components.  The Arc has its own agent, other
	    cards use the NMC  card for their agent.   The NMC can be  used as
	    an SNMP relay agent  on behalf of the  Arcs.  The procedure  to do
	    this is to specify the NMC's community string with  "@<entitynum>"
	    appended on the  end.  <entitynum>  is a value  used internally in
	    the chassis to  refer to specific  components of the  system.  For
	    example, the  card in  slot 16  (typically the  HiPer Arc)  has an
	    entitynum of 16000.  The card  in slot 5 would be an  entitynum of
	    5000.   The  third  modem  on  the  card  in  slot  5  would be an
	    entitynum  of  5003.   So,  to  send  an  SNMP command to the Arc,
	    assuming its in slot 16,  and assuming an NMC community  string of
	    "public" for example purposes,  you'd use the community  string of
	    "public@16000".  The only real drawback to this workaround is  the
	    extra load that is  put on the NMC  cards (many of which  are only
	    486  processor  based...none-too-overpowered),  and  that the SNMP
	    operations  are  slowed  down  by  having  to be processed through
	    another system.