[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF-49 (San Diego) IPSP WG minutes
Meeting agenda
Agenda bashing (L. Sanchez)
Roadmap document (H. Orman)
Requirements doc. (M. Blaze)
IPsec config. model (J. Jason)
QPIM/IPsec model (L. Rafalow)
Arch. Issues (A. Rayhan)
SPSL updates (M. Condell)
IPsec Config. MIB (R. Charlet)
IPsec MIB (M. Li)
Discussion (L. Sanchez)
Roadmap items (Hilarie Orman)
-------------
Hilarie talked about the intent on producing various documents:
Requirements: standards track
Data model: standards track
Architecture: standards track
Policy language: standards track
- also parser implementation
Provisioning: standards track
- implementations
Policy exchange and negotiation protocol: standards track
IMPLEMENTATIONS!
Hilarie talked about the status of documents (see slides for draft
names). Comments are sorely needed on the requirements and
architecture drafts, to begin with; comments on all the other drafts
(policy model, etc.) is also needed.
Need for policy MIBs; we also need to make sure the various (numerous)
documents are consistent with each other.
We need definitions for:
- authentication policy (and translation into data items)
- definition of "security domain"
- policy integrity
Requirements Document (Matt Blaze)
---------------------
Matt outlined the issues referenced in the requirements document:
- 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)
Policy model: defines all the semantics of IPsec policy, and should be
independent of specific details (language, protocols, etc.)
Gateway discovery: self-explanatory
IPSP language: this is for externalizing policy; how policy is
expressed internally is not important for this WG
Distribute policy: delegation; mus tbe possible to have remote
administration of node's policy
Policy discovery: protocol used by nodes to determine how to talk to
each other; does not need to be full-disclosure.
SA parameter resolution: given the results from policy discovery,
resolve those in determining what can/should be used for the SAs. Must
be computationally efficient enough to be practical (general case is
NP complete).
Compliance checking: given a set of proposed SA parameters, verify
that a node must be able to verify whether they meet its own
policy. This is where policy enforcement is implemented (and is safe
even if SA resolution gives wrong results).
No changes to anything else: self-explanatory -- IPsec too long enough
and is complicated enough.
Slides on: http://www.crypto.com/talks
Question: how much is authorization vs. "what to propose" ?
Answer: one input to IPSP as a system is "I want to talk to host foo,
tell me what I need to do"; on the other side, the `responder` needs
to verify a symmetric operation, in verifying that the proposed
attributes (SA parameters, addresses, authentication mode, etc.) meet
local node policy.
Question: in addition to doing gateway discovery, do we also discover
other information like proxy nodes behind the gateway ?
Answer: this is probably outside the scope of the IPsec policy.
Question: When we're done with the work, do you think we'll be able to
be as flexible/easy-to-use/whatever as SSL (talk to anyone in the
world with minimal or no setup) ? Or is IPSP more geared towards
extranet-like scenarios ?
Answer: We certainly want to be able to do the talk-to-anyone
scenario. Solving the end-to-end communication case, makes it possible
to actually solve the network-to-network (firewall-to-firewall)
configuration etc.
IPsec Policy Model Updates (Jamie Jason)
--------------------------
Numerous changes to DMTF version since last IETF; model has
stabilized, and has been submitted for inclusion in CIM v2.5. Those
updates will be rolled up into IETF version.
Numerous changes in Policy, Condition/Filter, Action,
Proposal/Transform classes were described (too many/too fast to write
down -- see the slides for details).
New draft with those changes will probably be out in January.
Location of slides will be posted on the mailing list by Jamie.
Question: is the model supposed to capture authorization issues ?
Answer: the CredentialFilter entries are supposed to capture the
authentication side of authorization; the rest of the model can
capture authorization issues like time-of-day considerations (e.g.,
"users can only login between 9am-5pm")
IPSP Configuration Model Framework Feedback (Lee Rafalow)
-------------------------------------------
http://rafalow.home.mindspring.com/dmtf.htm
Some differences in the models between PCIM/QPIM and IPsec
Configuration Information model. Some of them come from layering
variations:
- PCIM is a general framework
- QPIM is a domain-level policy model
- IPsec Configuration Information Model is a device-level policy model
Condition differences:
- IPSP provides discipline-specific condition evaluation information,
where as QPIM uses a more generic approach
- There are different identities in IPsec, at different times in the
protocol sequence.
- Condition evaluation is predicated on presence of information
(e.g., some rule may begin as true, but eventually turn out to be
false -- an example was given with Phase 1 IDs in IKE); this is
partly because of authentication (some information in the protocol
is authenticated/verified long after it is
known/discovered/assumed)
Group-related differences:
- Priorities are applied to groups vs. individual filters (IPSP vs. QPIM)
- Rules in exactly one group (in PCIM they can be in multiple groups)
- Unique rule & group priorities (thus, deterministic rule evaluation
order)
- Different Decision strategies:
- IPSP uses MatchFirst
- QPIM has a number of different strategies
Policy Roles:
- IPSP uses explicit association of rules with interfaces; PCIM uses
a named relationship.
- IdentityContext
Other discussion topics:
- Sequence actions (like FallBack) between PCIM and IPSP somewhat
different semantics ("mandatory" vs. "use first appropriate")
Question: what happens if we don't resolve those differences ?
Answer: we probably want to keep in sync as much as possible, if only
to make it possible to interact. There aren't any specific disasters.
Comment from Luis: differences between the IPSP model and models from
other WGs will be tolerated if it's necessary to be
different. Otherwise, it makes sense to reconcile.
Lee: there are a couple of important differences, but most of the
changes are details and don't really matter.
Architecture Issues (A. Rayhan)
-------------------
draft-cuervo-ipsp-arch-02.txt (hasn't made it into the I-D yet)
Abdul discussed the issues on the mailing list:
- Discovery and resolution: should these be bundled ?
Currently, several concepts are merged in one protocol (gateway
discovery, policy negotiation, exchange, resolution, distribution).
Proposal to separate discovery from resolution:
- stable/scalable framework for the development of the architecture
- provide stronger security model
- allow better extensibility
There are two types of policies: distributed and local.
Distributed: SGs need to be discovered and tunneling policies should
be resolved.
Local: access and SA policies are installed only on the two ends of
the tunnel and there is no need for collective knowledge.
Distributed policies reflect mostly security requirements, whereas
local policies reflect security policies.
Requirements for distributed policies:
- requests can at least be authenticated (can't be encrypted)
- piggyback requests in a message can be used to construct a
topology matrix
- the topology matrix is used to resolve conflicts across SGs
- this phase precedes the next phase
- Policy Signaling Protocol
Requirements for local policies: (too fast to write down, see slides)
Summary: separate gateway discovery and policy distribution
Slides will be made available through the mailing list.
Question: are the end hosts involved in the signaling ?
Answer: they can be (they can pretend to be security gateways for
themselves)
SPSL Updates (M. Condell)
------------
Matt gave a quick update on the status of the SPSL draft; current one
has expired but there's been work on the new one (hopefully available
in the next month or two).
Briefly: some classes were combined, short form of policy class was
dropped, added forward action, and some text cleanup.
Some more changes to appear (in the new draft): policy file
description class (for describing the policy file itself), logging
actions, add missing defaults for some selectors and actions, finish
incomplete sections (certificate encodings, general SA endpoints,
re-think object signing, support for DNS names wherever missing).
IPsec Configuration MIB (R. Charlet)
-----------------------
Rick talked about the status of this effort; in short, have done about
20% of a MIB so far, but in conflict with the IPsec PCIM at this
point. Group of volunteers approach hasn't worked very well so far,
will take the effort to the mailing list. Intent to have a -00 draft
before next IETF.
A high-level group outline of the MIB was shown, feedback requested.
Question: is there any work in the Policy Framework WG that allows
derivation of MIB from a PCIM ?
Answer: not really; there's some experience in the area, but no tools
or anything solid at this point.
IPsec Policy Information Base (PIB) (M. Li)
-----------------------------------
draft-ietf-ipsp-ipsecpib-01.txt
PIBs are used by policy servers to distribute IPsec policy to
IPsec-enabled devices (gateways, routers, laptops, etc.) using the
COPS protocol. COPS is used for QoS configuration, so the goal is to
reuse the same mechanism.
New items in draft -01:
- Separate roles in IPsec and IKE rules, so they can be used
independently from each other.
- Added start-up conditions for IPsec and IKE rules
It used to be there was only "OnDemand" condition (as packets
showed up). There are three new types:
- OnBoot (when a system boots)
- OnTraffic (OnDemand)
- OnPolicy (time-based, a rule is fired or becomes valid based on
time constraints)
- Modified Selector table construction
- Added Conformance section
Things to add: need to align with IPsec Information Model, and add
policy target IPsec capabilities.
Question: it seems difficult to keep this synchronized with the Information
Model. It looks like it's a moving target trying to keep them consistent with
each other.
Answer1: one approach is to get the Information Model more or less stable, then
try to sync the PIB.
Answer2: there's all sorts of problems with policy versioning and migration,
that are related to this. Difficult issue.
--- End of presentations ---
Luis:
- We need to send the following documents to Last Call:
IPSP RoadMap, IPSP Requirements, IPsec Configuration Policy Model
Feedback is needed!
Hilarie:
What's the status of implementations, especially on the Information Model ?
Jamie: there has been some feedback from inside the DMTF process, some people
are trying to implement the Information Model.
Answer2: one reason we're not seeing implementation feedback is because policy
is a large project *and* all-or-nothing. A "first step" approach may
be easier to follow.
Luis: the information model is trying to capture the complexity of the existing
IPsec protocols, thus it has to be pretty big and comprehensive.
Marcus: there's a large dependency on humans to interpret policy for firewalls
etc. so IPSP should make it easier to automate this process.
End of session.