Current Meeting Report
Jabber Logs

2.6.2 IP Security Policy (ipsp)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 08/02/2002

Hilarie Orman <>
Luis Sanchez <>
Security Area Director(s):
Jeffrey Schiller <>
Steve Bellovin <>
Security Area Advisor:
Steve Bellovin <>
Technical Advisor(s):
Lee Rafalow <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
Description of Working Group:
The rapid growth of the Internet and the need to control access to network resources (bandwidth, routers, hosts, etc.) has quickly generated the need for representing, discovering, exchanging and managing the policies that control access to these resources in a scalable, secured and reliable fashion.

Current IP security protocols and algorithms [RFCs 2401-2412, 2085, 2104 and 2451] can exchange keying material using IKE [RFC2409] and protect data flows using the AH [RFC2402] and/or ESP protocols [RFC2406]. The scope of IKE limits the protocol to the authenticated exchange of keying material and associated policy information between the end-points of a security association.

However, along the path of a communication, there may be administrative entities that need to impose policy constraints on entities such as security gateways and router filters. There also is a need for end-points of a security association and/or, for their respective administrative entities, to securely discover and negotiate access control information for the end hosts and for the policy enforcement points (security gateways, routers, etc.) along the path of the communication.

To address these problems the IPSP Working Group will:

1) Specify a repository-independant Information Model for supporting IP security Policies. This model preferrably derives from the Information Model as defined in the Policy Framework WG.

2) Develop or adopt an extensible policy specification language. The language should be generic enough to support policies in other protocol domains, but must provide the necessary security mechanisms that are vital to IPSEC.

3) provide guidelines for the provisioning of IPsec policies using existing policy distribution protocols. This includes profiles for distributing IPsec policies over protocols such as LDAP, COPS, SNMP, and FTP,

4) adopt or develop a policy exchange and negotiation protocol. The protocol must be capable of: i) discovering policy servers, ii) distributing and negotiating security policies, and; iii) resolving policy conflicts in both intra/inter domain environments. The protocol must be independent of any security protocol suite and key management protocol. Existing protocol work in the IETF, such as SLP, will be considered if such protocols meet the requirements of this work.

5) Work with the "Policy Terminology" design team to define a common set of terms used in documents in the area of Policy Based (Network) Management.

The proposed work item for this group would yield standards that are compatible with the existing IPsec architecture [RFC 2401] and IKE [RFC 2409], complementing the standards work achieved by the IPsec Working Group. The data model, specification language and exchange protocol will evolve from some of the work previously published in the following documents:






This group will also coordinate with other IETF working groups working on specifying policies and policies schemas in order to maintain compatibility and interoperability. In particular, this working group will work closely with the Policy Framework WG to ensure that the IPsec Policy Information and data model fits and can be supported within the general Policy Framework.

Goals and Milestones:
JAN 00  Post an Internet-Draft on IPsec Policy Management Roadmap
JAN 00  Post an Internet-Draft on Requirements for IPsec Policy Management
FEB 00  Post a revised draft for the IPsec Policy Information and Data Model
JUN 00  Conduct initial interop testing of a Policy Exchange and Negotiation Protocol
SEP 00  Submit applicable drafts for PS consideration
OCT 00  Revisit WG charter
  • - draft-ietf-ipsp-config-policy-model-06.txt
  • - draft-ietf-ipsp-spp-01.txt
  • - draft-ietf-ipsp-requirements-02.txt
  • - draft-ietf-ipsp-ipsecpib-05.txt
  • - draft-ietf-ipsp-ipsec-conf-mib-03.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of IPSec Policy, IPSP, 55th IETF, Monday, November 18, 3:30 pm EST
    Attendance at the meeting was over 100 people.
    The meeting opened with agenday bashing and a status of the WG 
    documents.  The policy configuration documents are within episolon of 
    being ready to present to the IESG for a request for promotion to 
    Proposed Standard.  Other Working Group items need discussion and 
    decisions about direction.
    The Area Direction, Steve Bellovin verifies that he alone has looked at the 
    submitted documents and he provided feedback to the document authors.  The 
    IESG as a whole has not yet seen them.
    The AD comments are summarized in the Chairs' presentation.  Man Li asked if 
    AES must be added to the supported algorithms list, and the answer was yes.
    Another was whether or not the lifetime counters should be specified at 
    64-bits in the IPSec architecture document.  The answer is no, but we 
    should make sure that the IPSec group is aware of the need to match the 
    lifetime counter size to the linespeed.  For configuration, we have 
    chosen 64-bits because it is large enough for all expected needs.
    Eric Vyncke presented the IPSec Configuration Policy Model status.  In 
    response to his comments that the ICPM is fairly abstract was is not 
    expected to have much in the way of concrete security 
    considerations, Steve Bellovin commented that he expects the WG's in the 
    security area to have expertise for writing good security 
    considerations sections.  Luis Sanchez replied that the 
    Architecture document will be revived for use as a normative 
    reference, and this will answer many of the questions for security 
    The ICPM revisions based on AD feedback will be incorporated and the 
    document will be resubmitted very soon.  The WG Chairs will notify the AD 
    when the new documents are available, and this will alert him to begin 
    tracking the document through the IESG document tracker.
    Man Li presented the Policy Information Base (PIB) document.  This 
    document is complete, modulo the 64-bit counters.  
    Robert Story presented a summary of the MIB document.  The MIB extends the 
    ICPM with generic offset in the iPHeaderFilter.  This document is nearly 
    done, normative and non-normative references have been added, and the AD 
    comments on the other documents will be addressed in this document as 
    well.  The next version will be available very soon.
    Demonstrations of the net-policy project ( were 
    available during the conference of the freely available reference 
    release ( for Linux and PlutoPlus + 
    Apache + perl for GUI).
    An informal poll showed that a handful of attendees are planning to use 
    PIBs or MIBs in projects in the very near future.  Demonstrations of the 
    net-policy project ( could be given during the 
    conference of the freely available reference release could be given by the 
    above 3 people.
    Bill Sommerfield presented the PF_POLICY concept, which is one part of a 
    three-part API for IPSec: IPSec management, PF_POLICY, PF_KEY.  He was 
    asked several questions about how PF_KEY might change and what the status of 
    documentation and implementation is.  He said that some minor parts of the 
    implementation were done and that he needed time to write up the 
    documentation.  He got a volunteer to assist in writing a 
    requirements document.  We can expect a document on PF_POLICY by second 
    quarter 2003. 
    Michael Richardson re-presented slides about policy discovery.  We need 
    further discussion on the mailing list about how this might be used for 
    enterprise and ISP 


    None received.