[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec error codes
Paul Koning wrote:
>
> >>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
>
> Scott> Hi Suresh, Pyda Srisuresh wrote:
> >> <... snip> > I'd like some input on this before attempting to
> >> write up something more > substantial. Are there additional
> >> requirements? Are the ones specified > here correct? > > Scott >
> >> Here is my thinking on this.
> >>
> >> When a packet is dropped at any node across the network due to
> >> enforcement of a certain policy, it would be beneficial for the
> >> end-node (that originated the packet) to know the policy that
> >> caused the packets to drop and why.
> >>
>
> Scott> One obvious concern with this would be denial of service
> Scott> attacks, i.e. now, you not only have to reject the packet,
> Scott> but you have to send out a meaningless notification as well. I
> Scott> suppose that if you could configure the device to only respond
> Scott> to known (that is, configured) endpoints, this would mitigate
> Scott> the risk, though not eliminate it entirely.
>
> Not just that, but responding to strange input may be a security
> concern above and beyond denial of service.
>
> Clearly, any notion that you respond in ANY way to erroneous packets
> has to be at the option of the network manager. It probably should be
> implementation-optional. It may well be appropriate for the default
> to be not to respond. (My reasoning is that everyone should always
> default to the most secure option, while giving management the option
> to open things up. Of course I realize that many virus channels,
> er.., software products are built on the opposite notion.)
>
Agree fully - something that ocurred to me after replying to Suresh is
that where the message is sent to is really out of scope for this
effort. That is, the focus of this effort should be the content of the
messages, not the destination(s).
Scott
References: