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

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?

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? 

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.

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

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

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

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.

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

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?

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