Re: [Ipsec] Issue on input process of Linux native IPsec

Re: [Ipsec] Issue on input process of Linux native IPsec

[Park Lee]

On Wed, 22 Dec 2004 at 17:17, Kausty wrote:
>
> On Tue, 21 Dec 2004 10:52:22 -0800 (PST), Park Lee
> <parklee_sel@yahoo.com> wrote:
> > Hi,
> > We know that the output process of Linux native
> > IPsec fully uses the XFRM architecture. The order 
> > of primal functions are xfrm_lookup(),
> > xfrm_tmpl_resolve(), xfrm_bundle_create() and
> > dst_output().
> > The input process for IPsec is more simple than
> > output. The order of primal functions (in IPv4) 
> > are xfrm4_rcv(), xfrm4_rcv_encap(),
> > xfrm4_parse_spi(), xfrm4_policy_check().
> >  But, Why should the input process also go 
> > throught xfrm_lookup(), xfrm_tmpl_resolve(),
> > xfrm_bundle_create()? What's the purpose of this?
>
> i havent gone through the code flow as u mentioned 
> but this is my general idea.
>
> these are generic lookup functions irrespective of 
> ipv6/v4.
> the purpose is to ensure that all the SA's are 
> applied hence a bundle needs to be created 
> everytime a packet is recieved.
> If no bundle is created then a seperate search 
> needs to be done for ESP/AH/Transport/Tunnel
>
> is this what u were looking for ??

Thanks.
But, After a packet was received, It has already been
processed by xfrm4_rcv(), xfrm4_rcv_encap(),
ah_input(), esp_input(),etc. so, I think that there is
no need to search(or created) a bundle everytime a
packet is recieved, since it has already been
processed. Am I right?


=====
Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

Re: [Ipsec] Issue on input process of Linux native IPsec

[David Dillow]

On Wed, 2004-12-22 at 22:29 -0800, Park Lee wrote:
> Thanks.
> But, After a packet was received, It has already been
> processed by xfrm4_rcv(), xfrm4_rcv_encap(),
> ah_input(), esp_input(),etc. so, I think that there is
> no need to search(or created) a bundle everytime a
> packet is recieved, since it has already been
> processed. Am I right?

Are you sure you're not seeing the creation of a reply packet? Unless
you're testing with UDP and a listening socket on the receiver, you're
going to get a response packet if the incoming packet makes it through
the iptables rules. You were testing with ICMP echo requests (ping), if
I recall.

