[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Draft Minutes from IPSP WG Mtg at 51st IETF


IP Security Policy Working Group Meeting
at the 51st IETF
6 August 2001, 0900 - 1130

Hilarie Orman (not able to attend meeting)
Luis Sanchez

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
position statement.

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
   are generic.

   -- 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.