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
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 <[email protected]> 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
> [email protected]
> https://lists.libreswan.org/mailman/listinfo/swan
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.