Minutes of the IPsec Policy BOF (ipsp)
Luis Sanchez <firstname.lastname@example.org>
Roy Pereira <email@example.com>
Reported by: John Zao, Matt Condell
Edited by: Luis Sanchez and Roy Pereira
Summary (reported by: Luis Sanchez)
The IPsec Policy BOF met Wednesday, March 17 for two hours. Over 150 individuals attended the meeting. The meeting began with a presentation of a taxonomy of IPsec Policy related problems that the BOF chairs believe a group working in this area should address.
There were several other presentations covering different solutions to the problem of general schemas, policy languages, directory systems, general policy systems and specific new key exchanges for IKE. After the presentations several members of the audience expressed their support for this work and their discontent with the existing vendor dependent solutions.
There was consensus that a WG should be formed to:
1) address the need for a general IPsec policy model that fits within the general policy schema currently under development by the Policy WG,
2) adopt a vendor independent policy specification language and,
3) develop an inter-domain dynamic policy discovery, negotiation and conflict resolution protocol independent of any Key Exchange or protocol suite.
A mailing list was announced and the BOF chairs agreed under guidance of the Area directors to refine the proposed charter to accommodate the suggestions made during the BOF. The next paragraphs cover each of the presentations in some level of detail.
IP Security Issues (Roy Pereira-Timestep and Luis Sanchez-BBN Tech)
Roy delivered this initial presentation. He identified the following three main issues relevant to IPsec policies.
· Entities with un-synchronized policies may not communicate
· Needs to discover security gateways along secure communication paths
46. needs to deal with complex topology
47. needs to manage intra-/inter-domain policies
· Existence of different and proprietary IPSec policy models
Roy also listed the four initial Internet Drafts submitted to the BOF, outlined the issues that motivate the formation of a working group, and announced the mailing list.
53. To subscribe, send mail to firstname.lastname@example.org with subscribe ipsec-policy in email message body
Policy Framework for IPSec (Pyda Srisuresh-Lucent and Luis Sanchez-BBN Tech)
Pyda motivated the development of an IPsec policy framework by highlighting the characteristics of IPsec policy management task, the potential problems and the requirements of policy framework.
Pyda described the following problems as key problems that a group working in this area should addressed:
· different matching orders of policies may exist
· policy request & response packets may go through different routes
· applications with dynamic sessions can only be protected by coarse-grain policies
He also described some of the requirements for solutions in this problem space:
· flexible, router-independent representation
· end-node policy query & discovery of policies
· mechanism for policy exchange
· policy negotiation as an integral part of SA negotiation
· resolution of policy conflicts
· dynamically update policies
· policy description mechanism that permits SA bundling
· error notification to end-nodes
There are risks of disclosing policies to communicating peers.
We must allow the peers to know the policies relevant to the communication. The concern is how not to disclose other irrelevant policies.
LDAP VPN Policy Schema (Charlie Kunzinger, IBM)
The speaker reported the architecture model, the high-level schema and the issues addressed by Internet-Draft, LDAP VPN Policy Schema. Some of the issues included:
· Format of condition list
54. the use of BNF/CNF
· Semantics of security policy
55. Should the policies be meta-rules deriving lower level rules?
56. Or, should it be like filtering rules specifying PEP actions?
· Policy implementation in heterogeneous network
57. How to implement a policy on devices supporting different algorithms
58. Suggestions: use abstract algorithm grouping
SPS and SPSL (Matt Condell, BBN Technologies)
Matt highlighted the functions of Security Policy Specification Language [SPSL], and explained the operation of Security Policy Protocol [SPP] that enables discovery and authenticated message exchanges among policy servers.
The policy server discovery mechanism (by sending query messages from upstream servers to destination host) may not work in some routing conditions. Other mechanisms may be used to perform the same function.
The discussion will be continued off-line.
Multi-Domain IKE (Charles Lynn-BBN Tech for Kai Martius-Secunet)
Kai proposes extensions to IKE that will enable a chain of ipsec agents to establish security associations (SAs) for protecting an end-to-end communication with minimal message flow and shared knowledge of SPIs.
Kai's scheme proposes to reduce number of IKE message exchanges between security gateways and to enable trusted gateways to derive filtering rules of IPsec-ESP/AH tunnel traffic based on the knowledge of SPIs. An internet-draft describing the mechanism will be available soon. Send any questions or comments to email@example.com
On-going Work in Policy Framework Working Group (Ed Ellesson, IBM)
Mailing lists of Policy Framework WG:
59. General Discussion: firstname.lastname@example.org
60. To Subscribe: email@example.com
61. In Body: subscribe Archive: http://www.raleigh.ibm.com/maillists/policy
Ed introduced the Policy Framework WG. He explained its charter and summarized the short history of their work. The charter mandated the WG to develop means to represent, merge and share policies of network services and configuration. The work was based on results provided by CIM and DEN initiatives. Currently, the policy schema is rest on a declarative language.
Why limiting the policy language to be declarative instead of programmatic? Will the declarative nature of the language limit its capability in specifying stateful packet filtering and intrusion detection/response strategy?
A declarative language is chosen so that the WG may focus on a small set of issues and gain some experience in developing the schema. More understanding of stateful packet filtering and intrusion detection/response is needed before commenting on the capability of the language in handling their specification.
Another comment: the language (with if-then construct) may not be strictly declarative.
Requirements of an IPsec Policy System for Dynamic Security Association (S.Felix, NCSU)
Felix discussed the Deciduous project. The Deciduous project at NCSU investigates how to utilize the IPsec framework to support intrusion detection and particularly attack source identification without introducing any new protocols.
One key component in this project is to dynamically and efficiently establish IPsec SAs in reacting to the analysis results from an intrusion detection system. Felix discussed the requirements for a IPsec Policy system to support the Deciduous architecture. For more information see http://shang.csc.ncsu.edu/deciduous
IPSec Policy Specification (Jamie Jason and Skip Booth, Intel Corp.)
Skip discussed the basic requirements for IPsec policies. He covered generic format and extensibility issues. He discussed the aspects of a core-representation and a task-specific-representation. Jamie discussed the need to define policy building blocks such as conditions and actions. He pointed out that conditions are generic and actions are task-specific.
IPSec Policy Schema (Bill Dixon, Microsoft)
Bill presented by the underlying concepts of Directory Enabled Networking (DEN) and made the following suggestions on the coordination between Policy Framework and IPSec Policy WGs:
62. Develop basic policy architecture and schema in Policy Framework WG;
63. Define VPN policy architecture in IPSec WG;
64. Define VPN policies in IPSec Policy WG.
Saying that IKE is already doing some form of multi-domain policy negotiation is inaccurate. IKE conducts point-to-point SA negotiations by exchanging protection suite proposals, but it must rely on other systems to determine the kind of services to be supported by the SAS and the range of protection suite to be proposed along the communication path.
Policy Maker (Matt Blaze, ATT Research)
Matt made an announcement on the recent progress in Keynote, a security policy and trust management system. Implementation of Keynote (v.2.0) is ready. Please write to firstname.lastname@example.org for more information.