[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
questions
>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
>draft-ietf-ipsec-vpn-policy-schema-00.txt?
We have built a Enterprise MIB Based on an earlier version of this
draft
primary to interrogate the PDP on the status of the policies read from
the
directory server.
>2. The IPSecProposal object includes one AHTransformRef, one
>ESPTransformRef, and one IPCOMPTransformRef. Is the intention here to
limit
>SA bundles to the possible combination of one each from the above three
>possibilities?
No, each of those references is a multi-valued attribute. For
instance,
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
reference
>vendor specific actions not defined in this draft? What would be the
minimum
>requisites.
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
schema
and we did not implement the proxy attributes and instead extracted
the information in the IPPolicyCondition to use as our proxy.
Hopefully
we can reach some agreement on whether there is value in defining
separate
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.
i.e.
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
to
>me.
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
written
the "filter rules" could actually be stored in the directory. I am
hoping
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
packet
>passed?
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
negotions.
Once the negotiation completes, the SG has established a specific
instance
of the policy to use for the rest of the packets.
>Ricky Charlet
>rcharlet@redcree.com
-----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
Ricky:
In short, the LDAP VPN policy schema draft
draft-ietf-ipsec-vpn-policy-schema-00.txt
provides the full policy expressive power as required by IPSec.
The basic version of an IPSec (data protection) policy as described in the
draft
consists of
- one PolicyCondition object and
- one IPSecSecurityAction object
- one ISAKMPAction object
The IPSecSecurityAction object consists of tunnel end point descriptions
and
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)
Policy:
- PolicyConditionRef ---------> PolicyCondition object (proto= HTTP,
destAddr = 1.1.1.X)
- IPSecSecurityAction
--------->IPSecProposal obj
attr: AHTransformRef
-------->IPSecTransform
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
Follow-Ups: