Hi,
Replies inline.
Regards,
Radu
On 6/21/2018 5:15 PM, berengerf via Lists.Fd.Io wrote:
Hello,
I have some questions regarding the integration of IKEv2 within VPP.
When an IKEv2 negotiation succeeds, an ipsecX interface is created.
Then in order to encrypt the outgoing traffic, the interface has to be
set up manually, an address needs to be assigned to this interface
(the address seems to be arbitrary) and finally the traffic must be
routed through the interface.
My questions are the following:
*- What is the address that needs to be set on ipsecX, does it relate
to anything? I tried many addresses, and I found out that the address
can be anything that does not conflict with existing networks.*
Here is an example of a working setup after a successful IKEv2
negotiation:
/set interface state ipsec0 up
/
/set interface ip address ipsec0 11.11.11.11/32
/
/ip route add 192.168.3.0/24 via 11.11.11.11 ipsec0/
In this example, I want to protect packets that have the network
192.168.3.0/24 as a destination. But it does not necessarily respect
the negotiated traffic selectors.
You don't have to assign an IP address to the ipsec0 interface, you just
need to route traffic through it. For consistency, the above config can
be written as:
/set interface state ipsec0 up
/
/ip route add 192.168.3.0/24 via <the remote IP of tunnel> ipsec0
but any IP that does not conflict with local settings should work
/
*- Is there a way to automate this process after a negotiation
(without executing command lines on the gateway) ? Given that a SA has
just been negotiated, a SPD entry could be created with this SA. Or if
the SPD entry already exists, it could be bound with the new SA.*
No, there is no existing way.
There is a way that involves extending the control plane by writing some
more code :) The issue is more complex that is seems, for example, when
the SA expiration is close there will be a new SA existing in parallel
with the old one, and control plane will have to switch traffic before
deleting the old one, while making sure that all inflight traffic using
the old SA is not dropped.
For example, if I set IPsec up manually I get the following output:
/DBGvpp# show ipsec
/
/sa 10 spi 1001 mode tunnel protocol esp
/
/ crypto alg aes-cbc-128 key 4a506a794f574265564551694d653768
integrity alg sha1-96 key 4339314b55523947594d6d3547666b45764e6a58
/
/ tunnel src 192.168.100.3 dst 192.168.100.2
/
/sa 20 spi 1000 mode tunnel protocol esp
/
/ crypto alg aes-cbc-128 key 4a506a794f574265564551694d653768
integrity alg sha1-96 key 4339314b55523947594d6d3547666b45764e6a58
/
/ tunnel src 192.168.100.3 dst 192.168.100.2
/
/spd 1
/
/outbound policies
/
/ priority 100 action bypass protocol IPSEC_ESP
/
/ local addr range 0.0.0.0 - 255.255.255.255 port range 0 - 65535
/
/ remte addr range 0.0.0.0 - 255.255.255.255 port range 0 - 65535
/
/ packets 0 bytes 0
/
/ priority 10 action protect protocol any sa 10
/
/ local addr range 192.168.100.3 - 192.168.100.3 port range 0 - 65535
/
/ remte addr range 192.168.100.2 - 192.168.100.2 port range 0 - 65535
/
/ packets 0 bytes 0
/
/ priority 100 action bypass protocol IPSEC_ESP
/
/ local addr range :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff port
range 0 - 65535
/
/ remote addr range :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
port range 0 - 65535
/
/ packets 0 bytes 0
/
/inbound policies
/
/ priority 10 action protect protocol any sa 20
/
/ local addr range 192.168.100.3 - 192.168.100.3 port range 0 - 65535
/
/ remte addr range 192.168.100.2 - 192.168.100.2 port range 0 - 65535
/
/ packets 0 bytes 0
/
/ priority 100 action bypass protocol IPSEC_ESP
/
/ local addr range 0.0.0.0 - 255.255.255.255 port range 0 - 65535
/
/ remte addr range 0.0.0.0 - 255.255.255.255 port range 0 - 65535
/
/ packets 0 bytes 0
/
/ priority 100 action bypass protocol IPSEC_ESP
/
/ local addr range :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff port
range 0 - 65535
/
/ remote addr range :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
port range 0 - 65535
/
/ packets 0 bytes 0
/
/tunnel interfaces/
And here is what I obtain when I use IKEv2 :
/DBGvpp# show ipsec//
/
/tunnel interfaces//
/
/ ipsec0 seq//
/
/ seq 0 seq-hi 0 esn 0 anti-replay 1//
/
/ local-spi 3429274994 local-ip 192.168.4.2//
/
/ local-crypto aes-cbc-192
c0a824dc1e0dcb393bce998d1f6fcec71c96dcd52d561a05//
/
/ local-integrity sha1-96 3fc636ce2b321d3291caf75ddc4c792fa46cd9ac//
/
/ last-seq 0 last-seq-hi 0 esn 0 anti-replay 1 window
0000000000000000000000000000000000000000000000000000000000000000//
/
/ remote-spi 3972674850 remote-ip 192.168.4.1//
/
/ remote-crypto aes-cbc-192
253eac1ea57b10dfb491d5483ea8ef2bc5139f6dedeb819c//
/
/ remote-integrity sha1-96 ddc3b2913d99f74375aca09a58b2781773ecbac1/
Here I expected to see a similar output for both methods.
You will get similar results if you use the create ipsec tunel command,
as described here:
https://docs.fd.io/vpp/18.07/clicmd_src_vnet_ipsec.html#clicmd_create_ipsec_tunnel
Best regards,
Berenger
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9672): https://lists.fd.io/g/vpp-dev/message/9672
Mute This Topic: https://lists.fd.io/mt/22502432/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
