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
  • [vpp-dev] C... Zdenko Olsovsky -X (zolsovsk - PANTHEON TECHNOLOGIES at Cisco)
    • Re: [v... Neale Ranns
      • Re... Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)
        • ... Neale Ranns
          • ... Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)
            • ... Neale Ranns
              • ... Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)

Reply via email to