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

RE: multiple payloads via "ID_LIST"



Title: RE: multiple payloads via "ID_LIST"

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


Follow-Ups: