netdev - Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Oct 2007 12:30:57 +0900
From:	Masahide NAKAMURA <nakam@...ux-ipv6.org>
To:	hadi@...erus.ca
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.

Wednesday 24 October 2007 04:47, jamal wrote:
> On Tue, 2007-23-10 at 16:08 +0900, Masahide NAKAMURA wrote:
> 
> > Thanks. I would like you to find too much item at my patch
> > for the statistics, too.
> 
> I am not anywhere close to a machine where i can give you precise
> details to this; the one thing that sticks out in my brain cells is the
> SPI mismatch. This (in static setups) seemed to be the most common
> mistake i saw (other than a mismatched key). Your stats as you have them
> now and as is will catch both in one spot - which is a good start.

At IPsec point of view, actually "SPI mismatch" caused by user configuration
cannot be identified easily since identify of SAD is consist of SPI, address and
protocol(ESP/AH...) and linux SAD uses hash database. It is database identify
mismatch. Then, SPI mismatch goes "NoStates" at my patch.
OTOH Key mismatch goes "ProtoError" since esp[46]_input returns error.


> > This point is one of what I want to hear comment.
> > My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at
> > include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and
> > it does not seem to be defined by any RFC specification. 
> 
> I thought those were part of some MIB somewhere. Doesnt RFC 4898 cover
> them?

Thanks for pointing the RFC. I've read it, however, I cannot find them at the RFC.

> In any case, it seems to me to be more accurate to not call them MIB
> stats if they are not. This doesnt qualify using the macros, utilities
> etc used for MIBs.

How about assuming it as "private MIB" of linux?

> > Then I feel it is not so bad to
> > use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB.
> > 
> > Now we have the following candidates:
> > 
> > (1) my patch		XFRM_MIB_INHDRERROR
> > (2) some extender	XFRM_XXX_INHDRERROR	(XXX is requested)
> > (3) not-mib extender	XFRM_NOTMIB_INHDRERROR
> > (4) no extender		XFRM_INHDRERROR
> > (5) merge linux-mib	LINUX_MIB_XFRMINHDRERROR
> > 
> > Comments?
> 
> I am very tempted to say #4. And when you push this to be a real MIB
> stat then 

Shouldn't we have something after XFRM_  to distinguish from other XFRM
macros?

> > > 2) Why /proc? Are you going to make these available also via netlink? 
> > 
> > Because /proc is easy to see it without any modified application.
> > If you want the netlink interface, I can do it as the next step. Do you want it?
> 
> Absolutely - it would be much appreciated. And if you dont have time, I
> will write and test the user space part extension.

Thanks. After my first step is completed, could you write the netlink part?

-- 
Masahide NAKAMURA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html