Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation segments
for your use cases, we'd like to know whether you would be inclined to use
dedicated routing tiers for isolation groups in production without the
proposed enhancements below, or whether you would require either/both of
the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an isolated
pool of Diego Cells. On its own, this design will rely on a shared routing
tier with access to all isolation segments. This requires an operator to
carefully configure their load balancer and firewall rules to prevent an
attacker using a spoofed Host header to reach an application that shouldn't
be publicly routable.

An operator can currently deploy dedicated deployments of routers for an
isolation segment but the routing table will be shared among them. Should a
misconfigured load balancer forward a request to routers for an app on
another isolation segment, the routers will attempt to route the request.
If the firewall is correctly configured, the router will return a 502. If
the firewall is misconfigured, a private app may be publicly accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation
segment will only route requests for apps in an associated isolation
segment; if a load balancer were misconfigured, and a request for an app in
another isolation segment were forwarded to the routers, a 404 would be
returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A space
is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.
foo.example.com at routers for isolation segment IS-1 and *.
bar.example.com at routers for isolation segment IS-2, there's nothing
preventing an app developer from creating a route from domain
foo.example.com in a space associated with IS-2. Requests to the route
will fail and the developer would not know why. To prevent this, we'll
enable API clients to filter domains by targeted space, so that a developer
only sees domains from which they can create working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements for
routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.