[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
IBM Networking Hardware Division
Dept MZDA, Bldg 664/H515
RTP, NC 27709
Internal email: IBMUSM25(SBOOTH)
Internet email: email@example.com
Notes email: Skip Booth/Raleigh/IBM
Ricky Charlet <firstname.lastname@example.org> on 03/11/99 01:45:25 PM
To: "'Partha P. Bhattacharya'" <email@example.com>,
cc: (bcc: Skip Booth/Raleigh/IBM)
Subject: RE: policy expressive power in IPSec-VPN policy draft
> 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
>I have a few questions about the Draft "An LDAP Schema for
>Configuration and Administration of IPSec based Virtual Private Networks
>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
>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:
> 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
The validity period is also already a defined condition. So I would
recommend that you
would have two IPSECSecurityActions and policies with the conditions
Policy 1: if (condition == interface X is down)
|| (condition == interface X is heavily loaded)
IPsecSecurityAction (autostart == off)
Policy 2: if (duringTimeRange X..Y)
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
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.
From: Partha P. Bhattacharya [mailto:firstname.lastname@example.org]
Sent: Wednesday, March 10, 1999 10:43 PM
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
- 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
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)
obj (attrib. AHProtocol = SHA)
-------->IPSecTransform obj (attrib. AHProtocol = MD5)
obj (attrib ESPCipher = 3DES, ESPAuth = SHA)
obj (attrib ESPCipher = DES, ESPAuth = SHA)
Hope this answers your question.
Partha P. Bhattacharya
Internet Services Management Group
255 Tasman Drive
San Jose CA 95134