(12) United States Patent
`Graham-Cumming, Jr.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,182,146 B1
`*Jan. 30, 2001
`
`US006182146B1
`
`(54) AUTOMATIC IDENTIFICATION OF
`APPLICATION PROTOCOLS THROUGH
`DYNAMIC MAPPING OF
`AppLICATION_p()RT ASSOCIATIONS
`
`5,719,942 *
`5,734,865 *
`5,734,887 *
`5,787,253 *
`
`...................... .. 709/228
`2/1998 Aldred etal.
`3/1998 Yu ...................................... .. 709/250
`3/1998 Kingberg et al.
`...................... .. 707/4
`7/1998 McCreery et al.
`............ .. 395/200.61
`
`(List continued on next page.)
`
`Primary Examiner—Mehmet B. Geckil
`Assistant Examiner—William C. Vaughn, Jr.
`(74) Attorney, Agent, or Firm—Blakely, Sokoloff, Taylor &
`Zafman
`
`(57)
`
`ABSTRACT
`
`A system, method, and software product dynamically deter-
`mine network applications associated with any ports being
`used by packets on a network, allowing the packets to be
`properly routed, counted, and reported according to their
`applications. In one embodiment, an application-port map-
`ping table stores static associations or mappings between
`applications and ports, as defined by a standards body or
`other source. The application-port mapping table is dynami-
`cally updated during runtime to reflect dynamic associations
`between applications and ports as extracted from packet
`data. The associations are
`a packet analysis
`module which performs a two step verification of an appli-
`cation for a packet. In a first step, the packet analysis module
`applies the ports from a packet
`to the application-port
`mapping table to obtain a first application identifier. In a
`second, separate step, the packet analysis module applies
`identification logic to the packet to identify an application
`based on packet data. The second step may be used for each
`packet or only where the packet is not identified by the
`application-port mapping table. If a second application is
`successfully identified, the packet analysis module updates
`the application-port mapping table by adding a new asso-
`ciation between the second identified application, and a port
`of the packet. To keep the application-port mapping table
`current, the table is periodically scanned to remove associa-
`tions which have expired; alternatively, an association is
`-
`-
`-
`i‘:I(Ii1f(:)t\:(::(tle\(7iVhCI1 an end of sequence packet for its application
`'
`
`11 Claims, 6 Drawing Sheets
`
`(75)
`
`Inventor:
`
`John Graham-Cumming, Jr., Menlo
`Park, CA (US)
`
`(73) Assignee: Compuware Corporation, Farmington
`H1115, MI (US)
`
`(*) Notice:
`
`This patent issued on a continued pros-
`ecution application filed under 37 CFR
`1.53(d), and is subject to the twenty year
`patent
`term provisions of 35 U.S.C.
`154(a)(2).
`
`Under 35 U.S.C. 154(b), the term of this
`patent shall be extended for 0 days.
`
`(21) Appl. No.: 08/884,396
`
`(22)
`
`Ffled;
`
`Jun_ 27, 1997
`
`7
`
`(51)
`
`......................... .. G06F 15/173; G06F 15/16
`Int. Cl.
`........................ ..
`UISI C].
`709/235, 709/238; 709/239, 709/245, 709/246;
`709/248; 709/250, 370/389; 370/392, 370/400,
`370/401, 370/402, 370/469
`(58) Field of Search ....................... .. 395/200.68, 200.61,
`395/200.78, 200.65; 370/401, 392, 402,
`400, 389, 469; 709/238, 231, 248, 235,
`250, 224, 226, 239, 245, 246
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`.................... .. 709/107
`5/1996 Moeller et al.
`5,519,867 *
`..
`.. 709/228
`7/1996 Sharma et al.
`5,537,417 *
`55669336 * 10/1996 Futatsugi Ct a1~
`~~ 395/701
`3536371 *
`6/1997 Yuh -----------
`709/250
`,640,394 *
`6/1997 Sc rier eta.
`.. 370/389
`..
`5,640,399 *
`6/1997 Rostoker et alt
`N 370/392
`5,649,105 *
`7/1997 Aldred et al.
`.. 709/220
`5,684,800 * 11/1997 Dobbins et al.
`.. 370/401
`5,708,659 *
`1/1998 Rostoker et al.
`.................. .. 370/392
`
`
`
`am
`TRAVERSE
`
`CA9 lu:atmnMnps son
`nmmoN
`
`VOENTWWER
`0175
`MATCHWG Form
`
`an:
`sn FVRST APP. ID TO
`
`nsrurwso mus vEs
`
`
`
`
`
`
`
`an
`TRAVERSE
`CAapplH:a mnlaennlers
`ID APP VD
`ma SE
`am
`swam: APP VD :
`UNKNOWN”
`
`5-5
`CREATE NEW
`V55
`1:23
`
`cm
`CApptwat\mvMa
`mscmu PACKS!
`SEGONDA .10,
`on PASS To
`Pom ASSOC/ATVON
`nmuu
`Avptncmou
` mcams NEW
`
`CAppkcatvnnPaz:ket
`smPASS
`CADphcauanPa:kst T0
`
`Awvtlcmon
`
`
`
`N0
`
`SET F/RSTBEPF 10 m
`UNKNOWN
`
`
`
`521
`=1RST APP ID :
`UNKNOWN"
`
`Petitioners‘ EX1010 Page 1
`
`
`
`
`
`Petitioners' EX1010 Page 1
`
`

`
`US 6,182,146 B1
`Page 2
`
`US. PATENT DOCUMENTS
`
`8/1998 Yasue eta1~ ~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ 710/52
`5a797a041 *
`
`5,835,710 * 11/1998 Nagami et al.
`.
`. 395/200.8
`5,838,920 * 11/1998 Rosborough ....................... .. 709/224
`
`3/1999 Richardson, Jr. et al.
`.
`.. 379/189
`5,883,945 *
`
`.. 379/205
`5,995,608 * 11/1999 Detampel, Jr. et al.
`........................ .. 370/389
`6,061,349 *
`5/2000 Coile etal.
`
`* cited by examiner
`
`Petitioners‘ EX1010 Page 2
`
`Petitioners' EX1010 Page 2
`
`

`
`U.S. Patent
`
`Jan. 30, 2001
`
`Sheet 1 of 6
`
`US 6,182,146 B1
`
`TCP Header for HTTP Protocol
`
`
`
`
`
`“ass
`
`Urgent Pointer
`Checksum
`
`
`
`FIG. 1
`
`TCP Header for H1TP Protocol for Port 8080
`
`Flags
`
`32 Sequence Number
`
`32 bit Acknowiedgment Number
`
`Destination Port
`
`Urgent Pointer
`
`FIG. 2
`
`Petitioners‘ EX1010 Page 3
`
`Petitioners' EX1010 Page 3
`
`

`
`U.S. Patent
`
`Jan. 30, 2001
`
`Sheet 2 of 6
`
`US 6,182,146 B1
`
`
`
`102
`
`APPLICATION
`
`IDENTIFIEFI
`MODULE
`
`
`
`APPLICATION
`IDENTIFIER
`
`
`
`RAW
`
`PACKET
`/
`207
`
`
`
`
`
`
`DYNAMIC /
`POFIT
`
`DATA
`APPLICATION
`APPLICATION-PORT
`'DENT'F'ER 203/
`ASSOCIATIONS
`
`
`204
`
`
`STATIC
`APPLICATION-
`APPLICATION-POFIT
`PORT
`MAPPING DATA
`
`MAPPING TABLE
`
`205
`
`108
`
`
`
`
`
`
`
`FIG. 3
`
`Petitioners‘ EX1010 Page 4
`
`106
`
`DATA
`NETWORK
`
`PACKET SOURCE
`
`
`
`
`
`110
`100
`PACKET wITI-I
`Am‘|3_I\<(I§|TS
`APPLICATION
`
`MODULE IDENTIFER
`
`112
`
`
`
`
`
`Petitioners' EX1010 Page 4
`
`

`
`U.S. Patent
`
`Jan. 30, 2001
`
`Sheet 3 of 6
`
`US 6,182,146 B1
`
`300
`
`ADDRESSABLE MEMORY
`
`303
`
`3.0.4
`
`100
`PACKET
`ANALYSIS MODULE
`
`IDENTIFIER MODULE
`
`102
`APPLICATION
`
`104
`
`106
`
`MAPPING TABLE
`
`APPLICATION-PORT
`
`PACKET SOURCE
`
`308
`NETWORK
`
`306
`NETWORK INTERFACE
`302
`
`OPERATING SYSTEM
`
`301
`CPU
`
`FIG. 4
`
`Petitioners‘ EX1010 Page 5
`
`Petitioners' EX1010 Page 5
`
`

`
`U.S. Patent
`
`Jan. 30, 2001
`
`Sheet 4 of 6
`
`US 6,182,146 B1
`
`CApplicationSource and associated objects
`
`CPacketSource
`
`
`—:,,()
`
`R
`iv ()
`7o§,°§,,f
`
`
`
`Kfl
`
`T3 PRIVATE
`.9 DATA MEMBER
`
`it METHOD
`
`
`
`CApp|icationSource
`
`o : CApp|icationMap
`0 : CApp|icationldentifier
`‘Receive () : CAppiicationPackei
`
`
` CPacket
`¢Protoooi : WORD
`oSouroePon : WORD
`¢DestinationPon 2 WORD
`¢PayIoad : BYTE '
`
`
`
`
`CApp|icationPacket
`
`CApp|ication|dentifier
`
`‘identify( CPacket ' )
`
`CAppiicationMap
`
`
`
`
`
`
`
`oAppiication 2 EApp|ication
`
`?oAppIication : EApplication
`
`Won : wono
`iabnme : owono
`
`
`
`FIG. 5
`
`Petitioners‘ EX1010 Page 6
`
`Petitioners' EX1010 Page 6
`
`

`
`U.S. Patent
`
`Jan. 30, 2001
`
`Sheet 5 of 6
`
`US 6,182,146 B1
`
`FIG. 6
`
`601
`INVOKE
`CPacketSource
`Receive() TO OBTAIN
`PACKET
`
`soa
`TRAVERSE
`
`CAppIicationMaps FOR
`APPLICATION
`IDENTIFIER
`
`605
`
`
`
`607
`
`609
`
`
`
`SET FIRST APP. ID TO
`UNKNOWN
`
`SET FIRST APP. ID TO
`RETURNED VALUE
`
`
`
`MATCHING PORT?
`
`
`
`
`
`
`611
`
`TRAVERSE
`
`CAappIicationIdentifers
`FOR SECOND APP. ID
`
`YES
`
`
`
`613
`UNKNOWN?
`SECOND APP. ID =
`
`
`
`
`FIRST APP. ID =
`UNKNOWN?
`
`621
`
`615
`
`
`
`CREATE NEW
`
` 623
`APPLICATION
` DEFAULT
`
`CApp|icationMap for
`SECOND APP. ID,
`PORT ASSOCIATION
`
`DISCARD PACKET
`OR PASS TO
`
`617
`
`CREATE NEW
`
`
`CAppIicationPacket
`
`
`
`
`
`PASS
`
`
`CApp|icationPacket TO
`
`APPLICATION
`
`
`619
`
`Petitioners‘ EX1010 Page 7
`
`Petitioners' EX1010 Page 7
`
`

`
`U.S. Patent
`
`Jan. 30, 2001
`
`Sheet 6 of 6
`
`US 6,182,146 B1
`
`FIG. 7
`
`YES
`
`701
`INVOKE
`CPacketSource
`
`
`
`Receive() TO OBTAIN
`PACKET
`
`703
`
`
`
`NO
`
`
`
`
`
`
`
`
`TIMESTAMP
`
`DIFFERENCE
`
`BETWEEN
`PACKETS >
`GLOBAL TIMEOUT?
`
`
`
`
`711
`TRAVERSE
`
`CApp|icationMaps FOR
`APPLICATION
`IDENTIFIER
`
`705
`TRAVERSE
`
`APPLICATION
`IDENTIFIER
`
`CAppIicationMaps FOR
`
`707
`
`REMOVE EXPIRED
`
`CApp|icationMaps
`
`709
`
`MATCHING PORT?
`
`
`
`YES
`
`713
`SET FIRST APP. ID TO
`
`RETURNED VALUE
`
`719
`
`SET FIRST APP. ID TO
`UNKNOWN
`
`715
`
`UPDATE
`
`_ CAppIicationMap WITH
`I NEW EXPIRATION
`TIME
`
`727
`
`CREATE NEW
`
`CAppIicationPacket
`
`729
`PASS
`
`APPLICATION
`
`CAppIicatIonPacket TO
`
`721
`TRAVERSE
`
`FOR SECOND APP. ID
`
`CAappIicationIdentiIers
`
`723
`
`
`SECOND APP. ID:
`
`WKNOWN?
`
`YES
`
`717
`DI,SACS"SR$OPég,I§EEflR
`APPLICATION
`
`725
`CREATE NEW
`
`PORT ASSOCIATION
`
`CAppIicationMap for
`SECOND APP. ID,
`
`Petitioners‘ EX1010 Page 8
`
`Petitioners' EX1010 Page 8
`
`

`
`US 6,182,146 B1
`
`1
`AUTOMATIC IDENTIFICATION OF
`APPLICATION PROTOCOLS THROUGH
`DYNAMIC MAPPING OF APPLICATION-
`PORT ASSOCIATIONS
`
`BACKGROUND
`
`1. Field of Invention
`
`The present invention relates generally to the field of
`computer network management, and more particularly, to
`systems, methods, and software ax products for identifying
`network applications for processing packet data.
`2. Background of the Invention
`Conventional network applications in computer networks
`running over common layer 3 (network layer) protocols use
`static port mappings. A port mapping defines the specific
`port or socket number that network traffic for a specific
`network application is routed to, or sent from. These port
`mappings are available from the Internet Assigned Numbers
`Authority (IANA) in order to differentiate between applica-
`tions. These application-port mappings are published and
`are well defined, and typically used to deliver network traffic
`to the appropriate applications.
`When ports are defined statically in relationship to
`applications, it is possible for a network monitor, or similar
`product,
`to reliably identify traffic by looking at a single
`packet and checking its port number against the IANA (or
`similar) list. These static mappings are thus relied upon by
`network management software products to determine the
`protocols and applications being used for network traffic,
`and therefore compile information about
`traffic patterns,
`demand, latency, and other performance characteristics.
`However, a number of network protocols allow for the use
`of dynamic application-port mappings. These protocols
`allow a packet to be sent from or directed to any available
`port, not only the statically defined ports. As a result,
`reliance on the static application-port mappings cannot
`guarantee accurate decoding and use of packets, or accurate
`analysis of network traffic.
`For example, FIG. 1 illustrates the TCP header for a
`packet carrying HTTP traffic. The HTTP protocol (defined in
`RFC 1945) generally uses the port 80 when running over
`TCP (defined in RFC 793). Traffic for the HTTP protocol is
`thus identified by examining the source or destination ports
`in the TCP header for the value “80”. This value identifies
`
`the packet as being a TCP packet for the HTTP protocol.
`However,
`the URL specification for HTTP (defined in
`RFC 1738) allows a dynamic port to be added to the end of
`a URL request. For example, a URL for HTTP may have the
`form “http://www.company.com:8080”, where the value
`“8080” identifies the port number to be used. FIG. 2 illus-
`trates the TCP header in this case. With a port of 8080 it is
`not possible using conventional network management tools
`to identify this as HTTP traffic, since the standard port is not
`being used.
`This problem has existed at least since the introduction of
`the HTTP protocol in 1991. This problem also occurs with
`other protocols, such as FTP, and NNTP, and for any of the
`many IP protocols. Indeed, dynamic ports are frequently
`used, for example to provide for security or for improved
`resource sharing. Accordingly, there is a need to be able to
`handle dynamic mappings for network traffic.
`Several approaches have been attempted to solve this
`problem. Some existing solutions require that network man-
`agement software be manually configured to add the map-
`ping of the new port (e.g. 8080 or whatever other port
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`
`number is used) to the application protocol HTTP (or other
`protocol). This requires the user of network management
`software to know in advance the ports being used, in order
`to configure the mapping. This is not a satisfactory solution
`since it is generally not possible to know the mappings ahead
`of time. In addition, the mappings can change at any time.
`Thus, preconfiguring the network management software
`with a fixed set of mapping means that software does not
`have great flexibility to deal with new mappings. In addition,
`the software will not be able to identify many packets which
`do not comply with its preconfigured mappings.
`Other schemes require instrumentation of the application
`using the protocol to determine the port mappings it is using,
`or the interception of common protocol interfaces, such as in
`Microsoft Corp.’s WinSock,
`to attempt to determine the
`mapping required. Neither of these methods provide a
`non-intrusive or configuration-free method of identifying
`application traffic from a raw stream of data on a computer
`network.
`
`Accordingly, it is desirable to provide a system, method
`and software product that can dynamically map application
`and port relationships and thereby correctly identify
`applications, protocols and other network data from packet
`data.
`
`SUMMARY OF THE INVENTION
`
`The present invention overcomes the limitations of con-
`ventional systems and methods by dynamically identifying
`the relationships between applications and ports in received
`packet data, and by storing and updating these relationships.
`In this manner, the present invention is able to identify the
`correct applications for packets that use either standard,
`default port numbers, or non-standard, dynamically defined
`port numbers.
`invention provides a
`the present
`In one embodiment,
`computer-implemented method for dynamically determin-
`ing a network application for a stream of network packets.
`Aplurality of associations between network applications and
`ports are stored, for example, in a high speed cache. Apacket
`is received from a network packet source. If there is a stored
`association between a network application and a port of the
`packet (as contained in the packet header), then the packet
`is provided to the network application so identified.
`If there is no stored association between a network
`
`application and a port of the packet, the packet data, for
`example the payload and/or header, is analyzed to identify a
`network application for handling the packet, and a new
`association is stored between this identified network appli-
`cation and a port of the packet. This analysis may be made
`even if there was a previously stored association between a
`port of the packet and a network application.
`Additionally, stored associations may have expiration
`times, based on a timestamp of the last packet that matched
`the port
`in a stored association, and a timeout value.
`Periodically, the stored associations are processed to remove
`associations that have expired, according their expiration
`times.
`
`the present invention operates in
`In one embodiment,
`software products such as network monitors or protocol
`decoders. Such products are configured as follows. An
`application-port mapping table is used to store the associa-
`tions between network applications and ports. Each network
`application is uniquely associated with, and identified by,
`one application identifier. A special identifier is used to
`represent an “unknown” application. The application-port
`mapping table is initialized with a set of static application-
`
`Petitioners' EX1010 Page 9
`
`Petitioners' EX1010 Page 9
`
`

`
`US 6,182,146 B1
`
`3
`port mappings, such as defined by a standards authority. The
`application-port mapping table will be subsequently updated
`with new application-port associations as these are extracted
`from actual packet data that is received and processed. The
`application-port mapping table is preferably stored in high
`speed memory during runtime.
`During runtime, packet data is received by a packet
`analysis module. The packet analysis module extracts from
`the packet its destination port and source port values. The
`packet analysis module applies these port values to the
`application-port mapping table. If the application-port map-
`ping table contains an association with a port matching one
`of the ports for the packet, then the packet is positively
`identified, and the application-port mapping table returns the
`application identifier associated with the matching port. This
`first application identifier initially identifies the application
`for handling the packet.
`In a conventional system, as explained above, if a packet
`includes a port value which that is not static value for the
`appropriate application, i.e. a dynamic port, the packet will
`not be properly identified as being appropriate for
`the
`application (the packet may still be received by the appli-
`cation since other mechanisms may be preserving this state
`information).
`the application-port mapping
`In the present invention,
`table will initially not contain an association between the
`dynamic port and an application identifier, and thus the
`application for the packet will be unknown. However, unlike
`conventional approaches, the packet analysis module then
`analyzes the packet to determine the appropriate application
`for handling the packet. The analysis is preferably of the
`payload, but may also include the packet header. The analy-
`sis is generally based on predefined data patterns that are
`uniquely associated with each application. This analysis
`may include, for example, determining whether the payload
`includes a valid URL to an HTTP address, thereby indicating
`an HTIP application. Other payload specific data or patterns
`may also be recognized.
`Once the packet analysis module successfully identifies
`the packet as belonging to a specific application, it creates a
`new entry in the application-port mapping table, associating
`a port number from the packet with the application identifier
`appropriate to the identified application. The packet analysis
`module also checks to make sure that no duplicate mappings
`for the port exist in the application-port mapping table. The
`next time a packet is received with the newly mapped port
`number, the application-port mapping table will correctly
`identify it.
`In this manner,
`the packet analysis module
`dynamically updates the application-port mapping table to
`include associations between application identifiers and
`ports extracted from packet data.
`In some instances, even if the application-port mapping
`table does contain an association between an application
`identifier and a port, this association may no longer be valid.
`This is particularly true for associations that were dynami-
`cally created, as described above, since these tend to be
`specific to individual transactions. In one embodiment then,
`after the application-port mapping table has provided the
`application identifier, the packet analysis module separately
`analyzes the packet, as above. If this analysis is successful
`and an application is identified, this application will be given
`the packet, regardless of the application identified by the
`application-port mapping table.
`In one embodiment, outdated associations defined in the
`application-port mapping table are periodically removed
`through a garbage collection process, so that the current
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`dynamic associations will always be present in table. In one
`embodiment, the newly created entries in the application-
`port mapping table have an expiration time. The packet
`analysis module periodically checks the application-port
`mapping table, and removes associations that have expired.
`In one embodiment, the expiration time of an application-
`port association is based on the timestamp of the last packet
`that matched the port of the association, plus a local timeout
`value (a fixed number of seconds). The expiration time may
`be compared to either a current time, or the timestamp of the
`last received packet to determine whether it has expired. In
`this manner, the table is maintained with the most current
`associations between applications and ports, as determined
`by the packet data itself.
`The use of expiration times further allows for another
`optimization of the packet analysis module’s performance.
`Since the expiration time of each application-port associa-
`tion ensures that
`the application-port mapping table is
`always current,
`in one embodiment,
`the packet analysis
`module processes the packet a second time only when the
`application-port mapping table is unable to identify the
`packet. In this manner, the packet analysis module updates
`the application-port mapping table only as needed, which is
`when the packet cannot be matched to an application-port
`mapping that has been previously detected.
`The present invention may be implemented in a number
`of different manners. One implementation uses an object
`oriented collection of objects to provide the described func-
`tionality and features. The application-port mapping table is
`implemented as a collection of application map objects, each
`storing an application identifier and port association, and an
`optional expiration time where garbage collection is used.
`The packet analysis module is implemented as an applica-
`tion source object and a collection of application identifier
`objects. Each of the application identifier objects imple-
`ments a method that encodes the logic used to identify a
`specific application from the packet data.
`The application map objects are initialized with a set of
`standard, static application identifier-port associations. The
`application source object receives a packet from a packet
`source object, and traverses the collection of application
`map objects to obtain a first application identifier from the
`application map object having a matching port. If none of
`the application map objects match the packet,
`then the
`application is deemed “unknown.”
`The application source object also traverses the applica-
`tion identifier objects, having each one process the packet to
`separately identify the application. Each application identi-
`fier object returns either an application identifier of the
`specific application it recognizes or an “unknown” if the
`application identifier object does not recognize the packet.
`If the packet is recognized by one of the application
`identifier objects, then the application source object instan-
`tiates a new application map object with the application
`identifier returned by the application identifier object which
`recognized the packet, and a port number from the packet.
`The application source object then passes the packet to the
`second, identified application. Summary data, may now be
`accurately accumulated for all packets, to accurately moni-
`tor network performance.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is the header of an HTTP packet over TCP/IP using
`a standard port mapping.
`FIG. 2 is the header of an HTTP packet over TCP/IP using
`a non-standard port mapping.
`
`Petitioners‘ EX1010 Page 10
`
`Petitioners' EX1010 Page 10
`
`

`
`US 6,182,146 B1
`
`5
`FIG. 3 is a functional model of a system in accordance
`with the present invention.
`FIG. 4 is an illustration of a hardware architecture for
`implementing the present invention.
`FIG. 5 is an object model of a software product
`accordance with the present invention.
`FIG. 6 is a flowchart of a method for managing the
`identification of an application for a packet.
`FIG. 7 is a flowchart of an optimized method for man-
`aging the identification of application for a packet.
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`in
`
`Referring now to FIG. 3 there is shown a functional model
`of the present invention for identifying applications and
`network protocols from raw packet data.
`In this
`embodiment, the present invention includes a packet analy-
`sis module 100, an application identifier module 102, and an
`application-port mapping table 104. These elements may be
`included in various different products, such as network
`monitors, protocol decoders, protocol analyzers, routers,
`brouters, bridges, or the like.
`The application-port mapping table 104 stores associa-
`tions between application identifiers and port numbers. Each
`application identifier identifies a different application avail-
`able on the computer (or network of computers for distrib-
`uted applications) capable of receiving or processing the
`packet. Each application has a unique identifier. A special
`‘unknown’ application identifier
`(e.g. “APP_
`UNKNOWN”) is used to represent an unknown application,
`though a mapping for the unknown application need not be
`stored in the table. The application-port mapping table 104
`is cached in memory for high speed access.
`Upon startup, the application-port mapping table 104 is
`initialized 213 with some number of static application-port
`associations 108. These static associations (or ‘mappings’)
`are based on the published specifications for the various
`applications and protocols, and their standard port numbers.
`Table 1 includes a preferred list of network applications,
`application identifiers, and their standard ports used to
`define the static application-port associations 108.
`
`Application
`HTTP
`FTP
`FTP
`SMTP
`NNTP
`POP3
`
`TABLE 1
`
`Port
`80
`20
`21
`25
`119
`110
`
`Application Identifier
`APP_HTT'P
`APP_FTP
`APP_FTP
`APP_SMTP
`APP_NNTP
`APP_POP3
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`The application-port mapping table 104 will be later
`updated 205 by the packet analysis module 100 with
`dynamic associations 112 between application identifiers
`and ports based on the actual packet data that is received
`from the packet source 106. The packet source 106 is any
`useful source of packet (layer 3) data.
`The packet analysis module 100 receives 201 raw packet
`data from the network packet source 106, typically through
`some network interface, such as a network interface card.
`The packet analysis module 100 decomposes this packet,
`extracting various field data from the packet. The extracted
`data includes the source port, the destination port from the
`packet header, and the payload.
`The packet analysis module 100 applies 203 the port
`numbers from the packet to application-port mapping table
`
`55
`
`60
`
`65
`
`HTTP
`NNTP
`
`SMTP
`
`POP3
`
`50
`
`FTP
`
`6
`104 to obtain an application identifier. If there is an asso-
`ciation that matches the port data,
`then application-port
`mapping table 104 returns 204 the application identifier for
`the network application. The application-port mapping table
`104 will be able to return an application identifier if either
`the port number is a standard port number for the application
`and included in the original set of static application-port
`mappings, or is a new application identifier-port mapping
`extracted from the received packets, and stored in the
`application-port mapping table. If there is no matching port,
`then the packet analysis module 100 assigns the result as
`being the unknown application identifier.
`In one embodiment, even if the application-port mapping
`table 104 returns 204 an application identifier for a specific
`application,
`the present invention provides an additional
`sequence of processing steps to verify this application,
`which in some instances may be incorrect. This is done as
`follows. The packet analysis module 100 passes 207 the
`packet to the application identifier module 102. This module
`102 analyzes the packet to determine 209 an application
`appropriate for handling the packet.
`The application identifier module 102 attempts to match
`portions of the packet data, including the payload or header,
`with defined patterns or attributes for each of a plurality of
`different applications. Generally, for each application there
`are one or more bit patterns which uniquely identify the
`application. These patterns may be in the payload data, in the
`header, or in combinations of both. The bit patterns are
`defined as sequences of <offset, bit patterns> tuples. Each
`application may have one or more such sequences which
`uniquely identifies it. Table 2 includes preferred bit patterns
`used to identify selected network applications, along with
`the port used to map the application into the application-port
`mapping table 104. Alternate patterns are shown numbered.
`
`TABLE 2
`
`Application Data Patterns <bit offset, data pattern>
`
`Port Used
`in Mapping
`
`Source
`
`Destination
`
`Destination
`<0, “GET”><4,URL><n, “HTTP/1.”>
`<0, “GROUP”><6, newsgroup><n, CRLF> Destination
`<n + 2, EndofFrame>
`1) <0, “220_”><4, server_name>
`<n, “Simple Mail Transfer Service Ready”>
`2) <0, “MAIL FROM: <”><11, email_addr> Destination
`<n, CRLF>
`3) <0, “RCPT TO: <”><9, email_addr>
`<n, CRLF>
`1) <0, “+OK POP3 server ready”><22,
`CRLF>
`2) <0, “+OK”><4, number><n, “messages
`(“><n+10, number><m, “octets)”>
`1) <0, “230 User logged in”>
`2) <0, “Z27 Entering Passive Mode (“><26,
`n1, n2, n3, n4, n5, n6><n,”)”>
`[where n;<256]
`3) <0, “PORT”<5, n1, n2, n3, n4, n5, n6>
`[where n;<25 6]
`
`Source
`
`Source
`Source
`Source
`
`Destination
`
`Here URL, newgroup, server_name, email_addr, and
`number are valid forms as defined by their respective
`protocols. The identification of these patterns may done
`through various types of pattern matching algorithms, or
`simple conditional testing.
`In one embodiment, the application identifier module 102
`processes the packet data until it positively identifies one
`application, and returns 209 the application identifier for this
`application.
`In another embodiment, the application identifier module
`102 identifies all applications that may be appropriate and
`
`Petitioners‘ EX1010 Page 11
`
`Petitioners' EX1010 Page 11
`
`

`
`US 6,182,146 B1
`
`7
`applies a selection logic to select one of these as the most
`appropriate application, returning 209 the application iden-
`tifier for this application. One implementation of the selec-
`tion logic is to assign a confidence factor to each pattern or
`logic used to identify an application. When multiple appli-
`cations are identified, the application identifier module 102
`selects the application having the highest confidence factor.
`If the application identifier module 102 is unable to match
`the packet data with any applications, then it returns 209 the
`unknown application identifier to the packet analysis module
`100. Alternatively,
`the application identifier module 102
`returns a null result to the packet analysis module 100,
`which assigns an unknown application identifier to the
`outcome.
`
`If the application identifier returned by the application
`identifier module 102 identifies an application (i.e.
`the
`application is not unknown) then the packet analysis module
`100 creates 205 a new entry in the application-port mapping
`table 104 using the returned application identifier from the
`application identifier module 102 and a port number from
`the packet. The port used is determined by the specific
`method used to identify the application, as shown in the
`examples of Table 2. The packet analysis module 100 checks
`to make sure that duplicate entries for a port are not present,
`replacing any previous association with the new association.
`Where garbage collection is used, the packet analysis mod-
`ule 100 also sets an expiration time for this new association.
`Preferably the expiration time is equal to the timestamp of
`the packet plus a local timeout value. The new association
`will enable the application-port mapping table 104 to return
`203 the correct application identifier for packets which use
`the same port number, which will be other than the standard
`default ports for that particular application. In this manner,
`the application-port mapping table 104 is continually
`updated to refiect the dynamic application-port associations
`present in the packet data, and not merely the static asso-
`ciations set by the standards authorities, such as the IANA.
`When a subsequent packet, typically in the same transaction,
`is received, the packet analysis module 100 will be able to
`obtain the correct application identifier from the application-
`port mapping table 104 immediately, and then verify it in the
`application identifier module 102.
`After the packet is identified, it is provided 211 to the
`specified application for processing. This processing may
`include any type of analysis or use of the packet.
`If the application identifier module 102 was not able to
`identify the packet, then the application identified 203 by the
`application-port mapping table 104 is used to invoke 211 an
`application for processing the packet.
`If neither the application-port mapping table 104 or the
`application identifier module 102 is able to identify a packet,
`then the packet is discarded, or alternatively, passed to a
`default application for handling unknown packets.
`Where garbage collection is used,
`the packet analysis
`module 100 periodically scans the application-port mapping
`table 104 to check the expiration time of each association. If
`an association has expired, then the packet analysis module
`100 removes it from the application-port mapping table 104.
`In one embodiment, the packet analysis module 100 stores
`a global timeout value, which defines a fixed number of
`