Subject: Draft Minutes from IPSP WG Mtg at 52st IETF

From: Matthew Condell <[email-masked]>
Date: 11 Dec 2001 15:54:45 -0000

IPsec Security Policy WG
                            DRAFT Minutes
                      Monday December 10, 2001
                               IETF 52

E. Vyncke - IPsec Configuration Policy Model 
  draft-ietf-ipsp-config-policy-model-04

  PCIM is in last call, so the base for the config model is now stable.

  Changes have been mostly minor, the larger ones include:

  1) Clarifications to compound actions with allow complex policies.

     A) If in a DoAll and one of the actions fail:
           - The aggregate action fails
           - Previously established SAs MAY be kept or MAY be removed
     B) Which selectors should be used with multiple action:
           - For last action, use IPHeader + Granularity
           - For all other actions IP Address to IP Address

  2) Provision for non-IKE key negotiation - SANegotiation class is
        super class for all key negotiation protocols

  3) Removed 50 pages of CIM Appendixes and replaced with pointers to
        appropriate documents on http://www.dmtf.org

  Document has been through WG last call and will be submitted to the IESG

S. Fluhrer - Tunnel Endpoint Discovery
  draft-fluhrer-ted-00

  Discovering gateways is necessary for scalability.
  Add and IKE TED message.
  Use routing to send a TED probe to endpoint.
  Peer gateway intercepts probe and sends a TED response which lists the
    peer identity and the appropriate selectors for IKE.
  Protocol is limited in many ways, such as requiring publicly addressable
    endpoints and is limited to IP address selectors, but addresses a
    common discovery situation.

  Concerns from the audience included:
    - Concern about using IKE
    - Applicability to nested gateways

  WG chairs asked for a show of hands:
    1) Does IPSP need to address gateway discovery:  Many hands for,
                                                     few objections
    2) Should the WG pursue TED as is?  a few hands
       Should the WG pursue something beyond TED, which could be SPP?
                                        somewhat more hands

  There was a call to reintroduce SPP.

P. Srisuresh - Policy Extensions to IKE
  no draft

  Motivation:
    - Policy negotiation in IKE is low granularity & needs two ID payloads
    - Policy parameters cannot change without requireing new SAs & keys

  Solution 1:
    - Define a policy payload for IKE with IPsec granularity and a 
      policy ID.
    - Use IKE for dynamic policy updates
    - A Policy Agent coordinates updates
      
  Solution 2:
    - Define a policy payload for IKE with IPsec granularity and a 
      policy ID.
    - A Policy Agent acts as a policy decision point that runs an
      exchange protocol.
    - Use IKE for establishing SAs/keys.
      
  Solution 2 prefered.  

C. Wang - IPsec Policy Groups
  draft-wang-cevpn-group-00  (submitted to ppvpn working group)

  There's currently a gap between device level IPsec configuration
  and provisioning large scal VPNs, so we need a mechanism to model,
  design, provision, and manage large, complex VPNs.  It must take
  into consideration:
     - security
     - scalability
     - manageability
     - reachability
  Managing at the device level is not scalable

  Propose using IPsec groups:
     - a middle layer building block
     - can provision tunnels on group and device levels
  Group attributes are defined and applied to all tunnels by default

  Need group-level policy definition, negotiation, provisioning and
  management along with interaction with device level policy
  management.

  Question (from the audience) if this naturally leads to nested
  tunneling.

  WG chairs: more work is needed to determine if this belongs in IPSP.

