I 1111111111111111 11111 1111111111 lllll 111111111111111 11111 1111111111 11111111
`US009264400B 1
`
`c12) United States Patent
`Lin et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,264,400 Bl
`Feb.16,2016
`
`(54) SOFTWARE DEFINED NETWORKING PIPE
`FOR NETWORK TRAFFIC INSPECTION
`
`(71) Applicant: Trend Micro Incorporated, Tokyo (JP)
`
`(72)
`
`Inventors: Chuan-Hung Lin, Taipei (TW);
`Ching-Yi Li, Taipei (TW); Po-Cheng
`Liang, Taipei (TW)
`
`(73) Assignee: Trend Micro Incorporated, Tokyo (JP)
`
`( *) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 121 days.
`
`(21) Appl. No.: 14/094,442
`
`(22) Filed:
`
`Dec. 2, 2013
`
`(51)
`
`Int. Cl.
`G06F 21100
`H04L29/06
`(52) U.S. Cl.
`CPC ............ H04L 63102 (2013.01); H04L 6310245
`(2013.01)
`
`(2013.01)
`(2006.01)
`
`( 58) Field of Classification Search
`CPC ............................ H04L 63/02; H04L 63/0245
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,697,806 Bl*
`6,751,219 Bl*
`
`2003/0021230 Al *
`
`2006/0036780 Al *
`
`2/2004 Cook ...................... G06F 21/31
`6/2004 Lipp ..................... H04L 49/201
`370/390
`8,339,959 Bl * 12/2012 Moisand ............. H04L 63/0236
`370/235
`1/2003 Kuo ........................ H04L47/10
`370/230
`2/2006 Dernis ................ G06F 13/4282
`710/36
`2009/0249472 Al* 10/2009 Litvin ................. H04L 63/0263
`726/14
`2009/0300353 Al* 12/2009 Hart .................... H04L 63/1416
`713/168
`2010/0269171 Al* 10/2010 Raz ......................... G06F 17/00
`726/13
`2010/0278180 Al* 11/2010 Ma ........................ H04L 49/354
`370/392
`
`2011/0286324 Al* 11/2011
`
`2012/0210416 Al*
`
`8/2012
`
`2013/0291088 Al* 10/2013
`
`2014/0133360 Al *
`
`5/2014
`
`2014/0211807 Al*
`
`7/2014
`
`2015/0124629 Al*
`
`5/2015
`
`2015/0163150 Al*
`
`6/2015
`
`2015/0222491 Al *
`
`8/2015
`
`2015/0236900 Al *
`
`8/2015
`
`Bellagamba ........ H04L 41/0677
`370/219
`Mihelich ............. H04L 63/0218
`726/11
`Shieh .................. H04L 63/0218
`726/11
`Chiueh ................... H04L 41/12
`370/256
`Takenaka ................ H04L45/74
`370/392
`Pani .................... H04L 12/4679
`370/248
`Beheshti-Zavareh . H04L 45/121
`370/400
`Clark ...................... H04L 45/48
`370/256
`Chung . ................... H04L 69/02
`709/221
`
`OTHER PUBLICATIONS
`
`OpenFlow-Wikipedia, the free encyclopedia, 3 sheets [ retrieved on
`Nov. 15, 2013], retrieved from the internet: http://en.wikipedia.org/
`wiki/OpenFlow.
`ONF-Open Networking Foundation, White Paper, Software-De(cid:173)
`fined Networking: The New Form Norm for Networks, Apr. 13, 2012,
`pp. 1-12.
`
`* cited by examiner
`
`Primary Examiner - Lisa Lewis
`(7 4) Attorney, Agent, or Firm - Okamoto & Benedicto LLP
`
`ABSTRACT
`(57)
`A software defined networking (SDN) computer network
`includes an SDN controller and an SDN switch. The SDN
`controller inserts flow rules in a flow table of the SDN switch
`to create an SDN pipe between a sender component and a
`security component. A broadcast function of the SDN switch
`to the ports that form the SDN pipe may be disabled. The SDN
`pipe allows outgoing packets sent by the sender component to
`be received by the security component. The security compo(cid:173)
`nent inspects the outgoing packets for compliance with secu(cid:173)
`rity policies and allows the outgoing packets to be forwarded
`to their destination when the outgoing packets pass inspec(cid:173)
`tion. The SDN controller may also insert a flow rule in the
`flow table of the SDN switch to bypass inspection of specified
`packets.
`
`17 Claims, 8 Drawing Sheets
`
`611
`
`620
`
`Flow{ables~624
`
`60'2~
`
`SON Pipe
`
`6.IO
`
`Security Service
`
`62J-3
`packets
`~ - - -~=+ - -~NEXT HOP
`
`SON Switch
`
`6ZJ-4
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 1 of 15
`
`

`

`U.S. Patent
`
`Feb.16,2016
`
`Sheet 1 of 8
`
`US 9,264,400 Bl
`
`OpenFlow Controller
`(Control Plane)
`
`Flow policy
`database
`
`Manage flow tables
`
`Egress
`Port
`
`Packets
`To next hop
`
`I
`
`I
`
`Flow Tables
`
`• l Lookup rule
`t
`
`OpenFlow Switch
`(Data Plane)
`
`HG,/
`
`(PRIOR Al?T}
`
`Packets
`From sender
`
`Ingress
`Port
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 2 of 15
`
`

`

`U.S. Patent
`
`Feb.16,2016
`
`Sheet 2 of 8
`
`US 9,264,400 Bl
`
`/00~
`
`IOI
`
`102
`
`106
`
`/04
`
`PROCESSOR
`
`USER INPUT
`DEVICE
`
`DATA
`STORAGE
`
`DISPLAY
`MONITOR
`
`/OJ
`
`105
`
`/08
`
`COMPUTER
`NETWORK
`INTERFACE
`
`MAIN MEMORY
`
`SOFTWARE MODULES
`
`110
`
`HG.Z
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 3 of 15
`
`

`

`U.S. Patent
`U.S. Patent
`
`Feb.16,2016
`Feb. 16, 2016
`
`Sheet 3 of 8
`Sheet 3 of 8
`
`US 9,264,400 Bl
`US 9,264,400 B1
`
`a.
`0
`.s:::.
`~ C
`
`0
`~
`
`Egress|Packets
`-(I)
`Security
`
`11
`
`$
`(I)
`.l<:
`(.)
`
`(ti a..
`
`-
`
`IJ)
`IJ) t::
`~ 0
`Cl a_
`UJ
`
`L . - -
`
`IJ)
`IJ) t::
`~ 0
`Cl a..
`.E
`
`(.)
`
`·2:
`(I)
`Cl)
`~ ·;::
`::J
`(.)
`(I)
`Cl)
`,.__
`
`- .
`
`c
`
`.B -~
`
`Cl)
`
`,.__
`
`w-TonexthoeasP
`Packets
`Service HG.3
`
`- ~
`
`IJ)
`IJ) t::
`~ 0
`Cl a_
`UJ
`
`essEgressPortPort
`
`
`
`t::
`0 a..
`
`IJ)
`IJ)
`~
`Cl
`Ingr
`.E
`~ .l<:
`(ti a..
`
`(.)
`
`cE
`"O
`C
`(I)
`IJ)
`
`Fromsender
`
`E e LL
`
`Exhibit 1005
`Cisco v. Orckit — IPR2023-00554
`Page 4 of 15
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 4 of 15
`
`

