Repository navigation
BEP: decide how the proxy checks an unsealed host_ip cohort request #3074
Description
Situation
T119 (#2855, PR #3065) delivers host_ip cohort connections to the Box Egress Proxy under a reserved cohort id. The proxy cannot tell which member sent such a connection.
The redeemer handles cohort requests in two ways:
- A request with a sealed value is checked again against the egress of the box that the value names (BEP-084).
- A request with no sealed value is checked against the union of every resident
host_ipbox's egress (BoxRedeemer::egressincrates/bep/src/redeemer.rs).
Networking §4.3 rule 2 (line 84) makes that union the shared cohort address's reach, and BEP-030 needs unsealed requests to pass through, for example git's first request before its 401. The owner accepted the union for T119.
Networking §7.1 line 253 also gates host_ip on a VM node per box, by the classifier inside the VM. If that per-box gate covers a box's ordinary egress, then box A can send an unsealed request through the proxy to a host that only box B declares. A has no direct reach to that host. The review finding on #3065 (thread PRRT_kwDOPdfcxM60SWjv) raised this.
Done when
The design of record says how the proxy checks an unsealed cohort request. One of these holds:
- The design records that the union is the intended reach of an unsealed cohort request, and says why that does not widen a box's per-box reach inside the VM.
- Or the proxy checks an unsealed cohort request against the sending box's egress, with the sender identified by a mechanism the design names, and a test shows box A refused at a host that only box B declares.
Not checked
Whether the in-VM classifier gates a host_ip box's ordinary egress per destination, or only the proxy's address and UDP 443.
Activity