Abstract:
Disclosed is a method and apparatus for checking link layer protocol frames such as Ethernet frames. The method can be implemented on a processor executing software instructions stored in memory. In one embodiment of the invention, the method includes receiving an Ethernet frame, and counting data bytes of the Ethernet frame to generate a total number of counted bytes. The total number of counted bytes can be used to calculate a data length of a datagram of the Ethernet frame. Once calculated, the datagram data length can be compared to a predetermined value. If the datagram length does not fall within an acceptable range of the predetermined value, the Ethernet frame may be dropped so that the Ethernet frame does not reach its final destination.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite allows computers of all sizes, from many different computer vendors, running totally different operating systems, to communicate with each other. Stevens, W. Richard, 1994, TCP/IP Illustrated, Volume 1, which is incorporated herein by reference, describes general aspects of the TCP/IP protocol suite. Request For Comment (RFC) 793, also incorporated by reference, is considered the main TCP specification. Additional RFCs that describe TCP and IP are published for informational purposes. The RFCs are provided by the Internet Engineering Task Force (IETF) at www.ietf.org.  
           [0002]    [0002]FIG. 1 is a block diagram illustrating a networked system consisting of a pair of computer systems (nodes)  12  and  14  executing the TCP/IP protocol suite. In FIG. 1, nodes  12  and  14  communicate with each other by transmitting frames of data via router  16  and Ethernet communication links  20  and  22 .  
           [0003]    [0003]FIG. 2 is a block diagram illustrating relevant components the TCP/IP protocol suite. More particularly, nodes  12  and  14  are shown having four communication layers  30 - 36  and  40 - 46 , respectively. Layers  30 - 36  and  40 - 46  take form in software executing on one or more processors in nodes  12  and  14 , respectively. Layers  32 - 36  and  42 - 46  are implemented in operating systems of nodes  12  and  14 , respectively, while layers  30  and  40  take form in any one of many user applications including File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), telnet for remote login, etc.  
           [0004]    Layers  32  and  42  of nodes  12  and  14 , respectively, are commonly referred to as the transport layers. There are several distinct transport layers including TCP and User Datagram Protocol (UDP). For purposes of explanation, layers  32  and  42  will take form in either the TCP or UDP transport layers. Layers  34  and  44  are commonly referred to as the network layers. A network layer may take many forms such as Internet Control Message Protocol (ICMP) or IP. For purposes of explanation, FIG. 2 will be described with layers  34  and  44  taking form in the well-known IP network layer. Lastly, layers  36  and  46  are commonly referred to as the link or network interface layers. This layer handles the details of physically interfacing with a communication link. For purposes of explanation, link layers  36  and  46  will take form in Ethernet link layers for interfacing with Ethernet communication links  20  and  22 , respectively.  
           [0005]    Most networked systems are designed such that at least one node is a client to a server node. In FIG. 2, node  12  is presented as a client to server node  14 . In this configuration, server application  40  provides some type of service (e.g., SMTP) in response to a request from client application  30 . When client application  30  communicates with server application  40 , including a request for service, client application  30  sends data down through layers  32 - 36  until the data is sent as a stream of bits to node  14  via router  16  and communication links  20  and  22 . The data received by node  14  is sent up through layers  46 - 42  until it reaches server application  40 .  
           [0006]    As data moves down layers  30 - 36  of node  12 , each of the layers  30 - 36  adds headers (and sometimes trailers) containing communication information. FIG. 3 illustrates relevant aspects of this process. FIG. 3 shows data  50  generated by application layer  30 . An application header  52  is concatenated to data  50  by application layer  30 , the result of which is provided to TCP/UDP layer  32  as application data  54 . TCP/UDP layer  32 , in turn, concatenates a TCP or UDP header to application data  54  received from application layer  30 . For purposes of explanation, TCP/UDP layer  32  concatenates a TCP header  56  to application data  54 , the result of which is provided to IP layer  34 . The unit of data that the TCP layer  32  sends to IP layer  34  is called an IP payload. IP layer  34  concatenates an IP header  60  to the IP payload it receives, the result of which is provided to Ethernet link  36 . Generally, the unit of data that layer  34  sends to layer  36  is referred to as an IP datagram (datagram) or packet. As will be more fully described below, a datagram can be fragmented and sent to Ethernet layer  36  as datagram fragments. Ethernet layer  36  appends an Ethernet header  62  and Ethernet trailer  64  to the datagram or datagram fragments received from IP layer  34 , the result of which is referred to as an Ethernet frame.  
           [0007]    The Ethernet frame is transmitted to node  14  as a stream of bits via router  16  and Ethernet communication links  20  and  22  (FIG. 2). When the Ethernet frame is received at destination node  14 , the frame moves up through the protocol layers  46 - 42 , and all headers (and trailers) are removed by the appropriate protocol layer until the original data  50  is provided to server application  40 . Each layer looks at certain identifiers in its corresponding header to determine which succeeding layer is to receive the data. This is called demultiplexing. For example, Ethernet layer  46  routes the datagram or datagram fragment of the frame it receives to IP layer  44  after Ethernet layer  46  strips off the Ethernet header and trailer  62  and  64 , respectively.  
           [0008]    [0008]FIG. 4 shows an exemplary Ethernet frame in greater detail. The Ethernet frame includes header  62 , datagram  64 , and trailer  66 . The header  62  consists of a 6-byte Ethernet destination address, a 6-byte Ethernet source address, and a 2-byte type code. The Ethernet trailer  66  consists of a Cyclic Redundancy Check (CRC) field. CRC field is used to detect errors in the rest of the frame. Figures in this specification, including FIG. 4, show an empty 2-byte field in the Ethernet frame header adjacent the 2-byte type code. This empty field contains no data. This empty field is simply provided in the Figures so that datagram  64  can be positioned to begin at the first bit of the first line after the header.  
           [0009]    [0009]FIG. 5 illustrates an exemplary IP datagram having an IP header  80  and IP payload (e.g., TCP segment)  82 . The IP header shown in FIG. 5 includes many fields each of which stores a value. The 4-bit header length field defines the number of 32-bit words in the IP header, including any option fields. The 16-bit total length field defines the total length of the IP datagram in bytes. The header length subtracted from the total length can be used to determine the IP payload (e.g., TCP segment) length. The 8-bit protocol field defines the transport layer (e.g., TCP or UDP) that is to receive the IP payload of the datagram.  
           [0010]    Normally, an upper limit is imposed on the size of the frame that can be transmitted between nodes  12  and  14 . Many IP datagrams are fragmented to meet this limit. Thus, an IP datagram may be fragmented into IP datagram fragments, each of which is provided to the Ethernet layer for transmission in a separate frame. When an IP datagram is fragmented it is not reassembled until it reaches its final destination. The IP layer at the destination performs the reassembly. The 16-bit identification field shown in FIG. 5 contains a unique value for each IP datagram that the sender transmits. This number is copied into each fragment of a particular datagram. The 13-bit fragment offset field of the header shown in FIG. 5, contains the offset (in 8 byte units), of the fragment from the beginning of the original IP datagram. When an IP datagram is fragmented, the total length field of each fragment is changed to be the size of that fragment.  
           [0011]    [0011]FIGS. 6 and 7 illustrate UDP and TCP segments, respectively. In FIG. 7, the TCP segment (IP payload) includes a TCP header  90  and application data. TCP header  90  includes several fields each containing a value. The 4-bit header length defines the length of the TCP header in 32-bit words. When a new connection is sought to be established between nodes  12  and  14  for the purposes of, for example, file transfer, the 1-bit SYN flag of the TCP header  90  is turned on or set to binary 1. TCP headers as well UDP headers include 16-bit port number fields. Servers, such as node  14 , are normally known by their well-known port number. For example, every TCP/IP implementation that provides an FTP server provides that service on TCP port number  21 . Telnet servers are commonly on TCP port number  23 .  
           [0012]    Unauthorized access (i.e., hacking) of computer systems, such as node  14  of FIG. 2, continues to be an ongoing problem. Filters are often provided in routers, such as router  16 , for preventing unauthorized access of computer systems. Filters, oftentimes referred to as firewalls, may take form in hardware and/or software executing on one or more processors. FIG. 2 shows router  16  having a filter  100 . Filter  100  checks frames (or the IP datagrams thereof) received by router  16  to ensure that the frames are not designed to initiate an unauthorized operation at node  14 . If a frame is deemed by filter  100  to be part of an authorized operation, the frame is allowed to pass through the filter. If the frame is deemed by the filter to be part of an unauthorized operation, the frame is dropped by filter  100  so that the frame cannot reach its final destination (i.e., node  14 ).  
           [0013]    Filter  100  performs numerous checks on frames it receives. For example, filter  100  compares the destination port number and SYN flag values of all frames it receives. If the destination port number and SYN flag values of a received frame equal  21  and binary 1, respectively, the received frame is configured to initiate an unauthorized file transfer protocol (FTP) and will be dropped by filter  100 . FIG. 8 shows a frame  102  having a TCP header  90  with a destination port number and a SYN flag set to  21  and binary 1, respectively. Frame  102  is configured to initiate a file transfer at node  14 . Filter  100  will drop frame  102 .  
           [0014]    As noted above, IP datagrams can be fragmented to meet the limit on the size of frames that can be transmitted between nodes  12  and  15 . Fragmented IP datagrams are not reassembled until they reach their final destination, e.g., node  14 . Thus, Ethernet frames containing datagram fragments can pass through router  16 , and filter  100  thereof, before reaching destination node  14 . Fragmentation can be used to disguise frames from filter  100 . One technique for disguising frames using fragmentation is often referred to as a “tiny fragment attack.” For example, FIGS. 9 and 10 illustrate frames containing datagram fragments which, when reassembled at node  14 , can initiate an otherwise unauthorized file transfer operation. More particularly, FIG. 9 shows a frame  104  consisting of an Ethernet header  62 , datagram fragment  64 , and CRC  66 . Datagram fragment  64  of frame  104  includes full IP and TCP headers. Frame  106  shown in FIG. 10 also includes an Ethernet header  62 , datagram fragment  64  and CRC  66 . Datagram fragment  64  includes an IP header  80  with fragment offset set to 0 and a less than full TCP header  90 . As such, datagram fragment  64  of frame  106  is referred to as a tiny fragment. As will be more fully described below, filter  100  will pass frames  104  and  106  to node  14 . FIG. 11 shows the datagram payload which results when node  14  reassembles the payloads of the datagram fragments of frames  104  and  106 . The datagram payload of FIG. 11 initiates an otherwise unauthorized FTP at node  14 .  
           [0015]    Frames  104  and  106  shown in FIGS. 9 and 10, respectively, are transmitted to router  16  in sequence. As noted above, one of the checks performed by filter  100  is to compare the destination port number and SYN flag values to  21  and binary 1, respectively, of received frames. In frame  104  of FIG. 9, the destination port number in TCP header  90  is set to 23 while the SYN flag is set to binary 1. With these destination port number and SYN flag values, frame  104  passes the filter check mentioned above, and frame  104  is forwarded to node  14 . Frame  106  shown in FIG. 10 includes only a source port number, a destination port number, and a sequence number. Filter  100  will pass frame  106  since frame  106  lacks a destination port number equal to 21 and SYN flag equal to binary 1. It is noted that the fragment offset is set to 0 within frame  106 . As such, when the datagram payload fragments contained in frames  104  and  106  are reassembled at node  14 , the source port number, destination port number, and sequence number of the TCP header  90  in FIG. 9 will be overwritten with the source port number, destination port number, and sequence number, respectively, of the TCP header  90  shown in FIG. 10, resulting in the datagram shown in FIG. 11.  
           [0016]    The tiny fragment attack described above can be averted. More particularly, RFC  3128  describes an algorithm which may be used within filter  100  to avert the tiny fragment attack described above. The RFC 3128 algorithm provides:  
                                                                                               if (Protocol = TCP)                if   (Fragment Offset = 0)                Check Length 1 ≧ 16 bytes                else                Check Fragment Offset ≧ 2,                      
 
           [0017]    where Length 1 is calculated by filter  100  for each frame according to the following equation:  
                                       Length 1 (in bytes) =   (Total Length Value in IP Header of the           Received Frame) − ((IP Header Length           Value in IP Header of the Received Frame) × 4).                  
 
           [0018]    In accordance with the RFC 3128 algorithm above, filter  100  will drop any frame it receives if the protocol field of the IP header is set to TCP, the fragment offset of the IP header is set to 0, and the calculated Length 1 is less than 16 bytes. Additionally, filter  100  will drop any received frame if the fragment offset of the IP header is set to 1. Frame  104  shown in FIG. 9 will pass both checks performed by filter  100  executing the RFC 3128 algorithm above. However, frame  106  shown in FIG. 10 will be dropped by filter  100  since the calculated Length 1 of frame  106  is 8 bytes.  
           [0019]    The RFC 3128 algorithm set forth above is incapable of averting certain variations of the tiny fragment attack described above. To illustrate, FIG. 12 shows a frame  108  having an Ethernet header  62 , a datagram  64 , and CRC  66 . As can be seen in FIG. 12, TCP header  90  of frame  108 , like TCP header  90  shown in FIG. 10, is less than a complete or full TCP header. Note also that the value of the total length field of the IP header is 36 bytes in frame  108  even though actual total length of the datagram  64  is 28 bytes. Frame  108  may pass RFC 3128 algorithm above since the calculated Length 1 is 16 bytes. Unfortunately, if the frame  108  passes filter  100  and datagram  64  of frame  108  combines with random data in memory of node  14 , the result may produce an unauthorized operation such as file transfer protocol.  
         SUMMARY OF THE INVENTION  
         [0020]    Disclosed is a method and apparatus for checking Ethernet frames. The method can be implemented on a processor executing software instructions stored in memory. In one embodiment of the invention, the method includes receiving an Ethernet frame, and counting data bytes of the Ethernet frame to generate a total number of counted bytes. The total number of counted bytes can be used to calculate a data length of a datagram of the Ethernet frame. Once calculated, the datagram data length can be compared to a predetermined value. If the datagram length exceeds the predetermined value, the Ethernet frame may be dropped so that the Ethernet frame does not reach its final destination 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0021]    The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.  
         [0022]    [0022]FIG. 1 is a block diagram illustrating relevant components of a networked system;  
         [0023]    [0023]FIG. 2 is a block diagram illustrating relevant components of the nodes of the networked system shown in FIG. 1;  
         [0024]    [0024]FIG. 3 illustrates aspects of data communication between layers of one of the nodes shown in FIG. 2;  
         [0025]    [0025]FIG. 4 is a block diagram representation of a typical Ethernet frame;  
         [0026]    [0026]FIG. 5 is a block diagram representation of a typical IP datagram;  
         [0027]    [0027]FIG. 6 is a block diagram representation of a typical UDP segment;  
         [0028]    [0028]FIG. 7 a block diagram representation of a typical TCP segment;  
         [0029]    [0029]FIG. 8 is a block representation of an exemplary Ethernet frame;  
         [0030]    [0030]FIG. 9 is a block representation of an exemplary Ethernet frame;  
         [0031]    [0031]FIG. 10 is a block representation of an exemplary Ethernet frame;  
         [0032]    [0032]FIG. 11 is a block representation of an exemplary IP datagram;  
         [0033]    [0033]FIG. 12 is a block representation of an exemplary IP datagram;  
         [0034]    [0034]FIG. 13 is a block diagram illustrating relevant components of a networked system employing one embodiment of the present invention, and;  
         [0035]    [0035]FIG. 14 is a block diagram illustrating relevant components of one embodiment of a filter employed in the router or switch of FIG. 13. 
     
    
       [0036]    The use of the same reference symbols in different drawings indicates similar or identical items.  
       DETAILED DESCRIPTION  
       [0037]    [0037]FIG. 13 is a block diagram illustrating relevant components of a networked system  110  employing one embodiment of the present invention. FIG. 13 shows a pair of computer systems (nodes)  112  and  114  executing the TCP/IP protocol suite. In FIG. 13, nodes  112  and  114  are coupled to each other via a router or switch  116  and Ethernet communication links  120  and  122 . In one embodiment, the present invention may take form in software executing on one or more processors within router or switch  116 . In another embodiment, the present invention may take form in an application specific integrated circuit (ASIC) in router or switch  116 . The present invention should not be limited to use within router or switch  116 . The present invention could find use within, for example, node  114 . For purposes of explanation, the present invention will be explained as being used within router  116 , it being understood that the present invention should not be limited thereto.  
         [0038]    Nodes  112  and  114  are shown having four communication layers  130 - 136  and  140 - 146 , respectively. Layers  130 - 136  and  140 - 146  take form in software instructions executing on one or more processors in nodes  112  and  114 , respectively. Layers  132 - 136  and  142 - 146  are implemented in operating systems of nodes  12  and  14 , respectively. Layers  130  and  140  and nodes  112  and  114 , respectively, take form in any one of many user applications including FTP, SMTP, telnet, etc.  
         [0039]    For purposes of explanation, layers  132  and  142  will take form in either TCP or UDP transport layers, layers  134  and  144  will take form in IP network layers, while layers  136  and  146  take form in Ethernet link layers for interfacing with Ethernet communication links  120  and  122 , respectively. In FIG. 13, node  112  is presented as a client to server node  114 . Server application  40  provides some type of service (e.g., SMTP) to client application  130  in response to a request from client application  130 . Client application  130  communicates with server application  140  by sending data down through layers  132 - 136  until the data, along with appended headers and/or trailers, is sent as a stream of bits to node  114  via router  116  and communication links  120  and  122 . The data received by node  114  is sent up through layers  146 - 142  until the data, less headers and/or trailers reaches server application  140 . The type of headers and/or trailers generally added to data generated by layers  130 - 136  are described in the background section above with reference to FIGS. 4-7.  
         [0040]    Router  116  shown in FIG. 13 includes a filter  142  that checks frames it receives. If a frame received by router  116  passes the checks performed by filter  142 , the frame is passed to, for example, node  114 . If a frame received by router  116  does not pass one or more of the checks performed by filter  142 , the frame is dropped so that the frame does not reach its destination (e.g., node  114 ). Filter  142  can perform many checks on frames received by router  116 . In one embodiment, filter  142  performs any one or more of the checks of the algorithm listed below:  
                                                                                                                                                 if (Protocol = TCP)                if   (Fragment Offset = 0)                   Check Length 1 ≧ (P0 × 8)   Check (1)               Check Length 2 ≧ (P0 × 8)   Check (2)               Check TCP Header Length ≧ 5   Check (3)           else               Check Fragment Offset ≧ P0   Check (4)                if (Protocol = UDP)                if   (Fragment Offset = 0)                   Check Length 1 ≧ (P1 × 8)   Check (5)               Check Length 2 ≧ (P1 × 8)   Check (6)           else               Check Fragment Offset ≧ P1   Check (7)                else                if   (Fragment Offset = 0)                   Check Length 1 ≧ (P2 × 8)   Check (8)               Check Length 2 ≧ (P2 × 8)   Check (9)           else               check Fragment Offset ≧ P2,   Check (10)            where Length 1 and Length 2 are calculated according to the       following equations:                Length 1 (in bytes) =   (Total Length Value in IP Header of the               Received Frame) − ((IP Header Length               Value in IP Header of the Received Frame)               × 4).           Length 2 (in bytes) =   (Total Number of Counted Bytes in the               Received Frame) − (Total Number of               Data Bytes In Ethernet Header and               Trailer of the Received Frame) − ((IP               Header Length Value in IP Header of the               Received Frame) × 4)                      
 
         [0041]    P0, P1, and P2 in the above algorithm are programmable values stored within memory. P0, P1, and P2 may be equal to each other, or different from each other. It is noted that P0, P1, and P2 are multiplied by 8 in the above algorithms. In an alternative embodiment, P0, P1, and P2 may be multiplied by values other than  8 .  
         [0042]    Length 2 is calculated as a function of the total number of counted bytes in the received frame to be checked. The total number of counted bytes of the received frame can be generated in one of many different ways. In one embodiment, a counting variable N in memory is initially to 0. Thereafter, N is incremented by one for each byte in the received frame until all bytes in the received frame are counted. The bytes of the frame can be counted as the bytes enter the router  116 , or the bytes can be counted after the received frame has been temporarily stored in memory of router  116 .  
         [0043]    In an alternative embodiment, Length 2 can be calculated as follows:  
         Length 2 (in bytes)=(Total Number of Counted Bytes in the Datagram of the Received Frame)−((IP Header Length Value in IP Header in the Received Frame)×4)  
         [0044]    It is noted that in this alternative embodiment of calculating Length 2, only the bytes of the datagram of the received frame need be counted. The total number of counted bytes of the datagram can be generated in one of many different ways. In one embodiment, a counting variable M in memory is initially to 0. Thereafter, M is incremented by one for each byte of the datagram in the received frame until all bytes of the datagram are counted. The bytes of the datagram can be counted as the bytes of the datagram enter the router  116 , or the bytes of the datagram can be counted after the datagram have been temporarily stored in memory of router  116 .  
         [0045]    In operation, filter  142  will drop any received frame if any one or more of the various checks (1)-(10) are not passed. It is noted that filter  142  need not perform all checks (1)-(10) listed above for each frame received by router  116 . For example, filter  142  at one point in time, may perform only check (2) or only check (3), or filter  142  may perform only checks (2), (3) and (4) on frames received by router  116 . At another point in time, filter  142  may perform all checks (1)-(10) on frames received by router  116 . For purposes of explanation, it will be presumed that filter  142  performs all checks (1)-(10) on all frames received by router  116 .  
         [0046]    Thus, if router  116  receives a frame, regardless of whether its datagram contains a UDP or TCP segment as identified in the protocol field of the IP header, if the fragment offset of the IP header is set to 0, and if Lengths 1 or 2 are calculated to be less than P2×8, filter  142  will drop the frame such that it never reaches its destination (e.g., node  14 ) in accordance with checks (8) and (9), respectively. If router  116  receives a frame, regardless of whether its datagram contains a UDP or TCP segment as identified in the protocol field of the IP header, filter  142  will drop the frame if the fragment offset defined in the IP header is not equal to 0 but is less than P2 in accordance with check (10).  
         [0047]    If router  116  receives a frame having a UDP segment in its datagram (as identified in the protocol field of the IP header of the received frame) and if the fragment offset set forth in the IP header of the received frame is set to 0, then filter  142  will drop the received frame if Length 1 or Length 2 is less than P1×8 in accordance with checks (5) and (6), respectively. If router  116  receives a frame having a UDP segment, filter  142  will drop the frame if the fragment offset set forth in the IP header is not set to 0 but is set to a value less than P1 in accordance with check (7).  
         [0048]    If router  116  receives a frame having a TCP segment in its datagram (as identified in the protocol field of the IP header of the received frame), filter  142  will drop the frame if the fragment offset value set forth in the IP header is set to 0, and if Length 1 or Length 2 is less than P0×8 in accordance with checks (1) and (2), respectively. If router  116  receives a frame having a TCP segment in its datagram (as identified in the protocol field of the IP header of the received frame), filter  142  will drop the frame if the value of the TCP header length field is than 5 in accordance with check (3). If router  116  receives a frame having a TCP segment, filter  142  will drop the frame if the fragment offset set forth in the IP header is not set to 0 but is set to a value less than P0 in accordance with check (4).  
         [0049]    As described in the background section above Frame  108  in FIG. 12 is capable of passing the RFC 3128 algorithm. If router  116  receives frame  108 , filter  142  executing the algorithm set forth above, will drop frame  108  if, for example, P0 is set to 2 such that P0×8 is 16 bytes. When router  116  receives frame  108 , Lengths 1 and 2 are calculated. For purposes of explanation the total number of bytes of frame  108  including the bytes in the Ethernet header and trailer, is counted. In the illustrated example, because each line of frame  108  is 32-bits long, a total number of 46 bytes will be counted. The total number of bytes in the Ethernet header and trailer is 18. The IP header length value in the IP header of frame  108  is 5. Accordingly, Length 2 (in bytes)=46−18−(5×4)=8. Because 8 bytes is less than P0×8=16 bytes, frame  108  shown in FIG. 12 will be dropped by filter  142  in accordance with check (2).  
         [0050]    As noted above, the checks (1)-(10) above can be performed by one or more processors within router  116  executing software instructions. Alternatively, the checks (1)-(10) above can be performed by one or more ASICs within router  116 . FIG. 14 illustrates one non-software implemented filter embodiment for checking frames in accordance with checks (1)-(10). More particularly, FIG. 14 shows in block diagram form, a media access control (MAC) circuit  144  coupled to a parser circuit  146  and ASIC  148 . In operation, MAC circuit  144  receives an Ethernet frame directly or indirectly from node  112  via Ethernet communication link  120 . Media access controller may store the received frame within a memory (not shown). MAC circuit  144  counts the total number of bytes within the received frame, including the number of bytes of the Ethernet frame header and trailer. This value is provided as the total number of counted bytes to ASIC  148 . Additionally, MAC circuit  144  provides the frame data to ASIC  148  and parser  146 . It is noted that MAC circuit  144  processes the received frame into a format that can be understood by ASIC  148  and parser  146 . ASIC  148  in response to receiving the frame data and the total number of counter bytes from MAC circuit  144 , performs one or more of the checks (1)-(10) above. If the frame received by ASIC  148  does not meet one or more of the checks set forth above, then the frame is dropped.  
         [0051]    Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the embodiments described herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.