I think either you're basing your idea of the packet flow on printk()'s,
or I'm just too tired and missing where xfrm_lookup() gets called on the
rx path... (yes, sk can be NULL there, but I was wrong about it being
called for Rx'd packets, I think).

However, if your NIC driver does NAPI, you can see an xfrm_lookup() on
the reply packet when the driver calls netif_receive_skb() -- this bit
me recently...
-- 
David Dillow <dave@thedillows.org>

Re: [Ipsec] Issue on input process of Linux native IPsec

[Park Lee]

On Fri, 24 Dec 2004 at 01:23, David Dillow wrote:
> On Wed, 2004-12-22 at 22:29 -0800, Park Lee wrote:
> > Thanks.
> > But, After a packet was received, It has already 
> > been processed by xfrm4_rcv(), xfrm4_rcv_encap(),
> > ah_input(), esp_input(),etc. so, I think that 
> > there is no need to search(or created) a bundle 
> > everytime a packet is recieved, since it has 
> > already been processed. Am I right?
>
> Are you sure you're not seeing the creation of a 
> reply packet? Unless you're testing with UDP and a 
> listening socket on the receiver, you're going to 
> get a response packet if the incoming packet makes 
> it through the iptables rules. You were testing 
> with ICMP echo requests (ping), if I recall.
>
> I think either you're basing your idea of the 
> packet flow on printk()'s,or I'm just too tired and 
> missing where xfrm_lookup() gets called on the
> rx path... 

Yes, I'm testing with ping and basing my idea of the
packet flow on printk().

> (yes, sk can be NULL there, but I was wrong about 
> it being called for Rx'd packets, I think).

Does this mean that when the reply (response) packet
is sending out through xfrm_lookup(), the sk parameter
of xfrm_lookup() will not be NULL? and When the
incoming packet itself goes through xfrm_lookup(), the
sk parameter will be NULL?

Thank you 
and 
Merry Christmas.


=====
Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

Re: [Ipsec] Issue on input process of Linux native IPsec

[David Dillow]

[ Trimmed cc list to non-moderated lists.]

On Fri, 2004-12-24 at 11:23 -0800, Park Lee wrote:
> > I think either you're basing your idea of the 
> > packet flow on printk()'s,or I'm just too tired and 
> > missing where xfrm_lookup() gets called on the
> > rx path... 
> 
> Yes, I'm testing with ping and basing my idea of the
> packet flow on printk().

In the work I've been doing, I've found it very helpful to open a text
editor, and make a call graph for the task I'm interested in -- in your
case, a graph of every function that gets called upon receive, starting
with your network driver's receive function.

Doing a similar one for Tx would be useful for you as well, though I'd
start with the UDP output path, as it was pretty simple.

> > (yes, sk can be NULL there, but I was wrong about 
> > it being called for Rx'd packets, I think).
> 
> Does this mean that when the reply (response) packet
> is sending out through xfrm_lookup(), the sk parameter
> of xfrm_lookup() will not be NULL? and When the
> incoming packet itself goes through xfrm_lookup(), the
> sk parameter will be NULL?

xfrm_lookup() is only called for outgoing packets, not for received
packets.  I don't think ping replies (ICMP echo replies) will ever have
a non-NULL sk, as they are not associated with a socket.
-- 
David Dillow <dave@thedillows.org>

Re: [Ipsec] Issue on input process of Linux native IPsec

[Park Lee]

On Fri, 24 Dec 2004 at 16:15, David Dillow wrote:
> In the work I've been doing, I've found it very 
> helpful to open a text editor, and make a call 
> graph for the task I'm interested in -- in your
> case, a graph of every function that gets called 
> upon receive, starting with your network driver's 
> receive function.
>
> Doing a similar one for Tx would be useful for you 
> as well, though I'd start with the UDP output path, 
> as it was pretty simple.

I'll try it.
Thank you very much.


=====
Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com

Re: [Ipsec] Issue on input process of Linux native IPsec

[Park Lee]

On Fri, 24 Dec 2004 at 16:15, David Dillow wrote:
> xfrm_lookup() is only called for outgoing packets, 
> not for received packets.  I don't think ping 
> replies (ICMP echo replies) will ever have a non-
> NULL sk, as they are not associated with a socket.

But, as we know, The Linux network component creates
two special purpose sockets for use by the AF_INET
protocol family. The tcp socket is used to send resets
when a TCP packet is rejected, since there may be no
local socket corresponding to the packet. The icmp
socket is used to send ICMP messages.

Then, Why did you say that ping replies (ICMP echo
replies) were not associated with a socket? 
Is there any difference between the special purpose
socket and the socket you mentioned above?

Thank you.

Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Ipsec] Issue on input process of Linux native IPsec

[Dave Dillow]

On Thu, 2005-03-10 at 02:37 -0800, Park Lee wrote:
> On Fri, 24 Dec 2004 at 16:15, David Dillow wrote:
> > xfrm_lookup() is only called for outgoing packets, 
> > not for received packets.  I don't think ping 
> > replies (ICMP echo replies) will ever have a non-
> > NULL sk, as they are not associated with a socket.

> Then, Why did you say that ping replies (ICMP echo
> replies) were not associated with a socket? 

Because your crashes where caused by blindly assuming the sk would never
be NULL in xfrm_lookup(), and it clearly was. The simple debugging
printk() I suggested you insert with your code would have shown you that
that was the reason for your crashes.

And if I was feeling nice that day, which is possible, since it was
Christmas Eve, I may have even put the printk() in myself and tested.

> Is there any difference between the special purpose
> socket and the socket you mentioned above?

I have no idea. You have the code, and probably as much understanding of
the networking stack as I do. I suggest you use find and grep to track
down the what you are interested in, and how xfrm_lookup() is called in
various situations. Take good notes, especially about avenues of
exploration that come time mind as you chase one code path. It's not
very hard, it's how I learned.
-- 
Dave Dillow <dave@thedillows.org>