DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 10,942,795 to Yanacek, and further in view of US 10,419,403 to Wining et al.
Regarding claim 1 Yanacek teaches method comprising:
receiving, by one or more hardware processors, a request to execute a user-defined function (UDF) within a sandbox process (FIG. 1 is a block diagram depicting an illustrative environment in which an on-demand code (UDF) execution system can operate to distribute calls to execute tasks. Col. 8, lines 32-35: he program codes can be executed in isolated containers that are created on the virtual machine instances (sandbox)).
Yanacek acknowledges that isolated execution environments require network access to fetch external data. But lacks or does not expressly disclose a secure egress path.
However Wining teaches
establishing a secure egress path for the UDF using an overlay network ,
wherein the overlay network includes a dedicated DNS resolver at a proxy service (establishing a secure egress path from an isolate compute environment using an over lay network, IPSEC or GRE tunnel routed to an external proxy service, This proxy service includes a dedicated DNS proxy).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Yanacek with Wining to include an egress path, in order to provide outside secure communication.
Yanacek, as modified above, further teaches
receiving, from the UDF, a DNS request to resolve a hostname (when the executing code initiates an outbound API call, the resulting DNS request is intercepted and routed over the overlay network to the proxy);
validating, by the proxy service, that the hostname is included in an allowed host list associated with the UDF (Wining further teaches the proxy service evaluates the requested DNS hostname against policy configurations, validating it against a tenant or application specific allowed host list (allowlist) before permitting resolution);
resolving, by the dedicated DNS resolver, the hostname to an IP address using a UDP listener configured to handle DNS protocol traffic on a designated port of the proxy service; and
enabling the UDF to communicate with a host at the resolved IP address via the secure egress path (the DNS proxy operates a UDP lister bound to port 53 (Wining the standard designated port for DNS protocol traffic).
Regarding claim 2, Yanacek as modified above further discloses the method of claim 1, wherein establishing the secure egress path comprises:
identifying a virtual ethernet pair to isolate UDF traffic within the sandbox process;
using the virtual ethernet pair to put an ethernet device in a namespace of the sandbox process; and
implementing packet encapsulation between an execution platform and the proxy service.
Regarding claim 3, Yanacek as modified above further discloses the method of claim 1, further comprising:
deploying, on the proxy service, an extended Berkeley Packet Filter (eBPF) to decapsulate DNS packets;
extracting a policy identifier from the decapsulated DNS packets; and
validating the policy identifier against stored egress policies (Fig. 1).
Regarding claim 4, Yanacek as modified above further discloses the method of claim 1, wherein the overlay network comprises, a first tier implementing virtual ethernet pairs for sandbox isolation, a second tier providing Generic Network Virtualization Encapsulation (GENEVE) tunneling between an execution platform and the proxy service, and a third tier handling verified packet routing to external destinations (Fig. 3, col. 6 lines 2-20).
Regarding claim 5, Yanacek as modified above further discloses the method of claim 1, further comprising:
collecting metric event information associated with DNS resolution attempts;
logging unauthorized hostname resolution attempts; and
publishing metrics to an administrator interface (Fig. 3, col. 9 lines 2-20).
Regarding claim 6, Yanacek as modified above further discloses the method of claim 1, wherein validating the hostname comprises:
performing a lookup in a policy map using a sandbox identifier;
verifying DNS patterns against wildcard-based allowlist entries; and
reporting policy violations to a security monitoring system (Fig. 3, col. 6 lines 1-40).
Regarding claim 7, Yanacek as modified above further discloses the method of claim 1, further comprising:
maintaining a connection map at the proxy service to track authorized DNS resolutions;
performing Source Network Address Translation (SNAT) on validated packets; and
routing translated packets to authorized external destinations (Fig. 3, col. 10 lines 2-20).
Regarding claim 8, Yanacek as modified above further discloses the method of claim 1, wherein the proxy service implements:
a packet decapsulation filter;
an authorization filter for policy enforcement; and
a dynamic forward upstream cluster for routing resolved DNS requests (Fig. 6, col. 6 lines 2-20).
As per claims 9-16 and 17-20, this is a system and medium version of the claimed method discussed above in claims 1-8 wherein all claimed limitations have also been addressed and/or cited as set forth above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AUBREY H WYSZYNSKI whose telephone number is (571)272-8155. The examiner can normally be reached M-F 9-5.
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, ALI SHAYANFAR can be reached at 571-270-1050. 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.
/AUBREY H WYSZYNSKI/Primary Examiner, Art Unit 2434
Prosecution Insights