Middlebox Communication BOF (midcom) THURSDAY, December 14 at 0900-1130 ================================== CHAIR: Melinda Shore" DESCRIPTION: As policy enforcement is increasingly being moved to the edges of networks and as trusted third parties are being asked to make policy decisions on behalf of the various entities participating in an application, a need has developed to be able to communicate policy to the devices that provide the policy enforcement points. Examples of these devices and applications include firewalls, network address translators (both within and between address families), signature management for intrusion detection systems, multimedia buffer management, application-aware caching, load balancers, and third-party SA provisioning. We refer to these as "intermediate devices." Decomposing applications requiring policy decisions by moving application logic into a controlling device provides a number of benefits, including improved performance, lower software development and maintenance costs, improved ability to support traversal of packet filters by complex protocols, and the ability to consolidate management functions. For example, by moving stateful inspection of protocols such as H.323 out of firewalls it is possible to improve performance and scalability and reduce development and maintenance costs. The elements of this architecture include . an intermediate device in a network . a request entity . a policy entity The request entity may be trusted or untrusted. In the case where it is trusted, the intermediate device will treat the request entity as authoritative. In the case where it is not trusted, the intermediate device will have to verify that it is authorized to complete the request. That authorization could come from a policy server or it could come from static configuration of the device. The focus of the working group will be the protocol between the intermediate device and the control entity and the protocol between the intermediate device and the policy entity. In both cases we intend to reuse existing or in process IETF protocols if possible. The security of the interfaces will be one of the primary focuses of the work, and potential vulnerabilities on the interfaces and in the architecture along with defenses against those threats will be identified. The deliverables will be . a document specifying the architecture and interfaces on . the control entity . the intermediate device . a document describing the requirements for both the architecture and the control language The goal of this BOF is to finalize the work needed to move forward as a working group. This includes reaching agreement on deliverables and schedule, resolving any outstanding questions about the charter, and moving towards a consensus on basic architecture. AGENDA: 5 min Agenda bashing 45 min Charter and deliverables review, discussion 15 min Related work in NAT working group 60 min Architecture and requirements 25 min Wrap-up and way forward DOCUMENTS: draft-ietf-nat-interface-framework-02.txt draft-kuthan-fcp-02.txt draft-tiphon-foglamps-01.txt