Re: DMTF SAAction restriction

[vincent <vincent@xxxxxxxxxx>]

"Wang, Cliff" wrote:
> 
> Thanks for the clarifications.
> 
> Then the trial and switch by failure is really addressing a different
> issue, which is providing redundant IKE connection.
> 
> The original question is on how to set up policy for nested tunnels.
> 
> -----Original Message-----
> From: Jason, Jamie [mailto:jamie.jason@xxxxxxxxx]
> Sent: Tuesday, February 06, 2001 12:06 PM
> To: 'Man.M.Li@xxxxxxxxx'; evyncke@xxxxxxxxx; ipsec-policy@xxxxxxx
> Subject: RE: DMTF SAAction restriction
> 
> The ability to try different actions until one succeeds was not created as a
> way to subvert the IKE proposal mechanism (i.e., we don't want it used to
> try one proposal, and then if that fails, try another, etc.).  This came out
> of discussions we had with regard to establishing tunnels.  For example, I
> have several different machines I can contact to establish a VPN connection
> into Intel.  I would set up my actions such that my machine would first
> attempt to establish a tunnel to the Jones Farm server, if that fails, I
> would then try to establish a tunnel to the Santa Clara server, etc.
> 
> Hopes this helps.
> 
> Jamie
> 
> > -----Original Message-----
> > From: Man.M.Li@xxxxxxxxx [mailto:Man.M.Li@xxxxxxxxx]
> > Sent: Tuesday, February 06, 2001 8:20 AM
> > To: evyncke@xxxxxxxxx; ipsec-policy@xxxxxxx
> > 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
> >
Please can everybody tell me, how i unsubscribe that mailinglist
ipsec.policy from my
mailing account!
Please give me an answer!
Thanks!

Christian