Using libnetfilter_queue

Using libnetfilter_queue

[Rennie deGraaf]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

Hello all,

I am trying to write an application that uses libnetfilter_queue, and
have a few questions about its API.

If I understand correctly from the example program supplied with
libnetfilter_queue, the user is responsible for reading messages from
kernelspace with a recv() call.  At this point, the messages are still
opaque nfnetlink messages, which must be passed to nfq_handle_packet()
for parsing.  This function never returns a parsed message; the caller
only gets access to the message fields inside the callback that was
provided to nfq_create_queue().  The callback is expected to call either
nfq_set_verdict() or nfq_set_verdict_mark() before returning.

My questions follow:
1. How is the caller supposed to correctly read the message from
kernelspace, when the caller doesn't know the message size?  The caller
should know an upper bound on the size of the packet contents being
returned, but doesn't know the size of the metadata fields or the
netlink header.  The only ways that I have found to safely read messages
are to either allocate large buffers that *should* be able to fit
everything (this is the approach taken by the example program -- except
that the buffer that it allocates is too small for large packets) or to
first read a struct nlmsghdr using MSG_PEEK, decode the total message
size, allocate a buffer of appropriate size, and then read the whole
message (this breaks encapulation).  It seems to me that the better way
to do this would be for the libnetfilter_queue API to provide a function
that safely reads packets from kernelspace without exposing
implementation details to the caller.  If the callback architecture is
preserved, this could be done inside nfq_handle_packet().

2. What is the point of the callback?  It seems to me that it would be
much simpler to have nfq_handle_packet() (or better yet, a function that
reads a packet) return a parsed packet to the caller and let it handle
it as it wishes.  The only good reason that I can see for having a
callback is to require that nfq_set_verdict() gets called at some point,
but the callback doesn't actually enforce this.  I don't see what
advantage this architecture has over a simpler socket-like API where
programs can open a connection, read a packet, analyze its contents, set
a verdict, and close the connection all from the same logical block.

If I'm misunderstanding how the libnetfilter_queue API works, please let
me know.

Thanks,
Rennie deGraaf


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

SHA-2 HMAC support in linux kernel

[Chinh Nguyen]

Hi,

I believe that this is the right list for my question. I'm trying to get 
SHA-2 HMAC support working ipsec in linux kernel (I'm configuring via 
pfkey).

First, sha-384 and sha-512 as authentication algorithm always return 
function not support. But I noted that my linux kernel has a sha512 
kernel module (with alias for sha384). Second, sha-256 uses a 12-byte 
hmac (96 bits).

Looking at the source http://lxr.linux.no/source/net/xfrm/xfrm_algo.c, 
it seems to confirm that this is true. In fact, sha-384 and sha-512 are 
not supported at this time and sha-256 is truncated to 96-bit.

However, the following ietf draft, which I believe is very closed to 
ratification (it has already been assigned iana numbers), specifies 
sha-256 to use 128-bits as hmac (page 18): 
http://www.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-01.txt

sha-384 is 192 bits, and sha-512 is 256 bits.

1. Is adding sha-384 and sha-512 as simple as adding to the aalg_list 
structure? Can this be done for some subsequent kernel release in the 
future?
2. Can the sha-256 be changed to use 128 bits? Or in order to not break 
backward compatibility, another sha-256 hmac algorithm id be used for 
128 bits?

Thanks,

Chinh

Re: SHA-2 HMAC support in linux kernel

[YOSHIFUJI Hideaki / 吉藤英明]

In article <45FB0B61.8060809@certicom.com> (at Fri, 16 Mar 2007 16:25:53 -0500), Chinh Nguyen <cnguyen@certicom.com> says:

> I believe that this is the right list for my question. I'm trying to get 
> SHA-2 HMAC support working ipsec in linux kernel (I'm configuring via 
> pfkey).

I don't think so.
Use linux-crypto@vger.kernel.org instead.

--yoshfuji

Re: SHA-2 HMAC support in linux kernel

[Jan Engelhardt]

On Mar 17 2007 05:31, YOSHIFUJI Hideaki / 吉藤英明 wrote:
>In article <45FB0B61.8060809@certicom.com> (at Fri, 16 Mar 2007 16:25:53 -0500), Chinh Nguyen <cnguyen@certicom.com> says:
>
>> I believe that this is the right list for my question. I'm trying to get 
>> SHA-2 HMAC support working ipsec in linux kernel (I'm configuring via 
>> pfkey).
>
>I don't think so.
>Use linux-crypto@vger.kernel.org instead.

(And don't hijack threads.)


Jan
-- 

Re: SHA-2 HMAC support in linux kernel

[Chinh Nguyen]

My apologies to both.

Chinh
--
http://www.certicom.com

Jan Engelhardt wrote:
> On Mar 17 2007 05:31, YOSHIFUJI Hideaki / 吉藤英明 wrote:
>> In article <45FB0B61.8060809@certicom.com> (at Fri, 16 Mar 2007 16:25:53 -0500), Chinh Nguyen <cnguyen@certicom.com> says:
>>
>>> I believe that this is the right list for my question. I'm trying to get 
>>> SHA-2 HMAC support working ipsec in linux kernel (I'm configuring via 
>>> pfkey).
>> I don't think so.
>> Use linux-crypto@vger.kernel.org instead.
> 
> (And don't hijack threads.)
> 
> 
> Jan

using libnetfilter_queue

[Abhijit Menon-Sen]

(I posted to the lartc mailing list, and received no responses, so I'm
posting here too.)

Hi.

Has anyone written or used, or does anyone know of, applications that
use libnetfilter_queue to mangle packets in userspace before letting
them proceed on their way?

I'm wondering if it's possible to write a not-quite-transparent proxy
that way, and looking for documentation, examples, and inspiration.

Thanks.

-- ams

Re: using libnetfilter_queue

[Eric Leblond]

Hi,

Le samedi 17 novembre 2007 à 02:32 +0530, Abhijit Menon-Sen a écrit :

> Has anyone written or used, or does anyone know of, applications that
> use libnetfilter_queue to mangle packets in userspace before letting
> them proceed on their way?

Look at snort-inline code:
http://snort-inline.sourceforge.net/

It is able to modify packets in a flow.

BR,
-- 
Eric Leblond <eleblond@inl.fr>
INL

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