Hi Neale,
There was an issue in my code (we use a different IKE stack with VPP
IPSEC). While copying keys recvd from the IKE process, I was using strncpy
instead of memcpy. As the encr and auth keys can have a '0' byte, the
strncpy gets terminated before copying all the n bytes. This caused
decryption failure or Integrity check failure when SS sent IPSEC pkts.
*NOTE*: -
Whenever the keys generated did not have a '0' byte, there was no issue. It
used to work fine in such cases.
On Mon, Aug 2, 2021 at 5:34 PM Neale Ranns <ne...@graphiant.com> wrote:
>
>
>
>
> *From: *Vijay Kumar <vjkumar2...@gmail.com>
> *Date: *Monday, 2 August 2021 at 11:33
> *To: *Neale Ranns <ne...@graphiant.com>
> *Cc: *vpp-dev <vpp-dev@lists.fd.io>
> *Subject: *Re: [vpp-dev] Regarding IPsec errors "Integrity failure" and
> "Unsupported payload"
>
> Hi Neale,
>
>
>
> My IPSEC rekey is set to high (2 hr). So the issue is not during rekey.
>
>
>
> I don’t understand why the former statement leads to your latter
> conclusion. Is it because you see this failure happen soon after the
> initial session is established and before the first rekey?
>
>
>
> According to code, during decrypt the esp_process_ops() is called. In this
> function, I had added the below print. Whenever I get integrity check
> failure, I see that print in my application logs.
>
>
>
> Once I land into this issue, it always fails. To recover I have to reset
> ike and ipsecsa and establish again.
>
>
>
> When can I see the integrity check failure in decrypt??
>
>
>
> Do you mean why would an integrity check fail? Lot’s of reasons. But given
> that you see all packets fail, and it is recovered by reset/rekey, I would
> suggest the sender has changed its keys.
>
>
>
> /neaele
>
>
>
>
>
> *Code snippet*
>
> *========*
>
> static_always_inline void
> esp_process_ops (vlib_main_t * vm, vlib_node_runtime_t * node,
> vnet_crypto_op_t * ops, vlib_buffer_t * b[], u16 * nexts,
> int e)
> {
> vnet_crypto_op_t *op = ops;
> u32 n_fail, n_ops = vec_len (ops);
>
> if (n_ops == 0)
> return;
>
> n_fail = n_ops - vnet_crypto_process_ops (vm, op, n_ops);
>
> while (n_fail)
> {
> ASSERT (op - ops < n_ops);
> if (op->status != VNET_CRYPTO_OP_STATUS_COMPLETED)
> {
> u32 err, bi = op->user_data;
> if (op->status == VNET_CRYPTO_OP_STATUS_FAIL_BAD_HMAC)
> {
> err = e;
> printf("In esp_process_ops op status =
> VNET_CRYPTO_OP_STATUS_FAIL_BAD_HMAC\n");
>
> }
>
> else
> {
> err = ESP_DECRYPT_ERROR_CRYPTO_ENGINE_ERROR;
> printf("In esp_process_ops err =
> ESP_DECRYPT_ERROR_CRYPTO_ENGINE_ERROR\n");
> }
> b[bi]->error = node->errors[err];
> nexts[bi] = ESP_DECRYPT_NEXT_DROP;
> n_fail--;
> }
> op++;
> }
>
> }
>
>
>
> On Mon, Aug 2, 2021 at 1:06 PM Neale Ranns <ne...@graphiant.com> wrote:
>
>
>
> Hi Vijay,
>
>
>
> No I don’t see random failures. Do they occur during a rekeying event?
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Vijay
> Kumar via lists.fd.io <vjkumar2003=gmail....@lists.fd.io>
> *Date: *Monday, 2 August 2021 at 08:43
> *To: *vpp-dev <vpp-dev@lists.fd.io>
> *Subject: *Re: [vpp-dev] Regarding IPsec errors "Integrity failure" and
> "Unsupported payload"
>
> Hi Neale,
>
>
>
> Do you have any suggestions for this problem.
>
> Did you face this random issue anytime?
>
>
>
>
>
>
>
>
>
> On Sat, Jul 31, 2021 at 7:05 PM Vijay Kumar via lists.fd.io <vjkumar2003=
> gmail....@lists.fd.io> wrote:
>
> Hi Neale,
>
>
>
> I am testing data traffic b/w Strongswan and VPP but sometimes data
> traffic is dropped in *esp4-decrypt-tun *graph node. Sometimes it is
> dropped with "Integrity failure" while sometimes it is "Unsupported
> payload"
>
>
>
> But if I delete the tunnel and re-establish IPSec SA, then it works fine.
>
>
>
> I have ensured the configuration w.r.t PSK, Proposals and TS is fine.
> Also, I confirmed that the adjacencies(routes) for the Strongswan are fine
> on the VPP side.
>
>
>
> Version I am using is pasted below.
>
>
>
> Could I be missing something? These are random issues.
>
>
>
>
>
> vpp# show version
>
> *vpp v20.05.1-2*~g44ff05906-dirty built by an-vijay_kumar on 56d1c81f572a
> at 2021-07-30T15:54:16
>
>
>
>
>
>
>
> Regards.
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19898): https://lists.fd.io/g/vpp-dev/message/19898
Mute This Topic: https://lists.fd.io/mt/84569833/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
