[redhat-lspp] RE: Inbound XFRM state during forwarding

[Venkat Yekkirala]

> On Fri, 20 Oct 2006, Paul Moore wrote:
>
> > I just spent the past couple of hours looking at the kernel
> trying to
> trace an
> > IPsec packet's path through the stack from when it first enters to
> when it
> > leaves through the forwarding path.  From what I can tell it appears
> that the
> > XFRM state is kept in the sk_buff->sp field for inbound
> transforms and
> in the
> > sk_buff->dst->xfrm field for outbound transforms.  Unless I missed
> something
> > somewhere (very possibile, I was looking at a *lot* of code this
> morning) it
> > seems like we should be able to retrieve the context from
> the inbound
> SAs
> > without problem,

Assuming someone doesn't come in and from an engineering standpoint optimize
the xfrm code to where the sp is released right after policy_check.

> eliminating the need to overload/split/etc. the
> > sk_buff->secmark field.

This isn't the only thing that was causing us to split the secmark. There's
the localhost traffic that used secmark as well.

> >
> > If I'm wrong about the XFRM state could someone please correct me?
>
> I believe this is correct.

But I wonder if we can say it will hold true into the future (see my
comment above); unless James/someone is going to watchout for us.

But all in all, I see there was a good discussion on splitting secmark
the past few days. Now what we need are the following:

The allow rule set that the user would be looking at for forwarding
controls.

Are we going to have them say:

allow http_packet_t http_server_packet_t:packet { send };

where http_packet_t would be the "secmark" on the packet during inbound
and http_server_packet_t might be the "secmark" on the packet during
outbound.

What I am asking is for a realistic example rule set that doesn't look
awkward for forwarded traffic.