[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DMTF SAAction restriction
Because, I'm sending proposals to three different IKE peers.
-eric
At 10:20 6/02/01 -0600, Man.M.Li@xxxxxxxxx wrote:
>Correct me if I am wrong. But why cannot the three tries be bundled into one
>action with multiple proposals? My understanding is that the purpose of
>having multiple proposals is exactly such that if the responder cannot
>accept the first one (hence fails), it has the choice to choose another one
>from the list.
>
>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 Eric Vyncke [mailto:evyncke@xxxxxxxxx]
>Sent: Tuesday, February 06, 2001 11:17 AM
>To: Man.M.Li@xxxxxxxxx; ipsec-policy@xxxxxxx
>Subject: RE: DMTF SAAction restriction
>
>
>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
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