Subject: IETF-50 (Minneapolis) IPSP WG minutes

From: "Angelos D. Keromytis" <[email-masked]>
Date: Mon, 19 Mar 2001 22:49:30 -0500

(I walked in 10 minutes late, so I may have missed something -- still,
Luis insisted that I keep 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.

---

From: "Avri Doria" <[email-masked]>
Date: Tue, 20 Mar 2001 23:54:42 -0600

"Angelos D. Keromytis" wrote:
...
>     Roadmap, IPSP Requirements, IPsec Policy Configuration Model.
...

Hi,

I wasn't able to attend the WG meeting otherwise I would have
suggested this at the time.  I think that the PIB should also 
go through working group last call at the same time as the 
Config Model.  The work has been tracking the model and has 
seen at least one implementation so far with a few others 
rumored to be under consideration (of course I understand that
implementations aren't required before going to proposed).

a.

-- 

Avri Doria
+1 401 663 5024

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Thu, 22 Mar 2001 21:10:57 -0600

Avri,

I want the IPsec PIB to move to PS status. However, I think it may be a
bit earlier for this. First, I would like to see people discussing it.
Second, I would like to see at least two independent implementations and
some level of interoperability first. I'm also checking with the OPS/MAN
area directors for the exact requirements on PIBs. Even if two
implementations are not required we need to discuss the PIB more. I
believe that you folks can help with this.

Thanks,

Luis