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

RE: policy expressive power in IPSec-VPN policy draft

My responses are inline:

Skip Booth, T/L 441-3186, ext 3-3186
VPN/RLAN Development
IBM Networking Hardware Division
Dept MZDA, Bldg 664/H515
RTP, NC 27709

Internal email: IBMUSM25(SBOOTH)
Internet email: sbooth@us.ibm.com
Notes email: Skip Booth/Raleigh/IBM

Ricky Charlet <rcharlet@redcreek.com> on 03/11/99 01:45:25 PM

To:   "'Partha P. Bhattacharya'" <pbhattac@cisco.com>,
      "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
cc:    (bcc: Skip Booth/Raleigh/IBM)
Subject:  RE: policy expressive power in IPSec-VPN policy draft

>Hey thanks,
>    Actually I knew that about the draft-ietf-ipsec-vpn. I have
>reciently posted two question sets. One was to the 'policy group'I  asking
>the policy group if they are prepared to deal with the 'negotiating
>proposals'. The other was to the IPSec group asking some specific
>about this draft. I am not sure which you are responding to. My questions
>(as posted about this draft) so far remain unaswered by anyone. Here they
>are again.
>I have a few questions about the Draft "An LDAP Schema for
>Configuration and Administration of IPSec based Virtual Private Networks
>(VPNs)" draft-ipsec-vpn-policy-schema-oo.txt
>Even if you have only a subset of answers, I'd be interested.
>1. Has anyone built a MIB translation of LDAP formatted

     We have built a Enterprise MIB Based on an earlier version of this
     primary to interrogate the PDP on the status of the policies read from
     directory server.

>2. The IPSecProposal object includes one AHTransformRef, one
>ESPTransformRef, and one IPCOMPTransformRef. Is the intention here to
>SA bundles to the possible combination of one each from the above three

     No, each of those references is a multi-valued attribute.  For
     a proposal with AH and ESP transforms might look as follows:

          AHTransformRef:  1: cn=strongAH, o=ibm, c=us
          ESPTransformRef: 1: cn=veryStrongESPnoAuth, o=ibm,c=us
          ESPTransformRef: 2: cn=StrongESPnoAuth, o=ibm,c=us

     The <n>:dn syntax allows the values of the attributes to state
     the priority of the transform in the proposal.

>3. Could there be a way for the PolicyAction object to be able to
>vendor specific actions not defined in this draft? What would be the

     You can always subclass the PolicyAction class and define whatever is
     necessary.  I would hope that we could minimize subclassing into new
     classes just to avoid interropability problems.  I would prefer that
     if there is information that is important to all implementations that
     it would make it into the original class.

>4. In the IPSecSecurityAction, aren't the *proxied* objects redundant with
>the IPPolicyCondition which brought this action into play?

     I think so as well.  We have done an implementation based on this
     and we did not implement the proxy attributes and instead extracted
     the information in the IPPolicyCondition to use as our proxy.
     we can reach some agreement on whether there is value in defining
     attributes that define the same set of information.

>5. What do you think of changing the *autoStartFlag objects to
>*autoStartCondition objects which would have references like:
>    always
>    never
>    duringTimeRange X..Y
>    if interface X is down
>    if interface X is heavily loaded

     It seems that like the always and never are already covered in the
current definition.
     The validity period is also already a defined condition.  So I would
recommend that you
     would have two IPSECSecurityActions and policies with the conditions
stated above.


     Policy 1:      if (condition == interface X is down)
                    || (condition == interface X is heavily loaded)
               then do:
                    IPsecSecurityAction (autostart == off)

     Policy 2: if (duringTimeRange X..Y)
               then do:
                    IPSecSecurityAction (autostart == on)

>6. Inside of one IPSecProposal are we limited to one DH group for all
>transforms (ESP, AH)?

     Yes the current schema limits you to that.  However, I actually
     think that the DH Group should be in the IPSecSecurityAction
     since that my understanding is that all the transform within
     a proposal suite must have the same value for PFS and
     correspondingly to the DHGroup.

>7. What are the reasons for making ISAKMPAction a PolicyAction? Arn't the
>'PolicyCondition's for selection ISAKMPAction trivial and possibly even
>unalterable by local policy <if port 500>? I see that ISAKMPAction is
>reference from IPSecSecurityAction, this seems appropriate and sufficient

     I agree.  It really depends on the semantics of the policy and whether
     the Phase 1 policies (condition ISAKMP Packets + ISAKMP Action) is
     stored in the directory or whether the PDP will generate these rules
     after downloading the security policy.  As the current schema is
     the "filter rules" could actually be stored in the directory.  I am
     that we can start some discussion on this issue.

>8. Does anyone <esp. authors> have some opinions about how external
>authentication/authorization engines might be married into this draft?

     None at this point

>9. Suppose two packets pass through a security gateway, receiving IPSec
>treatment. On the first packet, how does this schema allow multiple ISAKMP
>and IPSec proposals to be offered in the two negotiation phases? On the
>second packet, how does this schema identify those particular proposals
>(ISAKMP and IPSec, one each) that won the negotiation when the first

     I don't believe this is a schema issue.  The schema tells the PDP
(security gateway)
     what proposal suite to negotiate.  The first packets will kick off the
     phase 1 negotiations and then once they complete the phase 2
     Once the negotiation completes, the SG has established a specific
     of the policy to use for the rest of the packets.

>Ricky Charlet

-----Original Message-----
From: Partha P. Bhattacharya [mailto:pbhattac@cisco.com]
Sent: Wednesday, March 10, 1999 10:43 PM
To: policy@raleigh.ibm.com
Cc: rcharlet@redcreek.com
Subject: policy expressive power in IPSec-VPN policy draft


In short, the LDAP VPN policy schema draft
provides the full policy expressive power as required by IPSec.

The basic version of an IPSec (data protection) policy as described in the
consists of
   - one PolicyCondition object and
   - one IPSecSecurityAction object
  - one ISAKMPAction object

The IPSecSecurityAction object  consists of tunnel end point descriptions
a list of IPSecProposal objects (semantics between multiple proposals is
logical OR).
The preference can be  ndicated by doing "n:DN".

Each proposal is an IPSec transform set; it consist of
 - a list of AH transforms,
 - optionally a list of ESP transforms and
 - optionally a list of  IPCOMP transforms.

AH, ESP and IPCOMP  transform objects are represented as
IPSecTransform objects (it includes a type that indicates what protocol
it corresponds to).

If multiple AH (resp. ESP, IPCOMP) transforms are present in the same
IPSec proposal then the semantics is logical OR. The preference can be
indicated by doing "n:DN".

The semantics of any combination of AH, ESP and IPCOMP protocols in an
IPSec proposal is logical AND.

Consider the following multi-proposal example, suppose your policy is
 - if HTTP to dest 1.1.1.* then
- do ipsec and negotiate two proposals
     - either ESP= 3DES, SHA and AH = SHA  or MD5 (first preference)
    -  or  EPS = DES, SHA (second preference)


   - PolicyConditionRef ---------> PolicyCondition object (proto= HTTP,
destAddr = 1.1.1.X)
   - IPSecSecurityAction
             --------->IPSecProposal obj
                               attr:  AHTransformRef
obj (attrib. AHProtocol = SHA)

-------->IPSecTransform obj (attrib. AHProtocol = MD5)

                               attr: ESPTransformRef------->IPSecTransform
obj (attrib ESPCipher = 3DES, ESPAuth = SHA)

             ---------->IPSecProposal obj
                               attr: ESPTransformRef------->IPSecTransform
obj (attrib ESPCipher = DES, ESPAuth = SHA)

Hope this answers your question.

Partha P. Bhattacharya
Internet Services Management Group
Cisco Systems
255 Tasman Drive
San Jose CA 95134