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
he examiner fully reviewed the applicant’s argument remarks filed on 06/25/2026 in response to the Office Action mailed on 06/03/2026. However, the applicant’s arguments are not persuasive to overcome the prior ats in record and place the claims and the application in condition for allowance for at least the following reasons:
In the response the applicant argues that Haddad dedicated RtAdv (the alleged "authenticating message') would not comprise the Haddad periodic RtAdv (the alleged "router advertisement message") - they are different messages with different content and sent differently. Claim 1 recites that the "self-authenticating message" comprises the "router advertisement message."
Applicant requests clarification as to what "authenticating message" in the combination would comprise the "router advertisement message." Haddad specifically states that "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… Applicant submits that a person of ordinary skill in the art (POSITA), seeing Haddad's complaint about CGA signatures being "heavy," would not have wanted to add the CGA signature feature that the Office finds in Droms. If this rejection is maintained, Applicant requests clarification as to why a POSITA would have disregarded Haddad's teachings to make the alleged modification. See, e.g., MPEP 2143.01(V) ("The Proposed Modification Cannot Render the Prior Art Unsatisfactory for its Intended Purpose"). Furthermore, with Haddad's use of its OWHC value V(i+1), the issue of authentication is already taken care of. There would be no need for the addition of the "heavy" CGA signature process from Droms. A POSITA would have no reason for making the modification that the Office proposes.
The examiner notes that the current application under examiner describes a way for a network router to prove it is authentic when it sends router advertisement messages to nearby devices. The router adds a special hash-based value to the message, using a secret value known to the router. Host devices receive the message and independently compute their own matching hash from stored values. If the two values match, the hosts treat the router as genuine and continue communicating with it. The approach is designed to work in multicast or broadcast settings, where many hosts may receive the same router message at once. It is aimed especially at IPv6 neighbor discovery and router advertisement traffic. The disclosure says the technique avoids some of the complexity of IPSec and SEND, which can be hard to deploy in large networks (See Paragrphs [0015- 0018]). The router can include identity or capability information in the authenticated message. The host does not need to send a challenge first, so the process is one-way and more suitable for router announcements. If the hashes do not match, the host rejects the message. The overall result is a self-authenticating router message that helps prevent spoofed network advertisements. In Haddad [0035], the host 800 verifies the Ks signature of the RtAdv st step 540 and if this signature is valid it stores the new NA-IPv6 address, the CGA+ of the nAR and the value V(k) at step 545. At [0037] the host the 800 then compares a result of the hashing with the previously stored V(i) value at step 615 which effectively authenticates the router advertisement message.
The prior art the prior art Haddad discuses, existing secure neighbor-discovery techniques, especially those based on Cryptographically Generated Address signatures, are computationally heavy. Repeating those expensive signatures for every router-host exchange can add delay and increase power consumption, which is especially problematic for battery-powered devices. It further notes security risks such as denial-of-service attacks and spoofed router advertisements or neighbor discovery messages. The problem is to maintain strong protection while limiting repeated use of heavy cryptographic operations. As a solution to the above-described problem, Haddad uses public-key cryptography only at the beginning to establish trust and deliver a secret key, then switches later communications to lighter secret-key signatures. At the same time, it uses a one-way hash chain to authenticate periodic router advertisements. This combination reduces processing costs while still allowing the router and host to verify that messages are legitimate. The same secret-key framework is extended to neighbor discovery and mobility support (See paraphs [0013]-[0019]). Furthermore, in a similar field of endeavor, as a secondary reference the prior art Droms describes existing routers can advertise prefixes for host autoconfiguration, and prefix delegation has traditionally relied on DHCP-based mechanisms. It identifies a need for routers to autonomously obtain and use delegated prefixes on local networks without requiring a routing protocol between routers. It further addresses the need to avoid prefix conflicts and to let routers defend or query claimed prefixes securely. Droms states the problem is how to deploy routers that can independently derive usable downstream prefixes in a consistent, scalable, and collision-aware way. As a core solution, it provides the router listens for an unsolicited router advertisement that includes both a normal autoconfiguration prefix and a delegated prefix. It then automatically forms its own downstream prefix by concatenating the delegated prefix with a generated suffix. That suffix is produced either from a CGA-derived hash output or from a distributed-hash-table assigned index, so the prefix can be generated consistently and/or uniquely. The router may then validate, claim, and defend the selected prefix using neighbor discovery. Droms in [0038 & 0045] discloses the hashed portion of the router advertisement using a secret value of the network router; and the router advertisement option is in the router advertisement message. For at least the above reasons, the applicant’s argument are not persuasive to overcome the prior arts in record and place the claims in a better condition for allowance.
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 Droms (US 20080263353 A1 –hereinafter—" Droms” 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, a router advertisement option ([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 800 hosts 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 and the hashed router advertisement option ([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); and
communicating with the plurality of host devices after the host devices authenticate the 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; and the router advertisement option is in the router advertisement message. Droms, in analogous art however, discloses the hashed portion of the router advertisement message is using a secret value of the network router ([0038] Assuming the routing circuit 28 is configured for executing the CGA-based autoconfiguration of the autoconfigured IPv6 address prefix 15, the memory circuit 42 can be configured for storing an RSA public key 64 of the router, the RSA private key 63 that corresponds to the public key 64, and additional CGA parameters used for generating the CGA address value (e.g., "CGA1") 44 according to RFC 3972, including a pseudorandom modifier value 48, a collision count value 43, and optional extension fields 45 specified within the CGA parameters data structure generated by the routing circuit 28. [0066] The neighbor advertisement message 112 also includes the CGA option 76 including the identical parameters as illustrated in FIG. 4. The prefix ownership option 132 specifies a type of field 80 having a value (e.g., "Type=B") identifying that the autoconfigured prefix 15 is owned by the router outputting the NA message 112. The routing circuit 28 can sign the neighbor advertisement message 112 by adding the RSA signature option 130 including the digital signature 114, based on performing a cryptographic hash of the preceding portions 50, 74, 126, 76, and 132 with the private key 66); and
the router advertisement option is in the router advertisement message([0045] The neighbor advertisement message 14 can include an IPv6 header 50 according to RFC 2460, a router advertisement message header 52, a prefix information option 16, a prefix delegation information option 18, and an optional CGA parameters assignment option 70. If preferred, the prefix information option 18 can be omitted, such that the prefix information option 16 and CGA parameters assignment operation 70 can be sent in one router advertisement message, and the prefix delegation option 18 can be sent in another distinct router advertisement message. Although not shown in FIG. 3, the router advertisement message 14 also can includes an RSA signature option according to RFC 3971. The neighbor solicitation message 72 of FIG. 4 and the neighbor advertisement message 112 of FIG. 6 also can include the RSA signature option according to RFC 3971. The router advertisement message header 52 includes ICMP fields as specified in section 4.2 of RFC 2461. The prefix information option 16 specifies the assigned prefix 11 for autonomous address autoconfiguration, as described in section 4.2 of RFC 2461. The prefix delegation information option (PDIO) 18 specifies a delegated IPv6 address prefix and can also specify a type of field 58, a option length field 60, a prefix length field 62, a required delegated prefix length (DPL) field 65, and a delegation authorization identifier 66. The type field 58 identifies the prefix delegation information option (PDIO) 18 to ensure that the specified delegated prefix 56 is used for IPv6 address prefix delegation, and not autonomous address configuration; in other words, the type field 58 uniquely identifies the option 18 to ensure that the option 18 is not confused with the existing prefix information option 16 that is used for address autoconfiguration. The length field 60 specifies the length of the option 18, and the prefix length field 62 identifies the length (e.g., "x") of the delegated prefix in terms of the number of valid bits; hence, if the 128-bit delegated prefix field 56 specifies a hexadecimal value of "0x2001:0DB8::" (according to the conventions in RFC 3513) and the prefix length field 62 specifies a (decimal) value of "48", then the PDIO 18 specifies the IPv6 address prefix "2001:0DB8::/48" according to the conventions in RFC 3513. [0057] The unsolicited router advertisement message 14 can include a prefix information option 16 specifying an address autoconfiguration prefix 11, and/or a prefix delegation information option 18. The router advertisement message 14 also can include a CGA parameters assignment option 70, as illustrated in FIG. 3. In response to the prefix information option 16, the routing circuit 28 can initiate address autoconfiguration in step 142 in order to generate the CGA address as described in RFC 3972. For example, the routing circuit 28 can use in step 144 the supplied modifier 48 specified in the CGA parameters assignment option 70, if the option 70 is supplied in the router advertisement message 14; if the router advertisement message 14 does not include a CGA parameters assignment option 70, the routing circuit 28 can dynamically generate its own modifier 48 as a pseudorandom 128-bit value, in accordance with RFC 3972. The routing circuit 28 can then generate a secondary hash "Hash2" in step 146 based on performing an SHA-1 hash of the concatenated data structure of the modifier 48 obtained in step 144, followed by 9 zero octets (i.e., 72 bits), followed by the router public key 64, followed by any optional extensions 45. The symbol "|" illustrated in FIG. 5 (e.g., steps 146, 150, 152, 154) and FIG. 8 (e.g., steps 215, 222) refers to concatenating together adjacent data values. The 112 leftmost bits of the SHA-1 hash value generated in step 146 are used to form the 112-bit "Hash2" value). 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 router advertisement option disclosed by Haddad is in the router advertisement message and 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 to automatically select a second IPv6 address prefix for use on the at least one ingress link based on concatenating a suffix to the delegated IPv6 address prefix, and dynamically generating the suffix based on a prescribed distributed hash operation as suggested by Droms ([0016]).
Haddad and Droms 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 Droms 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 Droms 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 Droms 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 router advertisement option (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 Droms in further view of Levy discloses the method of claim 1, wherein the self-authenticated message is generated without using previously -received 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
comprising a hashed router advertisement option ([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 router advertisement option ([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; and the router advertisement option is in the router advertisement message. Droms, in analogous art however, discloses comparing the first hash value and the second hash value ([0057] In response to the prefix information option 16, the routing circuit 28 can initiate address autoconfiguration in step 142 in order to generate the CGA address as described in RFC 3972. For example, the routing circuit 28 can use in step 144 the supplied modifier 48 specified in the CGA parameters assignment option 70, if the option 70 is supplied in the router advertisement message 14; if the router advertisement message 14 does not include a CGA parameters assignment option 70, the routing circuit 28 can dynamically generate its own modifier 48 as a pseudorandom 128-bit value, in accordance with RFC 3972. The routing circuit 28 can then generate a secondary hash "Hash2" in step 146 based on performing an SHA-1 hash of the concatenated data structure of the modifier 48 obtained in step 144, followed by 9 zero octets (i.e., 72 bits), followed by the router public key 64, followed by any optional extensions 45. The symbol "|" illustrated in FIG. 5 (e.g., steps 146, 150, 152, 154) and FIG. 8 (e.g., steps 215, 222) refers to concatenating together adjacent data values. The 112 leftmost bits of the SHA-1 hash value generated in step 146 are used to form the 112-bit "Hash2" value. [0058] The secondary hash value "Hash2" generated in step 146 is tested by the routing circuit 28 in step 148, as described in section 4 of RFC 3972, to ensure the 16*Sec leftmost bits of the "Hash2" value are all zeros (or if Sec=0). If the test fails in step 148, the routing circuit 28 increments the modifier value by one and regenerates the secondary hash value in step 146. [0059] The routing circuit 28 next generates in step 150 the primary hash value "Hash1". In particular, the routing circuit 28 performs an SHA-1 hash of the concatenated data structure of the final modifier value concatenated with the subnet prefix 11, a collision count initially set to zero, the router public key 64, and any optional extension fields 45. The leftmost 64 bits of the SHA-1 hash performed in step 150 are used to form the 64-bit "Hash1" value. The routing circuit 28 also forms in step 150 an interface identifier from the generated primary hash value "Hash1" by writing the value of the security perimeter "Sec" into the three leftmost bits and by setting bits six and seven to zero. The interface identifier can then be used to identify the egress interface circuit 32 for communications on the attachment link 20b); and
the router advertisement option is in the router advertisement message([0045] The neighbor advertisement message 14 can include an IPv6 header 50 according to RFC 2460, a router advertisement message header 52, a prefix information option 16, a prefix delegation information option 18, and an optional CGA parameters assignment option 70. If preferred, the prefix information option 18 can be omitted, such that the prefix information option 16 and CGA parameters assignment operation 70 can be sent in one router advertisement message, and the prefix delegation option 18 can be sent in another distinct router advertisement message. Although not shown in FIG. 3, the router advertisement message 14 also can includes an RSA signature option according to RFC 3971. The neighbor solicitation message 72 of FIG. 4 and the neighbor advertisement message 112 of FIG. 6 also can include the RSA signature option according to RFC 3971. The router advertisement message header 52 includes ICMP fields as specified in section 4.2 of RFC 2461. The prefix information option 16 specifies the assigned prefix 11 for autonomous address autoconfiguration, as described in section 4.2 of RFC 2461. The prefix delegation information option (PDIO) 18 specifies a delegated IPv6 address prefix and can also specify a type field 58, an option length field 60, a prefix length field 62, a required delegated prefix length (DPL) field 65, and a delegation authorization identifier 66. The type field 58 identifies the prefix delegation information option (PDIO) 18 to ensure that the specified delegated prefix 56 is used for IPv6 address prefix delegation, and not autonomous address configuration; in other words, the type field 58 uniquely identifies the option 18 to ensure that the option 18 is not confused with the existing prefix information option 16 that is used for address autoconfiguration. The length field 60 specifies the length of the option 18, and the prefix length field 62 identifies the length (e.g., "x") of the delegated prefix in terms of the number of valid bits; hence, if the 128-bit delegated prefix field 56 specifies a hexadecimal value of "0x2001:0DB8::" (according to the conventions in RFC 3513) and the prefix length field 62 specifies a (decimal) value of "48", then the PDIO 18 specifies the IPv6 address prefix "2001:0DB8::/48" according to the conventions in RFC 3513. [0057] The unsolicited router advertisement message 14 can include a prefix information option 16 specifying an address autoconfiguration prefix 11, and/or a prefix delegation information option 18. The router advertisement message 14 also can include a CGA parameters assignment option 70, as illustrated in FIG. 3. In response to the prefix information option 16, the routing circuit 28 can initiate address autoconfiguration in step 142 in order to generate the CGA address as described in RFC 3972. For example, the routing circuit 28 can use in step 144 the supplied modifier 48 specified in the CGA parameters assignment option 70, if the option 70 is supplied in the router advertisement message 14; if the router advertisement message 14 does not include a CGA parameters assignment option 70, the routing circuit 28 can dynamically generate its own modifier 48 as a pseudorandom 128-bit value, in accordance with RFC 3972. The routing circuit 28 can then generate a secondary hash "Hash2" in step 146 based on performing an SHA-1 hash of the concatenated data structure of the modifier 48 obtained in step 144, followed by 9 zero octets (i.e., 72 bits), followed by the router public key 64, followed by any optional extensions 45. The symbol "|" illustrated in FIG. 5 (e.g., steps 146, 150, 152, 154) and FIG. 8 (e.g., steps 215, 222) refers to concatenating together adjacent data values. The 112 leftmost bits of the SHA-1 hash value generated in step 146 are used to form the 112-bit "Hash2" value). 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 router advertisement option disclosed by Haddad is in the router advertisement message and 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 to automatically select a second IPv6 address prefix for use on the at least one ingress link based on concatenating a suffix to the delegated IPv6 address prefix, and dynamically generating the suffix based on a prescribed distributed hash operation as suggested by Droms ([0016]).
Haddad in view of Droms 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 Droms 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 Droms 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 Droms in further view of Levy discloses the method of claim 6, wherein the router advertisement option value indicates a maximum transmission unit 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 Droms 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 router advertisement option (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 Droms 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.
Aura US 20050041634 A1 describes a way for a mobile device to prove both who it is and where it is on the network when it sends an address update. The device first asks nearby access routers for a secure router advertisement. That advertisement includes identifying information for the device, such as its home address or public key, and a signed statement from the access router. The mobile device then attaches that signed router advertisement to its binding update or other address update. A correspondent node can use the attached data to check that the update really came from the claimed mobile node. It can also check that the node is actually connected through the advertised subnet prefix, which helps prove location. The approach is designed for Mobile IPv6, but the specification says it can be used with other protocols that use address updates. The system reduces the need for multi-message handshakes. It also avoids relying only on outside certificate authorities or other heavier infrastructure. In effect, the invention creates a single-message proof that combines identity verification and location verification.
Malinen US 20030028763 A1 describes a way to authenticate a mobile user and authorize access to a network service using three parties instead of just two. The three parties are the client, an authorizer, and a local attendant that relays messages between them. The client sends an identity, the authorizer issues a challenge, and the client proves it knows the right SIM-based credentials by responding correctly. If the client is accepted, the authorizer lets a peer or service provider use a session key for the client’s access. The client does not necessarily receive that key directly over the network; instead, the client can recreate its own copy using information stored on its SIM card. The system is designed for IPv6 and can work with mobile nodes, access routers, home agents, and service peers. It uses local challenges and replay protection to prevent reuse of old authentication messages. The local attendant also helps route messages to the proper authentication gateway. The invention supports network access, encryption, and service authorization. It aims to make authentication scalable and easier to deploy across different domains.
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
Prosecution Insights