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 argument, see Remarks, filed 11/25/2025, with respect to the rejection(s) of independent claims 1, 10 and 12 under 35 USC § 103 has been fully considered, and is persuasive. However, a non-final rejection is being issued herewith based on a newly found prior art, a Non-Patent Literature (NPL) titled “Traps and pitfalls in secure clock synchronization”, by Treytl.
Claim Rejections - 35 USC § 103
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.
Claims 1-2, 5, 12-13 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US-PGPUB No 2019/0394211 A1 to Filsfils et al. (hereinafter “Filsfils”), The Non-Patent literature “Traps and pitfalls in secure clock synchronization”, October, 2007, by Treytl et al. (hereinafter “Treytl”), and further in view of US-PGPUB No. 2014/0281530 A1 to Song et al. (hereinafter “Song”)
Regarding claim 1:
Filsfils discloses:
A method (see the methods of Fig. 5B-5F), performed by a network device (see Fig. 5A, Network node 532, ¶90: “Network node 532 receives packet 522 …”), for preventing a replay attack on a Segment Routing over Internet Protocol version 6 (SRv6) keyed hashed message authentication code (HMAC) verification (¶86-89: “… protecting Internet Protocol version 6 (IPv6) Segment Routing (SRv6) packets and functions using Security Segment Identifiers. … a Security Association having been established between Segment Routing nodes 531 and 532 for being authenticated by a secured Segment Routing function identified by C2::C3, with anti-replay protection enabled … a one-way cryptographic hash function is performed on at least the secured portion of packet 522 in formulating the value of Security Segment Identifier 553, typically using a pre-shared key that is part of the security association.”), the method comprising:
receiving a first SRv6 packet (¶90: “Network node 532 receives packet 522 …”) comprising a first packet header (¶89: “Segment Identifier 554 …”), […]
However, Filsfils does not explicitly disclose the following limitation taught by Treytl:
[…] wherein the first packet header comprises an extended type length value (TLV) (Treytl, see page 20, left column, lines 20-21: “authentication type length value (TLV) extension.”) carrying first anti-replay attack verification information (Treytl, see page 20, right column, lies 37-39: “… replay protection is maintained through a random lifetime id and a replay counter. Both values contained in the authentication TLV.”) and HMAC verification information (Treytl, see page 20, left column, lines 21-22: “This TLV contains the message authentication code also called integrity check value (ICV),”, and also page 20, right column, lines 48-50: “An important property of the security mechanisms are the symmetric hash-functions HMAC-SHAI-96 and HMAC-SHA256-128 [4] used to generate the ICV:”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Filsfils to incorporate the functionality of the method to include a MAC-TLV portion that includes parameters (sequence numbers) that can be used to prevent (block) replay of messages, and a (H)MAC that can be used for message integrity check, as disclosed by Treytl, such modification would enable the system to carry both the HMAC and replay protection information within a single TLV allowing for a compact representation of these security elements, and processing a single TLV to validate both message integrity and anti-replay properties can be more efficient than handling separate data units.
The combination of Filsfils and Treytl does not explicitly disclose the following limitation taught by Song:
performing anti-replay attack verification on the first SRv6 packet based on the first anti- replay attack verification information (Song, ¶49: “… that method 800 may check the SEQ-ICV (e.g. block 812) at the receiving node after checking the sequence number with the anti-replay window”);
and performing HMAC computation on the first SRv6 packet based on the HMAC verification information in response to the first SRv6 packet passing the anti-replay attack verification (Song, ¶06: “performing a Sequence-ICV (SEQ-ICV) check that validates a sequence number within the IPsec packet, and performing an ICV check that validates a checksum within the IPsec packet such that the SEQ-ICV check is performed before the ICV check.”, p-51-52: “The SEQ-ICV may be a lighter check than checking the ICV at block 816, and may filter or reject packets with modified sequence numbers. … Method 800 may subsequently proceed to block 816 after an IPsec packet passes the SEQ-ICV check.”, see Fig. 8, steps 808-816).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Filsfils and Treytl to incorporate the functionality of the method to generate a SEQ-ICV that represents a validity check for a sequence number located within the IPsec packet, and perform a validity check of the sequence number before an integrity check of the IPSec packet, and the received IPSec packet if the sequence number is duplicated (without performing the integrity check), as disclosed by Song, such modification would enable the system to perform the less intensive sequence number anti-replay check before performing the HMAC integrity check which is rather expensive interms of resource and time consumption, thus lowering performance degradation and service interruption for users.
Regarding claim 2:
The combination of Filsfils, Treytl and Song discloses:
The method of claim 1, wherein the first anti-replay attack verification information comprises at least one of a timestamp, a nonce, or a sequence number (Treytl, ¶82: “… a replay counter. … The replay counter is incremented by two whenever a packet is sent.”).
The same motivation which is applied to claim 1 with respect to Treytl applies to claim 2.
Regarding claim 5:
The combination of Filsfils, Treytl and Song discloses:
The method of claim 1, wherein the first anti-replay attack verification information comprises a sequence number (Treytl, ¶82: “… a replay counter. … The replay counter is incremented by two whenever a packet is sent.”),
The same motivation which is applied to claim 1 with respect to Treytl applies to claim 5.
and wherein performing the anti-replay attack verification on the first SRv6 packet comprises verifying, based on a locally recorded packet sequence number (Song, ¶25: “… the receiving node may extract and perform an SEQ-ICV check that compares the received SEQ-ICV with a locally generated SEQ-ICV to determine whether the received SEQ-ICV matches the locally generated SEQ-ICV.”).
The same motivation which is applied to claim 1 with respect to Song applies to claim 5.
Regarding claim 12:
Filsfils discloses:
A network device (see Fig. 2B, an Apparatus 200) (¶88: “FIG. 5B illustrates an IP packet 511 being encapsulated and forwarded through network 500 … with anti-replay protection enabled …”) (¶41: “… an apparatus 220 … associated with providing processing and network efficiencies in protecting SRv6 packets and functions using Security Segment Identifiers.”, ¶89: “… each of formulating the Security Segment Identifier(s) and integrity check value(s) includes processing each value or field of the secured portion of the packet using a one-way cryptographic hash function.”), comprising:
at least one processor (see Fig. 2B, Processing Element 221); and
a memory (see Fig. 2B, Memory 222) coupled with the at least one processor (¶42: “… apparatus 220 includes one or more processor(s) …, memory 222 … communicatively coupled via one or more communications mechanisms 229”), wherein the memory is configured to store instructions that, when executed by the at least one processor (¶43: “Memory 222 typically stores computer-executable instructions to be executed by processor(s) 221”), cause the network device to:
In addition to the above limitations, claim 12 recites substantially the same limitations as claim 1 in the form of a device to realize the corresponding method. Therefore, it is rejected by the same rationale.
Regarding claims 13 and 16:
Claims 13, 16 and 19 recite substantially the same limitations as claims 2 and 5, respectively, in the form of a device to realize the corresponding method. Therefore, they are rejected by the same rationale.
Claims 3-4 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Filsfils, Treytl and Song, and further in view of US-PGPUB No. 2013/0151857 A1 to Agrawal
Regarding claim 3:
The combination of Filsfils, Treytl and Song discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Agrawal:
wherein the first anti-replay attack verification information comprises a timestamp (Agrawal, ¶07: “… a timestamp …”), and wherein performing the anti-replay attack verification on the first SRv6 packet comprises verifying whether a deviation between the timestamp and a current time of the first network device satisfies a preset condition (Agrawal, ¶08: “… determine that the timestamp of that message indicates a time that is within the valid period of time prior to the current time, …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Filsfils, Treytl and Song to incorporate the functionality of the method to create a record of previously received nonce, and determine that the nonce of the message is not present within the record of previously received nonces at the current time, as disclosed by Agrawal, such modification would allow the system to validate the integrity of the received message and determine a replay attack when the nonce is determined to be previously recorded.
Regarding claim 4:
The combination of Filsfils, Treytl and Song discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Agrawal:
wherein the first anti-replay attack verification information comprises a nonce (Agrawal, ¶07: “… a respective nonce …”), and wherein performing the anti-replay attack verification on the first SRv6 packet comprises verifying, based on a locally recorded nonce, whether the nonce is valid (Agrawal, ¶08: “… determine that the nonce of the that message is not present within the record of previously received nonces at the current time.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Filsfils, Treytl and Song to incorporate the functionality of the method to create a record of previously received nonce, and determine that the nonce of the message is not present within the record of previously received nonces at the current time, as disclosed by Agrawal, such modification would allow the system to validate the integrity of the received message and determine a replay attack when the nonce is determined to be previously recorded.
Regarding claims 14-15:
Claims 14-15 recite substantially the same limitations as claims 3-4, respectively, in the form of a device to realize the corresponding method. Therefore, they are rejected by the same rationale.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Filsfils, Treytl, Song, and further in view of US-PGPUB No. 2020/0322145 to Sheth et al. (hereinafter “Sheth”)
Regarding claim 7:
The combination of Filsfils, Treytl and Song discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Sheth:
wherein the first packet header comprises first indication information identifying a type of the anti-replay attack verification (Sheth, ¶129: “… the client 504 can obtain attestation information from one or more type-length-value (TLV) fields …”), wherein the type comprises at least one of the anti-replay attack verification using a nonce (Sheth, ¶76: “… detect attempts of a replay attack by embedding a nonce …”), the anti-replay attack verification using a timestamp, or the anti-replay attack verification using a sequence number.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Filsfils, Treytl and Song to incorporate the functionality of the method to add proof of integrity information to a set of type-length-value (TLV) fields, as disclosed by Sheth, such modification would allow the system to validate the integrity of a received message by matching the type, the length, and the value of the verification (sequence number, timestamp or nonce) to expected values, providing a stronger method of detecting replay attacks.
Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Filsfils, Treytl, Song, USPAT No. 8646090 B1 to Gadde et al. (hereinafter “Gadde”), and further in view of US-PGPUB No. 2008/0109891 to Greenwald et al. (hereinafter “Greenwald”)
Regarding claim 9:
The combination of Filsfils, Treytl and Song discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Gadde:
further comprising:
receiving a second SRv6 packet (Gadde, col 5, lines 4-5: “If a second packet arrives at security device 104, …”) comprising a second packet header (Gadde, col 5, lines 1-2: “… IPSec sequence number of the packet may be extracted from its header. …”), wherein the second packet header comprises second anti-replay attack verification information (Gadde, col 5, lines 6-7: “… sequence number of the second packet has been detected at security device 104, …”);
performing the anti-replay attack verification on the second SRv6 packet based on the second anti-replay attack verification information (Gadde, col 5, lines 5-7: “… bitmap 508 may be consulted in order to determine if the IPSec sequence number of the second packet has been detected at security device 104”); and
discarding the second SRv6 packet (Gadde, col 5, lines 8-10: “If the IPSec sequence number has been detected or seen previously, the second packet may be considered a replay packet and dropped.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Filsfils, Treytl and Song to incorporate the functionality of the process for checking if a packet is a replay packet by comparing the sequence number of the packet to stored sequence numbers, as disclosed by Gadde, such modification would allow the system to validate the integrity of the received message and determine a replay attack when the sequence number is determined to be previously recorded.
The combination of Filsfils, Treytl, Song and Gadde does not disclose the following limitation taught by Greenwald:
and terminating the HMAC computation in response to the second SRv6 packet failing the anti-replay attack verification (Greenwald, ¶71: “… once a given sequence number is received successfully, any duplicates can be discarded without computing the hash.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Filsfils, Treytl, Song and Gadde to incorporate the functionality of the method to perform an anti-replay verification before performing an HMAC computation of data packet, as disclosed by Greenwald, such modification would allow the system to minimize resource usage by performing the HMAC computation only after discarding duplicates, i.e., packets that failed the anti-replay verification, thus improving system efficiency.
Regarding claim 20:
Claim 20 recites substantially the same limitations as claim 9 in the form of a device to realize the corresponding method. Therefore, it is rejected by the same rationale.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Filsfils, and further in view of Treytl
Regarding claim 10:
Filsfils discloses:
A method (see the methods of Fig. 5B-5F), (¶86-89: “… protecting Internet Protocol version 6 (IPv6) Segment Routing (SRv6) packets …”) comprising:
generating a Segment Routing over Internet Protocol version 6 (SRv6) packet (¶89: “Network node 531 receives packet 511 and generates secure Segment Routing packet 522 which includes original packet 511 encapsulated therein.”) comprising a packet header (¶89: “… a Segment Routing Header of packet 522.”),
and sending the SRv6 packet (¶89: “Node 531 sends packet 522 …”) to a second network device (¶90: “Network node 532 receives packet 522 …”, see Fig. 5A).
However, Filsfils does not explicitly disclose the following limitation taught by Treytl:
an extended type length value (TLV) (Treytl, see page 20, left column, lines 20-21: “authentication type length value (TLV) extension.”) carrying first anti-replay attack verification information (Treytl, see page 20, right column, lies 37-39: “… replay protection is maintained through a random lifetime id and a replay counter. Both values contained in the authentication TLV.”) and HMAC verification information (Treytl, see page 20, left column, lines 21-22: “This TLV contains the message authentication code also called integrity check value (ICV),”, and also page 20, right column, lines 48-50: “An important property of the security mechanisms are the symmetric hash-functions HMAC-SHAI-96 and HMAC-SHA256-128 [4] used to generate the ICV:”)
wherein the packet header comprises an extended type length value (TLV) (Treytl, see page 20, left column, lines 20-21: “authentication type length value (TLV) extension.”) carrying anti-replay attack verification information (Treytl, see page 20, right column, lies 37-39: “… replay protection is maintained through a random lifetime id and a replay counter. Both values contained in the authentication TLV.”) and HMAC verification information (Treytl, see page 20, left column, lines 21-22: “This TLV contains the message authentication code also called integrity check value (ICV),”, and also page 20, right column, lines 48-50: “An important property of the security mechanisms are the symmetric hash-functions HMAC-SHAI-96 and HMAC-SHA256-128 [4] used to generate the ICV:”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Filsfils to incorporate the functionality of the method to include a MAC-TLV portion that includes parameters (sequence numbers) that can be used to prevent (block) replay of messages, and a (H)MAC that can be used for message integrity check, as disclosed by Treytl, such modification would enable the system to carry both the HMAC and replay protection information within a single TLV allowing for a compact representation of these security elements, and processing a single TLV to validate both message integrity and anti-replay properties can be more efficient than handling separate data units.
Regarding claim 11:
The combination of Filsfils and Treytl discloses:
The method of claim 10, wherein the anti-replay attack verification information comprises at least one of a timestamp, a nonce, or a sequence number (Treytl, ¶82: “… a replay counter. … The replay counter is incremented by two whenever a packet is sent.”).
The same motivation which is applied to claim 10 with respect to Treytl applies to claim 11.
Allowable Subject Matter
Claims 6, 8, 17 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claim 18 is also objected based on its dependency on claim 17.
The following is the Examiner’s statement of reason for allowance.
With respect to claims 6 and 17 (claim 17 recites substantially the same limitation as claim 6 in the form of a device to realize the corresponding method), the combination of Filsfils and Treytl fails to disclose an extended TLV which further comprises at least a first bit and a second bit, wherein the first bit when set indicates a first anti-replay attack verification type to perform on the first SRv6 packet, and wherein the second bit when set indicates a second anti-replay attack verification type to perform on the first SRv6 packet.
Claim 18 is indicated as allowable subject matter based on its dependence on claim 17.
With respect to claims 8 and 19 (claim 19 recites substantially the same limitation as claim 8 in the form of a device to realize the corresponding method) , the combination of Filsfils and Treytl fails to disclose performing the HMAC computation using the first anti-replay attack verification information as a hash factor. Therefore, claims 8 and 19 are indicated as allowable subject matter.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHIAS HABTEGEORGIS whose telephone number is (571)272-1916. The examiner can normally be reached M-F 8am-5pm ET.
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, William R. Korzuch can be reached on (571)272-7589. 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.
/MATTHIAS HABTEGEORGIS/Examiner, Art Unit 2491