[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DMTF SAAction restriction

To: <ipsec-policy@xxxxxxx>
Subject: Re: DMTF SAAction restriction
From: "Lee Rafalow" <rafalow@xxxxxxxxxxxxxxx>
Date: Tue, 6 Feb 2001 12:57:13 -0500
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>
References: <>
Sender: owner-ipsec-policy@xxxxxxxxxxxxx
As Eric indicated, the model has actions that contain proposals that contain
transforms.  So, a single action is used to send multiple proposals.  The
"try until successful" semantic on the ordered actions permits a rule to
specify fallback actions for the initiator.  The most common example might
be a rule that could specify a negotiation action as the first choice and a
bypass or discard static action as the second choice.  So, if the IKE
negotiation fails for some reason, the rule explicitly states the
alternative action.  Another example might be that a rule could also specify
a different negotiation action, perhaps to a different security gateway as a
second, third, ... action to try in the event of failure.  Similarly, the
fallback action could be to use a preconfigured SA in the event that the
peer has no IKE service.  These fallback functions may be beyond that
required for the protocol as specified, but they're not beyond that required
for implementations that use the protocol.  So, assuming we agree on these
semantics, this will be documented in the draft but it will documented as an
optional function.

I hope this helps.  Lee

----- Original Message -----
From: <Man.M.Li@xxxxxxxxx>
To: <evyncke@xxxxxxxxx>; <ipsec-policy@xxxxxxx>
Sent: Tuesday, February 06, 2001 11:20 AM
Subject: RE: DMTF SAAction restriction


> 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
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