[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiple payloads via "ID_LIST"
Roy,
I'm not talking about what policy is, I'm saying why would one want to
do IPSec at such a network aggregation point? How many disjoint, non-
combinable networks does TimeStep have? 2? 5? Probably less than 10.
If you go a few hops away from TimeStep into your service provider cloud
there'll probably be a network aggregation point at which there are
a hundred. But I don't think you want to do IPSec there. Most customers
are suspicious of the other people who are also routed to through that
aggregation point. Maybe some ISP would try to sell IPSec as a service in
this fasion, but I don't see any businesses purchasing that service. It
seems to me that you want to do IPSec as close as possible to you and do
it on a box that you manage. You want to do it on your gateway(s) or do it
end-to-end. And then the number of disjoint, non-combinable networks is
manageable, it's 2 or 5 or zero and you can just establish individual SAs
to handle them.
Assuming TimeStep does have hundreds of disjoint, non-combinable networks
that a single (TimeStep owned and managed) gateway can route to this also
seems like an inflexible, unextensible, management nightmare. There's a
one-size-fits-all policy for every single resource on those hundreds of
networks. Yeech.
You're right that it would be nice to have the capability to express
a list of networks, and then manage a single SA pair instead of 2 pairs or
5 pairs or whatever. But I don't see this as one of the "needed it yesterday"
problems (as was mentioned earlier in this thread). I think it fits more into
the "if it ain't broke" catagory since there is a way to solve this problem.
It's a tad annoying but it's not that bad. I think this can wait.
Dan.
On Wed, 30 Sep 1998 10:04:20 EDT you wrote
>
> Sorry Dan, but I have to agree with Shawn on this one. Policy isn't based
> on just the IKE ID types. Policy is usually based on groups of such objects
> so it make sense to set up one SA on that logical policy group on not is
> individual pieces.
>
> I don't think this is a major problem, but it would 'be nice to have' the
> ability to set up one SA instead of multiple for the exact same policy.
> Instead of waiting for 'x' * 'y' seconds to establish 'y' SAs, the user
> would only have to wait 'x' seconds. The key is that the exact same policy
> is being used, so the subsequent QuickModes are superfluous because they are
> negotiating the exact same policy. If policy is based on logical objects
> that may contain other objects, then it makes sense for the IKE negotiation
> to emulate this.
>
> > -----Original Message-----
> > From: Daniel Harkins [mailto:dharkins@cisco.com]
> > Sent: Tuesday, September 29, 1998 8:25 PM
> > To: Shawn_Mamros@BayNetworks.COM
> > Cc: Scott G. Kelly; Michael C. Richardson; ipsec@tis.com
> > Subject: Re: multiple payloads via "ID_LIST"
> >
> >
> > This may be an issue but is it a problem? Do your customers actually
> > want to do this? (As opposed to just wanting to raise it "as
> > an issue"). By
> > doing IPSec on such a network aggregation point you're saying
> > that all those
> > hundred+ networks share the same policy and are not mutually
> > suspicious.
> > This seems unrealistic to me. Does this aggregations point's
> > IPSec peer also
> > have a hundred+ disjoint, non-combinable networks behind it?
> >
> > Can you explain what it is these people are trying to do?
> >
> > Dan.
> >
> > On Thu, 24 Sep 1998 12:48:01 EDT you wrote
> > > > If they needed it yesterday tell them to establish 2
> > SAs, one soley
> > > >for X and the other soley for Y. It would be *nice* to be
> > able to have a
> > > >single one but I think this clearly falls in the "if it
> > ain't broke..."
> > > >category. It can be easily solved today (and yesterday
> > too) using existing
> > > >mechanisms.
> > >
> > > What if, instead of there being only two subnets behind a security
> > > gateway, there were a hundred or more? All disjoint,
> > non-combinable,
> > > etc. It becomes a serious resource utilization issue, not
> > to mention
> > > that negotiating all those Quick Modes takes time (especially when
> > > you're doing PFS), and it seems a waste when you're
> > applying the same
> > > security policy to all of them.
> > >
> > > And yes, I've had customers (plural) that have cited this
> > as an issue.
> >
>
> ------_=_NextPart_001_01BDEC7B.392DBE80
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2232.0">
> <TITLE>RE: multiple payloads via "ID_LIST" </TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2>Sorry Dan, but I have to agree with Shawn on this =
> one. Policy isn't based on just the IKE ID types. Policy is =
> usually based on groups of such objects so it make sense to set up one =
> SA on that logical policy group on not is individual pieces. =
> </FONT></P>
>
> <P><FONT SIZE=3D2>I don't think this is a major problem, but it would =
> 'be nice to have' the ability to set up one SA instead of multiple for =
> the exact same policy. Instead of waiting for 'x' * 'y' seconds =
> to establish 'y' SAs, the user would only have to wait 'x' =
> seconds. The key is that the exact same policy is being used, so =
> the subsequent QuickModes are superfluous because they are negotiating =
> the exact same policy. If policy is based on logical objects that =
> may contain other objects, then it makes sense for the IKE negotiation =
> to emulate this.</FONT></P>
>
> <P><FONT SIZE=3D2>> -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>> From: Daniel Harkins [<A =
> HREF=3D"mailto:dharkins@cisco.com">mailto:dharkins@cisco.com</A>]</FONT>=
>
> <BR><FONT SIZE=3D2>> Sent: Tuesday, September 29, 1998 8:25 =
> PM</FONT>
> <BR><FONT SIZE=3D2>> To: Shawn_Mamros@BayNetworks.COM</FONT>
> <BR><FONT SIZE=3D2>> Cc: Scott G. Kelly; Michael C. Richardson; =
> ipsec@tis.com</FONT>
> <BR><FONT SIZE=3D2>> Subject: Re: multiple payloads via =
> "ID_LIST" </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> This may be an issue but is it a =
> problem? Do your customers actually</FONT>
> <BR><FONT SIZE=3D2>> want to do this? (As opposed to just wanting to =
> raise it "as </FONT>
> <BR><FONT SIZE=3D2>> an issue"). By </FONT>
> <BR><FONT SIZE=3D2>> doing IPSec on such a network aggregation point =
> you're saying </FONT>
> <BR><FONT SIZE=3D2>> that all those </FONT>
> <BR><FONT SIZE=3D2>> hundred+ networks share the same policy and are =
> not mutually </FONT>
> <BR><FONT SIZE=3D2>> suspicious. </FONT>
> <BR><FONT SIZE=3D2>> This seems unrealistic to me. Does this =
> aggregations point's </FONT>
> <BR><FONT SIZE=3D2>> IPSec peer also </FONT>
> <BR><FONT SIZE=3D2>> have a hundred+ disjoint, non-combinable =
> networks behind it? </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> Can you explain what it is these =
> people are trying to do? </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> Dan.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> On Thu, 24 Sep 1998 12:48:01 EDT you =
> wrote</FONT>
> <BR><FONT SIZE=3D2>> > > If they needed it yesterday =
> tell them to establish 2 </FONT>
> <BR><FONT SIZE=3D2>> SAs, one soley</FONT>
> <BR><FONT SIZE=3D2>> > >for X and the other soley for Y. It =
> would be *nice* to be </FONT>
> <BR><FONT SIZE=3D2>> able to have a </FONT>
> <BR><FONT SIZE=3D2>> > >single one but I think this clearly =
> falls in the "if it </FONT>
> <BR><FONT SIZE=3D2>> ain't broke..." </FONT>
> <BR><FONT SIZE=3D2>> > >category. It can be easily solved =
> today (and yesterday </FONT>
> <BR><FONT SIZE=3D2>> too) using existing </FONT>
> <BR><FONT SIZE=3D2>> > >mechanisms.</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > What if, instead of there being only two =
> subnets behind a security</FONT>
> <BR><FONT SIZE=3D2>> > gateway, there were a hundred or =
> more? All disjoint, </FONT>
> <BR><FONT SIZE=3D2>> non-combinable,</FONT>
> <BR><FONT SIZE=3D2>> > etc. It becomes a serious resource =
> utilization issue, not </FONT>
> <BR><FONT SIZE=3D2>> to mention</FONT>
> <BR><FONT SIZE=3D2>> > that negotiating all those Quick Modes =
> takes time (especially when</FONT>
> <BR><FONT SIZE=3D2>> > you're doing PFS), and it seems a waste =
> when you're </FONT>
> <BR><FONT SIZE=3D2>> applying the same</FONT>
> <BR><FONT SIZE=3D2>> > security policy to all of them.</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > And yes, I've had customers (plural) that =
> have cited this </FONT>
> <BR><FONT SIZE=3D2>> as an issue.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01BDEC7B.392DBE80--
References: