COMMAND

	Cisco catalyst ports leak of restricted unicast  packets  cand  lead  to
	DoS

SYSTEMS AFFECTED

	

	Cisco Catalyst 4000 OS release 5.5.5; 6.3.5;  7.1.2;  and  probably  all
	others

PROBLEM

	Troy Coulombe reports :
	

	With the following configuration,
	

	 - Single VLAN, non-default \"VLAN 1\"; No Spanning Tree; 10/100 48 port blades.

	 - NO SPAN session is created.

	 - Using a sniffer to capture broadcasts/multicasts, etc only.

	

	Then in a middle of a TCP conversation, unicast packets sent to  a  host
	are flooded out all ports.
	

	 Details

	 =======

	

	Using a sniffer  [EtherPeek  NX  for  Windows,  NAI  Sniffer  Pro],  the
	Cat4006 floods TCP packets  out  to  all  ports.  Packets  captured  are
	unicast-mac and are not destined for the port  the  sniffer  is  on.  No
	SPAN session is created on the switch;  only  broadcasts/multicasts  and
	_initial_ session packets should be flooded. Sniffer is on  a  different
	port than the workstation and servers.
	

	It is understood that if the switch doesn\'t know where  a  MAC  is,  it
	will flood the packet out all ports until the MAC is  learned,  and  the
	CAM table is populated. Initial TCP packets are  also  captured  by  the
	sniffer, however, these packets would be indicated by the \"SYN\"  flag,
	and are considered normal.
	

	However, what is happening,  is  that  TCP  session  packets  are  being
	flooded, although the switch _should_ have learned the MAC.
	

	 Example

	 =======

	

	Example:
		

	01) workstation   -->   DNS server

		UDP DNS request packet

	

	02) workstation   <--   DNS server

		UDP DNS response packet

	

	03) workstation   -->   Server

		Initial TCP SYN packet

	

	04) workstation   <--   Server

		TCP SYN-ACK packet	

	

	05) workstation   -->   Server

		TCP ACK Packet

	

	06) workstation   <--   Server

		TCP Packet W

	

	07) workstation   <--   Server

		TCP Packet X

	

	08) workstation   <--   Server

		TCP Packet Y

	

	09) workstation   <--   Server

		TCP Packet Z

	

	Packet #01 is _not_ seen by the sniffer, and rightly  so,  assuming  the
	switch knows the MAC entry for the DNS server.
	

	Packet #02 is seen by the sniffer, but shouldn\'t have been. The  switch
	should have learned the workstation\'s MAC entry from packet #01.
	

	Packet #03 is _not_ seen by the sniffer, and rightly  so,  assuming  the
	switch knows the MAC entry for the Server.
	

	Packet #04 is seen by the sniffer, but shouldn\'t have been;  no  matter
	what. The switch now has had 2 different packets  from  the  workstation
	to learn it\'s MAC.
	

	Packet #05 is _not_ seen by the sniffer, and rightly so...
	

	Packet #06 through #09 are seen by  the  sniffer,  but  shouldn\'t  have
	been!
	

	Packet #10 is  assumed  to  be  an  \"ACK\"  from  the  workstation  and
	suddenly the switch registers  the  workstation\'s  MAC.  No  additional
	packets are seen for _this_ conversation.

SOLUTION

	Workaround: Setting the CAM agingtime to a larger time _helps_ but  does
	not completely eliminate the problem. \"set  cam  agingtime  xx  14400\"
	where xx is VLAN #.
	

	No patch yet.