throbber
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Patent of: Munger et al.
`U.S. Patent No.: 6,502,135
`Issue Date: Dec. 31, 2002
`Appl. Serial No.: 09/504,783
`Filing Date: Feb. 15, 2000
`Title: AGILE NETWORK PROTOCOL FOR SECURE COMMUNICATIONS
`WITH ASSURED SYSTEM AVAILABILITY
`
`DECLARATION OF DR. ROCH GUERIN
`
`1.
`
`My name is Dr. Roch Guerin. I am the chair of the Computer Science &
`
`Engineering department at Washington University in St. Louis. I have been asked
`
`to offer technical opinions relating to U.S. Patent No. 6,502,135, and prior art
`
`references relating to its subject matter. My current curriculum vitae is attached
`
`and some highlights follow.
`
`2.
`
`I earned my diplôme d'ingénieur (1983) from École nationale supérieure des
`
`télécommunications, in Paris, France. Thereafter, I earned my M.S. (1984) and
`
`PhD (1986) in electrical engineering from The California Institute of Technology
`
`in Pasadena, California.
`
`3.
`
`Prior to becoming a professor in engineering, I held various positions at the
`
`IBM T.J. Watson Research Center. Specifically, from 1986 to 1990, I was a
`
`research staff member within the Communication Department, where I worked to
`
`design and evaluate high-speed switches and networks. From 1990 to 1991, I was a
`
`research staff member within the IBM High Performance Computing and
`
`Mangrove 1003
`
`

`
`Communications Department, where I worked to develop and deploy an integrated
`
`broadband network. From 1992 to 1997, I was the manager of Broadband
`
`Networking within IBM’s Security and Networking Systems Department, where I
`
`led a group of researchers in the area of design, architecture, and analysis of
`
`broadband networks. One of the projects on which I worked, for example, led to
`
`U.S. Patent No. 5,673,318, which regards “[a] method and system for providing
`
`data authentication, within a data communication environment, in a manner which
`
`is simple, fast, and provably secure,” and of which I am a named inventor. See U.S.
`
`Patent No. 5,673,318, Abstract. From 1997 to 1998, I was the manager of Network
`
`Control and Services within IBM’s Security and Networking Systems Department,
`
`where I led a department responsible for networking and distributed applications,
`
`including topics such as advance reservations, policy support, including for
`
`Resource Reservation Protocol (RSVP), quality of service (QoS) routing, and
`
`security, and integrated switch and scheduling designs.
`
`4.
`
`I have been a professor of engineering for the past sixteen years. As such,
`
`but prior to becoming the chair of the Computer Science & Engineering
`
`department at Washington University in St. Louis, I was the Alfred Fitler Moore
`
`Professor of Telecommunications Networks (an honorary chair) in the Department
`
`of Electrical and Systems Engineering at the University of Pennsylvania. As a
`
`professor of engineering, I have taught many courses in networking, including
`
`2
`
`

`
`Advanced Networking Protocols (TCOM 502), which addressed, among other
`
`things, virtual private networks.
`
`5.
`
`I have authored more than fifty journal publications, including “On the
`
`Feasibility and Efficacy of Protection Routing in IP Networks,” which was
`
`honored with the IEEE INFOCOM 2010 Best Paper Award. I have been named a
`
`Fellow by both the IEEE and ACM, and, from 2009 to 2012, I was the Editor-in-
`
`Chief of the IEEE/ACM Transactions on Networking. Furthermore, I am a named
`
`inventor on over thirty issued U.S. patents.
`
`6.
`
`I am familiar with the content of U.S. Patent No. 6,502,135 (the “‘135
`
`patent”). In addition, I have considered the various documents referenced in my
`
`declaration as well as additional background materials. I have also reviewed
`
`certain sections of the prosecution history of the ‘135 patent, the prosecution
`
`histories of
`
`reexamination control numbers 95/001,269, 95/001,679 and
`
`95/001,682; and the claim construction orders from VirnetX Inc. v. Microsoft
`
`Corp., Docket No. 6:07-CV-80 (E.D. Tex.) and VirnetX Inc. v. Cisco Systems, Inc.
`
`et al., Docket No. 6:10-cv-417 (E.D. Tex.).
`
`7.
`
`Counsel has informed me that I should consider these materials through the
`
`lens of one of ordinary skill in the art related to the ‘135 patent as of its effective
`
`filing date, and I have done so during my review of these materials. I believe one
`
`of ordinary skill as of February 15, 2000 (the priority date of the ‘135 patent)
`
`3
`
`

