> ...
>
> > > (2) Section 4.9 defines rate control for
Authentication
> > > failures on a per-fabric granularity. That
strikes
> > > me as overly coarse, and I wonder if per-SA
would
> > > be a more appropriate/useful granularity.
> >
> > I think the question here is whether it's likely
that authentication
> > failures will occur on many SA's at the same time
-- if it is likely,
> > then per-Fabric rate control allows for plenty of
notifications in
> > isolated cases without getting overloaded when
many SA's have the
> > problem. But, if there's no correlation between
occurrences on
> > different SA's, then the odds of many SA's having
the problem at the
> > same time is presumably negligible, and I agree
that per-SA would be
> > better.
>
> I think this also revolves around the number of SAs. I
would expect
> FC-SP SA usage to be more akin to a site-to-site VPN
(small number of
> SAs carrying large amounts of traffic) than a remote
access VPN
> (large number of SAs carrying smaller amounts of
traffic). That
> should limit the size of a one-per-SA notification
burst in practice.
>
> I definitely agree with your concern about overload, as
authentication
> failures are relatively cheap to generate (e.g.,
attacker need not do
> any crypto calculations), and hence causing a large
number of such
> failures in a short time period could be a denial of
service attack
> based on the work involved in generating the
notifications.
>
> OTOH, this text:
>
> For t11FcSpSaNotifyAuthFailure, rate control is
achieved by
> specifying that it is generated only for the first
occurrence of an
> Authentication failure on a particular Fabric within
a time window.
>
> strikes me as providing unwarranted help for an
attacker trying
> to cover her tracks - she opens an SA to the victim,
generates
> an authentication failure, thereby generating the first
notification,
> and can then attack other SAs for the same fabric
within the time
> window, since their notifications are suppressed.
>
> Perhaps what's appropriate is a 2-level rate limiting
structure:
> - At most one notification per SA in the (settable)
time window.
> - At most <n> (new settable value) notifications
per fabric in
> the same (settable) time window.
That sounds fine to me.
(FYI - I'm going to keep track of the changes we agree upon,
and do all
the editing after the end of the Last Call.)
Keith.
_______________________________________________
imss mailing list
imss ietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss
|
