RE: [security-services] the "unbounded" issue

[Allen Rogers <arogers@authentica.com>]

Yes, very true. I thought about that and considered commenting on it. It
seems to me that there are a lot of ways to mount DoS attacks and we need to
rely on the applications to implement safeguards that are reasonable for
their specific situation. I know that's vague and ambiguous but I think it's
better than imposing arbitrary limits.

My $.02

-Allen


> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Thursday, January 24, 2002 4:55 AM
> To: arogers@authentica.com
> Cc: security-services@lists.oasis-open.org
> Subject: Re: [security-services] the "unbounded" issue
>
>
>
> Allen,
>
> There are also DoS issues. Every time I see an XML schema with
> an unbounded I think of DoS. Maybe I'm paranoid, but I think
> we're building ourselves some interesting future problems
> ('course we'll still have jobs to do as a result:-).
>
> Stephen.
>
> Allen Rogers wrote:
> >
> > I disagree. Putting arbitrary limits is generally a bad
> idea. We can't
> > propose to know all applications that this may be used for.
> What may seem
> > unreasonable today may not seem so unreasonable in the
> future. This has been
> > proven many times over in the technology field. Plus, any
> decent application
> > written to support 1,000 will do so dynamically and will
> just as easily
> > support 10,000 or 100,000. There may be performance
> implications but that's
> > for the application designer to address.
> >
> > -Allen
> >
> > > -----Original Message-----
> > > From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu]
> > > Sent: Wednesday, January 23, 2002 7:25 PM
> > > To: OASIS Security Services TC
> > > Subject: [security-services] the "unbounded" issue
> > >
> > >
> > >
> > > On Tue, 22 Jan 2002, Stephen Farrell wrote:
> > >
> > >   - Why allow "unbounded" anywhere? I see no reason why
> 10000000000
> > >   statements MUST be supported, which is what seems to be
> > > implied. Suggest
> > >   including a max value that implementations MUST support, to
> > > be the same
> > >   for all cases of "unbounded". Either incorporate this into
> > > the schema
> > >   (e.g. "maxOccurs=1000") or into text (considering how
> versioning is
> > >   currently done).
> > >
> > > I'm no schema expert, but it seems to me that putting
> something like
> > > "maxOccurs=1000" into the schema isn't the right thing,
> since it makes
> > > sending 1001 of something invalid, where what we want to say
> > > is just that
> > > it's not guaranteed to be interoperable.
> > >
> > > I agree with the sentiment, but the stating of "must handle
> > > at least N"
> > > seems to me to be much more appropriate for the
> conformance document,
> > > though I have to say I can't quite see where it would go in
> > > the current
> > > doc.  But it would be necessary, I think, for conformance
> > > tests to include
> > > handling multiple instances of all the possibly-multiple
> > > items up to the
> > > stated limits.
> > >
> > > So, I believe this is an Issue that needs to be resolved
> one way or
> > > another.
> > >
> > >  - RL "Bob"
> > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>