`
`would have a Master’s degree in computer science or computer engineering, or in a
`
`related field such as electrical engineering, as well as about two years of
`
`experience in computer networking and in some aspect of security with respect to
`
`computer networks. I base this on my own personal experience, including my
`
`knowledge of colleagues and others at the time.
`
`8.
`
`I have no financial interest in either party or in the outcome of this
`
`proceeding. I am being compensated for my work as an expert on an hourly basis.
`
`My compensation is not dependent on the outcome of these proceedings or the
`
`content of my opinions.
`
`9.
`
`My opinions, as explained below, are based on my education, experience,
`
`and background in the fields discussed above.
`
`10.
`
`This declaration is organized as follows:
`
`I. Brief Overview of the ‘135 Patent
`
`II.
`
`Terminology
`
`III. Kiuchi and Combinations Based on Kiuchi
`
`IV.
`
`Publication and Authenticity of Requests For Comment (RFCs)
`
`V. Conclusion
`
`4
`
`

`
`I.
`
`BRIEF OVERVIEW OF THE ‘135 PATENT
`
`11.
`
`The ‘135 patent is generally directed to a “agile network protocol for secure
`
`communications with assured system availability.” Ex. 1001, Title. The ‘135
`
`patent includes 18 claims, of which claims 1, 10, 13, and 18 are independent.
`
`12.
`
`A section of the ‘135 patent’s specification titled “B. Use of a DNS Proxy
`
`to Transparently Create Virtual Private Networks” describes “the automatic
`
`creation of a virtual private network (VPN) in response to a domain name server
`
`look-up function,” with reference to FIGS. 25-27. Ex. 1001 at 37:17-21. In the
`
`example embodiment, the ‘135 patent describes that a “specialized DNS server
`
`traps DNS requests and, if the request is from a special type of user (e.g., one for
`
`which secure communication services are defined), the server does not return the
`
`true IP address of the target node, but instead automatically sets up a virtual private
`
`network between the target node and the user.” Ex. 1001 at 37:63-38:2.
`
`13.
`
`In the case of standard “DNS requests that are determined to not require
`
`secure services (e.g., an unregistered user), the DNS server transparently ‘passes
`
`through’ the request to provide a normal look-up function.” Ex. 1001 at 38:6-9. On
`
`the other hand, if access to a secure site has been requested, the system described
`
`in the ‘135 patent “determines whether the user has sufficient security privileges to
`
`access the site,” and, if so, transmits a message requesting that a virtual private
`
`5
`
`

`
`network be created between the client and the secure target site. See Ex. 1001 at
`
`38:25-33. The ‘135 patent describes that the various functions of the DNS proxy,
`
`DNS server, and gatekeeper can be performed on the same or different machines.
`
`See Ex. 1001 at 38:53-55; 61-65.
`
`II.
`14.
`
`TERMINOLOGY
`I have been informed that claim terminology must be given the broadest
`
`reasonable interpretation during an IPR proceeding. I have been informed that this
`
`means the claims should be interpreted as broadly as their terms reasonably allow
`
`from the perspective of a person of skill in the art at the time, but that such
`
`interpretation should not be inconsistent with the patent’s specification. I have
`
`been informed that this may yield interpretations that are broader than the
`
`interpretation applied during a District Court proceeding.
`
`15.
`
`I have been informed that it would be useful to provide some guidance in
`
`this proceeding with respect to certain terms, and I have been asked to consider the
`
`term below and its corresponding interpretation. In doing so, I considered the
`
`term’s context within the claim, use within the specification, and my understanding
`
`of how one of ordinary skill in the art would understand the term around the time
`
`of the purported invention under the broadest reasonable interpretation standard.
`
`16.
`
`I have considered whether a broadest reasonable interpretation of “virtual
`
`private network” would be broad enough to cover “a secure network that includes
`
`6
`
`

`
`portions of a public network.” I believe that it would, since, as described below,
`
`such an interpretation is consistent with the ‘135 patent’s specification and the
`
`understanding one of ordinary skill in the art would ascribe to this term when
`
`looking for the broadest reasonable interpretation.
`
`17.
`
`There is not an explicit definition of “virtual private network” in the ‘135
`
`patent. However, the ‘135 patent describes that virtual private networks may be
`
`established over the Internet, and secured, for example, using public key
`
`encryption. See Ex. 1001 at 37:37-58. However, the ‘135 patent also contemplates
`
`other methods of establishing security. For example, the ‘135 patent describes the
`
`use of a quasi-random IP hopping scheme to implement a VPN. See, e.g., Ex. 1001
`
`at 23:10-14 (“In a second mode referred to as ‘promiscuous per VPN’ mode, a
`
`small set of fixed hardware addresses are used, with a fixed source/destination
`
`hardware address used for all nodes communicating over a virtual private
`
`network.”). Moreover, claims 6 and 11 rely on this embodiment. For example,
`
`claim 6 specifies that step 3 of claim 1 “comprises the step of establishing the VPN
`
`by creating an IP address hopping scheme between the client computer and the
`
`target computer.” Id. at 47:53-55 (emphasis added). Similarly, claim 11 specifies
`
`that the “gatekeeper” of claim 10 “creates the VPN by establishing an IP address
`
`hopping regime that is used to pseudorandomly change IP addresses in packets
`
`transmitted between the client computer and the secure target computer.” Id. at
`
`7
`
`

`
`48:20-24 (emphasis added); see also id. at 2:25-36 (explaining use of anonymity
`
`techniques).
`
`III. KIUCHI AND COMBINATIONS INVOLVING KIUCHI
`A.
`KIUCHI
`18.
`In general, Kiuchi describes a secure, closed HTTP-based network (C-
`
`HTTP) on the Internet, where each member of the network is protected by its own
`
`firewall. See Ex. 1002, p. 64, Abstract. Kiuchi describes that this secure, closed
`
`network can be used as a virtual network for connecting “closed groups; for
`
`example, the headquarters and branches of a given corporation.” Ex. 1002, p. 69, §
`
`5. The following Diagram 1 illustrates relevant parts within the C-HTTP system
`
`described by Kiuchi, and will be used to describe the system.
`
`19.
`
`Kiuchi describes a process by which a client-side proxy establishes a closed
`
`virtual network over the Internet with a server-side proxy, through which a user
`
`8
`
`

`
`agent associated with the client-side proxy may request information stored on an
`
`origin server associated with the server-side proxy. See Ex. 1002, p. 64, § 2.1. In
`
`particular, the client-side proxy performs various steps on behalf of the user agent
`
`to facilitate communications with an origin server and provides responses to a user
`
`agent’s resource requests. The C-HTTP connection established by the client-side
`
`proxy of Kiuchi relies on HTTP 1.0 exchanges as would any regular HTTP
`
`communication, and therefore the client-side proxy acts as a client computer in its
`
`communication with the server-side proxy and as a server in its communication
`
`with the user agent. See Ex. 1002, p. 67, § 4.2; see also Ex. 1014, p. 5 (T. Berners-
`
`Lee et al., Hypertext Transfer Protocol -- HTTP/1.0, RFC 1945, May 1996))
`
`(describing proxy as an “intermediary program which acts as both a server and a
`
`client for the purpose of making requests on behalf of other clients”).
`
`20.
`
`Kiuchi describes a number of discrete steps for establishing this secure C-
`
`HTTP connection, and, thus, creating an HTTP-based virtual network. See Ex.
`
`1002, pp. 65-66, § 2.3. These discrete steps for establishing the C-HTTP
`
`connection are illustrated in the following Diagram 2, in which each step is
`
`numbered to indicate a temporal sequence of the steps described by Kiuchi. Each
`
`numbered step will be described in detail with reference to subsequent diagrams
`
`created for explaining Kiuchi in this Declaration.
`
`9
`
`

`
`21. According to Kiuchi, the HTTP-compatible user agent may be used to
`
`display HTML documents to an end-user. See Ex. 1002, p. 65, § 2.3. Through
`
`interaction with the user agent, the end user may select a hyperlink URL included
`
`within an HTML document. See id. For example, the URL may take the form:
`
`http://server.in.current.connection/sample.html=@=6zdDfldfcZLj8V!i. Id. In this
`
`example URL, “server.in.current.connection” is the hostname, “sample.html” is the
`
`name of the resource being requested, and “6zdDfldfcZLj8V!i” is a connection ID
`
`used by the client-side proxy. As shown in this example, the “hostname” described
`
`by Kiuchi is a domain name. When the end user selects the hyperlink in the
`
`displayed HTML document, the user agent sends a request for the URL to the
`
`client-side proxy. See id.
`
`10
`
`

`
`22. When the client-side proxy receives the URL (including the hostname) from
`
`the user agent, it determines whether the connection ID included in the URL
`
`matches the IDs of any current connections being maintained by the client-side
`
`proxy. See id. If the connection ID is not found in the current connection table in
`
`the client-side proxy (or, presumably, if a connection ID is not present), the client-
`
`side proxy attempts to resolve the hostname through a query to the C-HTTP name
`
`server, and, if the C-HTTP name server returns an IP address, establish a new C-
`
`HTTP connection with the host corresponding to the hostname included in the
`
`URL. See id.
`
`23.
`
`As part of establishing a new C-HTTP connection with a host, the client-
`
`side proxy attempts to resolve the hostname included in the URL by asking the C-
`
`HTTP name server whether it can communicate with the host associated with the
`
`hostname. See 1002, p. 65, § 2.3(2). In some instances, the hostname corresponds
`
`to an origin server associated with a server-side proxy and is associated with an IP
`
`address for the server-side proxy. See Ex. 1002, p. 65, § 2.3. In other instances, the
`
`hostname corresponds to a server on the Internet outside the C-HTTP network. Id.
`
`Upon receipt of such a query, the C-HTTP name server first authenticates the
`
`client-side proxy to determine if the query is legitimate. Id. When the query is
`
`legitimate, the C-HTTP name server further determines “whether the requested
`
`server-side proxy is registered in the closed network and is permitted to accept the
`
`11
`
`

`
`connection from the client-side proxy.” Id. If the connection is permitted, the C-
`
`HTTP name server sends a response to the query that includes “the IP address and
`
`public key of the server-side proxy and both request and response Nonce values.”
`
`Id. If, on the other hand, the connection is not permitted, the C-HTTP name server
`
`returns an error message, in response to which the client-side proxy performs a
`
`look-up to a conventional DNS server. See id. In other words, prior to
`
`automatically initiating a C-HTTP connection between the client-side proxy and
`
`the server-side proxy, the C-HTTP name server determines whether the client-side
`
`proxy (and, through association, the user agent) is authorized to establish a C-
`
`HTTP connection and, if not so authorized, returns an error for the DNS request.
`
`24. Moreover, when the client-side proxy receives either an IP address or an
`
`error from the C-HTTP name server, the client-side proxy effectively determines
`
`whether the request received from the user agent is requesting access to either a
`
`secure web site (i.e., the C-HTTP name server returns an IP address for a server-
`
`side proxy within the C-HTTP network) or a nonsecure web site (i.e., the C-HTTP
`
`name server returns
`
`the above-described error message). Based on
`
`this
`
`determination, the client-side proxy either attempts to create a connection with the
`
`identified server-side proxy or, where an error message is received, “performs
`
`DNS lookup, behaving like an ordinary HTTP/1.0 proxy.” See Ex. 1002, p. 65.
`
`12
`
`

`
`25.
`
`To summarize, Diagram 3 illustrates: (1) a request sent from the user agent
`
`to the client-side proxy for a URL including a host name; (2) a query from the
`
`client-side proxy to the C-HTTP name server for information necessary to establish
`
`a C-HTTP connection with the server-side proxy associated with the host name
`
`included in the URL (when a C-HTTP connection does not already exist); and (3) a
`
`response from the C-HTTP name server that either includes the IP address
`
`associated with the host name or an error message. If the C-HTTP server returns
`
`an error message, then the client-side proxy performs a DNS lookup using the
`
`standard/public DNS, as illustrated by the dashed line.
`
`26.
`
`Kiuchi describes that each C-HTTP name server is particular to a closed C-
`
`HTTP network. See Ex. 1002, p. 65, § 2.2. Kiuchi describes the C-HTTP name
`
`13
`
`

`
`server, as opposed to a standard DNS, as performing name resolution for the C-
`
`HTTP private network. See Ex. 1002, p. 64, § 2.1 (“[t]he DNS name service is not
`
`used for hostname resolution”). In particular, Kiuchi describes: “When a given
`
`institution wants to participate in a closed network, it must 1) install a client-side
`
`and/or server-side proxy on its firewall, 2) register an IP address (for a server-side
`
`proxy, a port number should also be registered) and hostname (which does not
`
`have to be the same as its DNS name) for a firewall gateway, 3) give the proxy’s
`
`public key to the C-HTTP name server, and 4) obtain the C-HTTP name server’s
`
`public key.” Ex. 1002, p. 65, § 2.2.
`
`27.
`
`As described above, before providing the client-side proxy with the IP
`
`address of the server-side proxy, the C-HTTP name server “confirms that the query
`
`is legitimate” and determines “[i]f the connection is permitted.” Ex. 1002, p. 65, §
`
`2.3. Moreover, as illustrated in Diagram 4 (below), before the server-side proxy
`
`will accept a client-side proxy’s request for connection (see request to server-side
`
`proxy at 4), the server-side proxy “asks the C-HTTP name server whether the
`
`client-side proxy is an appropriate member of the closed network” (see request to
`
`name server at 5) and requests that the C-HTTP name server examine “whether the
`
`client-side proxy is permitted to access to the server-side proxy”. Ex. 1002, pp. 65-
`
`66, § 2.3. Communication of permission by the name server to the server-side
`
`proxy (see reply message at 6) is necessary and preliminary to communication of a
`
`14
`
`

`
`response from the server-side proxy to the client-side proxy that enables a C-HTTP
`
`connection to be established there between (see reply message at 7).
`
`28.
`
`Accordingly, the IP address of the server-side proxy (which corresponds to
`
`the hostname in the URL received by the client-side proxy) is a network address
`
`that requires authorization for access. The user agent and origin server are already
`
`part of private networks, as they are protected by the firewalls that host the client-
`
`side proxy and server-side proxy, respectively. See Ex. 1002, p. 64 (“each member
`
`is protected by its own firewall”). Because the C-HTTP connection creates a secure
`
`path between the proxies and thus effectively extends a secure path between the
`
`user agent and origin server, the user agent, client-side proxy, server-side proxy,
`
`and origin server become part of a virtual private network.
`
`15
`
`

`
`29.
`
`In summary, once the client-side proxy receives the IP address of the
`
`server-side proxy, the client-side proxy attempts to establish a C-HTTP connection
`
`with the server-side proxy. See Ex. 1002, p. 65, § 2.3(3). The steps described by
`
`Kiuchi for establishing the C-HTTP connection are illustrated in Diagram 5.
`
`30.
`
`In particular, Kiuchi describes that the client-side proxy sends a “[r]equest
`
`for connection to the server-side proxy” (4), the server-side proxy performs a
`
`“[l]ookup of client-side proxy information” (5 and 6), and the server-side proxy
`
`sends confirmation of the connection to the client-side proxy with the C-HTTP
`
`name server (5 and 6), and the server-side proxy sends confirmation of the
`
`connection to the client-side proxy (7), if the server-side proxy is able to properly
`
`authenticate the client-side proxy. See Ex. 1002, pp. 65-66, § 2.3, steps 3-5.
`
`16
`
`

`
`Through these steps, the server-side proxy acts as a gatekeeper computer that
`
`determines the security privileges of the client-side proxy (and, by association, the
`
`user agent) and allocates resources (e.g., “a connection ID derived from the server-
`
`side proxy’s name, date and random numbers (32 bits) using MD5, and also a
`
`second symmetric data exchange key for response encryption, which are sent to the
`
`client-side proxy”) for the secure connection between the user agent and the origin
`
`server. See Ex. 1002, pp. 65-66, § 2.3, steps 4-5.
`
`31.
`
`The operations of the client-side proxy to determine whether a request from
`
`the user agent is to a secure server within the C-HTTP network are transparent to
`
`the user agent. See Ex. 1002, p. 68, § 4.2. In particular, Kiuchi describes that the
`
`user agent and origin server operate solely based on standard HTTP/1.0 (as if the
`
`C-HTTP system did not exist), and, thus, “C-HTTP is transparent to both of them.”
`
`See id. Accordingly, the efforts of the client-side proxy to establish a secure
`
`connection with the corresponding server-side proxy are “automatic” from the
`
`perspective of the user agent, since the user agent simply issues a standard
`
`HTTP/1.0 request for content on the origin server and awaits a response.
`
`32.
`
`Having established the C-HTTP connection, the client-side proxy uses the
`
`C-HTTP connection to communicate access requests from the user agent to the
`
`server-side proxy. See Ex. 1002, p. 66, § 2.3, step 6. These requests each include
`
`the IP address of the server-side proxy, which the client-side proxy received from
`
`17
`
`

`
`the C-HTTP name server. See Ex. 1002, pp. 70-71, Appendix 1, § 1. Kiuchi
`
`describes an example of a request for the resource “sample.html” using an existing
`
`C-HTTP connection. See Ex. 1002, § 2.3, FIGS. (a)-(c). In particular, in the
`
`example described by Kiuchi with regard to FIGS. (a), (b), and (c), when the
`
`client-side proxy receives an indication that an end-user has requested to access the
`
`resource “sample.html” from the server-side proxy corresponding to hostname
`
`“server.in.current.connection,” the client-side proxy will forward a request using
`
`the C-HTTP
`
`protocols
`
`to
`
`the
`
`IP
`
`address
`
`corresponding
`
`to
`
`“server.in.current.connection,” if a C-HTTP connection with a connection ID
`
`“6zdDfldfcZLj8V!i” has already been established.
`
`33.
`
`Upon receipt of a request from a client-side proxy, “the server-side proxy
`
`forwards requests to [an] origin server,” which prepares standard HTTP/1.0
`
`responses that it returns to the server-side proxy. See Ex. 1002, p. 66, § 2.3(7)-(8).
`
`In the following Diagram 6, the steps for establishing a C-HTTP connection are
`
`illustrated as black arrows and the request for a resource sent using the C-HTTP
`
`connection is illustrated as a red arrow.
`
`18
`
`

`
`B.
`34.
`
`COMBINATION OF KIUCHI AND RFC 1034
`As described above, Kiuchi explains that, if a request by a user agent does
`
`not correspond to a domain name of another member of the C-HTTP network, the
`
`client-side proxy performs a conventional DNS lookup request. See Ex. 1002, p.
`
`65, § 2.3(2). In this instance, the function of DNS proxy is distributed among the
`
`client-side proxy and the C-HTTP name server. Alternatively, a person of ordinary
`
`skill in the art would have recognized that this conventional DNS lookup step
`
`could also be implemented by making a simple adaptation of the C-HTTP name
`
`server shown in Kiuchi, and that person would know how to do that based on the
`
`guidance in RFC 1034 (Ex. 1005)
`
`35.
`
`Specifically, the C-HTTP name server, which already performs a DNS
`
`look-up for secure pages, could be modified to also perform a DNS look-up for
`
`19
`
`

