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

RE: DMTF SAAction restriction

To: Man.M.Li@xxxxxxxxx, ipsec-policy@xxxxxxx
Subject: RE: DMTF SAAction restriction
From: Eric Vyncke <evyncke@xxxxxxxxx>
Date: Tue, 06 Feb 2001 17:17:13 +0100
In-reply-to: <>
List-archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-id: <ipsec-policy.vpnc.org>
List-unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>
Sender: owner-ipsec-policy@xxxxxxxxxxxxx

We talked about different things:

1) when ISAKMP is trying to build a SA, it sends multiple proposals

2) in the DMTF model, for one data traffic pattern, multiple actions are tried
until success:
    a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
    b) if it fails, let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG2
    c) if it fails, let's try DES-pre-shared with SG3

Obviously, the DMTF model allows the configuration of a complex IKE proposal
(see IKEProposal class which is associated to SANegotiationAction).

Hope this helps

-eric

At 09:30 6/02/01 -0600, Man.M.Li@xxxxxxxxx wrote:
>Is the "try until one succeeds" being described in any RFCs or is it only
>ONE way of implementation? I recall ISAKMP allow initiator to propose
>multiple proposals and multiple transforms for responder to choose from. But
>I do not recall seeing this "try until one succeeds". 
>
>
>Man Li
>Nokia 
>5 Wayside Road, Burlington, MA 01803
>man.m.li@xxxxxxxxx
>phone 1-781-993-3923
>GSM 1-781-492-2850 
>
>-----Original Message-----
>From: ext Lee Rafalow [mailto:rafalow@xxxxxxxxxxxxxxx]
>Sent: Tuesday, February 06, 2001 9:48 AM
>To: ipsec-policy@xxxxxxx
>Subject: Re: DMTF SAAction restriction
>
>
>The approach that we've thought through so far would use your first example
>to set up the tunnel.  We could explore your suggestion to add a sematic to
>the action list, but that complicates it significantly.  We already have
>semantics for the initiator and responder that are variations on "try until
>one succeeds."  Recall that for the initiator it's try the first one, if
>that fails try the second, etc.  For the responder it's a little more
>complicated: respond from the first action that is appropriate to the
>request (this allows a single rule to deal with both aggressive and main
>mode requests).
>
>
>To add semantics for "do ordered list of actions" would require a fairly
>complicated grammar for grouping actions into execution strategy groups (do
>all, do first successful).
>
>A way out of this might be to use the structured rules being proposed in the
>PCIM Extensions draft (currently being written) but that'll have to wait
>until we have a PCIMe draft to discuss.
>
>Lee
>----- Original Message -----
>From: <Man.M.Li@xxxxxxxxx>
>To: <HORMAN@xxxxxxxxxx>; <ipsec-policy@xxxxxxx>; <jamie.jason@xxxxxxxxx>;
><Man.M.Li@xxxxxxxxx>
>Sent: Monday, February 05, 2001 4:14 PM
>Subject: RE: DMTF SAAction restriction
>
>
>> Security per se may not be a problem. But if only a small percentage of
>> traffic needs multiple nested protection and we end up with giving all the
>> traffic multiple protections, it would be a waste of resources (e.g.,
>> processing resource for encryption). Security comes with a price and I
>> question if service providers or corporate IT managers will be happy about
>> giving the free ride at the expense of network resources.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@xxxxxxxxx
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Hilarie Orman [mailto:HORMAN@xxxxxxxxxx]
>> Sent: Monday, February 05, 2001 3:10 PM
>> To: ipsec-policy@xxxxxxx; jamie.jason@xxxxxxxxx; Man.M.Li@xxxxxxxxx
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Why would it be erroneous to include a tunnel gratuitously?
>> Wrt to security, what is the problem?
>>
>> Hilarie
>>
>> >>> <Man.M.Li@xxxxxxxxx> 02/05/01 11:22AM >>>
>> What selectors are you looking for in your second search after the
>transport
>> rule? Is it a selector for the already encrypted packets (hence protocol =
>> ESP, for example) or for the original packets (protocol = tcp)? I see
>> problems in both cases. In the first case, if there is a rule to set up a
>> tunnel for ESP packets, we may include some other traffic that are ESP
>> transport protected but should not be included in the tunnel. In other
>> words, those traffic should only be transport protected.
>>
>> In the second case, we cannot reach the second selector for tunnel set up
>> because first matches will stop the search.
>>
>> A simple solution would be to remove the restriction and let SAActions to
>> indicate an ordered list of actions to be executed.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@xxxxxxxxx
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Jason, Jamie [mailto:jamie.jason@xxxxxxxxx]
>> Sent: Monday, February 05, 2001 11:01 AM
>> To: 'Man.M.Li@xxxxxxxxx'; ipsec-policy@xxxxxxx
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Lee can correct me if I am wrong on this one, but I believe we had this
>same
>> discussion during a conference call between Lee, Eric Vyncke, and myself.
>I
>> believe the solution we came up with was that policy evaluation would
>first
>> encounter the transport rule.  Policy evaluation would then search to
>> determine if there was a tunnel rule that would apply (it would do this
>> recursively as you may have tunnels in tunnels).  This update probably
>> hasn't hit the MOF file or whitepaper yet.
>>
>> Jamie
>>
>> > -----Original Message-----
>> > From: Man.M.Li@xxxxxxxxx [mailto:Man.M.Li@xxxxxxxxx]
>> > Sent: Monday, February 05, 2001 7:16 AM
>> > To: ipsec-policy@xxxxxxx
>> > Subject: DMTF SAAction restriction
>> >
>> >
>> > Hi,
>> >
>> > The DMTF policy model Section 3 first paragraph indicates
>> > "The IPsec model
>> > restricts the use of SAActions to an ordered choice rather
>> > than a list of
>> > actions to be executed." I am wondering how the following
>> > situation would be
>> > handled with this restriction. We had similar discussions
>> > among IPsec PIB
>> > authors.
>> >
>> >        A (host)===========C(gateway)---B(host)
>> >
>> > A and C are connected to public Internet and B is connected
>> > to C. To protect
>> > TCP traffic between hosts A and B, an IPsec security association in
>> > transport mode needs to be established between hosts A and B.
>> > In addition,
>> > an IPsec security association in tunnel mode may be set up
>> > between host A
>> > and the gateway C that protects the LAN host B resides.
>> >
>> > In this case, A takes one action to set up an association
>> > between A and B.
>> > In addition, A should also set up a tunnel between A and C.
>> > From A's point
>> > of view, there are MULTIPLE actions to be taken in that order.
>> >
>> > How would you specify a policy to A if you are not allowed to
>> > specify a list
>> > of actions to be executed?
>> >
>> >
>> > Man Li
>> > Nokia
>> > 5 Wayside Road, Burlington, MA 01803
>> > man.m.li@xxxxxxxxx
>> > phone 1-781-993-3923
>> > GSM 1-781-492-2850
>> > 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@xxxxxxxxx          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000

References:
- RE: DMTF SAAction restriction
  - From: Man . M . Li

Prev by Date: RE: DMTF SAAction restriction
Next by Date: RE: DMTF SAAction restriction
Previous by thread: RE: DMTF SAAction restriction
Next by thread: RE: DMTF SAAction restriction
Index(es):
- Date
- Thread