You could certainly build a route service to support this use case. Users
would create a service instance of the service, configure it to block
specified IPs (on create, bind, or out-of-band), then bind it to the route,
causing requests to the route to be forwarded to the service instance,
which would block the requests or pass them through. All applications
mapped to the route would be protected.

Route Services opens a whole new class of services which could be offered
in the marketplace by exposing an point of extension. Now all these
features don't have be to implemented directly in the router itself.

Our work on support for Route Services has nearly reached MVP. The backend
work is nearly complete, and we've started work on the CLI commands. Soon
we'll publish documentation for service broker authors as well as end users.

I'll also be sending a request for feedback shortly on a header we're using
in the integration that must be handled by the services. With a few changes
we could support standard forwarding proxies as Route Services per the http
rfc, but it comes with tradeoffs. Stay tuned.

For now, you can refer to these docs for info about the Route Services
feature:
- UX proposal:
https://drive.google.com/open?id=1SfwaQ1hnngfopXC_Q24cT6lbo0yFwvbAbPcCPEHeNPY
- Original proposal:
https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing
- Tracker epics: https://www.pivotaltracker.com/epic/show/1884060 and
https://www.pivotaltracker.com/epic/show/2031344

Please let me know if you have any questions.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.