WO2016122692A1

WO2016122692A1 - Packet headers with device-extrinsic information

Info

Publication number: WO2016122692A1
Application number: PCT/US2015/023918
Authority: WO
Inventors: Pramod SHANBAG; Mohammed Javed PADINHAKARA; Santosh Kumar Singh
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-01-29
Filing date: 2015-04-01
Publication date: 2016-08-04

Abstract

In one implementation, tap information enrichment includes an extrinsic attribute to be marked with an interest status based on a device-intrinsic information, identification of whether tapped traffic includes the device-intrinsic information associated with the extrinsic attribute, device-extrinsic information to be obtained from an external source, and a packet header structured with the device-extrinsic information associated with the device-intrinsic information.

Description

Packet Headers with Device-Extrinsic information

BACKGROUND

[0001] Computer networks commonly include switches, routers, and endposnts (such as servers or client devices) thai are communicatively connected to transfer information between endpoints. Networks have evolved to include mobile computing devices, personal devices connected to business networks, virtual machines, and even virtual switches. Networks are commonly distributed across vendors of network devices and host multiple solutions, such as orchestration software and middle boxes, to meet daily customer requirements. As networks evolve, the importance of "network visibility" becomes very pertinent from the perspective of auditing, troubleshooting, and network data analytics. Network monitoring solutions can enable a network administrator to "tap" (i.e., copy and/or redirect) traffic at various tapping points in the network and use the tapped traffic for various analysis such as probing, auditing, and anomaly detection,

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figures 1 and 2 are block diagrams depicting example network tap systems.

|0003] Figures 3A and 3B depict example environments in which various network tap systems can be implemented.

[0004] Figure 4 depicts example modules used to implement example network tap systems.

[0005] Figures 5 and 6 are flow diagrams depicting example methods for tap information enrichment.

DETAILED DESCRIPTION [0006] In the following description and figures, some example implementations of network tap apparatus, network tap systems, and/or methods for tap information enrichment are described. Network monitoring solutions come in a variety of offerings. Traditionally techniques !ike sample-based monitoring (e.g., SFLOW), statistics-based monitoring (e.g., NETFLOW), port mirroring (e.g. , SPAN), etc. have been widely used for achieving network visibility objectives (e.g., traffic tapping objectives). Software- defined network ("SDN") environments provide opportunities for more precise tapping and traffic analytics because of the centralized visibility and capability to steer and/or copy traffic on a per-flow basis.

