[RFC][IPSEC]: tunnel mode processing

[RFC][IPSEC]: tunnel mode processing

[jamal]

At the moment transport mode processing is not dependent on skb->dst
being passed. Tunnel mode derives the ip->id and ttl from it. More like
computes ip->id.

I am trying to generate traffic via pktgen and it would be nice if i
could get the same behavior on tunnel mode as in transport mode. I dont
think it matters what the values of those two fields are.

Would it be reasonable to do a check so that incase a skb->dst doesnt
exist, the inner headers values can be used i.e something along 
xfrm4_tunnel_output()::

----
        top_iph->frag_off = (flags & XFRM_STATE_NOPMTUDISC) ?
                0 : (iph->frag_off & htons(IP_DF));
	if (dst) {
		if (!top_iph->frag_off) 
			__ip_select_ident(top_iph, dst->child, 0);
		top_iph->ttl = dst_metric(dst->child, RTAX_HOPLIMIT);
	} else {
		top_iph->id = iph->id;
		top_iph->ttl = iph->ttl;
	}
----

cheers,
jamal

Re: [RFC][IPSEC]: tunnel mode processing

[Herbert Xu]

On Thu, Aug 31, 2006 at 08:55:27PM -0400, jamal wrote:
> 
> Would it be reasonable to do a check so that incase a skb->dst doesnt
> exist, the inner headers values can be used i.e something along 
> xfrm4_tunnel_output()::

If you didn't care what values they were, couldn't you just stuff some
bogus dst into the skb? If this packet is going somewhere you're going
to have a dst one way or another :)

Also, the IPID is only generated if DF is not set on the packet.
Otherwise this path is already as fast as it can be.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC][IPSEC]: tunnel mode processing

[jamal]

On Fri, 2006-01-09 at 14:07 +1000, Herbert Xu wrote:
> On Thu, Aug 31, 2006 at 08:55:27PM -0400, jamal wrote:
> > 
> > Would it be reasonable to do a check so that incase a skb->dst doesnt
> > exist, the inner headers values can be used i.e something along 
> > xfrm4_tunnel_output()::
> 
> If you didn't care what values they were, couldn't you just stuff some
> bogus dst into the skb? 

That bogus dst is NULL ;->

> If this packet is going somewhere you're going
> to have a dst one way or another :)

If i was going to use routing/layer 3, then true. At the pktgen level
"somewhere" is just "shove down the ether". Actually (i havent thought
clearly about this) wouldnt a bump in the wire implementation aka
bridging level also not care about route details? 
Note: This does not absolve the need for a secure ipid or a proper ttl.

> Also, the IPID is only generated if DF is not set on the packet.
> Otherwise this path is already as fast as it can be.

In the case of traffic generation, if i could shave even more cycles the
better since i want to generate high speed. In this case the cycles
would be in creating a fake dst and attaching it some fake values.

I do agree that it is an awkward way of achieving my goals - but i dont
know of a clever way to do it ;->

cheers,
jamal

Re: [RFC][IPSEC]: tunnel mode processing

[Herbert Xu]

On Fri, Sep 01, 2006 at 08:17:14AM -0400, jamal wrote:
> 
> In the case of traffic generation, if i could shave even more cycles the
> better since i want to generate high speed. In this case the cycles
> would be in creating a fake dst and attaching it some fake values.

Right, you're testing the receiver side.  In that case I suggest that
you replicate the IPsec transport mode logic in the generator.  Just
as pktgen doesn't use net/ipv4/udp.c to generate UDP traffic, it doesn't
really need to use xfrm4_output.c to generate IPsec traffic.

You can still call down to esp4.c through the type pointer of course.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC][IPSEC]: tunnel mode processing

[jamal]

On Fri, 2006-01-09 at 22:22 +1000, Herbert Xu wrote:

> Right, you're testing the receiver side.  

both in/out sides (on the receiver); i just count and drop all packets
coming back to the sender (the pktgenerator)

> In that case I suggest that
> you replicate the IPsec transport mode logic in the generator.  

Tunnel mode you mean, i think.

> Just
> as pktgen doesn't use net/ipv4/udp.c to generate UDP traffic, it doesn't
> really need to use xfrm4_output.c to generate IPsec traffic.
> 

IPsec is slightly different since i need to use state in the core. i.e
it is stateful. Nothing that pktgen does today has such requirements.

> You can still call down to esp4.c through the type pointer of course.

Thats one idea i havent thought of. 

i.e the code would look like:
-----
        if (mode == tunnel) 
		err = mytunneloutput (x, skb);
	else 
        	err = x->mode->output(x, skb);
        if (err)
                goto error;
        err = x->type->output(x, skb);
--

This is what you are suggesting?
I am probably better off going back to creating a dummy dst with just
those two fields when in  tunnel mode;->

cheers,
jamal

Re: [RFC][IPSEC]: tunnel mode processing

[Herbert Xu]

On Fri, Sep 01, 2006 at 08:56:18AM -0400, jamal wrote:
> 
> Thats one idea i havent thought of. 
> 
> i.e the code would look like:
> -----
>         if (mode == tunnel) 
> 		err = mytunneloutput (x, skb);
> 	else 
>         	err = x->mode->output(x, skb);
>         if (err)
>                 goto error;
>         err = x->type->output(x, skb);
> --
> 
> This is what you are suggesting?

Yes, I suppose you could even replace x->mode directly.

> I am probably better off going back to creating a dummy dst with just
> those two fields when in  tunnel mode;->

Probably.  Although if you write your own output function you could
make it go faster by adapting it to the specifics of pktgen.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC][IPSEC]: tunnel mode processing

[jamal]

On Fri, 2006-01-09 at 23:04 +1000, Herbert Xu wrote:

> Yes, I suppose you could even replace x->mode directly.
>
> > I am probably better off going back to creating a dummy dst with just
> > those two fields when in  tunnel mode;->
> 
> Probably.  Although if you write your own output function you could
> make it go faster by adapting it to the specifics of pktgen.

gah. Ok, probably better solution to go this path then ;->

cheers,
jamal