`
`non-secure pages. It would have been an obvious and straightforward design
`
`choice to consolidate all domain name resolution functions in the C-HTTP name
`
`server, as this would simplify and streamline the functions performed by the
`
`Kiuchi system. RFC 1034 notes that, “[i]n any system that has a distributed
`
`database, a particular name server may be presented with a query that can only be
`
`answered by some other server.” Ex. 1005, p. 4. Thus, RFC 1034 outlines two
`
`general approaches for dealing with such queries: a “recursive” approach and an
`
`“iterative” approach. In the “iterative” approach rather than itself resolving the
`
`query, the server lets the client pursue the query Ex. 1005, p. 4. This iterative
`
`approach is akin to the one described by Kiuchi as being used by the C-HTTP
`
`name server, which returns an error to the client-side proxy when it cannot resolve
`
`the requested domain name and the client-side proxy turns to a conventional DNS
`
`server. See Ex. 1002, p. 65, § 2.3(2). On the other hand, in the “recursive”
`
`approach taught by RFC 1034, “the first server pursues the query for the client at
`
`another server.” Ex. 1005, p. 4. The recursive mode is the “simplest mode for the
`
`client.” Ex. 1005, p. 21. On pages 21 and 22, RFC 1034 outlines the structure of a
`
`recursive name service.
`
`36.
`
`There is no practical or functional consequence for a user, based on where
`
`the name resolution step is performed. For example, the C-HTTP name server
`
`already determines whether the DNS request received from the client-side proxy is
`
`20
`
`

`
`requesting access to a secure target web site within the C-HTTP system. See Ex.
`
`1002, p. 65, § 2.3(2). Rather than returning an error status to the client-side proxy
`
`when the DNS request is not requesting access to a secure target web site, it would
`
`have been trivial to have the C-HTTP name server recursively pass the domain
`
`name received in the C-HTTP name service request to a conventional DNS server
`
`for name resolution, as described in RFC 1034. See Ex. 1005, pp. 21-22.
`
`37.
`
`Such a modification of Kiuchi’s client-side proxy and C-HTTP name server
`
`would have been a straightforward design choice based on the guidance in RFC
`
`1034. On pages 21 and 22, RFC 1034 outlines the manner in which a name server
`
`may implement a recursive resolution process. Applied to the client-side proxy and
`
`C-HTTP name server, the C-HTTP name server could be configured to first
`
`determine whether a host name for which resolution is sought by the client-side
`
`proxy is registered as part of the C-HTTP closed network. If it is, the C-HTTP
`
`name server will return the IP address, encryption key, and nonce values as
`
`described by Kiuchi. However, if the host name being resolved is not part of the C-
`
`HTTP closed network, the C-HTTP name server would make a query for the
`
`hostname to a standard/public DNS server on the client-side proxy’s behalf. If the
`
`C-HTTP name server is able to resolve the hostname through this standard DNS
`
`query, it would return the IP address to the client-side proxy. Otherwise, the C-
`
`HTTP name server would return an error.
`
`21
`
`

`
`38.
`
`The client-side proxy would be modified to recognize the difference
`
`between a response from the C-HTTP name server corresponding to a secure
`
`destination within the C-HTTP network and a standard destination resolved
`
`through the conventional DNS. For example, a C-HTTP name service response
`
`message containing an IP address without a public key and Nonce values (e.g.,
`
`using values of zero or other convention for the public key and Nonce fields, or
`
`modifying the protocol to use a previously unused flag in the response to indicate
`
`that a public key and Nonce values are not provided) could indicate to the client-
`
`side proxy that the DNS request is not requesting access to a secure target web site
`
`and hence that no VPN is needed.
`
`39.
`
`These types of modifications to the client-side proxy and C-HTTP name
`
`server were well within the ability of a person of ordinary skill in the art by 2000.
`
`40.
`
`One of ordinary skill in the art would have been motivated to modify Kiuchi
`
`in this way because doing so would streamline the operation of the system. For
`
`example, instead of having the C-HTTP name server send an error status to the
`
`client-proxy which would in turn initiate a standard/public DNS inquiry, the
`
`modification eliminates the error status message from the process by having the C-
`
`HTTP name server directly initiate the request to the standard/public DNS server.
`
`Therefore, the implementation of a recursive C-HTTP name server would
`
`recognize the benefits identified by RFC 1034. See Ex. 1005, p. 21.
`
`22
`
`