[00073 Various examples described below relate to augmenting tapped traffic with additional logical information. Commonly, tapped data consists of basic header attributes, such as network entity information including an internet protocol ("IP") address and/or a media access control ("MAC") address. To analyze and/or enhance the tapped traffic information, a network administrator can manually identify logical information associated with the network entity information. Using attributes to identify an interest in logical information, a packet structure can be modified to include logical information associated with tapped traffic. In particular, information that is unknown at the device level can be retrieved at the time of tapping and added to the packet header structure of the copied traffic when being sent to the network monitoring destination.

[0008] A network element, as used herein, represents any appropriate device of a network, such as a switch, a router, a middle box, or an endpoint compute device. As used herein, device information (e.g., a type of information related to a network element and/or traffic tapable on the network element) that is located at the network element level is device-intrinsic information and device information that is not available locally to a target network element is device-extrinsic information. The terms "include," "have," and variations thereof, as used herein, mean the same as the term "comprise" or appropriate variation thereof. Furthermore, the term "based on," as used herein, means "based at least in part on." Thus, a feature that is described as based on some stimulus can be based only on the stimulus or a combination of stimuli including the stimulus. Furthermore, the term "maintain" (and variations thereof) as used herein means "to create, delete, add, remove, access, update, and/or modify." [0009] Figures 1 and 2 are block diagrams depicting example network tap systems 100 and 200, Referring to Figure 1 , the example network tap system 100 of Figure 1 generally includes a data store 102, an interest engine 104, and an assembler engine 108, In general, the assembler engine 106 can structure tapped traffic with a packet header to accept device-extrinsic information (e.g., data unknown to the target network element and known to an external source) associated with the tap traffic obtained via the interest engine 104. The example network tap system can include engines to facilitate data retrieval of device-extrinsic information, such as a push engine 108, an augmentation engine 110, a supplement enginel 12, and a repository engine 114.

[0010] The interest engine 104 represents any circuitry or combination of circuitry and executable instructions to identify an extrinsic attribute and communicate an interest in information associated with the extrinsic attribute to a network element, such as a network controller. For example, the interest engine 104 can represent any circuitry or combination of circuitry and executable instructions to identify an extrinsic attribute based on device-intrinsic information (e.g., information known to the target network element) and send an interest message to a network controller to request device- extrinsic information. An extrinsic attribute is a logical representation of a class of device-extrinsic information. Example device-extrinsic data include device fingerprint information, domain name service ("DNS") names, security-related information, network statistics, network events, business-entity information, and any representation of aggregated information of the network.

[0011] The Interest message can contain an identifier associated with the extrinsic attribute. For example, the network controller can utilize the identifier to mark information that may be relevant to the tapped traffic. The identifier can be any appropriate value, number, character, string, category, or other representation to denote an extrinsic attribute. The Information to be retrieved is information external to the local memory of the network element that is designated to tap traffic. In other words, the tap traffic is to be augmented with external information, such as logical entities (i.e., a particular term or phrase of the device-extrinsic information). Examples of the logical entities that can be represented include representations of the device performing the tapping, an attribute of the device performing the tapping, an analytical association with the device performing the tapping, and information related to the class, semantics, and/or purpose of data being tapped at the target device.

[0012| The interest message can be any appropriate communication of Interest in an extrinsic attribute. For example, the request from the target network element can instruct the SDN controller at the initial handshake regarding information that is to be recorded as relevant (e.g., marked as with an interest status to denote an interest) to the target network element. In that example, the SDN controller would identify the information is of interest to the network element (such as via a list or mapping of keywords to identifiers) and push the logical entity to the target network element when the logical entity is discovered (e_sg_ls discovered over a period of time during network monitoring). For another example, the interest message can be a representational state transfer ("REST") request to the network controller and the REST request can be sent at a time of copying the tapped traffic or otherwise made on demand.

OI33 A logical entity can be any appropriate representation of information that utilizes information external to device-intrinsic information, suc as a word or phrase associated with a network element primitive. For example, a logical entity can b a resolved network primitive (such as a host name of a device when the network primitive is a MAC address of the device) or supplemental traffic-analysis information (such as any Information that requires a lookup into data contained outside of the targeted network element). An external source can include any appropriate data source other than the network element being targeted for tap traffic. In other words, an external source includes any compute device or component that is external to the source of the tap traffic. For example, a logical entity representing the information of interest can be gathered from at least one of a service device coupled to the network that contains a database of network information and a SDN controller executing a network

management application. Example external sources include a middle box, an SDN controller, a network management database, and an application executing on a network element,

[00143 The extrinsic attribute and/or the logical entities can be identified using a mapping, such as map of network element primitives to a data structure of extrinsic attributes associated with those network element primitives, A mapping of keywords to primitives can include a knowledge base and/or a machine-learned store of terms that can represent a network element primitive. For example, the mapping can contain a data structure associating the string "conference room A" with strings "switch A" and "switch B" (or the MAC addresses associated with the switches A and B, respectively), so the map of keywords can generate the primitives of switch A and switch B when a tap configuration associated with the conference room A is requested. A mapping can represent any data structure or combination of data structures to provide association between identifiers (e.g., numbers, characters, strings, etc.). Example data structures usable as a mapping include an associative array, a tree, a map, a dictionary, and the like. In general, the mappings are used for lookups of associative terms and can be adapted to specific use cases by a network administrator.

[0015] Relevance of information can be based on the source of the tap request and/or the purpose of tapping the traffic. For example, a host name, workgroup, or location ma be relevant to the source when the logical entity is directly associated with the source, such as the device being a member of the workgroup. For another example, the source may become relevant based on analysis or other monitoring, such as following a group of users where a user of the group routes traffic through the source or a security breach is flagged on a particular application served by a device attached to the source network element. Relevance can be considered in a mapping, such as direct associations based on administrator-known relevance or a function to perform a relevance analysis.

[0016] The assembler engine 108 represents any circuitry or combination of circuitry and executable instructions to assemble the structure of the tapped traffic to include both the tapped traffic and the device-extrinsic information. For example, the assembler engine 106 can represent any circuitry or combination of circuitry and executable instructions to identify the device-extrinsic information associated with the identifier and a target of tapped traffic (e.g., a source network element requested to tap traffic), place the device-extrinsic information in a header structure of a packet of tapped traffic associated with the target, and send the tapped traffic with the header structure on a path to a tap destination. A tap destination can be a network element to receive the tap traffic, such as an SDN controller or a tap sink to perform analysts on the tap traffic. {0017| The push engine 108 represents any circuitry or combination of circuitry and executable instructions to manage messages to network element devices regarding device-extrinsic messages. For example, the push engine 108 represent any circuitry or combination of circuitry and executable instructions to flag the identifier with an interest status, mark the device-extrinsic information associated with the identifier based on the interest status, and send the marked device-extrinsic information to the assembler engine 106 when the marked device-extrinsic information is discovered. Other example devices that can manage sending messages to network elements include the controller or a service device that contains, manages access to, or i otherwise coupled to an external source.

[0018] The repository engine 114 represents any circuitry or combination of circuitry and executable instructions to maintain access to device-extrinsic information. For example, the repositor engine 114 can represent any circuitry or combination of circuitry and executable instructions to maintain access to a database of network management information where the network management information includes data from at least one external source, such as a lightweight directory access protocol ("LDAP") management application or a remote authentication dial in user service ("RADIUS") management application. For another example, the repository engine 114 can represent any circuitry or combination of circuitry and executable instructions to maintain access to a list of application programming interfaces ("API") of network management applications,

[00193 The repository engine 114 can supply access to device-extrinsic information directly or indirectly. The repository engine 1 14 can provide access to a device-extrinsic information directly b providing a logical entity, such as traffic analysis information particular to target being tapped. The repository engine 1 14 can provide access to device-extrinsic information indirectly by providing a manner to access the desired information, such as an API to a network management source.

[0020] The augmentation engine 1 10 represents any circuitry or combination of circuitry and executable instructions to resolve network element primitives of the device- intrinsic information to logical entities of the device-extrinsic information based on data from the external source, A network element primitive is an attribute at the network element level, such as a specific physical switch, a port, a MAC address, an IP address, a switch-port tuple, and the like. Some classes of device-extrinsic informatio are logical entities that represent device-intrinsic information, such as a host name or a DNS name, and the augmentation engine 110 represents any circuitry or combination of circuitry and executable instructions to map the logical entities (i.e., device-extrinsic information) from the network element primitives (i.e., the device-intrinsic information).

[0021 The supplement engine 112 represents any circuitry or combination of circuitry and executable instructions to identify traffic analysis information related to the extrinsic attribute. Some classes of device-extrinsic information are logical entitles that represent analysts performed on information of the network (such as analysis of network events, computation of network statistics, and comparison of network attributes to thresholds) and the supplement engine 112 represents any circuitry or combination of circuitry and executable instructions to map the analytical information of the network to logical entities that add to the information of the tap traffic (e.g., and are not contained in the tap traffic). Example traffic analysis information includes traffic statistics, network events, or security-related information. Example traffic statistics include packet counter information, byte counter information, packet errors, and checksum failures. Example network events include messages of a management protocol regarding a change in the network, such as a configuration change event. Example security-related information includes a failed MAC authentication event, an access attempt of a blacklisted MAC address, and a failed IP authentication event.

[0022] The data store 102 can contain information utilized by the engines 104, 108, 108, 110, 112, and 114. For example, the data store 102 can store device-intrinsic information, device-extrinsic information, an extrinsic attribute, an identifier, an API, tapped traffic, a mapping, and the like.

[0023] Figure 2 depicts the example system 200 can comprise a memory resource 220 operatively coupled to a processor resource 222. The processor resource 222 can be operatively coupled to a data store 202. The data store 202 can be the same as the data store 102 of Figure 1. [0024] Referring to Figure 2, the memory resource 220 can contain a set of instructions that are executable by the processor resource 222. The set of instructions are operable to cause the processor resource 222 to perform operations of the system 200 when th set of instructions are executed by th processor resource 222. The set of instructions stored on the memory resource 220 can be represented as an interest module 204, an assembler module 206, a push module 208, an augmentation module 210, a supplement module 212, and a repository module 214. The interest module 204, the assembler module 208, the push module 208, the augmentation module 210, the supplement module 212, and the repository module 214 represent program instructions that when executed function as the interest engine 104, the assembler engine 106, the push engine 108, the augmentation engine 110, the supplement engine 112, and the repository engine 114 of Figure 1 , respectively. The processor resource 222 can carry out a set of instructions to execute the modules 204, 206, 208, 210, 212, 214, and/or any other appropriate operations among and/or associated with the modules of the system 200. For example, the processor resource 222 can carry out a set of instructions to identify an extrinsic attribute based on device-intrinsic information of a target network element, identify a logical entity associated with the extrinsic attribute from a set of device-extrinsic information, instruct the target network element to monitor for tapped traffic associated with the logical entity based on the device-intrinsic information, and cause the tapped traffic to be encapsulated with a header structure that includes the device-extrinsic information associated with the extrinsic attribute when a source of the tapped traffic is the target network element. For another example, the processor resource 222 can carry out a set of instructions to record an interest in the extrinsic attribute at an initial handshake of the network element with a network controller, push the logical entity to the target network element of the recorded interest when the logical entity is discovered, and cause tapped traffic to be encapsulated with the logical entity within the header structure of a packet of the tapped traffic.

[0025] Although these particular modules and various other modules are illustrated and discussed in relation to Figure 2 and other example implementations, other combinations or sub-combinations of modules can be included within other implementations. Said differently, although the modules illustrated in Figure 2 and discussed in other exampSe implementations perform specific functionalities in the examples discussed herein, these and other functionalities can be accomplished, implemented, or realized at different modules or at combinations of modules. For example, two or more modules illustrated and/or discussed as separate can be combined into a module that performs the functionalities discussed in relation to the two modules. As another example, functionalities performed at one module as discussed in relation to these examples can be performed at a different module or different modules. Figure 4 depicts yet another example of how functionality can be organized into modules.

[0026] The processor resource 222 is any appropriate circuitry capable of processing {e.g.. computing) instructions, such as one or multiple processing elements capable of retrieving instructions from the memory resource 220 and executing those instructions. For example, the processor resource 222 can be a central processing unit ("CPU") that enables tap information enrichment by fetching, decoding, and executing modules 204, 208, 208, 210, 212_s and 214. Example processor resources 222 include at least one CPU_S a semiconductor-based microprocessor, an application specific integrated circuit ("ASIC"), a field-programmable gate array ( PGA")₍ and the like. The processor resource 222 can include multiple processing elements that are integrated in a single device or distributed across devices. The processor resource 222 can process the instructions serially, concurrently, or in partial concurrence.

|0027| The memory resource 220 and the data store 202 represent a medium to store data utilized and/or produced by the system 200. The medium is any non- transitory medium or combination of non-transitory mediums able to electronically store data, such as modules of the system 200 and/or data used by the system 200. For example, the medium can be a storage medium, which is distinct from a transitory transmission medium, such as a signal. The medium can be machine-readable, such as computer-readable. The medium can be an electronic, magnetic, optical, or other physical storage device that is capable of containing (i.e., storing) executable

instructions. The memor resource 220 can be said to store program instructions that when executed by the processor resource 222 cause the processor resource 222 to implement functionality of the system 200 of Figure 2. The memory resource 220 can be integrated in the same device as the processor resource 222 or it can be separate taut accessible to thai device and the processor resource 222. The memory resource 220 can be distributed across devices. The memory resource 220 and the data store 202 can represent the same physical medium or separate physical mediums. The data of the data store 202 can include representations of data and/or information mentioned herein.

(0028] In the discussion herein, the engines 104, 106, 108, 1 10, 1 12, and 1 4 of Figure 1 and the modules 204, 208, 208, 210, 212, and 214 of Figure 2 have been described as circuitry or a combination of circuitry and executable instructions. Such components can be implemented in a number of fashions. Looking at Figure 2, the executable instructions can be processor-executable instructions, such as program instructions, stored on the memory resource 220, which is a tangible, non-transitory computer-readable storage medium, and the circuitry can be electronic circuitry, such as processor resource 222, for executing those instructions. The instructions residing on the memory resource 220 can comprise any set of instructions to be executed directly (such as machine code) or indirectly (such as a script) by the processor resource 222. {00293 in some examples, the system 200 can include the executable instructions can be part of an installation package that when installed can be executed by the processor resource 222 to perform operations of the system 200, such as methods described with regards to Figures 4-8. in that example, the memory resource 220 can be a portable medium such as a compact disc, a digital video disc, a flash drive, or memory maintained by a computer device, such as a service device 334 of Figure 3, from which the installation package can be downloaded and installed. In another example, the executable instructions can be part of an application or applications already installed. The memory resource 220 can be a non-volatile memory resource such as read only memory ("ROM"), a volatile memory resource such as random access memory ("RAM"), a storage device, or a combination thereof. Example forms of a memory resource 220 include static RAM ("SRAM"), dynamic RAM ("DRAM"), electrically erasable programmable ROM ("EEPRO "), flash memory, or th like. The memory resource 220 can include integrated memory such as a hard drive ("HO"), a solid state drive ("SSD"), or an optical drive. [0030] Figures 3A and 3B depict example environments in which various exampie network tap systems can be implemented. The example environment 390 is shown to include an example system 300 for tap information enrichment. The system 300 (described herein with respect to Figures 1 and 2) can represent generally any circuitry or combination of circuitry and executable instructions to enrich tapped traffic with device-extrinsic information. The system 300 can include a combinatio of an interest engine 304, an assembler engine 306, a push engine 308, an augmentation engine 310, a supplement engine 312, and a repository engine 314 that are the same as the interest engine 104, the assembler engine 108, the push engine 108, the augmentation engine 110, the supplement engine 12, and the repository engine 114 of Figure 1 , respectively, and the associated descriptions are not repeated for brevity. As shown in Figure 3, the data store 302 (which is the same as data stores 102 of Figure 1 and 202 of Figure 2) and the engines 304, 306, 308, 310, 312, 314 can be integrated into a compute device, such as a switch network element or a tap sink, or distributed across multiple compute devices. The engines 304, 306, 308, 310, 312, and 314 can be integrated via circuitry or as installed instructions into a memor resource of the compute device,

[0031] The example environment 390 can include compute devices that are elements of the network, such as a controller 332, service devices 334, user devices 336, switches 338, wireless access point device 340, and an intermediary device 342, The controller 332 represents generally any compute device capable of managing the network. For example, the controller 332 can be a SDN controller that includes circuitry (or a combination of circuitry and executable instructions) to manage flows of traffic through the network 330 and execute a tap application, such as tap application to be a destination of the tap traffic (e.g., a network monitoring application). The service devices 334 represent generall any compute devices to respond to a network request received from a user devic 336, whether virtua! or real. For example, the service device 334 can operate a combination of circuitry and executable instructions to provide a network packet in response to a request for a page or functionality of an application. The user devices 336 represent generally any compute devices to communicate a network request and receive and/or process the corresponding responses. For example, a browser application may be installed on the user device 336 to receive the network packet from the service device 334 and utilize the payload of the packet to display an element of a page via the browser application. The switches 338 represent any network device capable of connecting devices of the network together. For example, a switch 338 can retain local routing information of paths describing how to transfer packets from a source to a destination.

(0032] In Figures 3A and 3B, the dotted lines represent logical connections between devices (such as between the controller 332, the intermediary device 342, and the switches 338) which may or may not be physically connected directly. For example with reference to Figure 3A, switches 338 can be logically coupled to the controller 332 and receive device-extrinsic information from the controller (which may have received the device-extrinsic information from a service device 334} before forwarding traffic tapped at a switch 338 to a tap destination (which may be another network element such as a tap sink or the controller). For example with reference to Figure 38, the switches 338 connected via dotted lines to the controller 332 can represent switches 338 selected as part of the tap domain to copy traffic to the controller 332, where the tap traffic is routed on a path through an intermediary device 342 rather than directly to the controller 332 and the intermediary device 342 is coupled to a plurality of external sources to gather device-extrinsic information. As mentioned, the intermediary device 342 can be a tap sink device, such as an intrusion detection system f IDS") or an intrusion prevention system ("IPS"). For example, the intermediary device 342 can be a tap sink device including circuitry to execute an enrichment application to receive the tap traffic and perform encapsulation of device-extrinsic information on the tap traffic. By directing tapped traffic to a centralized network element, such as intermediary device 342, the enrichment of data can happen at the centralized network element that has access to external sources, reducing the need for each switch 338 to access the external sources for device-extrinsic information.

[0033] In a centralized mode as depicted in Figure 38, the intermediary device 342 can host the system 300 and be the destination of a configured tap rule (e.g., the destination of all tap rules), in that example, the intermediary device 342 would query external applications to resolve a network element primitive to a logical entity (e.g., device-extrinsic information that would otherwise have been unknown to the target device of the tap rule), encapsulate the tapped data with the resolved data in a packet, and tunnel the packet to a destination of the tap rule, in a distributed mode as depicted in Figure 3A, the system 300 can be hosted on a switch 338 that Is the target of a tap rule where the switch 338 consults with the push engine 308 to get resolved logical entities, encapsulates the resolved logical entities in a packet, and tunnels the packet with resolved attributes to the destination of the tap rule. In either mode, the destination of the tap rule would de-capsuSate the packet to obtain the tapped traffic and the resolved data.

[00343 The compute devices can be located on separate networks 330 or part of the same network 330, The example environment 390 can include any appropriate number of networks 330 and any number of the networks 330 can include a cloud compute environment, such as a virtual shared poo! of compute resources. For example, networks 330 can be distributed networks comprising virtual computing resources. Any appropriate combination of the system 300 and compute devices can be a virtual instance of a resource of a virtuai shared poo! of resources. The engines and/or modules of the system 300 herein can reside and/or execute "on the cloud" (e.g. reside and/or execute on a virtuai shared pool of resources).

[0035] A link 328 generally represents one or a combination of a cable, wireless connection, fiber optic connection, or remote connections via a telecommunications link, an infrared Sink, a radio frequency link, or any other connectors of systems that provide electronic communication. The link 328 can include, at least in part, intranet, the

Internet, or a combination of both. The link 328 can also include intermediate proxies, routers, switches, load balancers, and the like.

0 363 Referring to Figures 1-3, the engines 104, 106, 108, 10, 112, and 114 of Figure 1 and/or the modules 204, 206, 208, 2 0, 212, 214 of Figure 2 can be distributed across devices 332, 334, 336, 338, 340, 342, or a combination thereof. The engine and/or modules can complete or assist completion of operations performed in

describing another engine and/or module. For example, the augmentation engine 310 of Figure 3 can request, complete, or perform the methods or operations described with the augmentation engine 1 10 of Figure 1 as well as the interest engine 104, the assembler 106, the push engine 108, and the supplement engine 112 of Figure 1 . Thus, although the various engines and modules are shown as separate engines in Figures 1 and 2, in other implementations, the functionality of multiple engines and/or modules may be implemented as a single engine and/or module or divided in a variety of engines and/or modules. In some example, the engines of the system 300 can perform example methods described in connection with Figures 4-6.

(0037] Figure 4 depicts example modules used to implement example network tap systems. Referring to Figure 4, the example modules of Figure 4 generally include an interest moduie 404, an assembler module 408, a push module 408, a repository module 414, and a modifier module 452 (which includes an augmentation module 410 and a supplement moduie 412). The interest moduie 404, the assembler module 408, the push module 408, the augmentation module 410, the supplement module 412, and the repository module 414 function similar to the interest module 204, the assembler module 206, the push module 208, the augmentation module 210, the supplement moduie 212, and the repository module 214 of Figure 2, and their respective

descriptions are not repeated in their entirety. The example modules of Figure 4 can be implemented on a compute device, such as a network switch, an SDN controller, or a tap sink.

[0038] The tap request 460 can activate a processor resource that executes an interest module 404 to obtain an extrinsic attribute using device information 462. The interest module 404 can include program instructions, such as an attribute module 440 and a mode module 442, to facilitate retrieval of device-extrinsic information. The attribute module 440 represents program instructions that when executed cause a processor resource to identify an extrinsic attribute that represents a class of

information of interest to the tap request 460 based on the device information 462. The mode module 442 represents program instructions that when executed cause a processor resourc to determine whether the network supports a distributed mode of operation or a centralized mode of operation. For example, if the destination of the tap request is a centralized collection unit for tapped traffic, then tap request can be completed based on a centralized mode of operation by sending the tapped traffic to the collection unit to be enriched with data via processor resource executing the repository module 414,

(00393 fr*^e system is to operate in the distributed mode, then a processor resource executing the push module 408 is activated. The push module 444 can include program instructions, such as an identifier module 444 and a mark module 446, to facilitate automatic transfe of relevant device-extrinsic information to the network elements of the network. The identifier module 444 represents program instructions that when executed cause a processor resource to determine an identifier associated with an extrinsic attribute that is of i nterest to the tap request 460. The mark module 446 represents program instructions that when executed cause a processor resource to flag information for forwarding to a network element when the information contains the identifier or otherwise matches a condition to forward the information where the condition is based on the identifier. For example, information regarding a network event can match an identifier marked based on the interest status of the associated extrinsic attribute,

10040] If the system is to operate in the centralized mode, then a processor resource executing the repository module 414 is activated. The repository module 414 can include program instructions, such as an API module 448 and a retrievai module 450, to facilitate access to device-extrinsic information. The API module 448 represents program instructions that when executed cause a processor resource to manage a list of APIs associated with network management applications and provide an API based on the interest of device-extrinsic information possessed by an associated network management application. The retrieval module 450 represents program instructions that when executed cause a processor resource to retrieve device-extrinsic information from via an API or a database managed by the processor resource executing the repository module. For example, a processor resource that executes the retrieval module 450 can maintain a database of collected network management Information based on data from a plurality of external sources,

[0041] The modifier module 452 represents program instructions that when executed cause a processor resource to determine and/or identify the forms i which device-extrinsic information is relevant to the tap traffic based on data 464 gathered from an external source (such as via a processor resource executing the push module 408 or a processor resource executing the repository module 414). The modifier moduie 452 can include program instructions, such as the augmentation moduie 410 and the supplement moduie 412, to facilitate identification of the type of device-extrinsic information is to enrich the tapped traffic.

[0042] The assembler moduie 406 can include program instructions (such as the identification moduie 454, the encapsulation module 456, and the forward moduie 458} that faciiitate generation of enriched tap traffic 474 based on relevant gathered data 486 to provide enrichment, the request protocol 468 of the tap request 460, and the path information 470 to the tap destination of the tap request 460. The identification moduie 454 represents program instructions that when executed cause a processor resource to identify device-extrinsic information of the enrichment data 466 based on device- intrinsic information of the tap request 480 that is associated with an extrinsic attribute. The encapsulation module 456 represents program instructions that when executed cause a processor resource to structure a header in a format compatible with the request protocol 468 and place the enrichment data 466 in the packet header structure of a packet with the tapped traffic as a payload. The forward module 458 represents program instructions that when executed cause a processor resource to place the source and destination information in the header structure based on the path

information and send enriched tap traffic 474 (i.e., the constructed packet of tap traffic with the enrichment data 466 in the packet header) on a path to a destination of the tap request 460.

[0043] Figures 5 and 6 are flow diagrams depicting example methods for tap information enrichment. Referring to Figure 5, example methods for tap information enrichment can generally comprise marking an extrinsic attribute with an interest status based on device-intrinsic information, identifying tapped traffic includes the device- intrinsic Information associated with the extrinsic attribute, obtaining device-extrinsic information from an externa! source, and structuring a packet header with a field to include the device-extrinsic information associated with the device-intrinsic information, [0044] At biock 502, an extrinsic attribute is marked with an interest status. The extrinsic attribute is marked based on device-intrinsic information. For example, device- intrinsic information of a set of copied traffic can be used to mark information as interested. An tdentifier can be used to track an extrinsic attribute and the interest status associated with the extrinsic attribute. For example, information that passes through an SDN controiler can be compared to the identifier and if a matc occurs, then the information associated with the extrinsic attribute is prepared to send to a network element to enrich the tapped traffic associated with the extrinsic attribute (e.g., traffic that inciudes the device-intrinsic information or originates from a network element represented by the device-intrinsic information).

[0045! At block 504, tapped traffic is identified as including the device-intrinsic information associated with the extrinsic attribute marked at block 502, A determination as to whether tapped traffic inciudes device-intrinsic information can be based on the content of the tapped traffic or if the network element from which the tap traffic originates is associated with the device-intrinsic information (e.g., whether the source network element is describabte by the device-intrinsic information).

100463 At block 506, device-extrinsic information is obtained from an external source. Device-extrinsic information can be obtained via any manner described herein or equivalent. For example, the device-extrinsic information can be obtained via a centralized collection device that collects device information of the network. For another example, the device-extrinsic information can be obtained via an API request to an external source, such as an SDN controller or a network management application executing on a service device. The device-extrinsic information is obtained based on a comparison of the identifier to the device-extrinsic information. For example, the identifier representing the extrinsic attribute is compared to the discovered device information based on whether the class of the extrinsic attribute matches the class of the device information. In that exampie, a match between the classes would signal the device information is device-extrinsic information of interest (e.g., relevant) to the tapped traffic.

[0047] At block 508, a packet header is structured with a field to include the device-intrinsic information associated with the device-intrinsic information. For exampie, the packet header can be structured by using a type, length, and vaiue ("TLV") format to designate a space in the packet header for the device-extrinsic information. The entirety of the packet header or a particular field of the packet header can be structured using the TLV format and accommodate the device-extrinsic information. For example in a traditional network, a protocol data unit PDU") structure can include a network layer header structured using a TLV format to with a payload consisting of transport layer information comprising the tapped traffic where the header is structured to include a first field to appropriately transport the packet and a second field to store the enrichment data (i.e., the device-extrinsic information). For another example in an OPENFLOW-based network, a PDU structure can include the GPEMFLOW header fields of the OPEN FLOW protocol and the OXM field of the OPENFLOW header fields can be modified with a TLV format in the OXM experimenter value where the

enrichment data can be stored in the OXM experimenter value field,

{0048] Figure 6 includes blocks similar to blocks of Figure 5 and provides additional blocks and details. In particular, Figure 6 depicts additional blocks and details generally regarding identifying an extrinsic attribute from a tap request, augmenting the tapped traffic with device-extrinsic information, and tunneling a packet with the device- extrinsic information to a tap destination. Blocks 602, 606, and 608 are the same as blocks 502, 504, and 506 of Figure 5 and, for brevity, their respective descriptions are not repeated.

[0049] At block 602, an extrinsic attribute is identified from a tap request. For example, a network element primitive can be derived from the tap request and a list of known extrinsic attributes can be looked up based on the network element primitive to find an extrinsic attribute associated with the network element primitive. The existence of the network element primitive may be sufficient to mark the identifier associated with the extrinsic attribute at block 604. For example, the extrinsic attribute can be marked for interest based on the existence of the network element primitive or based on analysis as to whether the extrinsic attribute is related to the tapped traffic.

[0050] At block 610, tapped traffic can be augmented with device-extrinsic information by at least one of resolving a network element primitive and supplementing the tapped traffic with traffic analysis information. A network element primitive can be resolved by matching device- intrinsic information to a logical entity of the device- extrinsic information. Tapped traffic can be supplemented with traffic analysis information associated with the tapped traffic based on an event associated with the device-intrinsic information. Example traffic analysis information can include at least one of security-related information, a traffic statistic, and network configuration event information. For example, an IPS can detect a security breach and trigger a security- related network event where information related to that event is relevant to tapped traffic that originates from the same location as the security breach, thus the security breach information should be sent along with the tapped traffic as the tapped traffic travels to the destination specified by the tap request. For another example, a configuration change event can be analyzed where the analysis of the configuration change event results in device-extrinsic information that enriches the information provided in the tapped traffic.

{0051] At block 614, a packet with device-extrinsic information in the packet header is tunneled to a tap destination. For example, an enriched packet (i.e., a packet with device-extrinsic information in the packet header) can be tunneled to a tap destination associated with the tap request by creating a secure data communication channel between the target network element that performed the tapping and a destination network element specified in the tap request and sending the packet with the packet header encapsulating the tapped traffic to the destination network element via the secure data communication channel. Using the manner described i Figures 5 or 8, a network administrator can refy on a tap technology to provide tapped traffic with tap information enrichment to avoid manual lookup of data associated with the tapped traffic.

[0052] Although the flow diagrams of Figures 4-6 illustrate specific orders of execution, the order of execution may differ from that which is illustrated. For example, the order of execution of the blocks may be scrambled relative to the order shown. Also, the blocks shown in succession may be executed concurrently or with partial

concurrence. All such variations are within the scop of the present description.

[0053] The present description has been shown and described with reference to the foregoing examples. It is understood, however, that other forms, details, and examples may be made without departing from the spirit and scope of the following claims. The use of the words "first," "second," or related terms in the claims are not used to limit the claim elements to an order or location, but are mereiy used to distinguish separate claim elements.

Claims

What is claimed is

1 1. A network tap system comprising:

2 an interest engine to:

3 identify an extrinsic attribute based on device-intrinsic information; and

4 send an interest message to a network controller to request device- s extrinsic information, the interest message to contain an identifier associated with

6 the extrinsic attribute;

7 an assembler engine to:

8 identify the device-extrinsic information associated with the identifier and a

9 target of tapped traffic, the device-extrinsic information derived from an external

I o source to the target;

I I place the device-extrinsic information in a header structure of a packet of

12 tapped traffic associated with the target; and

13 send the tapped traffic with the header structure on a path to a tap

14 destination.

1 2. The system of claim 1 , wherein the tap destination is the network controller.

1 3. The system of claim 1 , wherein the Interest message is a representational state

2 transfer ("REST") request to the network controller and the REST request is sent at

3 a time of copying the tapped traffic.

1 4. The system of claim 1 , wherein the network controller comprises:

2 a push engine to;

3 flag the identifier with an interest status;

4 mark the device-extrinsic information associated with the identifier based

5 on the interest status; and

6 send the marked device-extrinsic information to the assembler engine ? when the marked device-extrinsic information is discovered.

5. The system of claim 1 , comprtstng a tap sink coupted to the external source, the tap sink comprising:

an augmentation engine to resolve network primitives of the device-intrinsic information to logical entities of the device-extrinsic information based on data from the external source; and

a supplement engine to identify traffic analysis information related to the extrinsic attribute, the device-extrinsic information to comprise the traffic analysis information. 8. The system of claim 5, wherein the tap sink further comprises:

a repository engine to maintain at least one of;

a database of network management information, the network management information comprising the data from the externa! source; and a list of application programming interfaces of network management applications. 7. A compute readable storage medium comprising a set of instructions executable by a processor resource to:

identify an extrinsic attribute based on device-intrinsic information of a target network element;

identify a logical entity associated with the extrinsic attribute from a set of device- extrinsic information;

instruct the target network element to monitor for tapped traffic associated with the logical entit based on the device-intrinsic information; and

cause the tapped traffic to be encapsulated with a header structure that includes the device-extrinsic information associated with the extrinsic attribute when a source of the tapped traffic is the target network element. 8, The medium of claim ?, wherein the set of instructions is executable by the

processor resource to; record an interest in the extrinsic attribute at an initial handshake of the network element with a network controller; and

push the logical entity to the target network element when the logical entity is discovered. 9, The medium of claim 7, wherein the set of instructions is executable by the

processor resource to:

gather the logical entity from at least one of:

a service device thai contains a database of network information; and a software-defined network controller. 10. The medium of claim 7, wherein the logical entity is one of:

a resolved network primitive; and

a supplemental traffic-analysis information. 11. A method for tap information enrichment comprising:

marking, using an identifier, an extrinsic attribute with an interest status based on device-intrinsic information;

identifying that tapped traffic includes the device-intrinsic information associated with the extrinsic attribute;

obtaining device-extrinsic information from an external source based on a comparison of the identifier to the device-extrinsic information: and

structuring a packet header with a field to include the device-extrinsic information associated with the device-intrinsic information. 12. The method of claim 11 , comprising at least one of:

resolving a network primitive of the device-intrinsic information to a logical entity of the device-extrinsic information; and

supplementing the tapped traffic with traffic analysis information associated with the tapped traffic based on an event associated with the device-intrinsic information, the device-extrinsic information to include the traffic analysis information.

13. The method of claim 12, wherein the traffic analysis information comprises at least one of;

security-related information;

a traffic statistic; and

network configuration event information. 14. The method of claim 11 , wherein structuring the packet header comprises;

designating space in the packet header for the device-extrinsic information by using a type, length, and vaiue ("TLV") format to structure one of:

an entirety of the packet header; and

a particular field of the packet header. 15. The method of claim 11 , comprising:

identifying the extrinsic attribute from a tap request; and

tunneiing a packet with the device-extrinsic information in the packet header to a tap destination associated with a tap request, the packet header to encapsulate the tapped traffic.