IPsec PFP support on linux

3 messages, 2 authors, 2017-05-02 · open the first message on its own page

IPsec PFP support on linux

From: Sowmini Varadhan <hidden>
Date: 2017-05-02 12:32:38

I have a question about linux support for IPsec PFP (as defined in
rfc 4301). I am assuming this exists, and is accessible from uspace,
in which case I need some hints on how to set it up.

Assuming I have a server listening at port 5001 that I want to
secure via ipsec. Suppose I want to make sure that each TCP/UDP 5-tuple
sending packets to port 5001 gets its own SA.

RFC4301 has this:

       - SPD-S: For traffic that is to be protected using IPsec, the
         entry consists of the values of the selectors that apply to the
         traffic to be protected via AH or ESP, controls on how to
         create SAs based on these selectors, ...

and further down
      If IPsec processing is specified for
      an entry, a "populate from packet" (PFP) flag may be asserted for
      one or more of the selectors in the SPD entry (Local IP address;
      Remote IP address; Next Layer Protocol; and, depending on Next
      Layer Protocol, Local port and Remote port, or ICMP type/code, or
      Mobility Header type).  If asserted for a given selector X, the
      flag indicates that the SA to be created should take its value for
      X from the value in the packet.  Otherwise, the SA should take its
      value(s) for X from the value(s) in the SPD entry.

A google search produces a discarded patch
  http://marc.info/?l=linux-netdev&m=119746758904140
but its not clear to me how to set this up (if PFP works fine,
as suggested by Herbert's response above)

I tried experimenting with IP_XFRM_POLICY from a simple udp client but
(a) that seems to require a SPI and reqid to set up the SPD 
(b) I see the SADB_ACQUIRE upcall being triggered after the local port
    is bound (and SADB entry is set up for the lport).  But ike phase2
    does not converge for the lport specific sadb added
    by the bind (even in quick mode)

My understanding is that pluto shoud be generating spi's to make sure
they are sufficiently unique/random etc. so (a) makes me think I'm
either not setting this up or not using this correctly.

Any hints/sample code/RTFMs would be helpful (documentation for
IP_XFRM_POLICY seems scant, afaict). I'd be happy to share my 
udp client program, if it can provide more context to my question.

--Sowmini

Re: IPsec PFP support on linux

From: Paul Wouters <hidden>
Date: 2017-05-02 13:58:28

I think you want to use Opportunistic IPsec, eg see 

https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec

Note that IKEv2 also allows you to define one connection and instantiate  a connection based on the trigger packet whose src/dst proto/port are included in the IKEv2 packet as traffic selectors. See RFC7296 and "narrowing".

Paul


Sent from my iPhone
On May 2, 2017, at 08:32, Sowmini Varadhan [off-list ref] wrote:

I have a question about linux support for IPsec PFP (as defined in
rfc 4301). I am assuming this exists, and is accessible from uspace,
in which case I need some hints on how to set it up.

Assuming I have a server listening at port 5001 that I want to
secure via ipsec. Suppose I want to make sure that each TCP/UDP 5-tuple
sending packets to port 5001 gets its own SA.

RFC4301 has this:

      - SPD-S: For traffic that is to be protected using IPsec, the
        entry consists of the values of the selectors that apply to the
        traffic to be protected via AH or ESP, controls on how to
        create SAs based on these selectors, ...

and further down
     If IPsec processing is specified for
     an entry, a "populate from packet" (PFP) flag may be asserted for
     one or more of the selectors in the SPD entry (Local IP address;
     Remote IP address; Next Layer Protocol; and, depending on Next
     Layer Protocol, Local port and Remote port, or ICMP type/code, or
     Mobility Header type).  If asserted for a given selector X, the
     flag indicates that the SA to be created should take its value for
     X from the value in the packet.  Otherwise, the SA should take its
     value(s) for X from the value(s) in the SPD entry.

A google search produces a discarded patch
 http://marc.info/?l=linux-netdev&m=119746758904140
but its not clear to me how to set this up (if PFP works fine,
as suggested by Herbert's response above)

I tried experimenting with IP_XFRM_POLICY from a simple udp client but
(a) that seems to require a SPI and reqid to set up the SPD 
(b) I see the SADB_ACQUIRE upcall being triggered after the local port
   is bound (and SADB entry is set up for the lport).  But ike phase2
   does not converge for the lport specific sadb added
   by the bind (even in quick mode)

My understanding is that pluto shoud be generating spi's to make sure
they are sufficiently unique/random etc. so (a) makes me think I'm
either not setting this up or not using this correctly.

Any hints/sample code/RTFMs would be helpful (documentation for
IP_XFRM_POLICY seems scant, afaict). I'd be happy to share my 
udp client program, if it can provide more context to my question.

--Sowmini

_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: IPsec PFP support on linux

From: Sowmini Varadhan <hidden>
Date: 2017-05-02 14:05:26

On (05/02/17 09:58), Paul Wouters wrote:
   I think you want to use Opportunistic IPsec, eg see 
   https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec
I dont think that what I want is opportunistic ipsec..

taking an extreme example, I can set up the ipsec tunnels with 
esp-null for *.5001 and 5001.* (and that's how I'm able to
trigger quick mode in my experiment).

But I want each 5-tuple to/from 5001 to get its own SPI. That
is not happening in my case. 

If I used OE, I would *never* get a per-5-tuple SPI, right?
(I can give this a try later today but the rfc definition of OE is
not what I have in mind- I really want PFP, not OE).
   Note that IKEv2 also allows you to define one connection and instantiate
    a connection based on the trigger packet whose src/dst proto/port are
   included in the IKEv2 packet as traffic selectors. See RFC7296 and
   "narrowing".
yes, the rfc's permit this, I'm not sure how to set up my 
SPD for this though.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help