`
`IV. PUBLICATION AND AUTHENTICITY OF REQUESTS FOR
`COMMENT (RFCS)
`41.
`RFC 1034 discussed in this report is a “Request For Comment” or “RFC”
`
`document. These publications are prepared and distributed under a formalized
`
`publication process overseen by one of several Internet standards or governing
`
`bodies, such as the Internet Engineering Task Force (IETF).
`
`42.
`
`The way IETF RFC publications are prepared and released to the public is a
`
`formalized and structured process. In fact, the RFC development and publication
`
`process itself is described in an RFC – RFC 2026, dated October 1996. That RFC
`
`explains that that RFC publications and “Internet-Drafts” are widely disseminated
`
`on the Internet. For example, § 2.1 of RFC 2026 explains: “Each distinct version of
`
`an Internet standards-related specification is published as part of the “Request for
`
`Comments” (RFC) document series. This archival series is the official publication
`
`channel for Internet standards documents and other publications of the IESG, IAB,
`
`and Internet community. RFCs can be obtained from a number of Internet hosts
`
`using anonymous FTP, gopher, World Wide Web, and other Internet document-
`
`retrieval systems.” Ex. 1010, p. 5.
`
`43.
`
`RFC 2026 explains that once a standard is adopted, it will be published. See
`
`Ex. 1010, § 6.1.3 (“If a standards action is approved, notification is sent to the RFC
`
`Editor and copied to the IETF with instructions to publish the specification as an
`
`RFC.”).
`
`23
`
`

`
`44.
`
`RFC documents are published on a specific date, which starts a period for
`
`others to provide comments on the document. Ex.1010, pp. 19-20 (§ 6.2) (“These
`
`minimum periods are intended to ensure adequate opportunity for community
`
`review without severely impacting timeliness. These intervals shall be measured
`
`from the date of publication of the corresponding RFC(s)…”). The publication date
`
`of each RFC is contained in the RFC, typically in the top right corner of the first
`
`page of the document. This is the date it was released for public distribution on the
`
`Internet.
`
`45.
`
`Each RFC document is uniquely numbered. If it becomes necessary to make
`
`a substantive change (e.g., other than a minor typographical error), the RFC will be
`
`republished with a different number. See e.g., Ex. 1010, pp. 19-20 (§ 6.2) (“… the
`
`IESG or RFC Editor may be asked to republish the RFC (with a new number) with
`
`corrections…”).
`
`46.
`
`The formalized process of preparing, publishing and widely distributing
`
`RFC documents is a very important part of the Internet culture, which works to
`
`develop standards in an open and transparent process. It is also important to the
`
`adoption of these standards, and the stability and functionality of the Internet for
`
`developers to adhere to standards and evolving “best practices.”
`
`47.
`
`Because RFC documents are formally prepared and published, and are then
`
`widely distributed without any restrictions, they are printed publications as of the
`
`24
`
`

`
`date printed on their front page. As such, I understand the RFCs relied upon herein
`
`and submitted for this proceeding are authentic.
`
`25
`
`

`
`V. CONCLUSION
` I hereby declare that all statements made herein of my own knowledge are
`48.
`
`true and that all statements made on information and belief are believed to be true;
`
`and further that these statements were made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both,
`
`under Section 1001 of Title 18 of the United States Code.
`
`
`
`Signature: _______________

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket