Current Meeting Report

2.5.1 IP Security Policy (ipsp)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 22-Oct-01
Hilarie Orman <>
Luis Sanchez <>
Security Area Director(s):
Jeffrey Schiller <>
Marcus Leech <>
Security Area Advisor:
Marcus Leech <>
Technical Advisor(s):
Lee Rafalow <>
Mailing Lists:
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
No Request For Comments

Current Meeting Report

IPsec Security Policy WG
DRAFT Minutes
Monday December 10, 2001

E. Vyncke - IPsec Configuration Policy Model

PCIM is in last call, so the base for the config model is now stable.

Changes have been mostly minor, the larger ones include:

1) Clarifications to compound actions with allow complex policies.

A) If in a DoAll and one of the actions fail:
- The aggregate action fails
- Previously established SAs MAY be kept or MAY be removed
B) Which selectors should be used with multiple action:
- For last action, use IPHeader + Granularity
- For all other actions IP Address to IP Address

2) Provision for non-IKE key negotiation - SANegotiation class is super class for all key negotiation protocols

3) Removed 50 pages of CIM Appendixes and replaced with pointers to appropriate documents on

Document has been through WG last call and will be submitted to the IESG

S. Fluhrer - Tunnel Endpoint Discovery

Discovering gateways is necessary for scalability.
Add and IKE TED message.
Use routing to send a TED probe to endpoint.
Peer gateway intercepts probe and sends a TED response which lists the peer identity and the appropriate selectors for IKE.
Protocol is limited in many ways, such as requiring publicly addressable endpoints and is limited to IP address selectors, but addresses a common discovery situation.

Concerns from the audience included:
- Concern about using IKE
- Applicability to nested gateways

WG chairs asked for a show of hands:
1) Does IPSP need to address gateway discovery: Many hands for, few objections

2) Should the WG pursue TED as is? a few hands
Should the WG pursue something beyond TED, which could be SPP? somewhat more hands

There was a call to reintroduce SPP.

P. Srisuresh - Policy Extensions to IKE
no draft

- Policy negotiation in IKE is low granularity & needs two ID payloads
- Policy parameters cannot change without requiring new SAs & keys

Solution 1:
- Define a policy payload for IKE with IPsec granularity and a policy ID.
- Use IKE for dynamic policy updates
- A Policy Agent coordinates updates

Solution 2:
- Define a policy payload for IKE with IPsec granularity and a policy ID.
- A Policy Agent acts as a policy decision point that runs an exchange protocol.
- Use IKE for establishing SAs/keys.

Solution 2 preferred.

C. Wang - IPsec Policy Groups
draft-wang-cevpn-group-00 (submitted to ppvpn working group)

There's currently a gap between device level IPsec configuration and provisioning large scale VPNs, so we need a mechanism to model, design, provision, and manage large, complex VPNs. It must take into consideration:
- security
- scalability
- manageability
- reachability
Managing at the device level is not scalable

Propose using IPsec groups:
- a middle layer building block
- can provision tunnels on group and device levels
Group attributes are defined and applied to all tunnels by default

Need group-level policy definition, negotiation, provisioning and management along with interaction with device level policy management.

Question (from the audience) if this naturally leads to nested tunneling.

WG chairs: more work is needed to determine if this belongs in IPSP.

M. Condell - MSME: Policy Abstraction in IPSP

Multidimensional Security Management and Enforcement (MSME) is security policy management for dynamic coalitions. Allows partners to negotiate mission-related policy before communications required.

Accomplished by policy abstraction, resolution, exchange, and monitoring.

Architecture based around Policy Level Agreement (PLA) which has abstract policy rules and bindings that map the abstract rules to concrete policy. Compilation provides consistency checking and pulls in needed bindings. Resolution, exchange similar to IPSP.

Reconciliation allows a partner to verify that a resolved PLA is consistent with its local policy.

MSME/IPSP differences
- MSME resolves policy before communications are needed.
- MSME resolves all policy at once, instead of policy for one communication.
- Supports multiple security contexts
- Pre-IPSP step for coalitions

Abstraction in MSME
- Bindings map name to value
- may map to multiple security contexts
- Refer to name in policy rule
- Coalition-wide names for assets allows other partners to use the name in their policies
- Names mapped to values during resolution

Why use abstraction in IPSP?
- Late Name Binding
- Idea from SPP/SPSL, though not well developed there
- Names understood by both domains, defined during resolution
- Enables domains to change enforcement points without other domains having to change policy
- Generalization
- May allow IPSP to support more than IPsec
- One name maps to multiple security contexts
- Resolution determines which contexts supported

To support abstraction IPSP protocol needs to be able to define and transport binding names in policy rules and the bindings themselves.
Also needs to support processing of bindings

W. Hardaker - MIB

- text cleanup
- endpoint maps to a single group instead of multiple

Last call will be before March IETF

* Please read the draft!! *

A. Doria - PIB
draft-ietf-ipsp-ipsecpib-(soon to be 04)

-04 will be out within a month

It's compliant with IPsec standard, configuration policy model.

Mostly minor changes.
- Only MUSTs are what's in the IPsec standards
- Easy adding of other key negotiation protocols
- many other small changes.

There's a Nokia implementation and possibly one coming from SSH

Last call after -04.

Working group status:

There was a 2 week WG last call on

Will submit for Proposed Standards to IESG:
and possibly the MIB


None received.