[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft IPv6 Security API for BSD Sockets
>
> I'm not very happy with some aspects of the draft. My two main
> areas of concern are the nature of the interface and the error-reporting
> mechanisms proposed.
>
> The latter is easier to explain. I don't think that, in general,
> it's at all a good idea to send errors to a security-aware application
> simply because bogus (or damaged) packets are received. If nothing
> else, it opens us up to easy denial of service attacks -- an attacker
> can spew out bogus packets, he or she can cause these sessions to
> abort. While security error statistics should be maintained,
> certainly on a system- wide basis and probably on a per-SAID or
> per-connection basis, it isn't at all clear to me that most
> applications -- even security-aware ones -- need to be told about
> these at all times. I'd suggest a more tunable approach -- the
> process specifies a threshold, which defaults to infinity, for
> errors; when the the threshold is exceeded, a process-specified
> signal (or maybe SIGSECURITY or SIGHACK) could be raised.
[...]
Signals are only going to be useful when a process a single socket open.
There needs to be either assistance to the signal to distinguish it, else
saying "OI! Security Alert on *A* network connection!" isn't much help,
as a socket need not be actively doing IO for the condition to be arise.
That is, unless there is a restriction in the spec which says a process
may not open more than 1 network connection which requires security to be
observed (or only one can be monitored), the signal doesn't really help
much.
darren
References: