IPSec Inbound Processing Basic Doubt

IPSec Inbound Processing Basic Doubt

[k8 s]

Hello,

I have a basic doubt regarding ipsec inbound packet processing.
I have idea about the stackable destination.If I am not wrong it is like this.
 /* Output packet to network from transport.  */
static inline int dst_output(struct sk_buff *skb)
{
        int err;

        for (;;) {
                err = skb->dst->output(skb);

                if (likely(err == 0))
                        return err;
                if (unlikely(err != NET_XMIT_BYPASS))
                        return err;
        }
}

here skb->dst->oututput(skb)
               xfrm4_output(skb) 
                     {
                                x->type->output(skb)
                                skb->dst = dst_pop(skb);
                      }
                                            
And x->type->output(skb) calls ah_output | esp_output and the skb->dst
value is reset during dst_pop(skb)

All methods return non zero for the dst_output for loop to continue
except ip_queue_xmit   (I Think) which returns 0 and the for loop
exits. Error reporting by any member in the chain is through returning
XMIT_BYPASS or similar

I hope Its the way

My doubt regarding Inbound processing is
 dst_input()
{
    for(;;)
   {
        err = skb->dst->input()
   }
}
hope that it calls rxfrm4_rcv (ipv4)  calls
                                xfrm4_rcv_encap()
                                   {
                                        x->type->input()
                                        dst_release(skb->dst);

                                          //also there is a
netif_rx(skb) in the same method
                                    }
 and  x->type->input() calling ah_input | esp_input()

Now is it that 
a) inbound is similar to outbound stackable destination calls except
that the calls are in                                              
reverse direction
b)Does netif_rx call in xfrm4_rcv_encap mean one of the many xfrms of
ipsec gets processed first and the packet is fed back to the ipstack
through netif_rx() and the whole game starts again with ip_rcv
checking protocol finding 50 0r 51 and calling xfrm4_rcv

So is it a call chain 
or 
packet looping between ipsec and ip continuosly using  netif_rx and
ip_rcv and xfrm4_rcv




S Kartikeyan

Re: IPSec Inbound Processing Basic Doubt

[Michael Becker]

Hello,

ks> I have a basic doubt regarding ipsec inbound packet processing.
ks> I have idea about the stackable destination.If I am not wrong it is like this.
ks>  /* Output packet to network from transport.  */
ks> static inline int dst_output(struct sk_buff *skb)
ks> {
ks>         int err;

ks>         for (;;) {
ks>                 err = skb->dst->output(skb);

ks>                 if (likely(err == 0))
ks>                         return err;
ks>                 if (unlikely(err != NET_XMIT_BYPASS))
ks>                         return err;
ks>         }
ks> }

Most of the skb's travel from transport layer to IP layer via
ip_queue_xmit (ip_output.c).

Within this function ip_route_output_flow is the central entry point into
routing and xfrm (by means of xfrm_lookup, xfrm_find_bundle,
xfrm_bundle_create).

xfrm_bundle_create does create the destination stack. The last
dst_entry of the destination stack is the final routing entry, with
it's output function pointer (->output) set to ip_output
The other dst_entry's on top (up to nx transformations, see
the for-loop in __xfrm4_bundle_create) have set xfrm4_output, or
xfrm6_output, e.g.)

As ip_route_output_flow returns to ip_queue_xmit, the last function
call made is NF_HOOK (a macro actually), which sets dst_output as the
packets further processing function in case it traverses the hook
without being dropped.

So far you are right with your assumptions, I hope my explanation just
made it a bit clearer.

ks> All methods return non zero for the dst_output for loop to continue
ks> except ip_queue_xmit   (I Think) which returns 0 and the for loop
ks> exits. Error reporting by any member in the chain is through returning
ks> XMIT_BYPASS or similar

The return values are behave a little different.

xfrm4_output calls the appropriate transformation function (e.g. esp_output)
esp_output returns 0 on success, else an error occurred.

xfrm4_output itself returns NET_XMIT_BYPASS in case of no error.
If xfrm4_output would return 0, the for-loop in dst_ouput is left
immediately with a return statement, after the output function was
called.

So NET_XMIT_BYPASS keeps the destination stack running until
the final call to ip_output makes it return to ip_queue_xmit, which
returns with the result.


ks> I hope Its the way

You were very close to it :-)



ks> My doubt regarding Inbound processing is
ks>  dst_input()
ks> {
ks>     for(;;)
ks>    {
ks>         err = skb->dst->input()
ks>    }
ks> }
ks> hope that it calls rxfrm4_rcv (ipv4)  calls
ks>                                 xfrm4_rcv_encap()
ks>                                    {
ks>                                         x->type->input()
ks>                                         dst_release(skb->dst);

ks>                                           //also there is a
ks> netif_rx(skb) in the same method
ks>                                     }
ks>  and  x->type->input() calling ah_input | esp_input()

ks> Now is it that 
ks> a) inbound is similar to outbound stackable destination calls except
ks> that the calls are in                                              
ks> reverse direction

No it's not similiar. dst_input is not used for xfrm transformations.
Have a look at ip_local_deliver_finish. The packet enters as ESP or AH
and thus the protocol handler is xfrm4_rcv which is called via
ipprot->handler(skb)

xfrm4_rcv calls xfrm4_rcv_encap, which does all decapsulating
transformations in a do-while-loop, calling x->type-input.

When all transfromation processing is done the naked ip paket is put
back into the CPU specific packet queue by netif-rx.

ks> b)Does netif_rx call in xfrm4_rcv_encap mean one of the many xfrms of
ks> ipsec gets processed first and the packet is fed back to the ipstack
ks> through netif_rx() and the whole game starts again with ip_rcv
ks> checking protocol finding 50 0r 51 and calling xfrm4_rcv

The whole decapsulation is done in xfrm4_rcv_encap, except in case of
nat-traversal, where udp_rcv comes into play.
After the whole xfrm processing is done the packet is put back into the
network stack as it would look like without being ever processed by IPSec
(almost :-).

Best regards
  Michael Becker

Re: IPSec Inbound Processing Basic Doubt

[k8 s]

Hello,

> So far you are right with your assumptions, I hope my explanation just
> made it a bit clearer.

Yes. It was really nice organization of whole thing.


>The whole decapsulation is done in xfrm4_rcv_encap, except in case of
>nat-traversal, where udp_rcv comes into play.
>After the whole xfrm processing is done the packet is put back into the
>network stack as it would look like without being ever processed by IPSec
>(almost :-).

I have a doubt regarding nat-traversal. Let me first admit that I
don't have a perfect understanding of the NAT traversal concept. I
heard that IPSec is kept in a UDP packet and sent.  How does the tx
side processing happen (the host from which the udp encapsulated ipsec
packet originated). The last call in the stackable destination is
ip_output() as you said.
How does it go back to udp(transport) layer in this case.

S.Kartikeyan
http://www.geocities.com/kartikeyans/

Re: IPSec Inbound Processing Basic Doubt

[k8 s]

Also can you please tell me what is dst_input() forloop meant for .
Infact the code seems to match for dst_output() in terms of the 
NET_XMIT_BYPASS usage.
Infact I saw that ip_rcv_finish() calls this dst_input() what purpose
does it serve.



 S.Kartikeyan
 http://www.geocities.com/kartikeyans/

Re[2]: IPSec Inbound Processing Basic Doubt

[Michael Becker]

Hello,

ks> Also can you please tell me what is dst_input() forloop meant for .
ks> Infact the code seems to match for dst_output() in terms of the 
ks> NET_XMIT_BYPASS usage.
ks> Infact I saw that ip_rcv_finish() calls this dst_input() what purpose
ks> does it serve.

I assume most of the time or maybe always the for-loop reduces to a single
function call, either ip_forward or ip_local_deliver.
(see ip_route_input_slow, watch out for rth->u.dst.input = ...)

Maybe someone else can explain, if there are scenarios where more that
one dst input function comes into play or whether it was just done to
keep it analog to dst_output ...?

Best regards
     Michael Becker

Hochschule Niederrhein - Krefeld, Germany

Re[2]: IPSec Inbound Processing Basic Doubt

[Michael Becker]

Hello,

ks> heard that IPSec is kept in a UDP packet and sent.  How does the tx
ks> side processing happen (the host from which the udp encapsulated ipsec
ks> packet originated). The last call in the stackable destination is
ks> ip_output() as you said.
ks> How does it go back to udp(transport) layer in this case.

It doesn't go back.

UDP encapsulation is done for ...

INPUT:
 - udp_rcv
     |
     --- udp_queue_rcv_skb
           |
           --- udp_encap_rcv (strips of udp)
           |
           --- xfrm4_rcv_encap (usual procedure)


OUTPUT:
  - Done in esp_output as part of a stacked destination
    (e.g. net/ipv4/esp4.c)
    NAT-Traversal does only make sense for ESP, as AH protocol
    authenticates ("hashes") whole IP header including
    IP src / dst address, so you can't manipulate afterwards
    like SNAT / DNAT would do.

    exerpt from  net/ipv4/esp4.c

  /* this is non-NULL only with UDP Encapsulation */
71         if (x->encap) {
72                 struct xfrm_encap_tmpl *encap = x->encap;
..                 ...
81
82                 switch (encap->encap_type) {
83                 default:
84                 case UDP_ENCAP_ESPINUDP:
..                         ....
87                 case UDP_ENCAP_ESPINUDP_NON_IKE:
..                         ....
91                         break;
92                 }
93 
94                 top_iph->protocol = IPPROTO_UDP;
95         } else
96                 top_iph->protocol = IPPROTO_ESP;


As you see input and output processing isn't symetric any way,
with or without UDP encapsulation (NAT-T)

Have a look at http://lxr.linux.no which helps a lot sorting out
different pathes in the code. It's a complete cross reference of
the latest and some previous kernels

Best regards
     Michael Becker

Hochschule Niederrhein - Krefeld, Germany