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
The examiner fully considered the applicant’s argument remarks filed on February 16, 2026 in response to the Office Action mailed on December 17, 2025. However, the applicant’s argument remarks are not persuasive to overcome the prior arts in record and place the claims and the application in a better condition for allowance for at least the following reasons. The applicant argues that claim 1 recites that the "self-authenticating message" is sent "to a plurality of host devices." As noted above, the Haddad dedicated RtAdv is not sent to a plurality of host devices - it is instead unicast to just one host device. See, e.g., [0043] ("The RtAdv is sent in unicast mode, dedicated to the intent of this host 800 only.").
The examiner respectfully disagrees with the applicant’s argument because unlike the applicant’s assertion, Hadded further discusses the limitation “sending, by the network router and to a plurality of host devices, an authenticating message” in [0046] that the access router 700 broadcasts periodic RtAdv's sent in multicast towards all hosts 800 to which it is connected. In order to provide enhanced security to the periodic RtAdv's, the processing logic 730 may calculate a one-way hash chain of length "n", and identify public hash values from the one-way hash chain. Therefore the prior art Hadded teaches sending (broadcasting) by the access router 700 the secure RtAdv's sent in multicast towards all hosts 800 and identify public hash values from calculated one-way hash chain (implemented by SEND protocol, IETF 3971 and one-way hash chain OWHC with Cryptographically Generated Address (CGA) public/private key).
The examiner further notes that unlike the applicant’s assertion that "hashed portion” is not disclosed, Hadded teaches that in [0037] At step 600, the host 800 receives the periodic multicast RtAdv comprising the V(i+1) value. The host 800 reads the V(i) value from its memory. The V(i) value may have been stored upon receipt of a previous dedicated RtAdv or multicast RtAdv (Secure RtAdv or Secure multicast RtAdv sent by a router and received by hosts) . The V(i) may have been stored at step 355 of FIG. 3. The V(i) may actually be the V(k) received from the nAR 701 at step 535 of FIG. 5, and stored at step 545. Finally, the V(i) may be the value stored following receipt of the previous periodic RtAdv, in a previous instance of the sequence of FIG. 6. At step 610, the host 800 hashes the V(i+1) value. The host 800 then compares a result of the hashing with the previously stored V(i) value at step 615. If a match is positive, this new periodic RtAdv is deemed authentic and information contained therein is stored in the host 800 memory at step 620. Specifically, the V(i+1) value from the new periodic RtAdv is now stored as a new V(i) value at step 620. If the match of step 615 is negative, this new periodic RtAdv is discarded at step 625. [0038] The sequence of FIG. 6 may not be executed for one or a few periodic RtAdv messages not correctly received at the host 800 and, consequently, the V(i) value stored in the memory of the host 800 may be out of synchronization with the publicly disclosed values of the OWHC. Instead of ignoring the new periodic RtAdv following a first unsuccessful match at step 615, re-hashing the result of the first hash may take place at step 630, followed by a new comparison at step 615 of a second result with the value V(i). A positive match following the second hashing indicates that the host 800 has missed exactly one periodic RtAdv and that the newly received periodic RtAdv is valid. Preferably, in order to avoid any Denial Of Service attack, only a small number of re-hashing iterations is allowed, for example two or three iterations, before discarding the newly received RtAdv at step 625.
For at least above reasons, the applicant’s argument are not persuasive to overcome the prior arts in record and place claim 1 in a better condition for allowance and therefore the rejection is maintained. The rejection of the independent claims 6, 11, 16, 21, 26, 31, and 36, are also maintained for a similar reason as discussed above for claim 1. However, the applicant’s argument with regards to claim 3 is persuasive to overcome the prior arts in record and therefore the rejection has been withdrawn. The rejection of claims 13, 23 and 33 are also withdrawn for a similar reason.
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.
Claims 1-2, 4-12, 14-22, 24-32 and 34-40 are rejected under 35 U.S.C. 103 as being unpatentable over Haddad US 20080162936 A1 in view of Rossi US 20120110326 A1 in further view of Levy-Abegnoli et al. (US 20080307516 A1---hereinafter—"Levy”).
As per claim 1: Haddad disclose a method comprising:
generating, by a network router, a router advertisement message ([0006-0008] In IPv6 a host, for example an end-user device, receives a connection service from an Access Router (AR). One or more hosts may be connected to one AR, for example by way of an Ethernet link, or through a radio link, and the like. The host needs to receive information from the AR in order to configure the IPv6 address 100, which will in turn enable the host to communicate with further nodes on the Internet. The AR sends the required information, comprising the network prefix 110 of the AR, in Router Advertisement messages (RtAdv) described in the Internet Engineering Task Force (IETF) Request For Comments (RFC) number 2461. The RtAdv may be broadcasted periodically by the AR for the benefit of all hosts on the same link. .. The RtAdv provides the network prefix 110 that is used by the host to configure its IPv6 address 100. The host adds its own IID 120 to the network prefix 110 to generate the IPv6 address 100. The host must then initiate a Duplicate Address Detection (DAD) procedure, described in the IETF RFC 2462, to ensure that no host currently linked to the same AR is using the same IPv6 address 100. In the event where the IPv6 address 100 configured by the host is already in use, as detected in the DAD procedure, the host needs to generate a distinct IPv6 address 100 by use of a different IID 120 and invoke again the DAD procedure. This process may be repeated as many times as required until the host finally acquires a unique IPv6 address 100. Once the host has configured its IPv6 address 100, following proper verification that this address is unique, it receives further periodic RtAdv messages);
hashing, by the network router, the portion of the router advertisement message ([0029] The present invention provides a method for optimization of the SEcure Neighbor Discovery (SEND) protocol, described in the Internet Engineering Task Force (IETF) Request For Comments (RFC) number 3971. It provides an Access Router (AR) and a host supporting this optimization. It uses a combination of a One-Way Hash Chain (OWHC) of length "n", and of Cryptographically Generated Address (CGA) public keys (CGA+) and CGA private keys (CGA-), to provide security of communication between the host and the AR. For the purposes of the present invention, a value V(i) of the OWHC, wherein "i" is in a range between zero and "n", is publicly disclosed on a link between the AR and hosts connected thereto. In a first place, the value V(i=0) is disclosed, for example in a multicast Router Advertisement message (RtAdv). Later, a value V(i+1) corresponding to a result of one less hashing iteration, is disclosed, and so on. CGA signatures are used in a first message pair exchanged between the host and the router, and a secret Key (Ks) is generated. Once the first message pair has been exchanged, CGA signatures are no longer used. Instead, the Ks is used to sign messages exchanged between the host and the router, and values of the OWHC are publicly disclosed in broadcast messages sent by the AR to enable the router to prove to the host that the broadcast messages are valid; [0031] The local IPv6 address has a format as shown in the foregoing description of FIG. 1. In the local IPv6 address, an interface identifier (IID) 120 is preferably generated through a hashing of a CGA+ of the host. A dedicated RtAdv message is sent towards the host at step 340. The dedicated RtAdv comprises the NA-IPv6, a CGA+ of the AR 700 and the encrypted Ks, and may further comprise a Mobility indicator (M). [0036] The AR 700 serving the host 800 following the sequence of FIG. 3 (or the nAR 701 now serving the host 800 if the sequence of FIG. 5 has taken place) continues sending periodic RtAdv in multicast, intended for all hosts connected on the link. As described in relation to FIG. 2, each subsequent multicast RtAdv comprises a new value V(i+1) from the OWHC of the AR 700);
sending, by the network router and to a plurality of host devices, an authenticating message ([0035] The nAR 701 allocates a new NA-IPv6 address to the host 800 at step 525, using its own network prefix and the IID. Step 525 may comprise an internal Duplicate Address Detection (DAD) procedure. The nAR 701 then sends at step 535 a new dedicated RtAdv towards the host 800, comprising the newly assigned NA-IPv6 address, the CGA+ of the nAR 701, and a latest publicly disclosed value V(k) of a OWHC for the nAR 701. The RtAdv is signed with the Ks. The host 800 verifies the Ks signature of the RtAdv at step 540 and, if the signature is valid, stores the new NA-IPv6 address, the CGA+ of the nAR and the value V(k) at step 545. [0037] The host 800 then compares a result of the hashing with the previously stored V(i) value at step 615. If a match is positive, this new periodic RtAdv is deemed authentic and information contained therein is stored in the host 800 memory at step 620. Specifically, the V(i+1) value from the new periodic RtAdv is now stored as a new V(i) value at step 620. If the match of step 615 is negative, this new periodic RtAdv is discarded at step 625. [0046] The access router 700 broadcasts periodic RtAdv's sent in multicast towards all hosts 800 to which it is connected. In order to provide enhanced security to the periodic RtAdv's, the processing logic 730 may calculate a one-way hash chain of length "n", and identify public hash values from the one-way hash chai. [0038] The sequence of FIG. 6 may not be executed for one or a few periodic RtAdv messages not correctly received at the host 800 and, consequently, the V(i) value stored in the memory of the host 800 may be out of synchronization with the publicly disclosed values of the OWHC. Instead of ignoring the new periodic RtAdv following a first unsuccessful match at step 615, re-hashing the result of the first hash may take place at step 630, followed by a new comparison at step 615 of a second result with the value V(i). A positive match following the second hashing indicates that the host 800 has missed exactly one periodic RtAdv and that the newly received periodic RtAdv is valid. Preferably, in order to avoid any Denial Of Service attack, only a small number of re-hashing iterations is allowed, for example two or three iterations, before discarding the newly received RtAdv at step 625) comprising:
the router advertisement message ([0036] The AR 700 serving the host 800 following the sequence of FIG. 3 (or the nAR 701 now serving the host 800 if the sequence of FIG. 5 has taken place) continues sending periodic RtAdv in multicast, intended for all hosts connected on the link. As described in relation to FIG. 2, each subsequent multicast RtAdv comprises a new value V(i+1) from the OWHC of the AR 700. FIG. 6 shows a manner of using OWHC values within the host 800. As detailed in the foregoing description of FIG. 2, each time a new periodic RtAdv is sent, it carries a new OWHC value V(i+1), which corresponds to one less hash iteration than the value V(i) of the previous periodic RtAdv.) the hashed portion of the router advertisement message; [0037] At step 610, the host 800 hashes the V(i+1) value. The host 800 then compares a result of the hashing with the previously stored V(i) value at step 615. If a match is positive, this new periodic RtAdv is deemed authentic and information contained therein is stored in the host 800 memory at step 620. Specifically, the V(i+1) value from the new periodic RtAdv is now stored as a new V(i) value at step 620. If the match of step 615 is negative, this new periodic RtAdv is discarded at step 625);
a router advertisement option identifying the portion, of the router advertisement message, that was hashed to create the hashed portion of the router advertisement message ([0031] The local IPv6 address has a format as shown in the foregoing description of FIG. 1. In the local IPv6 address, an interface identifier (IID) 120 is preferably generated through a hashing of a CGA+ of the host. A network prefix 110 is generally a fixed 64-bit value for the host); and
communicating with the plurality of host devices after the host devices authenticate the self-authenticating message ([0040] Should the host 800 receive from the AR 700 the flag broadcasted as described at step 255 of FIG. 2, the value V(i) stored in the memory of the host 800 is no longer usable. The host 800 may request receipt of a new V(i) value, contained in a new RtAdv to be received from the AR 700, by sending a new RtSol message towards the AR 700, also comprising the lost synchronization indicator. The RtSol and RtAdv are, in this case also, preferably signed with the Ks. [0041] The AR 700 may generate another OWHC intended for authenticating multicast ND Advertisements sent by the host 800. This is especially useful when a specific host 800 for which the IPv6 address is advertised, is expected to exchange messages with many other parties on the same link).
Haddad does not explicitly disclose the hashed portion of the router advertisement message is using a secret value of the network router. Rossi, in analogous art however, discloses the hashed portion of the router advertisement message is using a secret value of the network router ([0104] During the boot-strapping procedure, the MN 50 generates its CGHoA and sends the generated CGHoA to the HA 22 as part of a signature request. The HA 22 validates the CGHoA and provides the MN 50 with the CS.sub.HoA-HA signature shown in Table 5. To begin the boot-strapping procedure, the MN 50 receives a router advertisement message from an advertising router (AR) in its home network (step a). The router advertisement message includes the home subnet and CGHA of the HA 22. The CGHA Parameters and message authentication code {HMAC}.sub.PKHA are received with the router advertisement message. As previously noted, the CGHA Parameters contain the information elements used to generate the CGHA. The router advertisement may also optionally include the security policies regarding the GCHoA, signatures, or other related security parameters used in the home network 20 which must be respected by the MN 50. [0117] When the MN 50 enters the visited network, the MN 50 receives a router advertisement from an advertising router (AR) in the visited network (step a). The router advertisement message contains the visited subnet and the CGVHA of the VHA 32. The router advertisement message may optionally include the security policies of the visited network. The CGVHA is generated in the same manner as a conventional CGA as shown in Table 4. The router advertisement further has extension fields appended containing the CGVHA Parameters and a hashed message authentication code {HMAC}.sub.PKHA signed with the private key of the VHA 32. The hashed message authentication code {HMAC}.sub.PKHA is formed by hashing the router advertisement and extension fields and signing the result the HA's private key). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the message disclosed by Haddad to include the hashed portion of the router advertisement message is using a secret value of the network router. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a secure route optimization procedure that eliminates or reduces the security threats as suggested by Rossi ([0006]).
Haddad and Rossi do not explicitly disclose the authenticating message is a self-authenticating message. Levy, in analogous art however, discloses the authenticating message is a self-authenticating message ([0022] The routing circuit 52 can be configured for determining whether the router 28 having sent the router advertisement message 38 is authorized to advertise itself as a router, and/or advertise the address prefix 44 specified in the router advertisement message 38, within the local area network 14. [0024] The SEND authentication circuit 60 can be configured for determining whether the router 28, identified by its corresponding link local address 40 in the received router advertisement message 38, is authorized to advertise itself as a router and/or advertise the advertised address prefix (e.g., "2001:0210::/32") 44, for example based on determining whether the identified router 28 is identifiable from a prescribed list 68 of authorized routers having respective authorized address prefixes 70, or based on authenticating the supplied secure token 42 according to SEND protocol relative to the trust anchor 30). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the message disclosed by Haddad and Rossi to include the authenticating message is a self-authenticating message. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide enhanced deployment of Secure Neighbor Discovery (SEND) in an Internet Protocol version 6 (IPv6) network with certificate formats mandated by the SEND protocol that enable host nodes to learn a certification path of a router, and to validate the authenticity of a router as suggested by Levy ([0002]).
As per claim 2: Haddad in view of Rossi in further view of Levy discloses the method of claim 1, wherein the hashing comprises hashing a capability attribute of the network router (under BRI for “a capability attribute” of the router , it could be an interface identifier of a router and under RFC 3971 SEND protocol, SEND utilizes Cryptographically Generated Addresses (CGAs) to establish address ownership to prevent spoofing, it could be CGAs are IPv6 addresses where part of the address (typically the interface identifier) is generated from a cryptographic hash of the address owner's public key. Levy [0015]: The SEND-enabled IPv6 host node 26 is configured for performing secure neighbor discovery (SEND) as specified in RFC 3971, including obtaining configuration with a trust anchor 30 which can be reachable via an IP-based wide area network 32 in order to determine whether any router has a certification path that enables the SEND-enabled host 26 to authenticate any certificate, digital signature, or public key received from a router 12, 20, or 28. In particular, RFC 3971 requires that all router advertisement messages sent according to the SEND protocol include a digital signature, for example an RSA signature; as described herein, however, other secure tokens can be supplied, for example a public key, or a digital certificate such as an X.509v3 public key certificate; hence the term "secure token" as used herein refers to any one of the public key, the digital signature, or the digital certificate as described for example in RFC 3961).
As per claim 4: Haddad in view of Rossi in further view of Levy discloses method of claim 1, wherein the self-authenticating message comprises a code indicating that the self-authenticating message comprises the hashed portion of the router advertisement message (Levy [0009] In one embodiment, a method comprises receiving, by a router in a network, a router advertisement message on a network link of the network; detecting within the router advertisement message, by the router, an advertised address prefix and an identified router having transmitted the router advertisement message within the network; determining, by the router, whether the identified router is authorized to at least one of advertise itself as a router, or advertise the advertised address prefix on the network link; and selectively initiating, by the router, a defensive operation against the identified router based on the router determining the identified router is not authorized to advertise itself as a router, or advertise the advertised address prefix on the network link. Levy [0024] The SEND authentication circuit 60 can be configured for determining whether the router 28, identified by its corresponding link local address 40 in the received router advertisement message 38, is authorized to advertise itself as a router and/or advertise the advertised address prefix (e.g., "2001:0210::/32") 44, for example based on determining whether the identified router 28 is identifiable from a prescribed list 68 of authorized routers having respective authorized address prefixes 70, or based on authenticating the supplied secure token 42 according to SEND protocol relative to the trust anchor 30).
As per claim 5: Haddad in view of Rossi in further view of Levy discloses the method of claim 1, wherein the self-authenticated message is generated without previously receiving information from the host devices (Haddad [0027] At step 215, another MN 110 that did not earlier receive a periodic RtAdv message enters the coverage, or domain, of the AP 120. In order to set up a session, it sends at step 220 an Association Request (AssReq) message to the AP 120, to request setting up a connection. At step 225, the AP 120 replies with an Association Response (AssResp). The AssResp comprises all information it has recently cached for the RtAdv, including a given NI-HNV pair which preferably is one of many NI-HNV pairs currently cached in the AP 120. Alternatively, the AP 120 may send the AssResp and the RtAdv sequentially, as two distinct messages, within a very brief period. Optionally, the AP 120 may, at step 227, send a Solicitation to the AR 150, for example a Route Solicitation (RtSol) message, on behalf of the MN 110. This RtSol message, if sent at this step, will trigger sending, by the AR 150, of another RtAdv message to the MN 110, as is described hereinbelow. If the AP 120 is configured for sending the RtSol message, it includes a parameter to inform the MN 110 of this fact in the AssResp sent at step 225).
As per claim 6: Haddad disclose a method comprising:
receiving, by a host device and from a network router (Figure 3-4: Access Router (AR), Host 800), a authenticating message ([0031]The AR 700 will be able to authenticate the signature of the MSG-A by use of the Ks stored in its cache memory. The host 800 will be able to authenticate the MSG-B signature by use of the Ks stored in its memory. [0037] The host 800 then compares a result of the hashing with the previously stored V(i) value at step 615. If a match is positive, this new periodic RtAdv is deemed authentic and information contained therein is stored in the host 800 memory at step 620. Specifically, the V(i+1) value from the new periodic RtAdv is now stored as a new V(i) value at step 620. If the match of step 615 is negative, this new periodic RtAdv is discarded at step 625. [0041] The AR 700 may generate another OWHC intended for authenticating multicast ND Advertisements sent by the host 800. This is especially useful when a specific host 800 for which the IPv6 address is advertised, is expected to exchange messages with many other parties on the same link) wherein the authenticating message:
was sent to a plurality of host devices (Figure 4: Host 800, 801); comprises a router advertisement message ([0031] A dedicated RtAdv message is sent towards the host at step 340. The dedicated RtAdv comprises the NA-IPv6, a CGA+ of the AR 700 and the encrypted Ks, and may further comprise a Mobility indicator (M). The encrypted Ks could alternatively be sent towards the host 800 is another type of message besides the RtAdv. Use of the RtSol and of the RtAdv messages in the sequence of FIG. 3 represents a preferred embodiment. As will be explained hereinbelow, in relation to FIG. 5, the M indicator will enable the host to sign other RtSol messages with the Ks, thereby consuming less processing resources than in the case of a CGA signature. The dedicated RtAdv is signed with the CGA- of the AR 700),
comprises a first hash value ([0046] The access router 700 broadcasts periodic RtAdv's sent in multicast towards all hosts 800 to which it is connected. In order to provide enhanced security to the periodic RtAdv's, the processing logic 730 may calculate a one-way hash chain of length "n", and identify public hash values from the one-way hash chain); and
comprises a router advertisement option value indicating a portion, of the router advertisement message, that was hashed to generate the first hash value ([0012]-[0013] A protocol named SEcure Neighbor Discovery (SEND), defined by the IETF RFC 3971, solves DOS attack issues by use of signatures and encryption. SEND relies on Cryptographically Generated Address (CGA) keys used by both the host and the AR to provide a strong signature to every message exchanged between these nodes. Use of CGA public and private keys provides a proof of ownership of the addresses of the host, of the AR and of other parties. However, CGA signature is a heavy process which requires extensive processing power. Using the CGA keys to sign every message exchanged between the AR and the host adds significant delays to the exchange. When battery-powered hosts such as mobile nodes or sensors are used, CGA key signatures may further cause high battery consumption. Another tool currently used in some systems to provide some level of security is a One-Way Hash (OWH) function. The OWH is a cryptographic hash function of a secret seed value, generally a random number, the result of which cannot be used to recover the value of the seed. A well-known example of hash function is called Secure Hash Algorithm (SHA), of which SHA-256 is preferably used because it provides a high level of security. The SHA function requires significantly less processing power than using the CGA keys A One-Way Hash Chain (OWHC) is formed from a seed V(n) when the result of hashing V(n) is hashed again to produce a value V(n-1), repeating the process "n" times by hashing again the result of the hash, in sequence, to obtain a n.sup.th value V(i=0). Hashing of a value V(i+1), where "i" is smaller than "n" produces a value V(i). With a strong hashing algorithm such as the SHA-256, it is not possible to infer the value V(i+1) from the value V(i). Once a first sending node has demonstrated its validity to a second receiving node by any means, and the second receiving node knows a V(k) value of the first sending node, the first sending node may demonstrate its validity by sending a value V(k+1). The second receiving node may hash the value V(k+1) and obtain the value V(k), thereby obtaining a proof of the identity of the first sending node). [0029] The present invention provides a method for optimization of the SEcure Neighbor Discovery (SEND) protocol, described in the Internet Engineering Task Force (IETF) Request For Comments (RFC) number 3971. It provides an Access Router (AR) and a host supporting this optimization. It uses a combination of a One-Way Hash Chain (OWHC) of length "n", and of Cryptographically Generated Address (CGA) public keys (CGA+) and CGA private keys (CGA-), to provide security of communication between the host and the AR. For the purposes of the present invention, a value V(i) of the OWHC, wherein "i" is in a range between zero and "n", is publicly disclosed on a link between the AR and hosts connected thereto. In a first place, the value V(i=0) is disclosed, for example in a multicast Router Advertisement message (RtAdv). Later, a value V(i+1) corresponding to a result of one less hashing iteration, is disclosed, and so on. CGA signatures are used in a first message pair exchanged between the host and the router, and a secret Key (Ks) is generated. Once the first message pair has been exchanged, CGA signatures are no longer used. Instead, the Ks is used to sign messages exchanged between the host and the router, and values of the OWHC are publicly disclosed in broadcast messages sent by the AR to enable the router to prove to the host that the broadcast messages are valid);
generating a second hash value based on the portion of the router advertisement message, indicated by the router advertisement option value ([0046] The access router 700 broadcasts periodic RtAdv's sent in multicast towards all hosts 800 to which it is connected. In order to provide enhanced security to the periodic RtAdv's, the processing logic 730 may calculate a one-way hash chain of length "n", and identify public hash values from the one-way hash chain. A last generated value of the chain is a first public hash value, with an index of value equal to zero (0). Then, a second to last generated value is a second public hash value, with an index value equal to one (1), and so on, each subsequent value of the chain becoming a subsequent public hash value and each subsequent index being incremented by one (i) from the previous index. The memory 700 stores the one-way hash chain in a hash value table 750 comprising entries, each entry having a hash value V(i) 754 along with an index (i) 752. The memory 740 also stores a current index (j) 766, which identifies an entry of the table 750 having an index (i=j) and a last publicly disclosed hash value V(i=j). The input port 720 sends periodic RtAdv's, each subsequent periodic RtAdv comprising one subsequent hash value V(i=j) 4, which becomes publicly disclosed. As described in relation to FIG. 2, the current index (j) is incremented by one (1) with the sending of each periodic RtAdv); and
authenticating the network router ([0040] Should the host 800 receive from the AR 700 the flag broadcasted as described at step 255 of FIG. 2, the value V(i) stored in the memory of the host 800 is no longer usable. The host 800 may request receipt of a new V(i) value, contained in a new RtAdv to be received from the AR 700, by sending a new RtSol message towards the AR 700, also comprising the lost synchronization indicator. The RtSol and RtAdv are, in this case also, preferably signed with the Ks; [0046] The access router 700 broadcasts periodic RtAdv's sent in multicast towards all hosts 800 to which it is connected. In order to provide enhanced security to the periodic RtAdv's, the processing logic 730 may calculate a one-way hash chain of length "n", and identify public hash values from the one-way hash chain);
communicating with the network router ([0041] The AR 700 may generate another OWHC intended for authenticating multicast ND Advertisements sent by the host 800. This is especially useful when a specific host 800 for which the IPv6 address is advertised, is expected to exchange messages with many other parties on the same link).
Haddad does not explicitly disclose comparing the first hash value and the second hash value. Rossi, in analogous art however, discloses comparing the first hash value and the second hash value ([0104] During the boot-strapping procedure, the MN 50 generates its CGHoA and sends the generated CGHoA to the HA 22 as part of a signature request. The HA 22 validates the CGHoA and provides the MN 50 with the CS.sub.HoA-HA signature shown in Table 5. To begin the boot-strapping procedure, the MN 50 receives a router advertisement message from an advertising router (AR) in its home network (step a). The router advertisement message includes the home subnet and CGHA of the HA 22. The CGHA Parameters and message authentication code {HMAC}.sub.PKHA are received with the router advertisement message. As previously noted, the CGHA Parameters contain the information elements used to generate the CGHA. The router advertisement may also optionally include the security policies regarding the GCHoA, signatures, or other related security parameters used in the home network 20 which must be respected by the MN 50. The MN 50 then generates a hash of the router advertisement message and extension, and compares it to the decrypted message authentication code to prove that HA 22 is the sender and that HA 22 owns the key used to generate CGHA. To validate CGHA, the MN 50 executes the hash-1 function using the CGHA Parameters and compares the results to the supplied CGHA. Provided that the validity checks are passed, the MN 50 then generates CGHoA using CGHA and the CGHA Parameters provided in the router advertisement message. [0110] To authenticate the MN 50, the HA 22 uses the shared key to decrypt the first message authentication code {HMAC}.sub.PKMNHA and compares the results with a computed hash of the signature request and extensions. To verify that the MN 50 owns the public key used to generate CGHoA, the HA 22 uses the public key provided in the CGHoA parameters to decrypt {HMAC}.sub.PKMN and compares the results to the hash of the signature request message and extensions. To validate the CGHoA, the HA 22 executes the hash-1 function according to Eq. 4 using the CGHoA Parameters and compares the results with the CGHoA supplied by the MN 50 in the signature request message. If the validity checks are successful, the HA 22 stores the backward key provided in the CGHoA Parameters for future authentication and generates the CS.sub.HoA-HA signature as shown in Table 5.) Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the message disclosed by Haddad to include comparing the first hash value and the second hash value. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a secure route optimization procedure that eliminates or reduces the security threats as suggested by Rossi ([0006]).
Haddad in view of Rossi do not explicitly disclose the authenticating message is a self-authenticating message. Levy, in analogous art however, discloses the authenticating message is a self-authenticating message ([0022] The routing circuit 52 can be configured for determining whether the router 28 having sent the router advertisement message 38 is authorized to advertise itself as a router, and/or advertise the address prefix 44 specified in the router advertisement message 38, within the local area network 14. [0024] The SEND authentication circuit 60 can be configured for determining whether the router 28, identified by its corresponding link local address 40 in the received router advertisement message 38, is authorized to advertise itself as a router and/or advertise the advertised address prefix (e.g., "2001:0210::/32") 44, for example based on determining whether the identified router 28 is identifiable from a prescribed list 68 of authorized routers having respective authorized address prefixes 70, or based on authenticating the supplied secure token 42 according to SEND protocol relative to the trust anchor 30). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the message disclosed by Haddad in view of Rossi to include the authenticating message is a self-authenticating message. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide enhanced deployment of Secure Neighbor Discovery (SEND) in an Internet Protocol version 6 (IPv6) network with certificate formats mandated by the SEND protocol that enable host nodes to learn a certification path of a router, and to validate the authenticity of a router as suggested by Levy ([0002]).
As per claim 7: Haddad in view of Rossi in further view of Levy discloses the method of claim 6, wherein generating the second hash value comprises hashing a capability attribute of the network router ( under BRI for “a capability attribute” of the router , it could be an interface identifier of a router and under RFC 3971 SEND protocol, SEND utilizes Cryptographically Generated Addresses (CGAs) to establish address ownership to prevent spoofing, it could be CGAs are IPv6 addresses where part of the address (typically the interface identifier) is generated from a cryptographic hash of the address owner's public key. Levy [0015]: The SEND-enabled IPv6 host node 26 is configured for performing secure neighbor discovery (SEND) as specified in RFC 3971, including obtaining configuration with a trust anchor 30 which can be reachable via an IP-based wide area network 32 in order to determine whether any router has a certification path that enables the SEND-enabled host 26 to authenticate any certificate, digital signature, or public key received from a router 12, 20, or 28. In particular, RFC 3971 requires that all router advertisement messages sent according to the SEND protocol include a digital signature, for example an RSA signature; as described herein, however, other secure tokens can be supplied, for example a public key, or a digital certificate such as an X.509v3 public key certificate; hence the term "secure token" as used herein refers to any one of the public key, the digital signature, or the digital certificate as described for example in RFC 3961).
As per claim 8: Haddad in view of Rossi in further view of Levy discloses the method of claim 6, wherein the router advertisement option value indicates a maximum transmission unit value of the router advertisement message (Levy [0015] The SEND-enabled IPv6 host node 26 is configured for performing secure neighbor discovery (SEND) as specified in RFC 3971, including obtaining configuration with a trust anchor 30 which can be reachable via an IP-based wide area network 32 in order to determine whether any router has a certification path that enables the SEND-enabled host 26 to authenticate any certificate, digital signature, or public key received from a router 12, 20, or 28. In particular, RFC 3971 requires that all router advertisement messages sent according to the SEND protocol include a digital signature, for example an RSA signature; as described herein, however, other secure tokens can be supplied, for example a public key, or a digital certificate such as an X.509v3 public key certificate; hence the term "secure token" as used herein refers to any one of the public key, the digital signature, or the digital certificate as described for example in RFC 3961. [0028] FIG. 4 is a diagram illustrating an example router advertisement message 72 output by the neighbor advertisement/router advertisement generation circuit 64 of the defending router 12, according to an example embodiment. The router advertisement message 72 generated by the circuit 64 can include an IPv6 header 76, router advertisement Internet Control Message Protocol (ICMP) fields 78 in accordance with Section 4.2 of RFC 2461, a Source Link-Layer Address (SLLA) Option field 79 in accordance with Sections 4.2 and 4.6.1 of RFC 2461, and a prefix information option (PIO) field 80 in accordance with Sections 4.2 and 4.6.2 of RFC 2461. In particular, the router advertisement message 72 generated by the generation circuit 64 of the defending router 12 includes an IP source address field 82 and an IP destination address field 86 in the IP header 76. The IP source address field 82 does not specify the link local address ("FE80::DF") 84 of the IPv6 interface circuit 50 of the defending router 12, but rather the generation circuit 64 inserts into the IP source address field 82 the link local address ("FE80::A") 40 of the rogue router 28. Hence, each IPv6 host 24 and 26 assumes that the router advertisement message 72 is transmitted from the rogue router 28, when in fact the defending router 12 impersonates the rogue router 28 by inserting the rogue router link local address 40 within the source address field 82 and its own MAC address 83 within the link layer address field 81 (the Type=1 field in the SLLA option 79 identifies the address field 81 as a source link-layer address). Note that the defense circuit 62, concurrently with generating the router advertisement message 72, can configure the IPv6 interface circuit 50 to accept incoming messages specifying the destination address "FE80::A" of the rogue router 28).
As per claim 9: Haddad in view of Rossi in further view of Levy discloses the method of claim 6, wherein the self-authenticating message comprises a code indicating that the self-authenticating message comprises a hash of the at least the portion of the router advertisement message (Levy [0009] In one embodiment, a method comprises receiving, by a router in a network, a router advertisement message on a network link of the network; detecting within the router advertisement message, by the router, an advertised address prefix and an identified router having transmitted the router advertisement message within the network; determining, by the router, whether the identified router is authorized to at least one of advertise itself as a router, or advertise the advertised address prefix on the network link; and selectively initiating, by the router, a defensive operation against the identified router based on the router determining the identified router is not authorized to advertise itself as a router, or advertise the advertised address prefix on the network link. Levy [0024] The SEND authentication circuit 60 can be configured for determining whether the router 28, identified by its corresponding link local address 40 in the received router advertisement message 38, is authorized to advertise itself as a router and/or advertise the advertised address prefix (e.g., "2001:0210::/32") 44, for example based on determining whether the identified router 28 is identifiable from a prescribed list 68 of authorized routers having respective authorized address prefixes 70, or based on authenticating the supplied secure token 42 according to SEND protocol relative to the trust anchor 30).
As per claim 10: Haddad in view of Rossi in further view of Levy discloses the method of claim 6, wherein the self-authenticating message is received from the network router without the host device previously sending information to the network router (Haddad [0027] At step 215, another MN 110 that did not earlier receive a periodic RtAdv message enters the coverage, or domain, of the AP 120. In order to set up a session, it sends at step 220 an Association Request (AssReq) message to the AP 120, to request setting up a connection. At step 225, the AP 120 replies with an Association Response (AssResp). The AssResp comprises all information it has recently cached for the RtAdv, including a given NI-HNV pair which preferably is one of many NI-HNV pairs currently cached in the AP 120. Alternatively, the AP 120 may send the AssResp and the RtAdv sequentially, as two distinct messages, within a very brief period. Optionally, the AP 120 may, at step 227, send a Solicitation to the AR 150, for example a Route Solicitation (RtSol) message, on behalf of the MN 110. This RtSol message, if sent at this step, will trigger sending, by the AR 150, of another RtAdv message to the MN 110, as is described hereinbelow. If the AP 120 is configured for sending the RtSol message, it includes a parameter to inform the MN 110 of this fact in the AssResp sent at step 225).
As per claims 11-12 and 14-15:
Claims 11-12 and 14-15 are directed to one or more non-transitory, computer-readable media storing instructions that, when executed, to perform substantially similar corresponding limitations of claims 1-2 and4-5 respectively and therefore claims 11-12 and 14-15 are rejected with the same rationale given above to reject claims 1-2 and 4-5 respectively.
As per claims 16-20:
Claims 16-20 are directed to one or more non-transitory, computer-readable media storing instructions that, when executed, to perform substantially similar corresponding limitations of claims 6-10 respectively and therefore claims 16-20 are rejected with the same rationale given above to reject claims 6-10 respectively.
As per claims 21-22 and 24-25:
Claims 21-22 and 24-25 are directed to a network router comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, configure the network router to perform substantially similar corresponding limitations of claims 1-2 and 4-5 respectively and therefore claims 21-22 and 24-25 are rejected with the same rationale given above to reject claims 1-2 and 4-5 respectively.
As per claims 26-30:
Claims 26-30 are directed to host device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, configure the host device to: perform substantially similar corresponding limitations of claims 6-10 respectively and therefore claims 26-30 are rejected with the same rationale given above to reject claims 6-10 respectively.
As per claims 31-32 and 34-35:
Claims 31-32 and 34-35 are directed to a system comprising: a host device and a network router, wherein the network router is configured to perform substantially similar corresponding limitations of claims 1-2 and 4-6 respectively and therefore claims 31-32 and 34-35 are rejected with the same rationale given above to reject corresponding limitations of claims 1-2 and 4-6 respectively.
As per claims 36-40:
Claims 36-40 are directed to a system comprising: a host device and a network router, wherein the host device is configured to perform substantially similar corresponding limitations of claims 1 and 6-10 respectively and therefore claims 36-340 are rejected with the same rationale given above to reject corresponding limitations of claims 1 and 6-10 respectively.
Allowable Subject Matter
Claims 3, 13, 23 and 33 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. The following is a statement of reasons for the indication of allowable subject matter: The prior arts of record either alone or in combination neither anticipates or renders obvious the when combined with their respective independent claims the following allowable subject matter: In claims 3, 13, 23, 33: wherein the router advertisement option indicates that a maximum transmission unit value of the router advertisement message is used to create the hashed portion of the router advertisement message.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached on (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408