`

`U.S. Patent
`
`Feb.16,2016
`
`Sheet 4 of 8
`
`US 9,264,400 Bl
`
`Switch
`
`Packets
`From sender
`
`Ingress
`Port
`
`Egress
`Port
`
`Packets
`To next hop
`
`User------------(cid:173)
`API call
`
`Intercept
`port/tunnel
`
`Security Service
`
`HG. 4
`
`Virtual
`machine
`
`Virtual
`machine
`
`Virtual
`machine
`
`I
`
`I
`I
`I vendor specific interception mechanism ~ '--+ Security Service
`I
`I
`I
`To next hop
`Packets
`-
`Virtualization hypervisor
`
`HG.5
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 5 of 15
`
`

`

`6
`
`SDN Controller
`
`Flow policy ~ ~ 6//
`database
`
`,--600
`
`620
`
`~r1
`~
`
`packets
`
`6217
`
`Ingress
`Port
`
`>22 '<
`__\
`
`l SENDER J ~
`
`625/
`
`Flowfables~624
`1
`2 i
`~
`60
`i e
`SDN PP
`
`l
`~
`
`Redirect
`Port
`
`62J-2
`
`L
`
`630
`_,.-----'----- I
`.
`security Service
`
`1 Re-Inject
`
`_
`
`I
`
`Port
`
`.J
`Egress
`Port
`
`I ---.____623-J
`packets
`~ NEXT HOP
`
`I ~2.J'-4
`
`SDN Switch
`
`, Packet
`Copies
`1
`I
`
`604
`
`HG. 6
`
`~
`00 .
`
`~
`~
`~
`
`~ = ~
`
`"f'j
`('D
`
`?' ....
`0 ....
`
`~Cl's
`N
`
`Cl's
`
`('D
`('D
`
`r,J =(cid:173)
`.....
`Ul
`0 ....
`
`QO
`
`d r.,;_
`\0
`'N
`0--,
`~
`
`~ = = = "'""'
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 6 of 15
`
`

`

`SDN Controller
`
`Flow policy
`database
`
`v-
`
`~
`
`611
`
`I
`
`Flow:ables I Rules ft-624
`652~ Lookup rule
`'
`
`(6'2J-2
`( 054
`
`,----000
`
`!6'JO
`
`Security Service
`
`620
`
`0217
`
`lf22
`6'2J-I\
`. \
`Outgoing
`I SENDER I packets
`-
`651
`
`I
`
`\
`
`Ingress
`Port
`
`_ Redirect
`Port
`I
`Re-Inject _ (655
`Port
`I
`Egress
`Port
`
`~6'23-3
`Outgoing
`packets
`"'----
`
`~6'23-4
`
`658
`
`6'5J
`
`657\
`
`SDN Switch
`
`DG.7
`
`~
`00 .
`
`~
`~
`~
`
`~ a
`
`"f'j
`('D
`
`?' ....
`0 ....
`
`~Cl's
`N
`
`Cl's
`
`r,J =(cid:173)
`
`('D
`...,._
`('D
`Cl's
`0 .....
`
`QO
`
`d r.,;_
`\0
`N
`0--,
`~
`
`~ = = = "'""'
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 7 of 15
`
`

`

`620
`
`6217
`
`623-1\
`Incoming
`packets
`\
`
`Ingress
`Port
`
`677
`
`5'22\
`
`I SENDER:
`
`,--600
`
`SON Controller
`Flow policy ,,..---- c -6//
`database
`
`I
`
`(623-2
`
`(630
`
`Redirect
`Port
`I
`Re-Inject
`~ Port
`I
`Egress
`Port
`
`/674
`
`(673
`
`Security Service
`
`~623-3
`Incoming
`packets
`\____
`6 71
`
`~ 2 3 -4
`
`Flow+l>es I Rules ft--624
`675
`i
`, /
`676
`
`Lookup rule
`
`1
`
`'
`
`672\
`
`bypass
`
`SON Switch
`
`HG,8
`
`~
`00 .
`
`~
`~
`~
`
`~ = ~
`
`"f'j
`('D
`?'
`.....
`~Cl's
`N
`0 .....
`Cl's
`
`('D
`('D
`
`r,J =(cid:173)
`.....
`-....J
`0 .....
`
`QO
`
`d r.,;_
`\0
`'N
`0--,
`~
`
`~ = = = "'""'
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 8 of 15
`
`

`

`U.S. Patent
`
`Feb.16,2016
`
`Sheet 8 of 8
`
`US 9,264,400 Bl
`
`(
`SET BYPASS FLOW RULES TO BYPASS PACKETS
`THAT DO NOT NEED SECURITY INSPECTION
`
`701
`
`SET REDIRECT FLOW RULE TO FORWARD PACKETS
`FROM INGRESS PORT TO REDIRECT PORT
`
`(702
`
`SET REDIRECT FLOW RULE TO FORWARD PACKETS
`FROM REDIRECT PORT TO INGRESS PORT
`
`(703
`
`I DISABLE BROADCAST TO REDIRECT AND INGRESS PORTS I
`
`(704
`
`'
`
`(705
`
`PERFORM SECURITY INSPECTION OF PACKETS
`REDIRECTED TO SECURITY COMPONENT
`
`I FORWARD PACKETS THAT PASS SECURITY INSPECTION I
`
`(706
`
`(
`I PERFORM SECURITY ACTION ON PACKETS THAT FAIL SECURITY INSPECTION I
`
`707
`
`HG.9
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 9 of 15
`
`

`

`US 9,264,400 Bl
`
`1
`SOFTWARE DEFINED NETWORKING PIPE
`FOR NETWORK TRAFFIC INSPECTION
`
`BACKGROUND OF THE INVENTION
`
`2
`packets to be forwarded to their destination when the outgo(cid:173)
`ing packets pass inspection. The SDN controller may also
`insert a flow rule in the flow table of the SDN switch to bypass
`inspection of specified packets.
`These and other features of the present invention will be
`readily apparent to persons of ordinary skill in the art upon
`reading the entirety of this disclosure, which includes the
`accompanying drawings and claims.
`
`DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 shows a schematic diagram of an SDN computer
`network that is compliant with the OpenFlow™ protocol.
`FIG. 2 shows a schematic diagram of a computer system
`that may be employed with embodiments of the present
`invention.
`FIGS. 3-5 show schematic diagrams of computer networks
`that are capable of intercepting network traffic.
`FIG. 6 shows a schematic diagram of an SDN computer
`network in accordance with an embodiment of the present
`invention.
`FIG. 7 schematically illustrates inspection of outgoing
`packets sent by a sender component in the SDN computer
`network of FIG. 6 in accordance with an embodiment of the
`present invention.
`FIG. 8 schematically illustrates inspection of incoming
`packets to be received by a sender component in the SDN
`computer network of FIG. 6 in accordance with an embodi(cid:173)
`ment of the present invention.
`FIG. 9 shows a flow diagram of a computer-implemented
`method of inspecting network traffic in an SDN computer
`network in accordance with an embodiment of the present
`invention.
`The use of the same reference label in different drawings
`indicates the same or like components.
`
`DETAILED DESCRIPTION
`
`10
`
`1. Field of the Invention
`The present invention relates generally to computer secu(cid:173)
`rity, and more particularly but not exclusively to software
`defined networking.
`2. Description of the Background Art
`Software defined networking (SDN) is an emerging archi(cid:173)
`tecture for computer networking. Unlike traditional computer
`network architectures, SDN separates the control plane from
`the data plane. This provides many advantages, including
`relatively fast experimentation and optimization of switching 15
`and routing policies. SDN is applicable to both physical (i.e.,
`real) and virtual computer networks.
`The OpenFlow™ protocol is an open protocol for remotely
`controlling forwarding tables of network switches that are
`enabled for SDN. Generally speaking, the OpenFlow proto- 20
`col allows direct access to and manipulation of the forwarding
`plane of network devices, such as switches and routers. A
`control plane of an OpenFlow™ protocol-compliant com(cid:173)
`puter network (also referred to as an "OpenFlow™ control(cid:173)
`ler") may communicate with OpenFlow™ switches (i.e., net- 25
`work switches that are compliant with the OpenFlow™
`protocol) to set flow policies that specify how the switches
`should manipulate packets of network traffic. Example
`packet manipulation actions include forwarding a packet to a
`specific port, modifying one or more fields of the packet, 30
`asking the controller for action to perform on the packet, or
`dropping the packet.
`FIG. 1 shows a schematic diagram of an SDN computer
`network that is compliant with the OpenFlow™ protocol.
`Generally speaking, the OpenFlow™ protocol separates the 35
`control plane from the data plane. An OpenFlow™ controller
`serves as a control plane for making forwarding decisions
`based on flow policies, which may be stored in a flow policy
`database. The controller determines flow policies in conjunc(cid:173)
`tion with network forwarding setting and network topology. 40
`The flow policies may contain a condition and corresponding
`action to be performed when the condition is met. The action
`may specify how to manipulate a packet.
`An OpenFlow™ switch serves as the data plane that for(cid:173)
`wards packets, e.g., from an ingress port to an egress port, 45
`according to flow tables maintained by the data plane. The
`data plane is a replacement of traditional switches. When the
`data plane does not know how to manipulate a specific packet,
`the data plane may request the controller to receive a flow rule
`for the specific packet, and store the flow rule in the flow 50
`tables. Other packets that meet the same condition as the
`specific packet will be processed in accordance with the flow
`rule. The control plane may also actively insert flow rules into
`the flow tables.
`
`SUMMARY
`
`In one embodiment, a software defined networking (SDN)
`computer network includes an SDN controller and an SDN
`switch. The SDN controller inserts flow rules in a flow table
`of the SDN switch to create an SDN pipe between a sender
`component and a security component. A broadcast function
`of the SDN switch to the ports that form the SDN pipe may be
`disabled. The SDN pipe allows outgoing packets sent by the
`sender component to be received by the security component.
`The security component inspects the outgoing packets for
`compliance with security policies and allows the outgoing
`
`In the present disclosure, numerous specific details are
`provided, such as examples of apparatus, components, and
`methods, to provide a thorough understanding of embodi(cid:173)
`ments of the invention. Persons of ordinary skill in the art will
`recognize, however, that the invention can be practiced with(cid:173)
`out one or more of the specific details. In other instances,
`well-known details are not shown or described to avoid
`obscuring aspects of the invention.
`FIG. 2 shows a schematic diagram of a computer system
`100 that may be employed with embodiments of the present
`invention. The computer system 100 may be employed as a
`control plane and/or a data plane, for example. As another
`example, the computer system 100 may be employed to host
`a virtualization environment that supports a plurality of vir(cid:173)
`tual machines. The computer system 100 may have fewer or
`more components to meet the needs of a particular applica-
`55 tion. The computer system 100 may include one or more
`processors 101. The computer system 100 may have one or
`more buses 103 coupling its various components. The com(cid:173)
`puter system 100 may include one or more user input devices
`102 (e.g., keyboard, mouse), one or more data storage devices
`60 106 (e.g., hard drive, optical disk, Universal Serial Bus
`memory), a display monitor 104 (e.g., liquid crystal display,
`flat panel monitor), a computer network interface 105 (e.g.,
`network adapter, modem), and a main memory 108 (e.g.,
`random access memory). The computer network interface
`65 105 may be coupled to a computer network 109.
`The computer system 100 is a particular machine as pro(cid:173)
`grammed with software modules 110. The software modules
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 10 of 15
`
`

`

`US 9,264,400 Bl
`
`3
`110 comprise computer-readable program code stored non(cid:173)
`transitory in the main memory 108 for execution by the pro(cid:173)
`cessor 101. The computer system 100 may be configured to
`perform its functions by executing the software modules 110.
`The software modules 110 may be loaded from the data
`storage device 106 to the main memory 108. An article of
`manufacture may be embodied as computer-readable storage
`medium including instructions that when executed by a com(cid:173)
`puter causes the computer to be operable to perform the
`functions of the software modules 110.
`Network security vendors provide network security ser(cid:173)
`vices, such as firewall or deep packet inspection (DPI). Gen(cid:173)
`erally speaking, to provide network security services, packets
`of network traffic are intercepted for inspection. One way of
`intercepting network traffic is to place the security service in
`the middle of the packet forwarding path. This is illustrated in
`FIG. 3, where packets from a sender component (e.g., a
`sender computer) are received in an ingress port of a switch,
`forwarded to an egress port of the switch, and forwarded to
`the ingress port of a security component, such as a security
`service. The security service may inspect the packets, and
`forward the packets to an egress port of the switch toward the
`next hop, which may be another switch or a destination com(cid:173)
`ponent (e.g., destination computer), for example.
`Another way of intercepting network traffic is to mirror the
`packets to be inspected on a switch that provides vendor
`specific mirroring application programming interface (API)
`as shown in FIG. 4. A user may make an API call such that
`particular packets that enter the ingress port of the switch are
`redirected or mirrored to the security service by way of a
`connection tunnel or a mirror port. The security service may
`forward the redirected or mirrored packets back to an egress
`port of the switch after inspection.
`In a virtualized computing environment, network traffic
`from a virtual machine may be intercepted as the network 35
`traffic passes through the hypervisor that runs the virtual
`machines. This is illustrated in FIG. 5, where packets trans(cid:173)
`mitted by virtual machines are intercepted at the virtualiza(cid:173)
`tion hypervisor for redirection to a security service.
`Referring now to FIG. 6, there is shown a schematic dia- 40
`gram of an SDN computer network 600 in accordance with an
`embodiment of the present invention. In one embodiment, the
`SDN computer network 600 is compliant with the Open(cid:173)
`Flow™ protocol. Accordingly, in one embodiment, the SDN
`controller 610 comprises an OpenFlow™ controller and the 45
`SDN switch 620 comprises an OpenFlow™ switch. The SDN
`controller 610 and the SDN switch 620 comprise the control
`plane and data plane, respectively, of the SDN computer
`network 600. The SDN computer network 600 may have a
`plurality of SDN switches 620 but only one is shown for 50
`clarity of illustration. The SDN controller 610 and the SDN
`switch 620 are logically separate components.
`In one embodiment, the SDN computer network 600 is a
`virtual computer network that allows for transmission of
`packets from one virtual machine to another. Accordingly, the 55
`SDN controller 610 may comprise a virtual OpenFlow™
`controller and the SDN switch 620 may comprise a virtual
`OpenFlow™ switch. The SDN computer network 600 may be
`implemented in a computer system comprising one or more
`computers that host a virtualization environment. For 60
`example, the SDN computer network 600 may be imple(cid:173)
`mented in the Amazon Web Services™ virtualization envi(cid:173)
`ronment. The sender component 622 may be a virtual
`machine in that embodiment.
`The SDN computer network 600 may also be implemented 65
`using physical or a combination of physical and virtual com(cid:173)
`ponents. For example, the SDN controller 610 may comprise
`
`4
`one or more computers that serve as a control plane for the
`SDN switch 620. In that embodiment, the SDN switch 620
`may comprise an SDN-compliant physical network switch,
`such as an OpenFlow™ protocol-enabled physical network
`switch. The sender component 622 may be a computer
`coupled to a port of the physical network switch.
`The SDN controller 610 provides a logically centralized
`framework for controlling the behavior of the SDN computer
`10 network 600. This is in marked contrast to traditional com-
`puter networks where the behavior of the computer network is
`controlled by low-level device configurations of switches and
`other network devices. The SDN controller 610 may include
`15 a flow policy database 611. The flow policy database 611 may
`comprise flow policies that are enforced by the controller 610
`on network traffic transmitted over the SDN computer net(cid:173)
`work 600. The flow policies may specify security policies that
`20 govern transmission of packets over the SDN computer net-
`work 600. The flow policies may be enforced in terms of flow
`rules (labeled as 624) that are stored in the flow tables 621 of
`the SDN switch 620. As a particular example, a flow policy in
`25 the flow policy database 611 may indicate inspection of par-
`ticular packets ( e.g., those that meet one or more conditions)
`by a security service 630. That flow policy may be imple-
`mented as a flow rule that forwards the particular packets
`30 received in an ingress port 623-1 to the redirect port 623-2 for
`inspection, for example.
`
`The SDN switch 620 may comprise a plurality of ports 623
`(i.e., 623-1, 623-2, 623-3, 623-4, etc.). The SDN switch 620
`may forward packets from one port 623 to another port 623 in
`accordance with flow rules in the flow tables 621. In the
`example of FIG. 6, the port 6231-1 is coupled to a sender
`component 622. The port 623-1 is referred to as an "ingress
`port" in that it is a port for receiving outgoing packets sent by
`the sender component 622. Similarly, the port 623-4 is
`referred to as an "egress port" in that it is a port for transmit(cid:173)
`ting outgoing packets sent by the sender component 622. It is
`to be noted that any port 623 may be employed as an "ingress
`port," "egress port," "redirect port," or "re-inject port." The
`aforementioned labels are used herein merely to illustrate
`processing of packets relative to the sender component 622.
`Packets going in the opposite direction, i.e., incoming packets
`that are going to the sender component 622, may be received
`in the egress port 623-4, forwarded to the re-inject port 623-3,
`received in the redirect port 623-2, and forwarded to the
`ingress port 623-1 toward the sender component 622.
`The SDN switch 620 may comprise one or more flow tables
`621. The flow tables 621 may comprise one or more flow rules
`(labeled as 624) that indicate how to manipulate or process
`packets that are passing through the SDN switch 620. As a
`particular example, a flow rule may indicate that a packet
`received in the ingress port 623-1 is to be forwarded to the
`redirect port 623-2. Another flow rule may indicate that a
`packet received in the redirect port 623-2 is to be forwarded to
`the ingress port 623-1. The just mentioned pair of flow rules
`are redirect flow rules that create an SDN pipe between the
`sender component 622 and the security service 630, allowing
`the security service 630 to inspect packets sent by or going to
`the sender component 622. Table 1 shows an example flow
`table with flow rules that create an SDN pipe between the
`security service 630 and the sender component 622.
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 11 of 15
`
`

`

`US 9,264,400 Bl
`
`5
`TABLE 1
`
`IN_PORT
`
`Ingress_port_ID
`Redirect_port_ID
`
`MAC
`src
`
`MAC
`dst
`
`IP
`IP
`src dst ... Action
`
`Count
`
`* Redirect port
`* Ingress port
`
`10
`10
`
`A flow table may include colunms that indicate one or more
`conditions, a column that indicates an action to take when the
`conditions are met, and a colunm for statistics. A row on the
`flow table may comprise a flow rule. In the example of Table
`1, the "Action" colunm indicates an action to take when
`conditions are met, and the "Count" colunm indicates statis(cid:173)
`tics, such as byte count. The rest of the colunms of Table 1
`indicate conditions. For example, "IN_PORT', "MAC src"
`(media access control (MAC) address of the source of the
`packet), "MAC dst" (MAC address of the destination of the
`packet), "IP src" (Internet Protocol (IP) address of the source
`of the packet), "IP dst" (IP address of the destination of the
`packet), etc. are conditions that identify a particular packet.
`When the conditions are met, i.e., the particular packet is
`identified, the action indicated in the corresponding "Action"
`colunm is performed on the packet. The asterisks in Table 1
`indicate an irrelevant condition.
`In the example of Table 1, the first and second rows are
`redirect flow rules for forming an SDN pipe between the
`sender component 622 and the security service 630. More
`specifically, the first row of Table 1 is a flow rule instructing
`the SDN switch 620 to forward packets received in a port
`having the Ingress_port_ID (e.g., ingress port 623-1) to the
`redirect port ( e.g., redirect port 623-2). Similarly, the second
`row of Table 1 is a flow rule instructing the SDN switch 620
`to forward packets received in a port having a "Redirect_
`port_ID" to the ingress port.
`The SDN computer network 600 may include a security
`component in the form of the security service 630. The secu(cid:173)
`rity service 63 0 may comprise a virtual machine that provides
`computer network security services, such as packet inspec- 40
`tion, for the sender component 622 and other virtual
`machines. For example, the security service 630 may com(cid:173)
`prise a virtual machine with a virtual network interface card
`that is coupled to the redirect port 623-2 and re-inject port
`623-3 of the SDN switch 620. The security service 630 may
`inspect packets for compliance/non-compliance with secu(cid:173)
`rity policies, such as for presence of malicious code, compli(cid:173)
`ance with firewall rules and access control lists, network
`intrusion detection, and other computer network security ser(cid:173)
`vices. The security service 630 may employ conventional
`packet inspection algorithms. The security service 630 may
`comprise the Trend Micro Deep Security™ service, for
`example. The security service 630 may also comprise a physi-
`cal machine, e.g., a server computer, an appliance, a gateway
`computer, etc.
`The security service 630 may be connected to the SDN
`switch 620 by a physical link (i.e., using a wire), a virtual link
`(i.e., in a virtualized environment), or by a software tunnel. As
`a particular example, instead of using a physical link or a
`virtual link, the security service 630 may be connected to the
`SDN switch 620 by a software tunnel using generic routing
`encapsulation (GRE), stateless transport tunneling (STT), or
`some other software tunneling protocol supported by the
`SDN switch 620. In that example, the security service 630
`serves as a remote (i.e., not in the same physical or virtual
`network) service that is only logically connected the SDN
`switch 620 by way of the software tunnel.
`
`5
`
`6
`The SDN controller 610 may insert flow rules in the flow
`tables 621 (see arrow 601) to create an SDN pipe (labeled as
`625) between the sender component 622 and the security
`service 630. The SDN pipe allows outgoing packets sent by
`the sender component 622 or incoming packets going to the
`sender component 622 to be redirected to the security service
`630 for inspection before the packets are sent out of the SDN
`switch 620. In one embodiment, the SDN pipe is created by
`creating a first flow rule that forwards packets received in the
`10 ingress port 623-1 to the redirect port 623-2, and a second
`flow rule that forwards packets received in the redirect port
`623-2 to the ingress port 623-1.
`Once outgoing packets from the sender component 622 are
`inspected by the security service 630 and re-injected by the
`15 security service 630 back into the SDN switch 620 through
`the re-inject port 623-3 and then forwarded out to the egress
`port 623-4, the L2 switching logic of the SDN computer
`network 600 (which is controlled by the SDN controller 610)
`remembers that packets destined for the sender component
`20 622 and entering the SDN switch 620 by way of the egress
`port 623-4 are to be forwarded to the re-inject port 623-3. This
`allows the security service 630 to also receive incoming pack(cid:173)
`ets going to the sender component 622 for inspection.
`In one embodiment, the creation of the SDN pipe also
`25 includes disabling the broadcast function of the SDN switch
`620 to the ingress port 623-1 and the redirect port 623-2. That
`is, packets that are broadcast to all ports of the SDN switch
`620 will not be sent to the ports that form the SDN pipe.
`Instead, packets that are broadcasted by the SDN switch 620
`30 are received by the security service 630 only through the
`re-inject port 623-3, and forwarded by the security service
`630 to the sender component 622 by way of the SDN pipe
`between the ingress port 623-1 and the redirect port 623-2.
`The sender component 622 receives broadcast packets only
`35 from the security service 630 in that embodiment. In one
`embodiment, the SDN controller 610 disables the broadcast
`function to the ports forming the SDN pipe using the Open
`vSwitch™ database (OVSDB) management protocol, which
`is an OpenFlow™ configuration protocol.
`After the redirect flow rules for creating the SDN pipe are
`inserted in the flow tables 621, any packet received by the
`SDN switch 620 in the ingress port 623-1 will be identified as
`to be forwarded to the redirect port 623-2, and any packet
`received by the SDN switch 620 in the redirect port 623-2 will
`45 be identified as to be forwarded to the ingress port 623-1 (see
`arrow 602). This allows the security service 630 to receive
`from the redirect port 623-2 all outgoing packets sent by the
`sender component 622 to the ingress port 623-1. The security
`service 630 may inspect the outgoing packets for compliance
`50 with security policies. The security service 630 may drop, or
`perform other security response, to packets that do not pass
`inspection ( e.g., packets that do not meet firewall policies,
`packets containing prohibited payload, packets with mali(cid:173)
`cious content, etc.). The security service 630 may forward
`55 those packets that pass inspection toward their destination by
`re-injecting the packets back into the SDN switch 620 by way
`of the re-inject port 623-3. Once back in the SDN switch 620
`by way of the re-inject port 623-3, the flow rules that govern
`packets received in the ingress port 623-1 and the redirect port
`60 623-2 no longer apply. Accordingly, the re-injected packets
`are forwarded to the egress port 623-4 (or some other port)
`toward the next hop in accordance with the L2 switching logic
`of the SDN computer network 600.
`Incoming packets to the sender component 622 that enter
`65 the SDN switch 620 on the egress port 623-4 are forwarded to
`the re-inject port 623-3 in accordance with the L2 switching
`logic of the SDN computer network 600. The security service
`
`Exhibit 1005
`Cisco v. Orckit – IPR2023-00554
`Page 12 of 15
`
`

`

`US 9,264,400 Bl
`
`8
`TABLE3
`
`IP TCP src TCP dst
`port
`port
`src
`
`80
`
`80
`
`... Action
`
`Count
`
`* Redirect port
`* Ingress port
`* Egress port
`* Ingress port
`
`10
`10
`130
`130
`
`IN_PORT
`
`Ingress_port_ID
`Redirect_port_ID
`Ingress_port_ID
`Egress_port_ID
`
`7
`630 receives the incoming packets from the re-inject port
`623-3, inspects the incoming packets, and transmits those
`incoming packets that pass inspection to the redirect port
`623-2. The incoming packets are forwarded from the redirect
`port 623-2 to the ingress port 623-1 in accordance with the
`flow rules that form the SDN pipe. The sender component 622
`is connected to the ingress port 623-1, and receives the incom(cid:173)
`ing packets therefrom.
`Re-injecting packets that pass inspection consume band- 10
`width, as the packets will have to be transmitted by the secu(cid:173)
`rity service 630 to the re-inject port 623-3. For optimization,
`the SDN switch 620 may be configured to copy packets that
`are redirected to the security service 630 for inspection. This
`way, the security service 630 simply has to inform the SDN 15
`switch 620 an action to take on packets based on the result of
`the inspection (see arrow 604). For example, the security
`service 630 may send an index identifying the packets and an
`action on how to manipulate the packets. The action may
`instruct the SDN switch 620 to drop the copied packets, 20
`forward the copied packets to their destinations, quarantine
`the copied packets, etc.
`In one embodiment, bypass flow rules are inserted in the
`flow tables 621 such that particular packets that do not need to
`be inspected are not redirected to the security service 630.
`This embodiment is explained with reference to example flow
`tables of Tables 2 and 3.
`
`In the exampleofTable3, the top two rows are redirect flow
`rules for redirecting HTTP packets to the security service 630
`for inspection, while the bottom two rows are bypass flow
`rules for all packets. Because