DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 02/26/2026 have been fully considered.
Applicant argues that the amendments to the claim 19 overcome the claim objection. In response to the argument, Examiner respectfully agrees. The claim objection is withdrawn.
Applicant argues that the amendments to the claims overcome the 112(b) rejections. In response to the argument, Examiner respectfully agrees in-part. Claim 16 still has an outstanding 112(b), please see below for details.
Applicant argues that the prior art does not teach “sending, by a first network element device having a route reflection function, … wherein the BGP connection is used to perform route reflection and a remote attestation process.
In response to the argument, Examiner respectfully disagrees. Filfils teaches on most of limitations of the independent claims. Filfils teaches on utilizing route reflection but, however, is silent that the network element device has a route reflection function. Ward is brought in to teach on a network element device having a route reflection function. Filfils (as modified by Ward) teaches on the limitations as recited.
Filfils teaches sending, by a first network element device apply attestation 160 to signaling messages 150 that are transmitted to other BGP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured). [0034] Fig 4, method 400 may be performed by any apparatus of a BGP network such as network element 120. Method 400 may begin at step 410 where an attestation token for the apparatus is received or otherwise accessed. [0035] At step 420, method 400 encodes the attestation token accessed in step 410 in a BGP signaling message. [0036] At step 430, method 400 sends the BGP signaling message with the encoded attestation token to second apparatus of the BGP network.)
Filsfils teaches on attestation, BGP route updates and trusted node reflection ([0015]-[0017], [0040]). However, Filsfils does not explicitly teach on a first network element device having a route reflection function.
Ward teaches on a first network element device having a route reflection function. See Ward, [0072] A route reflector is a network element used in a BGP network to implement route reflection. In a BGP route reflection deployment, one or more routers are designated as route reflectors and are allowed to accept and propagate iBGP routes to their clients. [0085] The route reflector 108 transmits a request to each router 112-116 of the AS 102 to obtain the integrity data for each of these routers 112-116, which can be used to determine their trustworthiness. The response may include a hash of the integrity data and the nonce, which the route reflector 108 can use to determine the trustworthiness of the corresponding router.
It would have been obvious to modify Filsfils per Ward as this would allow the modified system to ensure trust worthiness by utilizing a designated route reflector as a third party integrity check.
Please see updated rejection below in view of:
Claim(s) 1-6, 8-16, 18-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0322310 Al (Filsfils) in view of US 2021/0306256 Al (Ward).
Claim(s) 7, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0322310 Al (Filsfils) in view of US 2021/0306256 Al (Ward) further in view of US 20160315921 A1 (Dara).
Claim Rejections - 35 USC § 112
112(b):
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim(s) 16-18 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 16 recites the limitation "the BGP connection" in line 8. This renders the claim unclear as there is insufficient antecedent basis for this limitation in the claim. Previous limitations do not recite "a BGP connection".
All dependents are also rejected as having the same deficiencies as the claims from which they depend.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-6, 8-16, 18-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0322310 Al (Filsfils) in view of US 2021/0306256 Al (Ward).
Regarding Claim 1:
Filsfils teaches A remote attestation method, comprising:
sending, by a first network element device (ie. network element 120) (ie. second apparatus) through the BGP connection, wherein the BGP connection is used to perform route reflection and a remote attestation process, ([0034] Fig 4, method 400 may be performed by any apparatus of a BGP network such as network element 120. Method 400 may begin at step 410 where an attestation token for the apparatus is received or otherwise accessed. [0035] At step 420, method 400 encodes the attestation token accessed in step 410 in a BGP signaling message. [0036] At step 430, method 400 sends the BGP signaling message with the encoded attestation token to second apparatus of the BGP network.)
wherein the first BGP packet is used to query measurement information of the second network element device, ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BGP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured).) [0025]-[0028] attestation queries/TPM queries: The token may allow the replay attacks to be detected without a nonce and make it possible for the attestation for asynchronous push, multicast, broadcast, etc. The token or signed measurement may be referred as a canary stamp since a token or signed measurement may provide authenticity like a stamp and may be used as an indicator of an early sign of trouble.)
and wherein the BGP connection for the route reflection is established between the first network element device and the second network element device; ([0016] Figs 2A-D, BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. … BGP keepalive message 150d, BGP update message 150b, and BGP notification message 150c can be exchanged only after BGP open message 150a has been confirmed and the BGP connection had been established [0040] trusted reflection.)
receiving, by the first network element device through the BGP connection, a second BGP packet sent by the second network element device, and parsing the second BGP packet to obtain the measurement information carried in the second BGP packet; ([0011] The attestation is applied to a BGP keepalive message by appending the canary stamp to the end of a typical BGP keepalive message. The attestation is applied to a BGP update message by appending the canary stamp to a new attribute of a BGP update message. In both cases, the canary stamps may be transmitted to other network entities where they may be analyzed in order to determine whether the attesting node has been compromised.)
and comparing, by the first network element device, the measurement information (ie. attestation token) and a remote attestation baseline file (ie. policy), to obtain a remote attestation result (ie. trust level). ([0022] The first network node may determine that the attestation token is valid for the second network node at a current time. The first network node may compute a trust level for the second network node based at least on the received attestation token 160. The trust level for the second network node may be used by the network nodes in the network to compute a routing table of the network. [0032] In particular embodiments, a network element 120 may be configured to validate attestation 160 received from other network elements 120. The receiving network element 120 may be further configured to take action based on the status of the validation according to a specified policy provided to the network node. As an example, network element 120/ may validate a canary stamp received in a BGP signaling message 150 from a neighboring network element 120a.)
Filsfils teaches on attestation, BGP route updates and trusted node reflection ([0015]-[0017], [0040]). However, Filsfils does not explicitly teach on a first network element device having a route reflection function.
Ward teaches, in the same field of endeavor, on a verifier peer system which transmits a request to an application of another peer system to obtain integrity data of the application, Abstract.
Ward also teaches on a first network element device having a route reflection function. ([0072] A route reflector is a network element used in a BGP network to implement route reflection. In a BGP route reflection deployment, one or more routers are designated as route reflectors and are allowed to accept and propagate iBGP routes to their clients. [0085] The route reflector 108 transmits a request to each router 112-116 of the AS 102 to obtain the integrity data for each of these routers 112-116, which can be used to determine their trustworthiness. The response may include a hash of the integrity data and the nonce, which the route reflector 108 can use to determine the trustworthiness of the corresponding router.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include a first network element device having a route reflection function. This would have been advantageous as discussed above, as this would allow the modified system to ensure trust worthiness by utilizing a designated route reflector as a third party integrity check.
Regarding Claim 2:
Filsfils (as modified by Ward) teaches the invention of claim 1 as described.
Filsfils teaches wherein the first BGP packet comprises a first type-length-value (TLV) field, and the first TLV field indicates to query the measurement information. ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured). [0039] In some embodiments, a new BGP trust attribute may be defined in order to apply attestation to BGP. In general, BGP update messages 150b carry path attributes followed by a list prefixes sharing those attributes. A new BGP attribute may be defined in order to carry canary stamps. The type code may be assigned by IANA and the value is a set of Type-Length-Value (LV) triplets.)
Regarding Claim 3:
Filsfils (as modified by Ward) teaches the invention of claim 2 as described.
Filsfils teaches wherein the first BGP packet is a first update packet, the first update packet comprises comprising a first path attribute field, and the first TLV field is located in the first path attribute field. ([0020] FIGS. 3A and 3B illustrate novel BGP signaling messages 150 that may be used to apply attestation to BGP. Fig 3A, update message with attestation: field 2 “unfeasible routes”, variable field “withdrawn routes”. [0039] In a first example, a router ID type for trusted peering may include a value that is the router ID of the speaker followed by attestation 160. In this example, a first router and a second router attest and validate the trustworthiness of updates by attaching canary stamps in all updates in the router ID TLV of the BGP trust attribute.)
Regarding Claim 4:
Filsfils (as modified by Ward) teaches the invention of claim 1 as described.
Filsfils teaches wherein the second BGP packet comprises a second TLV field, and the second TLV field is used to carry the measurement information. ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured). [0039] In some embodiments, a new BGP trust attribute may be defined in order to apply attestation to BGP. In general, BGP update messages 150b carry path attributes followed by a list prefixes sharing those attributes. A new BGP attribute may be defined in order to carry canary stamps. The type code may be assigned by IANA and the value is a set of Type-Length-Value (LV) triplets.)
Regarding Claim 5:
Filsfils (as modified by Ward) teaches the invention of claim 4 as described.
Filsfils teaches wherein the second BGP packet is a second update packet, the second update packet comprises comprising a second path attribute field, and the second TLV field is located in the second path attribute field. ([0020] FIGS. 3A and 3B illustrate novel BGP signaling messages 150 that may be used to apply attestation to BGP. Fig 3A, update message with attestation: field 2 “unfeasible routes”, variable field “withdrawn routes”. [0039] In a first example, a router ID type for trusted peering may include a value that is the router ID of the speaker followed by attestation 160. In this example, a first router and a second router attest and validate the trustworthiness of updates by attaching canary stamps in all updates in the router ID TLV of the BGP trust attribute.)
Regarding Claim 8:
Filsfils (as modified by Ward) teaches the invention of claim 1 as described.
Filsfils teaches on a next hop type field in the update message ([0039]). However, Filsfils is silent on wherein before the sending the first BGP packet to the second network element device through the BGP connection, the method further comprises: sending, by the first network element device, a fifth BGP packet to the second network element device through the BGP connection, wherein the fifth BGP packet is used to negotiate an address family extension capability with the second network element device; and receiving, by the first network element device through the BGP connection, a sixth BGP packet sent by the second network element device, and determining, based on the sixth BGP packet, that the second network element device has the address family extension capability, so that the second network element device supports the remote attestation function.
Ward teaches wherein before the sending the first BGP packet to the second network element device through the BGP connection, the method further comprises: sending, by the first network element device, a fifth BGP packet to the second network element device through the BGP connection, wherein the fifth BGP packet is used to negotiate an address family extension capability with the second network element device; ([0069] A BGP session can be established when BGP neighbor routers establish a network connection in order to communicate in accordance with the protocol. This connection is typically established using a connection-oriented protocol such as TCP, which ensures delivery of messages between the connected neighbor routers. The connected neighbor routers can communicate using BGP to exchange update messages that include routing information. [0070] An AS can use iBGP to advertise reachability information for network address prefixes of destinations ( e.g., routers) outside the AS.)
and receiving, by the first network element device through the BGP connection, a sixth BGP packet sent by the second network element device, and determining, based on the sixth BGP packet, that the second network element device has the address family extension capability, so that the second network element device supports the remote attestation function. ([0069] Update messages are used to update information included in a routing information base (RIB) or the receiving neighbor router. An update message can announce a new route or withdraw a previously advertised route. Update messages can include various fields such as network layer reachability information (NLRI). NLRI may include IP address prefixes of feasible routes being advertised in the update message. A path can be defined by one or more attributes and is generally intended to be defined as the route between two points in a network, such as an AS. The network section identifies a set of destinations and is referred to as the prefix. A prefix in a destination address is used by a routing protocol to render a routing decision for the next hop in the path.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include wherein before the sending the first BGP packet to the second network element device through the BGP connection, the method further comprises: sending, by the first network element device, a fifth BGP packet to the second network element device through the BGP connection, wherein the fifth BGP packet is used to negotiate an address family extension capability with the second network element device; and receiving, by the first network element device through the BGP connection, a sixth BGP packet sent by the second network element device, and determining, based on the sixth BGP packet, that the second network element device has the address family extension capability, so that the second network element device supports the remote attestation function. This would have been advantageous as discussed above, as this would allow the modified system to provide further assurance of security with routing by verification of address family.
Regarding Claim 6:
Filsfils (as modified by Ward) teaches the invention of claim 8 as described.
Filsfils teaches on a next hop type field in the update message ([0039]). However, Filsfils is silent on wherein that the second network element device supports the remote attestation function comprises: the second network element device has the address family extension capability.
Ward teaches wherein that the second network element device supports the remote attestation function comprises: the second network element device has the address family extension capability. ([0069] Update messages are used to update information included in a routing information base (RIB) or the receiving neighbor router. An update message can announce a new route or withdraw a previously advertised route. Update messages can include various fields such as network layer reachability information (NLRI). NLRI may include IP address prefixes of feasible routes being advertised in the update message. A path can be defined by one or more attributes and is generally intended to be defined as the route between two points in a network, such as an AS. The network section identifies a set of destinations and is referred to as the prefix. A prefix in a destination address is used by a routing protocol to render a routing decision for the next hop in the path.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include wherein that the second network element device supports the remote attestation function comprises: the second network element device has the address family extension capability. This would have been advantageous as discussed above, as this would allow the modified system to provide further assurance of security with routing by verification of address family.
Regarding Claim 9:
Filsfils teaches A remote attestation method, comprising:
receiving, by a second network element device (ie. second apparatus) through a border gateway protocol (BGP) connection, a first BGP packet sent by a first network element device, wherein the BGP connection is used to perform route reflection and a remote attestation process, ([0034] Fig 4, method 400 may be performed by any apparatus of a BGP network such as network element 120. Method 400 may begin at step 410 where an attestation token for the apparatus is received or otherwise accessed. [0035] At step 420, method 400 encodes the attestation token accessed in step 410 in a BGP signaling message. [0036] At step 430, method 400 sends the BGP signaling message with the encoded attestation token to second apparatus of the BGP network.)
wherein the first BGP packet is used to query measurement information of the second network element device, ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured).) [0025]-[0028] attestation queries/TPM queries: The token may allow the replay attacks to be detected without a nonce and make it possible for the attestation for asynchronous push, multicast, broadcast, etc. The token or signed measurement may be referred as a canary stamp since a token or signed measurement may provide authenticity like a stamp and may be used as an indicator of an early sign of trouble.)
wherein the BGP connection for the route reflection is established between the second network element device and the first network element device, ([0016] Figs 2A-D, BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. … BGP keepalive message 150d, BGP update message 150b, and BGP notification message 150c can be exchanged only after BGP open message 150a has been confirmed and the BGP connection had been established [0040] trusted reflection.)
and sending, by the second network element device, a second BGP packet to the first network element device through the BGP connection, wherein the second BGP packet carries the measurement information, so that the first network element device obtains a remote attestation result corresponding to the second network element device. ([0011] The attestation is applied to a BGP keepalive message by appending the canary stamp to the end of a typical BGP keepalive message. The attestation is applied to a BGP update message by appending the canary stamp to a new attribute of a BGP update message. In both cases, the canary stamps may be transmitted to other network entities where they may be analyzed in order to determine whether the attesting node has been compromised.)
Filsfils teaches on attestation, BGP route updates and trusted node reflection ([0015]-[0017], [0040]). However, Filsfils does not explicitly teach on the first network element device having a route reflection function.
Ward teaches on the first network element device having a route reflection function. ([0072] A route reflector is a network element used in a BGP network to implement route reflection. In a BGP route reflection deployment, one or more routers are designated as route reflectors and are allowed to accept and propagate iBGP routes to their clients. [0085] The route reflector 108 transmits a request to each router 112-116 of the AS 102 to obtain the integrity data for each of these routers 112-116, which can be used to determine their trustworthiness. The response may include a hash of the integrity data and the nonce, which the route reflector 108 can use to determine the trustworthiness of the corresponding router.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include the first network element device having a route reflection function. This would have been advantageous as discussed above, as this would allow the modified system to ensure trust worthiness by utilizing a designated route reflector as a third party integrity check.
Regarding Claim 10:
Filsfils (as modified by Ward) teaches the invention of claim 9 as described.
Filsfils teaches wherein the first BGP packet comprises a first type-length-value (TLV) field, and the first TLV field indicates to query the measurement information. ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured). [0039] In some embodiments, a new BGP trust attribute may be defined in order to apply attestation to BGP. In general, BGP update messages 150b carry path attributes followed by a list prefixes sharing those attributes. A new BGP attribute may be defined in order to carry canary stamps. The type code may be assigned by IANA and the value is a set of Type-Length-Value (LV) triplets.)
Regarding Claim 11:
Filsfils (as modified by Ward) teaches the invention of claim 10 as described.
Filsfils teaches wherein the first BGP packet is a first update packet, the first update packet comprises comprising a first path attribute field, and the first TLV field is located in the first path attribute field. ([0020] FIGS. 3A and 3B illustrate novel BGP signaling messages 150 that may be used to apply attestation to BGP. Fig 3A, update message with attestation: field 2 “unfeasible routes”, variable field “withdrawn routes”. [0039] In a first example, a router ID type for trusted peering may include a value that is the router ID of the speaker followed by attestation 160. In this example, a first router and a second router attest and validate the trustworthiness of updates by attaching canary stamps in all updates in the router ID TLV of the BGP trust attribute.)
Regarding Claim 12:
Filsfils (as modified by Ward) teaches the invention of claim 9 as described.
Filsfils teaches wherein the second BGP packet comprises a second TLV field used to carry the measurement information. ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured). [0039] In some embodiments, a new BGP trust attribute may be defined in order to apply attestation to BGP. In general, BGP update messages 150b carry path attributes followed by a list prefixes sharing those attributes. A new BGP attribute may be defined in order to carry canary stamps. The type code may be assigned by IANA and the value is a set of Type-Length-Value (LV) triplets.)
Regarding Claim 13:
Filsfils (as modified by Ward) teaches the invention of claim 12 as described.
Filsfils teaches wherein the second BGP packet is a second update packet, the second update packet comprises comprising a second path attribute field, and the second TLV field is located in the second path attribute field. ([0020] FIGS. 3A and 3B illustrate novel BGP signaling messages 150 that may be used to apply attestation to BGP. Fig 3A, update message with attestation: field 2 “unfeasible routes”, variable field “withdrawn routes”. [0039] In a first example, a router ID type for trusted peering may include a value that is the router ID of the speaker followed by attestation 160. In this example, a first router and a second router attest and validate the trustworthiness of updates by attaching canary stamps in all updates in the router ID TLV of the BGP trust attribute.)
Regarding Claim 14:
Filsfils (as modified by Ward) teaches the invention of claim 9 as described.
Filsfils teaches wherein before the receiving the first BGP packet sent by the first network element device, the method further comprises: receiving, by the second network element device through the BGP connection, a third BGP packet sent by the first network element device, wherein the third BGP packet indicates to query a version information corresponding to the second network element device; ([0016] BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. If BGP open message 150a is acceptable to a network element 120, a BGP keepalive message 150d is sent to confirm the BGP open message 150a.)
and sending, by the second network element device, a fourth BGP packet to the first network element device through the BGP connection, wherein the fourth BGP packet carries the version information corresponding to the second network element device. (FIG. 2A, BGP open message 150a includes the following fields: a marker field (16 octets), a length field (2 octets), a type field (1 octet), a version field (1 octet), an AS field (2 octets), a hold time field (2 octets), a BGP ID field ( 4 octets), an optional length field ( octet), and an optional field (7 octets).)
Regarding Claim 15:
Filsfils (as modified by Ward) teaches the invention of claim 9 as described.
Filsfils teaches on a next hop type field in the update message ([0039]). However, Filsfils is silent on wherein before the receiving the first BGP packet sent by the first network element device, the method further comprises: receiving, by the second network element device through the BGP connection, a fifth BGP packet sent by the first network element device, wherein the fifth BGP packet is used to negotiate an address family extension capability with the first network element device; and generating, by the second network element device, a sixth BGP packet based on the address family extension capability of the second network element device, and sending the sixth BGP packet to the first network element device through the BGP connection.
Ward teaches receiving, by the second network element device through the BGP connection, a fifth BGP packet sent by the first network element device, wherein the fifth BGP packet is used to negotiate an address family extension capability with the first network element device; ([0069] A BGP session can be established when BGP neighbor routers establish a network connection in order to communicate in accordance with the protocol. This connection is typically established using a connection-oriented protocol such as TCP, which ensures delivery of messages between the connected neighbor routers. The connected neighbor routers can communicate using BGP to exchange update messages that include routing information. [0070] An AS can use iBGP to advertise reachability information for network address prefixes of destinations ( e.g., routers) outside the AS.)
and generating, by the second network element device, a sixth BGP packet based on the address family extension capability of the second network element device, and sending the sixth BGP packet to the first network element device through the BGP connection. ([0069] Update messages are used to update information included in a routing information base (RIB) or the receiving neighbor router. An update message can announce a new route or withdraw a previously advertised route. Update messages can include various fields such as network layer reachability information (NLRI). NLRI may include IP address prefixes of feasible routes being advertised in the update message. A path can be defined by one or more attributes and is generally intended to be defined as the route between two points in a network, such as an AS. The network section identifies a set of destinations and is referred to as the prefix. A prefix in a destination address is used by a routing protocol to render a routing decision for the next hop in the path.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include wherein before the receiving the first BGP packet sent by the first network element device, the method further comprises: receiving, by the second network element device through the BGP connection, a fifth BGP packet sent by the first network element device, wherein the fifth BGP packet is used to negotiate an address family extension capability with the first network element device; and generating, by the second network element device, a sixth BGP packet based on the address family extension capability of the second network element device, and sending the sixth BGP packet to the first network element device through the BGP connection. This would have been advantageous as discussed above, as this would allow the modified system to provide further assurance of security with routing by verification of address family.
Regarding Claim 16:
Filsfils teaches A remote attestation device (ie. processor/memory of the network element) used in a first network element device (ie. network element 120) ([0045] Fig 5, computer system 500 includes a processor 502, memory 504, storage 506, an input/output (I/O) interface 508, a communication interface 510, and a bus 512.) and the memory to store instructions ([0046] Fig 5, to execute instructions, processor 502 may retrieve ( or fetch) the instructions from an internal register, an internal cache, memory 504, or storage 506;), which when executed by the processor, cause the remote attestation device to:
send a first border gateway protocol (BGP) packet to a second network element device (ie. second apparatus) through the BGP connection, wherein the BGP connection is used to perform route reflection and a remote attestation process, ([0034] Fig 4, method 400 may be performed by any apparatus of a BGP network such as network element 120. Method 400 may begin at step 410 where an attestation token for the apparatus is received or otherwise accessed. [0035] At step 420, method 400 encodes the attestation token accessed in step 410 in a BGP signaling message. [0036] At step 430, method 400 sends the BGP signaling message with the encoded attestation token to second apparatus of the BGP network.)
wherein the first BGP packet is used to query measurement information of the second network element device ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured).) [0025]-[0028] attestation queries/TPM queries: The token may allow the replay attacks to be detected without a nonce and make it possible for the attestation for asynchronous push, multicast, broadcast, etc. The token or signed measurement may be referred as a canary stamp since a token or signed measurement may provide authenticity like a stamp and may be used as an indicator of an early sign of trouble.)
and wherein a BGP connection for the route reflection is established between the first network element device and the second network element device; ([0016] Figs 2A-D, BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. … BGP keepalive message 150d, BGP update message 150b, and BGP notification message 150c can be exchanged only after BGP open message 150a has been confirmed and the BGP connection had been established [0040] trusted reflection.)
receive, through the BGP connection, a second BGP packet sent by the second network element device, and parse the second BGP packet to obtain the measurement information carried in the second BGP packet; ([0011] The attestation is applied to a BGP keepalive message by appending the canary stamp to the end of a typical BGP keepalive message. The attestation is applied to a BGP update message by appending the canary stamp to a new attribute of a BGP update message. In both cases, the canary stamps may be transmitted to other network entities where they may be analyzed in order to determine whether the attesting node has been compromised.)
and compare the measurement information (ie. attestation token) and a remote attestation baseline file (ie. policy), to obtain a remote attestation result (ie. trust level). ([0022] The first network node may determine that the attestation token is valid for the second network node at a current time. The first network node may compute a trust level for the second network node based at least on the received attestation token 160. The trust level for the second network node may be used by the network nodes in the network to compute a routing table of the network. [0032] In particular embodiments, a network element 120 may be configured to validate attestation 160 received from other network elements 120. The receiving network element 120 may be further configured to take action based on the status of the validation according to a specified policy provided to the network node. As an example, network element 120/ may validate a canary stamp received in a BGP signaling message 150 from a neighboring network element 120a.)
Filsfils teaches on attestation, BGP route updates and trusted node reflection ([0015]-[0017], [0040]). However, Filsfils does not explicitly teach on a first network element device having a route reflection function.
Ward teaches on a first network element device having a route reflection function. ([0072] A route reflector is a network element used in a BGP network to implement route reflection. In a BGP route reflection deployment, one or more routers are designated as route reflectors and are allowed to accept and propagate iBGP routes to their clients. [0085] The route reflector 108 transmits a request to each router 112-116 of the AS 102 to obtain the integrity data for each of these routers 112-116, which can be used to determine their trustworthiness. The response may include a hash of the integrity data and the nonce, which the route reflector 108 can use to determine the trustworthiness of the corresponding router.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include a first network element device having a route reflection function. This would have been advantageous as discussed above, as this would allow the modified system to ensure trust worthiness by utilizing a designated route reflector as a third party integrity check.
Regarding Claim 18:
Filsfils (as modified by Ward) teaches the invention of claim 16 as described.
Filsfils teaches on a next hop type field in the update message ([0039]). However, Filsfils is silent on send a fifth BGP packet to the second network element device through the BGP connection, wherein the fifth BGP packet is used to negotiate an address family extension capability with the second network element device; receive, through the BGP connection, a sixth BGP packet sent by the second network element device; and determine, based on the sixth BGP packet, that the second network element device has the address family extension capability, so that the second network element device supports a remote attestation function.
Ward teaches send a fifth BGP packet to the second network element device through the BGP connection, wherein the fifth BGP packet is used to negotiate an address family extension capability with the second network element device; ([0069] A BGP session can be established when BGP neighbor routers establish a network connection in order to communicate in accordance with the protocol. This connection is typically established using a connection-oriented protocol such as TCP, which ensures delivery of messages between the connected neighbor routers. The connected neighbor routers can communicate using BGP to exchange update messages that include routing information. [0070] An AS can use iBGP to advertise reachability information for network address prefixes of destinations ( e.g., routers) outside the AS.)
receive, through the BGP connection, a sixth BGP packet sent by the second network element device; and determine, based on the sixth BGP packet, that the second network element device has the address family extension capability, so that the second network element device supports a remote attestation function. ([0069] Update messages are used to update information included in a routing information base (RIB) or the receiving neighbor router. An update message can announce a new route or withdraw a previously advertised route. Update messages can include various fields such as network layer reachability information (NLRI). NLRI may include IP address prefixes of feasible routes being advertised in the update message. A path can be defined by one or more attributes and is generally intended to be defined as the route between two points in a network, such as an AS. The network section identifies a set of destinations and is referred to as the prefix. A prefix in a destination address is used by a routing protocol to render a routing decision for the next hop in the path.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include send a fifth BGP packet to the second network element device through the BGP connection, wherein the fifth BGP packet is used to negotiate an address family extension capability with the second network element device; receive, through the BGP connection, a sixth BGP packet sent by the second network element device; and determine, based on the sixth BGP packet, that the second network element device has the address family extension capability, so that the second network element device supports the remote attestation function. This would have been advantageous as discussed above, as this would allow the modified system to provide further assurance of security with routing by verification of address family.
Regarding Claim 19:
Filsfils teaches A remote attestation device (ie. processor/memory of the network element) used in a second network element device (ie. second apparatus), ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120) comprising:
a network interface; a memory; and a processor in communication with the network interface ([0045] Fig 5, computer system 500 includes a processor 502, memory 504, storage 506, an input/output (I/O) interface 508, a communication interface 510, and a bus 512.) and the memory to store instructions ([0046] Fig 5, to execute instructions, processor 502 may retrieve ( or fetch) the instructions from an internal register, an internal cache, memory 504, or storage 506;), which when executed by the processor, cause the remote attestation device to:
receive, through a border gateway protocol (BGP) connection, a first BGP packet sent by a first network element device, ([0034] Fig 4, method 400 may be performed by any apparatus of a BGP network such as network element 120. Method 400 may begin at step 410 where an attestation token for the apparatus is received or otherwise accessed. [0035] At step 420, method 400 encodes the attestation token accessed in step 410 in a BGP signaling message. [0036] At step 430, method 400 sends the BGP signaling message with the encoded attestation token to second apparatus of the BGP network.)
wherein the first BGP packet is used to query measurement information of the second network element device, ([0015] In general, BGP-enabled network elements 120 (e.g., network elements 120a-c and 120.f-h in FIG. 1) apply attestation 160 to signaling messages 150 that are transmitted to other BOP-enabled network elements 120 ( e.g., external BGP peers). Attestation 160 provides verifiable evidence of the trustworthiness of network elements 120, thereby enabling external devices to ascertain if any network element 120 has been compromised (e.g., hacked or captured).) [0025]-[0028] attestation queries/TPM queries: The token may allow the replay attacks to be detected without a nonce and make it possible for the attestation for asynchronous push, multicast, broadcast, etc. The token or signed measurement may be referred as a canary stamp since a token or signed measurement may provide authenticity like a stamp and may be used as an indicator of an early sign of trouble.)
wherein the BGP connection for route reflection is established between the second network element device and the first network element device, ([0016] Figs 2A-D, BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. … BGP keepalive message 150d, BGP update message 150b, and BGP notification message 150c can be exchanged only after BGP open message 150a has been confirmed and the BGP connection had been established [0040] trusted reflection.)
and send a second BGP packet to the first network element device through the BGP connection, wherein the BGP connection is used to perform route reflection and a remote attestation process, ([0034] Fig 4, method 400 may be performed by any apparatus of a BGP network such as network element 120. Method 400 may begin at step 410 where an attestation token for the apparatus is received or otherwise accessed. [0035] At step 420, method 400 encodes the attestation token accessed in step 410 in a BGP signaling message. [0036] At step 430, method 400 sends the BGP signaling message with the encoded attestation token to second apparatus of the BGP network.)
wherein the second BGP packet carries the measurement information, so that the first network element device obtains a remote attestation result corresponding to the second network element device. ([0011] The attestation is applied to a BGP keepalive message by appending the canary stamp to the end of a typical BGP keepalive message. The attestation is applied to a BGP update message by appending the canary stamp to a new attribute of a BGP update message. In both cases, the canary stamps may be transmitted to other network entities where they may be analyzed in order to determine whether the attesting node has been compromised.)
Filsfils teaches on attestation, BGP route updates and trusted node reflection ([0015]-[0017], [0040]). However, Filsfils does not explicitly teach on a first network element device having a route reflection function.
Ward teaches on a first network element device having a route reflection function. ([0072] A route reflector is a network element used in a BGP network to implement route reflection. In a BGP route reflection deployment, one or more routers are designated as route reflectors and are allowed to accept and propagate iBGP routes to their clients. [0085] The route reflector 108 transmits a request to each router 112-116 of the AS 102 to obtain the integrity data for each of these routers 112-116, which can be used to determine their trustworthiness. The response may include a hash of the integrity data and the nonce, which the route reflector 108 can use to determine the trustworthiness of the corresponding router.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include a first network element device having a route reflection function. This would have been advantageous as discussed above, as this would allow the modified system to ensure trust worthiness by utilizing a designated route reflector as a third party integrity check.
Regarding Claim 20:
Filsfils (as modified by Ward) teaches the invention of claim 19 as described.
Filsfils teaches wherein the instructions when executed by the processor further cause the remote attestation device to: receive, through the BGP connection, a third BGP packet sent by the first network element device, wherein the third BGP packet indicates to query a version information corresponding to the second network element device; ([0016] BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. If BGP open message 150a is acceptable to a network element 120, a BGP keepalive message 150d is sent to confirm the BGP open message 150a.)
and send a fourth BGP packet to the first network element device through the BGP connection, wherein the fourth BGP packet carries the version information corresponding to the second network element device. (FIG. 2A, BGP open message 150a includes the following fields: a marker field (16 octets), a length field (2 octets), a type field (1 octet), a version field (1 octet), an AS field (2 octets), a hold time field (2 octets), a BGP ID field ( 4 octets), an optional length field ( octet), and an optional field (7 octets).)
Regarding Claim 21:
Filsfils (as modified by Ward) teaches the invention of claim 19 as described.
Filsfils teaches on a next hop type field in the update message ([0039]). However, Filsfils is silent on receive, through the BGP connection, a fifth BGP packet sent by the first network element device, wherein the fifth BGP packet is used to negotiate an address family extension capability with the first network element device; and generate a sixth BGP packet based on the address family extension capability of the second network element device, and send the sixth BGP packet to the first network element device through the BGP connection.
Ward teaches receive, through the BGP connection, a fifth BGP packet sent by the first network element device, wherein the fifth BGP packet is used to negotiate an address family extension capability with the first network element device; ([0069] A BGP session can be established when BGP neighbor routers establish a network connection in order to communicate in accordance with the protocol. This connection is typically established using a connection-oriented protocol such as TCP, which ensures delivery of messages between the connected neighbor routers. The connected neighbor routers can communicate using BGP to exchange update messages that include routing information. [0070] An AS can use iBGP to advertise reachability information for network address prefixes of destinations ( e.g., routers) outside the AS.)
and generate a sixth BGP packet based on the address family extension capability of the second network element device, and send the sixth BGP packet to the first network element device through the BGP connection. ([0069] Update messages are used to update information included in a routing information base (RIB) or the receiving neighbor router. An update message can announce a new route or withdraw a previously advertised route. Update messages can include various fields such as network layer reachability information (NLRI). NLRI may include IP address prefixes of feasible routes being advertised in the update message. A path can be defined by one or more attributes and is generally intended to be defined as the route between two points in a network, such as an AS. The network section identifies a set of destinations and is referred to as the prefix. A prefix in a destination address is used by a routing protocol to render a routing decision for the next hop in the path.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils per Ward to include receive, through the BGP connection, a fifth BGP packet sent by the first network element device, wherein the fifth BGP packet is used to negotiate an address family extension capability with the first network element device; and generate a sixth BGP packet based on the address family extension capability of the second network element device, and send the sixth BGP packet to the first network element device through the BGP connection. This would have been advantageous as discussed above, as this would allow the modified system to provide further assurance of security with routing by verification of address family.
Claim(s) 7, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0322310 Al (Filsfils) in view of US 2021/0306256 Al (Ward) further in view of US 20160315921 A1 (Dara).
Regarding Claim 7:
Filsfils (as modified by Ward) teaches the invention of claim 1 as described.
Filsfils teaches wherein before the sending the first BGP packet to the second network element device through the BGP connection, the method further comprises: sending, by the first network element device, a third BGP packet to the second network element device through the BGP connection, wherein the third BGP packet indicates to query the version information corresponding to the second network element device; ([0016] BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. If BGP open message 150a is acceptable to a network element 120, a BGP keepalive message 150d is sent to confirm the BGP open message 150a.)
receiving, by the first network element device through the BGP connection, a fourth BGP packet sent by the second network element device, and parsing the fourth BGP packet to obtain the version information that corresponds to the second network element device carried in the fourth BGP packet; ([0016] FIG. 2A, BGP open message 150a includes the following fields: a marker field (16 octets), a length field (2 octets), a type field (1 octet), a version field (1 octet), an AS field (2 octets), a hold time field (2 octets), a BGP ID field ( 4 octets), an optional length field ( octet), and an optional field (7 octets).)
([0016] BGP keepalive message 150d, BGP update message 150b, and BGP notification message 150c can be exchanged only after BGP open message 150a has been confirmed and the BGP connection had been established.)
Filsfils teaches on version information ([0016]). However, Filsfils (as modified by Ward) is silent that in response to that the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file, determining, by the first network element device, that the second network element device supports the remote attestation function.
Dara teaches, in the same field of endeavor, on methods for verifying proof of transit of network traffic through a plurality of network nodes in a network, Abstract.
Dara also teaches that in response to that the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file, determining, by the first network element device, that the second network element device supports the remote attestation function. ([0093] When a packet reaches the egress node, the service verification information may be extracted from the packet and the egress node may use the packet identifying value and the secrets of all services to generate or revise a copy of the piece of verification information and compare its own version with the generated or revised piece of verification information extracted from the packet to verify that the packet indeed passes through all services in the service chain.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils (as modified by Ward) by modifying Filsfils per Ward to include that in response to that the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file, determining, by the first network element device, that the second network element device supports the remote attestation function. This would have been advantageous as discussed above, as this would allow the combined system to ensure verification of nodes regardless of path taken, see Dara [0127].
Regarding Claim 17:
Filsfils (as modified by Ward) teaches the invention of claim 16 as described.
Filsfils teaches wherein the instructions when executed by the processor further cause the remote attestation device to: send a third BGP packet to the second network element device through the BGP connection, wherein the third BGP packet indicates to query the version information corresponding to the second network element device; ([0016] BGP open message 150a is the first message that is sent by both peers ( e.g., network elements 120c and 1201) after a connection (e.g., a TCP connection) has been established. If BGP open message 150a is acceptable to a network element 120, a BGP keepalive message 150d is sent to confirm the BGP open message 150a.)
receive, through the BGP connection, a fourth BGP packet sent by the second network element device, and parse the fourth BGP packet to obtain the version information that corresponds to the second network element device carried in the fourth BGP packet; ([0016] FIG. 2A, BGP open message 150a includes the following fields: a marker field (16 octets), a length field (2 octets), a type field (1 octet), a version field (1 octet), an AS field (2 octets), a hold time field (2 octets), a BGP ID field ( 4 octets), an optional length field ( octet), and an optional field (7 octets).)
([0016] BGP keepalive message 150d, BGP update message 150b, and BGP notification message 150c can be exchanged only after BGP open message 150a has been confirmed and the BGP connection had been established.)
Filsfils teaches on version information ([0016]). However, Filsfils (as modified by Ward) is silent that in response to that the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file, determining, by the first network element device, that the second network element device supports the remote attestation function.
Dara teaches that in response to that the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file, determining, by the first network element device, that the second network element device supports the remote attestation function. ([0093] When a packet reaches the egress node, the service verification information may be extracted from the packet and the egress node may use the packet identifying value and the secrets of all services to generate or revise a copy of the piece of verification information and compare its own version with the generated or revised piece of verification information extracted from the packet to verify that the packet indeed passes through all services in the service chain.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Filsfils (as modified by Ward) by modifying Filsfils per Ward to include that in response to that the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file, determining, by the first network element device, that the second network element device supports the remote attestation function. This would have been advantageous as discussed above, as this would allow the combined system to ensure verification of nodes regardless of path taken, see Dara [0127].
Conclusion & Contact Information
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHEL J HACKENBERG whose telephone number is (571)272-5417. The examiner can normally be reached 9am-5pm M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton B Burgess can be reached at (571)272-3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RACHEL J HACKENBERG/Primary Examiner, Art Unit 2454
Prosecution Insights