Comments inline Regards, Matus
> -----Original Message----- > From: Neale Ranns (nranns) > Sent: Wednesday, October 12, 2016 9:33 AM > To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) > <matfa...@cisco.com>; Zdenko Olsovsky -X (zolsovsk - PANTHEON > TECHNOLOGIES at Cisco) <zolso...@cisco.com>; vpp-dev@lists.fd.io > Cc: csit-...@lists.fd.io > Subject: Re: [csit-dev] [vpp-dev] Cannot add route to ipsec0 interface > > > Hi Matus, > > On 12/10/16 06:46, Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at > Cisco) > wrote: > > Hi Neale, > > > > IPSec interface is tunnel interface created by IKEv2 code when child > > SA is successfully established. > > is it similar to the ipsec-gre interface we were discussing earlier? i.e. it > is > functionally equivalent to an IP-over-IP tunnel with IPSEC as an input/output > feature? > IPSec tunnel interface is associated with SA, it is similar to ipsec-gre interface. Functionality is equivalent to IPSec as in/out feature it encapsulate/decapsulate packet to ESP. But it doesn't use standard tx_function in VNET_DEVICE_CLASS, it has ipsec-if-output node and for input ESP protocol is registered with ipsec-if-input node. Node path: ipsec-if-input->esp-decrypt and ipsec-if-output->esp-encrypt. > > You can't set IP on it because there is missing > > "ip4_sw_interface_enable_disable" when interface is created, I will fix it. > > As you have correctly identified that is the API that will enable/disable IP > on an > interface and therefore accept/reject IP packets. This scheme is implemented > by > adding the drop node as the default IP input feature on all interfaces. When > the > interface is IP enabled then the lookup feature is inserted in the front of > the drop > and hence we accept and process the RX'd packets. > Since we have not called ip4_sw_interface_enable_disable on the ipsec0 > interface it has the drop as it only input feature; > sh ip int features ipsec0 vpp# sh ip int features ipsec0 IP feature paths configured on ipsec0... ip4 feature paths configured on ipsec0... ip4 rx-unicast: ip4-drop ip4 rx-multicast: ip4-drop ip4 tx: interface-output ip6 feature paths configured on ipsec0... ip6 rx-unicast: ip6-drop ip6 rx-multicast: ip6-drop ip6 tx: interface-output > and should therefore be dropping RX traffic. Calling the API will allow it to > accept traffic, which it is already doing. > The question is how and why are we bypassing these input features? Without > running the input features how can we, for example, apply an ACL to the > decrypted traffic? > > I expect that you can still do; > set int ip addr ipsec0 10.0.0.1/30 > that is agnostic w.r.t. the interface type. This lead to segmentation fault currently. > > regards, > neale > > > > Regards, Matus > > > >> -----Original Message----- From: csit-dev-boun...@lists.fd.io > >> [mailto:csit-dev-boun...@lists.fd.io] On Behalf Of Neale Ranns > >> (nranns) > >> Sent: Tuesday, October 11, 2016 4:14 PM To: Zdenko Olsovsky -X > >> (zolsovsk - PANTHEON TECHNOLOGIES at Cisco) <zolso...@cisco.com>; > >> vpp-dev@lists.fd.io > >> Cc: csit-...@lists.fd.io Subject: Re: [csit-dev] [vpp-dev] Cannot add > >> route to ipsec0 interface > >> > >> > >> Hi Zdenko, > >> > >> I'm surprised traffic was received on the interface given it does not > >> have an IP address. A couple of questions: - what is an IPSEC > >> interface? - how and why did we bypass the IP input features on that > interface? > >> > >> some answers inline... > >> > >> On 11/10/16 13:53, Zdenko Olsovsky -X (zolsovsk - PANTHEON > >> TECHNOLOGIES at > >> Cisco) wrote: > >>> Hi everyone, > >>> > >>> > >>> > >>> I made some tests for IKEv2 functionality which were working about a > >>> month > >> ago. > >>> Unfortunately, today I realized that these are no longer working. > >>> > >>> > >>> > >>> Running this command : exec ip route add 10.0.10.1/24 via ipsec0 -- > >>> worked fine before > >>> > >>> Will result in error: 'via ipsec0' parse error. > >>> > >>> > >>> I suppose there should be some IP in front of the interface name, > >> > >> yes there should. On multi-access interfaces (like Ethernet) one must > >> send the packet TO a peer on the link, not just put a packet on the > >> wire. The only reason that would otherwise work is proxy-arp on the > >> peer, but the less said about that the better. for point-2-point > >> interfaces it is possible to just emit the packet on the wire without > >> identifying the peer (since there can be only one). I'll relax the > >> condition in the CLI to accept only an interface if it's point-2-point. > >> > >>> but I cannot directly set an ip to ipsec0 interface. > >> > >> this should work; set int ip addr ipsec0 10.0.0.1/30 > >> > >> then ip route add 10.0.10.1/24 via 10.0.0.2 ipsec0 > >> > >> regards, neale > >> > >> > >>> > >>> > >>> I can see from the packet that it arrived into ipsec interface and > >>> was decrypted and sent to loopback, but from that point it doesn't > >>> know how to forward it back and weird error is in the end of the packet > trace. > >>> > >>> > >>> > >>> Packet 3 > >>> > >>> > >>> > >>> 00:00:15:004763: dpdk-input > >>> > >>> GigabitEthernet0/a/0 rx queue 0 > >>> > >>> buffer 0x4db5: current data 0, length 102, free-list 0, totlen-nifb > >>> 0, trace 0x2 > >>> > >>> PKT MBUF: port 1, nb_segs 1, pkt_len 102 > >>> > >>> buf_len 2176, data_len 102, ol_flags 0x0, data_off 128, phys_addr > >>> 0x4e132c40 > >>> > >>> packet_type 0x0 > >>> > >>> IP4: 08:00:27:7e:6e:2e -> 08:00:27:9b:f1:65 > >>> > >>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>> > >>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>> > >>> fragment id 0x0001 > >>> > >>> 00:00:15:004790: ethernet-input > >>> > >>> IP4: 08:00:27:7e:6e:2e -> 08:00:27:9b:f1:65 > >>> > >>> 00:00:15:004794: ip4-input > >>> > >>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>> > >>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>> > >>> fragment id 0x0001 > >>> > >>> 00:00:15:004797: ip4-lookup > >>> > >>> fib 0 dpo-idx 6 flow hash: 0x00000000 > >>> > >>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>> > >>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>> > >>> fragment id 0x0001 > >>> > >>> 00:00:15:004800: ip4-local > >>> > >>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>> > >>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>> > >>> fragment id 0x0001 > >>> > >>> 00:00:15:004803: ipsec-if-input > >>> > >>> IPSec: spi 623421022 seq 1 > >>> > >>> 00:00:15:004804: esp-decrypt > >>> > >>> esp: crypto aes-cbc-192 integrity sha1-96 > >>> > >>> 00:00:15:004865: ip4-input > >>> > >>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>> > >>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>> > >>> fragment id 0x0001 > >>> > >>> ICMP echo_request checksum 0xf7ff > >>> > >>> 00:00:15:004866: ip4-lookup > >>> > >>> fib 0 dpo-idx 5 flow hash: 0x00000000 > >>> > >>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>> > >>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>> > >>> fragment id 0x0001 > >>> > >>> ICMP echo_request checksum 0xf7ff > >>> > >>> 00:00:15:004866: ip4-local > >>> > >>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>> > >>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>> > >>> fragment id 0x0001 > >>> > >>> ICMP echo_request checksum 0xf7ff > >>> > >>> 00:00:15:004867: ip4-icmp-input > >>> > >>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>> > >>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>> > >>> fragment id 0x0001 > >>> > >>> ICMP echo_request checksum 0xf7ff > >>> > >>> 00:00:15:004869: ip4-icmp-echo-request > >>> > >>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>> > >>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>> > >>> fragment id 0x0001 > >>> > >>> ICMP echo_request checksum 0xf7ff > >>> > >>> 00:00:15:004874: ip4-rewrite-local > >>> > >>> tx_sw_if_index 5 adj-idx 1 : loop0 index:1 flow hash: 0x00000000 > >>> > >>> > >>> > >>> 00:00:15:004876: ip4-arp > >>> > >>> IP6_HOP_BY_HOP_OPTIONS: 8.6.69.0 -> 0.28.127.62 > >>> > >>> version 15, header length 60 > >>> > >>> tos 0xff, ttl 0, length 65535, checksum 0x0000 (should be 0x1646) > >>> > >>> fragment id 0xffff offset 62824, flags MORE_FRAGMENTS > >>> > >>> 00:00:15:004878: error-drop > >>> > >>> ip4-arp: ARPs to non-ARP adjacencies > >>> > >>> > >>> > >>> VPP version : v16.12-rc0~173-gf56b77a~b1196 > >>> > >>> > >>> > >>> Is it better to adjust the ipsec implementation so the ipsec > >>> interface can be set an IP or is there other way I can accomplish this? > >>> > >>> Thanks, > >>> > >>> > >>> > >>> > >>> > >>> Zdeno > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ vpp-dev mailing > list > >>> vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev > >>> > >> _______________________________________________ csit-dev mailing list > >> csit-...@lists.fd.io https://lists.fd.io/mailman/listinfo/csit-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
