DPDK usage discussions
 help / color / mirror / Atom feed
From: "Das, Surajit" <Surajit.Das@commscope.com>
To: users <users@dpdk.org>
Subject: Re: [dpdk-users] DPDK l2fwd-crypto sample app Don't see encrypted icmp packet on the transmit side
Date: Fri, 12 Feb 2021 04:02:41 +0000	[thread overview]
Message-ID: <DM6PR14MB37570AE4FEAA980443001014E98B9@DM6PR14MB3757.namprd14.prod.outlook.com> (raw)
In-Reply-To: <DM6PR14MB3757C87C1DBDA50795A17305E98C9@DM6PR14MB3757.namprd14.prod.outlook.com>

Hi DPDK Experts,

I figured that the l2fwd-crypto app is encrypting packets.
Tshark, thinks the packet is ICMP because crypto dev does not modify the ipv4 header.
So ip4_hdr->next_proto_id value remains unchanged, causing tshark to think it's an ICMP packet.

The payload of the ipv4 header, which is the ICMP part does look encrypted.

Now, I tried decrypting the packet by using the l2fwd-cypto app on an adjacent container.

Command with arguments:
[root@decrypt-app-deployment-79fdd95b56-h8lxr build]# ./l2fwd-crypto -l 2-3 -n 4 --vdev "crypto_aesni_mb0" --vdev "crypto_aesni_mb1" -w 0000:65:01.0 -w 0000:65:01.6 -- -p 0x3 --cdev SW --chain HASH_CIPHER --cipher_op DECRYPT --cipher_algo aes-cbc --cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f --auth_op VERIFY --auth_algo aes-xcbc-mac --auth_key 10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f


On the other end of the receive side after decrypting, I still see the packet is encrypted.
Packet structure on the decrypted side:
Internet Protocol Version 4, Src: 30.30.20.12 (30.30.20.12), Dst: 30.30.20.10 (30.30.20.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 84
    Identification: 0x99cd (39373)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0x3c8a [validation disabled]
        [Good: False]
        [Bad: False]
    Source: 30.30.20.12 (30.30.20.12)
    Destination: 30.30.20.10 (30.30.20.10)
Internet Control Message Protocol
    Type: 169 (Unknown ICMP (obsolete or malformed?))
    Code: 121
    Checksum: 0xb89e [incorrect, should be 0xee1d]

As you can see, the ICMP part still looks encrypted.
Is there anything in the command line arguments, that I am missing?

Regards,
Surajit

From: Das, Surajit
Sent: Thursday, February 11, 2021 11:26 PM
To: users <users@dpdk.org>
Subject: DPDK l2fwd-crypto sample app Don't see encrypted icmp packet on the transmit side

Hi DPDK Experts,

I am running l2fwd-crypto app on SR-IOV VFs.
I am sending ICMP ping on ipv4 to the l2fwd-crypto.
On the transmit side, I am not receiving any encrypted packet.
Instead I am just receiving the very same icmp packet.
The only change I made, is to the l2fwd_mac_updating function, to set the destination mac to broadcast, to make sure the packet reaches destination VF.

Command to send packet:
arp -s 30.30.20.10 -i dev0 3a:fc:e6:60:a9:d3
ping -I dev0 30.30.20.10 -c1

Command to run l2fwd-crypto:
./l2fwd-crypto -l 0-1 -n 4 --vdev "crypto_aesni_mb0" --vdev "crypto_aesni_mb1" -w 0000:65:00.4 -w 0000:65:00.5 -- -p 0x3 --cdev SW --chain CIPHER_HASH --cipher_op ENCRYPT --cipher_algo aes-cbc --cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f --auth_op GENERATE --auth_algo aes-xcbc-mac --auth_key 10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f

Output Counter suggests encryption was done:
Port statistics ====================================
Statistics for port 0 ------------------------------
Packets sent:                                1
Packets received:                            0
Packets dropped:                             0
Statistics for port 1 ------------------------------
Packets sent:                                0
Packets received:                            1
Packets dropped:                             0
Crypto statistics ==================================
Statistics for cryptodev 0 -------------------------
Packets enqueued:                            0
Packets dequeued:                            0
Packets errors:                              0
Statistics for cryptodev 1 -------------------------
Packets enqueued:                            1
Packets dequeued:                            1
Packets errors:                              0
Aggregate statistics ===============================
Total packets received:                      1
Total packets enqueued:                      1
Total packets dequeued:                      1
Total packets sent:                          1
Total packets dropped:                       0
Total packets crypto errors:                 0
====================================================

What the received packet looks like:
[root@decrypt-app-deployment-79fdd95b56-h8lxr ~]# tshark  -i dev4
Running as user "root" and group "root". This could be dangerous.
Capturing on 'dev4'
  1 0.000000000  30.30.20.12 -> 30.30.20.10  ICMP 110 Unknown ICMP (obsolete or malformed?) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]
^C1 packet captured

Can anyone suggest what I could be missing here?

Regards,
Surajit

      reply	other threads:[~2021-02-12  4:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 17:56 Das, Surajit
2021-02-12  4:02 ` Das, Surajit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR14MB37570AE4FEAA980443001014E98B9@DM6PR14MB3757.namprd14.prod.outlook.com \
    --to=surajit.das@commscope.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).