M. Condell - MSME: Policy Abstraction in IPSP
  draft-ietf-ipsp-msme-00

  Mulidimensional Security Management and Enforcement (MSME) is
  security policy management for dynamic coalitions.  Allows partners
  to negotiate mission-related policy before communications required.
  Accomplished by policy abstraction, resolution, exchange, and
  monitoring.

  Architecture based around Policy Level Agreement (PLA) which has
  abstract policy rules and bindings that map the abstract rules to
  concrete policy.  Compilation provides consistency checking and pulls
  in needed bindings.  Resolution, exchange similar to IPSP.  
  Reconcilliation allows a partner to verify that a resolved PLA is
  consistent with its local policy.

  MSME/IPSP differences
    - MSME resolves policy before communications are needed.
    - MSME resolves all policy at once, instead of policy for one 
      communication.
    - Supports multiple security contexts
    - Pre-IPSP step for coalitions

  Abstraction in MSME
    - Bindings map name to value
    - may map to multiple security contexts
    - Refer to name in policy rule
    - Coalition-wide names for assets allows other partners to use the
      name in their policies
    - Names mapped to values during resolution

  Why use abstraction in IPSP?
    - Late Name Binding
       - Idea from SPP/SPSL, though not well developed there
       - Names understood by both domains, defined during resolution
       - Enables domains to change enforcement points without other domains
         having to change policy
    - Generalization
       - May allow IPSP to support more than IPsec
       - One name maps to multiple security contexts
       - Resolution determines which contexts supported

  To support abstraction IPSP protcol needs to be able to define and
  transport binding names in policy rules and the bindings themselves.
  Also needs to support processing of bindings

W. Hardaker - MIB
  draft-ietf-ipsp-ipsec-conf-mib-02

  Changes:
    - text cleanup
    - endpoint maps to a single group instead of multiple

  Last call will be before March IETF
  
  * Please read the draft!! *

A. Doria - PIB
  draft-ietf-ipsp-ipsecpib-(soon to be 04)

  -04 will be out within a month

  It's compliant with IPsec standard, configuration policy model.

  Mostly minor changes. 
    - Only MUSTs are what's in the IPsec standards
    - Easy adding of other key negotiation protocols
    - many other small changes.

  There's a Nokia implementation and possibly one coming from SSH

  Last call after -04.

Working group status:

  There was a 2 week WG last call on draft-ietf-ipsp-config-policy-model-04

  Will submit for Proposed Standards to IESG:
      draft-ietf-ipsp-requirements-01
      draft-ietf-ipsp-config-policy-model-04
      draft-ietf-ipsp-ipsecpib-04
      and possibly the MIB

---

From: "Lee Rafalow" <[email-masked]>
Date: Thu, 13 Dec 2001 22:19:32 -0700

>        Should the WG pursue something beyond TED, which could be SPP?

I was, I think, the only "few objections" to pursuing gateway discovery.
The reason I objected is that if we're going to have a protocol that
publishes policy to anyone who asks and that only works for a subset of the
network, we can do much, much better with an existing protocol: LDAP.
Define a schema (based on the ICPM + topology).  The installation can then
use the existing authorization mechanisms to restrict accesses as
appropriate and anyone with authorization can then find the appropriate
gateway(s) and the needed policy options to be able to initiate an SA.

Two cents from a minority of one.  Cheers.

Lee M. Rafalow
Voice: 1-919-254-4455, Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Personal email: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Dec 2001 22:25:26 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>>  "Lee" == Lee Rafalow <[email-masked]> writes:
     Lee> I was, I think, the only "few objections" to pursuing gateway
     Lee> discovery. 
     Lee> The reason I objected is that if we're going to have a protocol
     Lee> that publishes policy to anyone who asks and that only works for a
     Lee> subset of the 

   Keeping policy information confidential is a goal (not always achieveable),
although I see that it has slipped out of the requirements document. I'll add
it back.

     Lee> network, we can do much, much better with an existing protocol: LDAP.
     Lee> Define a schema (based on the ICPM + topology).  The installation
     Lee> can then 

   And what key would you use to look up the policy in this "global 
LDAP database"?

   if you wish, you may think of tunnel endpoint discovery as potentially
discoverying an address of an LDAP server along with index into its database.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 19 Dec 2001 08:44:13 -0500

Off the top of my head, I'd say that the schema and dit structure would be
optimized for a fully-qualified hostname search and that gateway topology
would be represented by DN references.  The available policies would also be
DN references and can be protected by access controls.  IMHO, this would be
significantly better than TED in that it is not topology limited and has
access controls, but I've given almost no thought to scaling and maintenance
issues (although they seem tractable on first blush).

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 17, 2001 10:25 PM
Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF)

> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Finger me for keys
>
> iQCVAwUBPB63JIqHRg3pndX9AQFsHAP/TBNgvYunZXdjilK8Xm8Z9EaJVVr2iHxm
> hAB/fXDf9xW+mj8SDYjsRs4hVw7/dDqY4V/5yzJqKuSnLhvK15Z3fjKpcze+BMY2
> IZam4L83O+IhX8YakBtZ3whp8kz68JiLLUzQbnoRVjJzFFsIprCuwBg5UcvPd724
> nT23n/yLhuQ=
> =3hps
> -----END PGP SIGNATURE-----
>

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Wed, 19 Dec 2001 15:42:23 -0500

Lee,

It would be extremely difficult to configure, maintain, secure, and  just to
make work in general an LDAP or series of LDAP directories with all the IP
addresses of all the IPsec Security Gateways that could be protecting some set
of hosts at any given time. First of all, one needs to answer a series of
political questions beyond the scope of our work here. For instance, which LDAP
directories, do we trust them, who do we trust, who maintain them...
authoritative?, etc... the list goes on and on. I would say that we should
consider an independent and dynamic protocol that can propagate IPsec SG
information (IP addresses, policies, etc.) in a secure fashion (authenticated,
integrity checked, encrypted when needed, etc.) among hosts that need such
information to establish an end2end IPsec SA.

Luis

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Dec 2001 16:32:32 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Lee" == Lee Rafalow <[email-masked]> writes:
    Lee> Off the top of my head, I'd say that the schema and dit structure
    Lee> would be optimized for a fully-qualified hostname search and that
    Lee> gateway topology would be represented by DN references.  The

  And, who would ask this question?

  Further, how does a forward search (FQDN->IP) tell you anything about about
the world? People can put any A record they want into DNS or into LDAP.

    Lee> available policies would also be DN references and can be protected
    Lee> by access controls.  IMHO, this would be significantly better than
    Lee> TED in that it is not topology limited and has access controls, but
    Lee> I've given almost no thought to scaling and maintenance issues
    Lee> (although they seem tractable on first blush).

  Oh, so you mean that LDAP directory replication is finally stable?

---

From: Henry Spencer <[email-masked]>
Date: Wed, 19 Dec 2001 16:35:49 -0500 (EST)

On Wed, 19 Dec 2001, Luis A. Sanchez wrote:
> of hosts at any given time...

Of course, if you want a database that covers all those gateways, there
*already is one*.  It's called DNS.  Why re-invent the wheel, especially
when the re-invented one is often square?

                                                          Henry Spencer
                                                       [email-masked]

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 20 Dec 2001 09:26:20 +0100

>when the re-invented one is often square?

So, we are back to square one: using the KX of DNSsec ;-)

Personally, I do not disagree

-eric

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 20 Dec 2001 09:33:35 +0100

At 22:19 13/12/2001 -0700, Lee Rafalow wrote:
>)

It is always nice to be part of the minority ;-)

Based on my experience of deploying IPSec, there is a big issue with
IPSec deployment compared to QoS deployment: if one single IPSec device
has a policy which is not compatible with the rest of the devices, then
your VPN (or IPSec protected network) will completely break (including
the lost of control plane).

This is thus completely different than the QoS story. If one QoS device
has a policy which is not compatible with the rest of the devices, then
your QoS enabled network will still run (including the control plane) but
perhaps with a sub-optimal configuration.

Where I'm getting to is the fact that any kind of centralized management
for IPSec is somehow broken because there is no guarantee that all
IPSec devices can receive their new policy at a convenient time.
=> some devices will have a policy incompatible with the rest of the
devices...

Even further, LDAP uses a poll & pull model which will delay the
policy synchronization. So, we should at least try to get a push
protocol (PDP to PEP flow) like COPS-PR (perhaps using a LDAP
based PDP).

Hence, the genuine interest of TED (which could of course be improved).

Regards

-eric