Abstract:
Methods, apparati, and computer-readable media for updating proxy executable code. An apparatus embodiment of the present invention comprises generic universal proxy executable code that can be instantiated multiple times, with each instance being driven by a different set of files comprising a protocol specification file and a proxy activity code file, to control protocol decomposition and proxy functions, respectively. In a method embodiment of the present invention, a protocol specification is created or updated; proxy activity code, separate from the protocol specification, is created or updated; and the proxy executable code is executed using the protocol specification and the proxy activity code.

Description:
TECHNICAL FIELD 
     This invention pertains to the field of creating and updating computer proxies. 
     BACKGROUND ART 
     There are many computer products that contain proxies for many protocols. This is especially true for data security products. In particular, desktop, gateway, and appliance versions of antivirus, firewall, antispam, content inspection, logging, filtering, intrusion prevention, and intrusion detection products all contain proxies for many protocols. Many of these products&#39; proxies are for the same protocols, but each proxy is implemented independently. New protocols come along frequently, and support for a greater number of protocols would be beneficial for all such products. Furthermore, support for existing protocols often needs to be updated due to changes in the way the protocol is used, understood, or defined. Implementation of proxies for new protocols, or updates to existing proxies, is usually a difficult and lengthy task and is often error prone. Furthermore, updating products in the field to add support for new protocols can be disruptive if such updates require a restart of the proxy executable, and these updates usually do require such a restart. 
     When tasked with writing a proxy for a given protocol, a computer programmer usually begins by looking up the protocol&#39;s specification. This specification may be published in the form of an RFC (Request for Comments) by the authority that defines the protocol. The RFC usually defines the protocol using a grammar such as BNF (Backus-Naur Form). Typically, the programmer then writes a proxy that intertwines a custom protocol decomposer (based upon the programmer&#39;s interpretation of the RFC) with application specific logic to implement the proxy activity code. Little, if any, of this proxy work can be used for creation of a new proxy. The treatment of a given protocol stream by different handcrafted protocol decomposition implementations is likely to vary widely, and is unlikely to rigorously match all aspects of the BNF from the RFC. Furthermore, such traditional proxies are delivered to customers as executable binaries, and customers are loath to update or deploy new executable binaries in the field, especially when doing so requires a restart of the proxy executable. When the BNF specification for the protocol changes, making the requisite changes to a traditional proxy implementation can be tedious, even if such changes are immaterial to the proxy activity code. 
     The present invention overcomes the aforementioned problems associated with the conventional art. 
     DISCLOSURE OF INVENTION 
     Methods, apparatus, and computer-readable media for updating proxy executable code ( 5 ). An apparatus embodiment of the present invention comprises generic universal proxy executable code ( 5 ) that can be instantiated multiple times, with each instance being driven by a different set of files comprising a protocol specification file ( 1 ) and a proxy activity code file ( 2 ), to control protocol decomposition and proxy functions, respectively. In a method embodiment of the present invention, a protocol specification ( 1 ) is created or updated ( 21 ); proxy activity code ( 2 ), separate from the protocol specification ( 1 ), is created or updated ( 22 ); and the proxy executable code ( 5 ) is executed ( 23 ) using the protocol specification ( 1 ) and the proxy activity code ( 2 ). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which: 
         FIG. 1  is a system level diagram illustrating apparatus of the present invention. 
         FIG. 2  is a flow diagram illustrating a first method embodiment of the present invention. 
         FIG. 3  is a flow diagram illustrating a second method embodiment of the present invention. 
         FIG. 4  is a flow diagram illustrating a third method embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     As used throughout the present specification including claims, the following terms have the following meanings: 
     “Proxy” is defined in the broad sense to mean a computational module containing executable code implementing a certain protocol. A firewall proxy, for example, inspects messages that enter the firewall. The computational module can be implemented in software (including scripting as well as compiled binary code), firmware, and/or hardware. The executable code can be in the form of a .DLL that requires some other module to execute said executable code. 
     “Protocol” is an ordered sequence of rules for performing a function on a computer system. Examples of protocols include SMTP, HTTP, FTP, and instant messaging protocols. An SMTP protocol, for example, defines the function of sending e-mail messages. 
     “Protocol specification” is the architectural definition that gives the essential features of the protocol. 
     “Proxy activity code” is computer code that performs the mandatory and/or optional features of the protocol. There can be many proxy activity codes associated with a single protocol specification. 
     “Coupled” means any type of direct or indirect communicative relationship. 
     “Data-driven” module is a module that is updated by just one or more data files, i.e., no executables are needed to update the module. Execution of a data-driven executable module is driven or affected by the data consumed by the executable module. 
     “Updating” proxy  5  means creating or updating proxy  5 . 
     A protocol is usually published in the form of an RFC (Request for Comments) from the protocol authority, e.g., IETF (Internet Engineering Task Force). The protocol is usually described by using a preselected grammar  7 , such as one of the BNFs (Backus-Naur Forms). These BNFs include conventional BNF, EBNF (Extended Backus-Naur Form), and ABNF (Augmented BNF). In the present invention, the protocol specification&#39;s grammar  7  can also comprise natural English or other natural language, regular expression, or a grammar that can be understood by one of the software tools known as Lex, Yacc, Gold, and Spirit. Lex and Yacc are third party Open Source tools, and require their inputs to be in BNF. The Gold parser is a Yacc-like tool that allows specification of grammars (typically programming language grammars) using BNF but not EBNF. The output of a Gold parser is a data file that represents the grammar. Spirit is the parsing component of the Boost library, an Open Source library of libraries. Lex, Yacc, Gold, and Spirit can be used to help create protocol specification compiler  8 . 
     Below is an excerpt from RFC 2821 (the SMTP protocol) giving an example of ABNF: 
     The syntax for a positive response, using the ABNF notation and terminal symbols of [8], is:
         ehlo-ok-rsp=(“250” domain [SP ehlo-greet] CRLF)
           /(“250-” domain [SP ehlo-greet] CRLF
               *(“250-” ehlo-line CRLF)
                   “250” SP ehlo-line CRLF)   
                   
               
           ehlo-greet=1*(% d0-9/% d11-12/% d14-127)
           ; string of any characters other than CR or LF   
           ehlo-line=ehlo-keyword*(SP ehlo-param)   ehlo-keyword=(ALPHA/DIGIT)*(ALPHA/DIGIT/“-”)
           ; additional syntax of ehlo-parms depends on   ; ehlo-keyword   
           ehlo-param=1*(% d33-127)
           ; any CHAR excluding &lt;SP&gt; and all   ; control characters (US-ASCII 0-31 inclusive)   
               

     Turning to  FIG. 1 , runtime proxy executable code  5  is the code that performs the proxy function or functions. The term “runtime proxy executable code” is sometimes used interchangeably herein with the term “proxy”. Proxy executable code  5  can be instantiated multiple times, as described below. 
     The protocol specification  7  is normally provided using a grammatical form  7 , as discussed above. Protocol specification compiler  8  is a module that takes the grammatical form  7  as input, and outputs a protocol specification file  1  that represents the protocol specification in a more compact form. In one embodiment, protocol specification  1  consists solely of data and does not contain any executable code. 
     Proxy activity code  2  is generated independently of the protocol specification  1 . In one embodiment, proxy activity code  2  consists solely of data and does not contain any executable code. In one embodiment, proxy activity code  2  is written in a scripting language such as Java, Visual Basic, or P-Code. P-Code is a scripting language developed by Symantec Corporation of Cupertino, Calif., and is used in Symantec&#39;s antivirus, intrusion detection, and firewall products. 
     Each instance of runtime proxy executable code  5  consumes, as input, the protocol specification  1  and proxy activity code  2  associated with that instance. In one embodiment, optional protocol-code association module  3 , which links elements of proxy activity code  2  with elements of protocol specification  1 , is also an input to runtime proxy executable code  5 . Modules  1 ,  2 ,  3 ,  5 ,  7 , and  8  can be embodied in software, firmware, and/or hardware, or any combination thereof. 
     Runtime proxy executable code  5  can be instantiated multiple times, each time with different inputs  1 ,  2 , and/or  3 , to support different protocols, or the same protocols for different purposes (functions). Thus, proxy  5  is a true universal (generic) reusable proxy. At least one protocol specification  1  can consist solely of data (i.e., not contain any executable code). Similarly, at least one proxy activity code  2  can consist solely of data (i.e., not contain any executable code). In the case where two or more instances of the same proxy  5  are used to implement the same protocol but for different purposes, the protocol specification file  1  is the same for each instance, but protocol-code association module  3  (if present) and proxy activity code file  2  are different. In all cases, runtime proxy executable code  5  uses the protocol specification file  1  to decompose and verify the protocol, while invoking proxy activity code  2  at appropriate points in the decomposition, as specified by protocol-code association module  3 . 
     Protocol specification  1  can also be made to be universal. In this scenario, the same protocol specification file  1  is instantiated multiple times and used with different proxy activity code files  2  (and protocol-code association module  3  if present) to perform different activities for the same protocol. For each instance of protocol specification file  1 , proxy  5  can be the same (i.e., it can be a universal proxy), or different versions of proxy  5  can be used. 
     Protocol-code association module  3  can be implemented by extending the grammatical form  7  of the protocol specification to contain information as to points where the proxy activity code  2  is to be executed. This information is processed by protocol specification compiler  8  via a field called, e.g., [ACTION]. Then, information contained in protocol-code association module  3  informs runtime proxy executable code  5  that proxy activity code  2  is to be executed at these points. If optional protocol-code association module  3  is not used, information that would otherwise be contained in module  3  is located in some combination of modules  1  and  2 . 
     Protocol specification compiler  8  is executed only when the protocol is first implemented or when the protocol specification  7  has changed. Runtime proxy executable code  5  is executed whenever it is desired to perform the function of that proxy. 
     A first method embodiment is illustrated in  FIG. 2 . At step  21 , protocol specification compiler  8  is invoked to create or update protocol specification  1 . Protocol specification compiler  8  has as an input a protocol specification  7 . The protocol specification  7  may be in a grammatical form such as BNF, EBNF, ABNF, natural English or other natural language, regular expression, or grammar understood by Lex, Yacc, Gold, or Spirit. At step  22 , proxy activity code  2 , separate and apart from protocol specification  1 , is created or updated. In one embodiment, proxy activity code  2  is written in a scripting language such as Java, Visual Basic, or P-Code. 
     At optional step  25 , protocol-code association module  3  is created or updated. In one embodiment, module  3  consists solely of data and does not contain any executable code. 
     At step  23 , runtime proxy executable code  5  is executed using the latest versions of modules  1  and  2  (and module  3  when present). Module  5  (for example a firewall proxy) may be executing constantly, although perhaps idly most of the time. In this case, module  5  does not have to be provided with the latest versions of modules  1 ,  2 , and/or  3  repeatedly, unless contents of modules  1 ,  2 , and/or  3  have changed. The updating of module  5  can be accomplished by providing for a routine within module  5  that checks to see, before accepting new data from modules  1 ,  2 , and/or  3 , whether contents of modules  1 ,  2 , and/or  3  have changed. Flags associated with module  5  can be used to indicate whether the contents of modules  1 ,  2 , and/or  3  have changed. 
     Protocol specification  1  and proxy activity code  2  can be updated independently of each other and independently of the execution of runtime proxy executable code  5  (and independently of the updating of protocol-code association module  3  when said module  3  is present). Protocol specification  1 , proxy activity code  2 , and/or protocol-code association module  3  can be updated at remote client sites by means of the author of said modules  1 ,  2 , and/or  3  using a push technology such as Live Update popularized by Symantec Corporation of Cupertino, Calif. 
     A second method embodiment of the present invention is illustrated in  FIG. 3 . At step  32 , proxy activity code  2  is created or updated. In this embodiment, code  2  consists solely of data and does not contain any executable code. 
     At step  33 , runtime proxy executable code  5  is executed using proxy activity code  2 . 
     In all respects not expressly mentioned herein, the embodiment illustrated in  FIG. 3  can contain any or all of the features of the embodiment illustrated in  FIG. 2 . 
     In the embodiment illustrated in  FIG. 3 , module  5  is data-driven with respect to proxy activity code  2  but is not necessarily data-driven with respect to protocol specification  1 . This embodiment is useful where protocol specification  1  is unlikely to change, but proxy activity code  2  is updated frequently. In this embodiment, protocol specification  1  may be in the form of source code that calls out at specified points to a P-Code (or other scripting) engine to invoke proxy activity code  2 . This makes for faster protocol decomposition, while still allowing data-driven proxy activity code  2  that is easily updatable in the field without requiring restarts of proxy  5 . 
     A third method embodiment of the present invention is illustrated in  FIG. 4 . At step  41 , protocol specification  1  is created or updated. In this embodiment, specification  1  consists solely of data and does not contain any executable code. 
     At step  42 , proxy activity code  2 , separate and apart from protocol specification  1 , is created or updated. In this embodiment, proxy activity code  2  consists solely of data and does not contain any executable code. 
     At optional step  45 , protocol-code association module  3  is created or updated. In an embodiment, module  3  consists solely of data and does not contain any executable code. 
     At step  43 , runtime proxy executable code  5  is executed using protocol specification  1  and proxy activity code  2 , and optional protocol-code association module  3  if present. 
     In all respects not expressly mentioned herein, the embodiment illustrated in  FIG. 4  can contain any or all of the features of the embodiment illustrated in  FIG. 2 . 
     It can be seen from the above discussion that the present invention eases the creation, maintenance, re-use, and distribution of proxies  5 , and the re-use of protocol specifications  7  among proxies  5  whose purposes may differ, but which operate on the same protocol  7 . Regardless of their eventual purpose, all proxies  5  that operate on streams for the same protocol  7  share the required task of proper decomposition (parsing) of that protocol  7 . The present invention allows the protocol model  7  to be specified in a reusable way  1  that is independent of the logic  2  that performs the application specific tasks for a given proxy  5 . 
     The present invention further allows the author of a proxy  5  to be rigorous in the decomposition of a protocol  7  while still allowing the flexibility to tolerate typical deviations from the standard  7 . Specification of the protocol is easier, yet rigorous, since the grammar  7  from the protocol definition (e.g., from an RFC) can be used directly. In addition, the present invention allows updates of the protocol specification  1  independently of updates to the application specific logic in the proxy activity code  2 . Updates to the protocol specification  1  and/or the proxy activity code  2  can be delivered as data rather than as executable binary code, making it easier to provide updates that do not require a restart of runtime proxy executable code  5 . Thus, customers are more likely to adopt the updates. 
     The invention illustrated herein advantageously allows enterprises to more quickly provide security for more protocols, to provide timely unobtrusive updates that add new proxies  5  or that update existing proxies  5 , and to provide more rigorous and therefore more secure treatment of protocols. Using a grammatical form  7  of the protocol specification and a protocol specification parser (compiler)  8  makes protocol decomposition easier and quicker for the author. In addition, the resulting protocol decomposition  1  is likely to be more rigorous and accurate than a handcrafted version would be. Having the runtime proxy executable code  5  consume the protocol specification  1  from a data file allows the same protocol specification  1  to be re-used for multiple proxies  5 , and it allows easy unobtrusive updates to the protocol specification  1  in the field. Furthermore, because the protocol specification  1  is independent of the proxy activity code  2 , if the protocol specification  1  is updated, all proxies  5  that work with that protocol can benefit without having to repeat the update work for each individual proxy  5 . Using P-Code or another scripting language for proxy activity code  2  allows for easy unobtrusive updates to application specific logic  2 ; because of the isolation of the protocol specification  1  from the proxy activity code  2 , changes to one  1 , 2  are unlikely to affect the other  2 , 1 . Updating a product in the field to add support for a new protocol becomes significantly easier when using this invention, because all that is needed is a new instance of the runtime proxy executable code  5  that takes some new data files  1 ,  2 , and/or  3  as input. Because of the efficiency and ease-of-use gains, protocols that would otherwise go unsupported are more likely to be supported. Support for more protocols, quick updates to support new protocols when they arrive, and quick updates to support the most recent changes to protocol specifications  7  are important distinctions with respect to previous art. 
     The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.