[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft Minutes from IPSP WG Mtg at 51st IETF
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
IP Security Policy Working Group Meeting
at the 51st IETF
6 August 2001, 0900 - 1130
Hilarie Orman (not able to attend meeting)
Notes: Russ Mundy
Approximate Attendance: 147
The meeting was opened by Luis with a comment about the recent email from
Marcus Leach related to the complexity of IKE (see Position statement on
IKE development, Date: Thu, 02 Aug 2001 21:33:47 -0400). Since the Charter
of IPSP essentially does not permit us to make changes to the various IP
security and related protocols, our work should not be impacted by this
After this short introduction, we moved right to the following agenda:
- Agenda Bashing L. Sanchez 5 minutes
- Roadmap L. Sanchez 10 minutes
- Configuration Model E. Vyncke 20 minutes
- PCIM Dependencies L. Rafalow 20 minutes
- PF_Policy B. Sommerfeld
- PIB M. Li 25 minutes
- MIB W. Hardaker 25 minutes
- Wrap-Up L. Sanchez 5 minutes
- Configuration Model presentation by Eric Vyncke
Eric presented the IPsec Configuration Policy Model (ICPM) which is
currently described in <draft-ietf-ipsp-config-policy-model-03.txt>. The
presentation focused on: the positioning of ICPM vs PCIMe and CIM; changes
and non-changes since 50th IETF; and the model status. Eric presented a
graphic which illustrated the relationships between the relevant RFCs, the
PCIMe, the ICPM, the IPsec PIB and the IPsec MIB as well as how it relates
to DMTF modeling efforts (see posted slides for details).
Things that were identified as non-changes since the 50th IETF include:
filters for ICMP and dynamic protocols lifetime, authors continuing to
follow RFC240* and retaining the possibility that models can be extended
for proprietary extensions.
Items identified as changing since 50th IETF include incorporation of
CompoundActions in PCIMe, IPHeaderFilter, PeerGatewayForPreconfiguredAction,
and changes to use of MAY/SHOULD/MUST in the document.
- The presentation descibed how the inclusion of CompoundPolicyAction fit
into the model and a description of how it should add value. An important
facet of SARule/CompoundPolicyAction is the ExecutionStrategy which can be
Do All, Do Until Success or Do Until Failure. At this point, it looks as
though all ICPM functions will have either Do All or Do Until Success
since a use for Do Until Failure could not be identified. There were
several questions from the audience about the examples were shown for the
uses of Do Until Success. Some of the details of the examples need to be
changed so they align with the appropriate specifications, e.g., what the
transport will negotiate over the tunnel in the Redundant Transport Mode
in Tunnel Mode example. Also, additional text needs to be included in the
document that will reflect the usages described in the WG. For example,
multiple rules or multiple tunnels may be needed in some instances.
Additionally, it was noted that the model may not accurately reflect
checking of the SPD and that all of the 5-tuple parameters must be covered
in the model.
- The changes to IPHeaderFilter were described and discussed. The
described intent of this additional class is to be able to filter on a
single rule. The question was raised as to why the diffserv code point
was included. The response was that this would facilitate the use of a
single set of software for all policy filtering. The addition of
PeerGatewayForPreconfigurationAction was described but there was little
discussion about this change.
- With respect to the MAY/SHOULD/MUST changes, the model was updated so
that all of the MUSTs from RFC-240* MUSTs are now MUSTs in the model.
Items from external objects (e.g., CIM) were changed to MAY.
- The readability changes included fixing typos and more descriptive text
for DoPacketLogging, Use of IKERules and IPsecRules, and IPsec
preconfigured key in SharedSecret LimitNegotiation in SARule.
- There were a few changes to follow the moving target of PCIMe but
otherwise the model appears to be stable. The presentation concluded with
the suggestion that after incorporating the changes related to the
examples and ensuring that all 5-tuple parameters are covered in the
model, the document is ready for Working Group Last Call.
- PCIM Dependencies presentation by Lee Rafalow
Lee Rafalow lead a discussion in issues related to the Policy Core
Information Model Extensions <draft-ietf-policy-pcim-ext-02.txt> which is
commonly called PCIMe. He presented a modified set of slides on PCIMe-02
issues that were prepared by Bob Moore for the Policy Framework Working
Group. The modifications high-lighted the items that probably have the
most impact on the IPSP Working Group. Any issues from the PCIMe document
or slides that are outside the scope of IPSP can be discussed in the Policy
Framework Working Group meetings or on their mail list. Lee noted that the
Policy Framework Working Group would like to take the PCIMe document to
Working Group Last Call right after the London meeting.
- Of the PCIMe actions since the Minneapolis meeting, moving the
Device-level header filters from the QDDM to PCIMe is the only thing that
seems to impact IPSP.
- Of the seven open PCIMe issues listed on the slides, four are of
particular interest to IPSP. These four are:
-- Issues related to IPHeaderFilter
-- The "Do Until Failure" ExecutionStrategy
-- Evaluation and execution order
-- Criticality of extended conditions
The details associated with each of these issues are available on the
slides from the presentation. The main area of discussed during this
presentation was whether or not other capabilities such as permit and
block would be considered for IPHeaderFilter. It was also suggested that
it might also be wise to include ICMP types in the Policy Framework. It
was noted by WG members that the current RFC240* documents do not have any
selector that includes features such as permit/block and, since the IPSP
charter does not permit us to add to RFC240*, it is more appropriate to
raise this in the IPSEC group for their consideration. It was also noted
that this set of items could be raised in the Policy Framework WG meeting
later in the week or on their mail list. Lee pointed out that he expected
that several of the issues impacting IPSP and ICPM will be clarified
during the Policy Framework WG meeting on Monday afternoon and he urged
interested IPSP WG members to participate in the Policy Framework WG
meetings during the IETF.
- PF_Policy presentation by Bill Sommerfeld
Bill Sommerfeld gave a short presentation on his initial thoughts on
PF_Policy. In general, PF_Policy is intended to provide a standard policy
management interface to push IPsec policy into TCP/IP/IPsec similar to the
way PF_Key functions for IPsec keys. The viewgraph illustrating this
should be available in the proceedings. He has not started the ID yet but
asked if individuals interested in working on it would contact him at
sommerfeld@xxxxxxxxxxxxx Bill expects to have the document available by
the 52nd IETF meeting.
- PIB presentation by Mi Lee
Mi Lee gave a presentation on the current version of the IPSec Policy
Information Base <draft-ietf-ipsp-ipsecpib-03.txt>. The presentation
structure included describing what the IPsec PIB is, what is new in the 03
Draft, what needs to be added to the PIB and an overview of the IPsec PIB.
- The IPsec Policy Information Base was described as the approach used by
policy servers to distribute IPsec policy to IPsec enabled devices such as
gateways, routers, laptops, using the COPS protocol with extensions for
- The new items in the current (03) version of the Draft include the
addition of an interface capability reporting table and associated
explanations, clarification of the text associated with multiple action
policy, and the addition of replay protections for ESP and AH.
- The items remaining to be completed were identified as the capability to
handle fall back and the capability to handle pre-configured security
- There were minimal discussions or questions raised during the IPsec PIB
overview and readers are encouraged to read the Draft for a description of
the PIB or see the presentation slides which should be in the proceedings.
At the end of the presentation, the Co-chair asked if anyone was implementing
the PIB besides Nokia. A WG member said that Intel had been working on it
but they did not know if the work was still underway. Another WG member
asked if anyone had looked at the PIB with respect to multicast security but
no one knew of any work or activity in this area.
- MIB presentation by Wes Hardaker
Wes Hardaker gave a presentation on the current version of the IPsec Policy
Configuration MIB <draft-ietf-ipsp-ipsec-conf-mib-01.txt>. Wes's
presentation was structured to provide an architectural overview of the
MIB, a description of the differences from the previous WG meeting,
description of the differences between the MIB and the configuration policy
model (ICPM), identification of things yet to be done and time for
discussion and questions.
- The architecture overview of the presentation described the set of MIB
tables and their relationship. There are currently 23 tables and 249
objects contained in the MIB.
- There have been a large number of changes since the previous WG meeting
and previous version of the Draft. An 'eye chart' was presented with about
60 changes that were distilled down to the following seven (more readable)
-- The MIB matches the current ICPM more closely but not completely.
More work will be needed here due to the continuing changes to the
-- The MIB now makes use of IPSEC-ISAKMP-IKE-DOI-TC
-- The MIB supports group in group
-- Filters can be ANDed or ORed (to support CNF/DNF)
-- The MIB now supports preconfigured actions tables
-- Support is provided for string lists -> tables (e.g., list of
transforms in a proposal)
-- Miscellaneous problems were submitted to the WG mail list.
- Even though there has been quite a bit alignment between the model and
the MIB since the last meeting, there are still some differences.
-- Packet classification is independent of IPsec/QoS/... since the names
-- Rule actions are specified via RowPointers which allows extensibility
and the packet classification system to be used by other external action
tables, e.g., vendor, QoS.
-- Filter OO objects are combined into one table.
-- CNF/DNF is implemented in a more flexible way.
- The following items remain to be completed: scheduling of policies;
filter types are missing; notifications; and conformance objects.
- Several items were identified for discussion including: lists contained
in separate tables; are there too many tables; should there be one keys
table or should keys be kept in each table. There was essentially no
input received from WG members on the discussion items or in other parts
of the presentation so work will continue in the current direction.
- The static SA portion of a previous version of the MIB has been
implemented by NAI Labs. No now spoke up when it was asked if there were
any other implementations of the MIB. The Co-chair asked when the code
would be released, Wes responded that this would probably be after they
have completed implementation on the Linux 2.4 kernel. A WG member asked
the amount of energy that it took to implement the MIB. Including the work
and re-work needed to track some of the changes to the model, NAI Labs
needed about 3.5 people over three months.
- Wrap-Up by Luis Sanchez
The next steps planned for the Working Group are:
- Conduct Working Group Last Call for the following drafts:
IPsec Policy Management Roadmap
Requirements for IPsec Policy Management
IPsec Policy Configuration Model
IPsec Policy Information Base
- Given successful completion of Working Group Last Call, each of the
documents will be submitted to the IESG with a recommendation for
advancement to Proposed Standard.
- Publish the initial version of the PF_Policy draft
- Continue SG Discovery Protocol design
- Close the loop on the policy specification and compliance checking
- The Working Group needs to evaluate support for multicast security
The Co-chair closed the meeting at approximately 1045.