NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Hilarie Orman <horman@novell.com>
Luis Sanchez <lsanchez@megisto.com>
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Marcus Leech <mleech@nortelnetworks.com>
Lee Rafalow <rafalow@us.ibm.com>
General Discussion:ipsec-policy@vpnc.org
To Subscribe: ipsec-policy-request@vpnc.org
In Body: subscribe
Archive: http://www.vpnc.org/ipsec-policy/
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:
draft-ietf-ipsec-policy-model-00.txt
draft-ietf-ipsec-vpn-policy-schema-00.txt
draft-ietf-ipsec-spsl-00.txt
draft-ietf-ipsec-sps-00.txt
draft-ietf-ipsec-secconf-00.txt
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.
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 |
· IPsec Configuration Policy Model
· IPSec Policy Information Base
IETF-50 (Minneapolis) IPSP WG minutes]
Matt Blaze -- requirements draft
Matt discussed the the requirements for IPSP. Since the draft hasn't changed since the last IETF, he just re-iterated the main points of the requirements draft:
- policy model
- gateway discovery mechanism
- policy languages for nodes
- means for distributing responsibility
- protocol for discovering policy
- method for resolving SA parameters
- semantics for compliance checking SA parameters & gateways
against each node's policy
- no changes to anything else (IKE, IPsec, etc)
The slides are online at http://www.crypto.com/talks
Desperate plea for comments on the document.
William Dixon asked about compliance checking and what that meant in terms of the policy model -- response: we have requirements for the policy model, but the WG has not decided on one yet.
Lee Rafalow -- IPsec Configuration Policy Model
Lee talked about PCIM extension proposals and convergence with IPSP and QPIM (see Policy Framework WG). The main points were:
- Rules may contain groups and rules
- Match first & all decision strategies
- Simplified priorities
- Refinements in the use of PolicyRoles
- Compound conditions & actions
- Variables & values, both for conditions & actions
- Common packet filtering representation
Remaining issues were:
- Declarative vs. procedural policies (rule actions early in policy may affect rules later on)
- Implicit & hierarchical contexts
- Deterministic vs. non-deterministic evaluation
- Transaction semantics were removed
- Implicit variables
- Use of regular expressions in conditions (currently not supported)
Draft does not yet reflect PCIM extensions, or note required/optional functions.
Lee then gave a quick overview of the model (using diagrams) -- giving the relations between rules, conditions, actions, and their components as they've been updated since the last meeting.
The document seems to be pretty stable at this point, so there may be a last call in August.
Dixon: customers ask for things like ICMP type/code handled by IPsec, which are not part of the IPsec spec but would be useful to be supported. Reponse: it's not in the model, but it's possible to add as an extension and could be mentioned in the spec as a MAY.
Other questions on reconciliation of the requirements draft and the PCIM model. The answer is that we can use a subset of the PCIM model that fits the requirements.
Will this model be driven down to the device ? Yes. It is intended to be used by all elements that can participate in an IKE negotiations.
What the relation of the model with other work like COPS that tries to do similar things ? This work is based on the PCIM model, as is similar work in the other working groups. Unclear what the overlap should/will be at this point. The goal is to make it possible to use either a PIB or a MIB-based mechanism (up to the vendor) to configure an element. They will both be consistent with each other (and the model).
There is an issue with policies that are more restrictive than an element's policy (currently, rules have to match exactly). There are no plans to address this at this stage.
Wes Hardaker -- IPsec Configuration MIB
Wes discussed the architectural overview and the diffrences with the PCIM model, as well as things to be done.
The MIB uses a hierarchy of tables, and follows the PCIM-derived model Lee presented. The tables are:
policyEndpointToGroupTable: maps endpoint address to groupname
policyIKERulesInGroupTable, policyIPsecRulesInGroupTable: map groupname to ordered list of rule names, and/or conditions in rules (there is some difference with the DMTF white papers). Rule processing is first-match.
conditionsInRuleTable: maps a rule name to an ordered condition name list, defines condition negation
filtersInConditionTable: maps a condition name to an ordered filter name list
filterTable: defines filters, multiple filter types in one row
actionsInRulesTable: maps rule names to a dual-ordered list of actions, multiple actions/fallbacks are specifiable (the actions/fallbacks may be in different "domains", e.g., QoS and IPsec)
saStaticActionTable: implements non-negotiated IPsec action (bypass, discard, rejectIKE, preconfigured)
saNegotiationActionTable: implements negotiation actions, points to ikeActionTable and ipsecActionTable, and contains parameters common to both
ikeProposalTable, ipsecProposalTable, ahTransformTable, espTransformTable, ipcompTransformTable, ikeIdentityTable: ipsec/ike parameters for negotiated actions
Differences form the data model:
- packet classification is independent of the action
- groups of groups are not implemented (too complicated)
- rules contain multiple actions (ordered by sequence number, with multiple possible fallback actions)
- Rule actions are specified by RowPoints
- Filter object-oriented objects combined into one table
- Conditions modified to be of multiple types
To be done:
- Clarify use/configuration of IKE identities
- Clarify use/configuration of identity contexts (credential filters)
- Catch up to new changes in policy model draft
- Resolve differences between MIB and policy model
- Move packet classification somewhere else
- Group in group (PCIM may want to support this as well, since it allows an administrator to construct coherent sets of rules that can be applied together -- comment from Lee Rafalow)
- Notifications
- Compliance
- English text (editorial issues with the draft)
- Row dependency issues (half-done at this point)
- Integration with snmpconf
- Authority/level classifications (IPSO labels -- contiguous or discrete)
- Local administrative realms (local policies that augment but don't conflict with "global" policies)
Question: can the MIB be used to specify port filters for applications that assign their ports dynamically ? No.
(Hilarie:) Implementations ? NAI will be doing one.
Man Li -- IPsec PIB
Man Li gave an overview of the PIB, and talked about new developments in the draft, and described differences with the information model.
IPsec PIB is used by policy servers to distribute IPsec policy to IPsec enabled devices using the COPS protocol.
CredentialTable and CredentialFieldsTable were added in the draft; the specify (respectively) the acceptable credentials types for the peer and the fields/values to be matched in these credentials.
The PIB currently supports multiple actions that can be applied in sequence to one packet. The information model uses "try until success" semantics, additional actions are used as fallbacks.
Things to do: add policy target IPsec capabilities, and align with the information model.
Luis Sanchez -- Next Steps
- WG last call for the following drafts: IPsec Policy Management Roadmap, IPSP Requirements, IPsec Policy Configuration Model.
- We should start detailed discussions of PIB and MIB, and see who is doing implementations (and what feedback we can get from them)
- Publish PF_POLICY draft
- Begin SG Discovery Protocol design
- Security Policy Specification Language
- Core Design Team volunteers
- SG Discovery Protocol
End of session.
None received.