[redhat-lspp] Labeled IPsec localhost problems

[Paul Moore]

On Wednesday, January 31 2007 4:33 pm, Joy Latten wrote:
> On Tue, 2007-01-30 at 23:14 -0500, Paul Moore wrote:
> > > By the way, I ran one last night with labeled ipsec over ipv6 with
> > > your patch and happy to report the stress test completed a 15 hour
> > > run successfully. So at least no regression on that front.
> >
> > Great, thank you for testing this.  Out of curiosity, how many times
> > during the test did the phase-2 SAs get re-keyed, i.e. what was the SA
> > lifetime?
>
> ISAKMP SA lifetime is 30 minutes and IPSEC SA is 15 minutes. And test
> ran for 15 hours sending streams of udp and tcp packets. I also had
> both esp and ah configured to be used.

Good to know thanks.  I wanted to make sure we were hitting the IKE 
negotiation code and it looks like we hit it quite a few times.

> > That is exactly the problem I am concerned about too ... using the
> > standard IPsec selectors of src,dst,proto,port I'm not sure there is a
> > way to differentiate connections between two localhost addresses in all
> > cases; for example, what happens if you want to label ICMP traffic across
> > localhost?
>
> Ok, I am going to talk myself through this, I apologize ahead of time
> if it is too much info and I will skip over stuff since xfrm process is
> kind of a lot to me. :-)

It's a lot for anybody to wrap their head around :)

> This is not exclusive to loopback. What if I have a traffic stream
> 10.1.1.1->10.1.2.3 and I have specified a separate ipsec policy for each
> upper layer protocol, udp, tcp, and icmp. This gives me 3 pairs of
> policy entries (6 entries altogether) with exact same info except for
> the upper-layer protocol. Well, in regular ipsec, this will result in a
> single pair of SAs, that will be used for icmp, udp, and tcp traffic.
> This single pair of SAs will be associated with all 3 pairs of policy.

Actually, if you configure the SPD such that you have a separate policy for 
UDP, TCP, and ICMP between two hosts then you will get three SA pairs, one 
pair for each protocol.  The protocol type is part of the IPsec selector (see 
RFC 2401).

> Now with labeled ipsec, the only difference is the security context.
> The security context is the "selector" that differentiates xfrms.
> So, instead of a single pair of xfrms, we could possibly have many.
> And the code takes care of this. To find correct xfrm, we do a
> xfrm_selector_match() and if successful, then do a
> security_xfrm_state_pol_flow_match(), which checks to see if (flow->sid
> == xfrm->id) then avc_has_perm(check for association:sendto) permission.
> This ensures we get correct xfrm for the flow. Otherwise return error
> and continue to step thru xfrm list until you find another one whose
> selector matches and try again. If there is none and we have a policy,
> then call racoon.

This gets to my original question about if the SELinux context was fully 
integrated into the IPsec selectors, it looks like it has - that is good.  
Have you verified this behavior over loopback?  One of us should ...

> Now with loopback the concern is we will have two exact SAs per
> security context. I am thinking that if they are exact, what does
> it matter which one gets used. We just want to make sure we use SA
> that has the correct security context and this will get done
> via security_xfrm_state_pol_flow_match() per what I said in above
> paragraph.

If two SAs have the exact same selectors, including SELinux context, then it 
probably shouldn't matter which one gets used.  I'm still slightly concerned 
about the AH/ESP sequence number but it's been so long since I have played 
with IPsec issues like this that I only have vague reasons why this would be 
a concern.

> Venkat or anyone, please correct me if I am off on this 
> or missing something. Regardless of which SA of the pair
> gets used, the SPI will ensure we pull up corresponding SA for inbound.

I believe you are correct, the SPI should solve the bulk of the problems for 
the inbound case.  However, like I said earlier, it's the outbound case that 
I am more concerned with as it is relies more heavily on the IPsec selectors 
to ensure the correct SA is used.

That said, it would be nice if Venkat could weigh in on this issue.

> Now because of the policy->bundle feature, I think one of the SAs
> of the pair will always end up being used for outbound and the other
> for inbound processing. Again, unless I am missing something, I
> think it won't matter which of the 2 gets associated with inbound or
> outbound policy->bundle since they are exact.

Well, I think the typical case is for each SA in a bundle would have a 
different context.  Using the client->server model I would expect one SA to 
have a "client_t" context while the other would have a "server_t" context.

> Switching back to regular labeled ipsec, I have noticed in a
> client->server model, "ssh" for example, 4 pairs of
> SAs get created per security context. A pair for server and a pair for
> client. I have noticed, when sending, the client security context is
> used. Upon receiving, the server needs to have recvfrom permission to
> use client SA. Correct SA will always get pulled up because of spi.
>
> Switching to loopback, this should work ok too. (i tried it and it did)

Okay, good.  Sorry to belabor the point, but did you verify the SPI from 
packets sent by the server?  For example, were the server's ACKs using a 
different SPI than the client's packet?

> As for sequence numbers, their use is optional and we can
> specify/document that when using loopback, we recommend you do not use
> them since loopback has guaranteed delivery. Because yes, packets can
> get dropped when using sequence numbers and window size.

Good to know.

> And last but not least, I started a labeled ipsec over loopback stress
> test last night. So far it has been running for 15 hours.
> isakmp lifetime is 30 minutes
> ipsec sa lifetime is 15 minutes
> esp used over tcp and udp.
>
> I have noticed only one thing that I am concerned about.
> I have not yet figured out what it means. Although pfkey ADD fails, I
> believe the new SA has been entered because when I dump the databases, I
> notice the new spis in the SAs.The old ones are gone...
>
> My log file has the following. I think it occurs for each rekeying.
>
> Jan 31 15:12:46 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport
> 127.0.0.1[0]->127.0.0.1[0] spi=29906937(0x1c857f9)
> Jan 31 15:12:47 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport
> 127.0.0.1[0]->127.0.0.1[0] spi=200715915(0xbf6ae8b)
> Jan 31 15:12:47 tim-hv4 racoon: INFO: initiate new phase 2 negotiation:
> 127.0.0.1[0]<=>127.0.0.1[0]
> Jan 31 15:12:47 tim-hv4 racoon: INFO: respond new phase 2 negotiation:
> 127.0.0.1[0]<=>127.0.0.1[0]
> Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established:
> ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=211935989(0xca1e2f5)
> Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists
> Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established:
> ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=251963520(0xf04a880)
> Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists

I saw that too, like I said, the patch was simply a proof-of-concept showing 
what needed to be done to allow racoon to negotiate with itself; there is 
still work that needs to be done before it is ready for actual use.

-- 
paul moore
linux security @ hp