packet encryption not correct

[mohamedalyk]

Hi @fasferraz ,

The tool is working fine with null encryption, but when using ENCR_AES_CBC for example, it is giving wrong data that is dropped by real epdg

test.zip

in the attached pcap, here is the tool output for decoding ESP SA INFO (wireshark): "IPv4","10.10.10.6","3.3.100.1","0x71000029","AES-CBC [RFC3602]","0x1f14f979c10b42b4deb00dce76beb345","HMAC-SHA-256-128 [RFC4868]","0xecd5b1b57be90d604d02cf26906b25991f4d7b7fbeb3b885e12c4214199b953c" "IPv4","3.3.100.1","10.10.10.6","0x80666f79","AES-CBC [RFC3602]","0x449feb81c85cde60af75faa37619e625","HMAC-SHA-256-128 [RFC4868]","0xc9c8123d2e997173fb8bf49f494d4d7fb1447e94702785b93e47a66edaba51ca"

and by using the tool data, wireshark was able to decode the epdg ping packet, while it was not able to decode the ping reply from the tool.

also the real epdg dropped the reply, and a counter is incremented Rx inbound IP packets with an invalid pad byte : 78

Thanks for the tool and your effort

BR, Mohamed

[fasferraz]

Hi, can you please provide a trace with ESP but also with the IKE packets? And please provide de output of the tool. This tool was tested with all the supported algorithms...

[mohamedalyk]

Hi, needed data is here pcaps.zip

here you find the tool output, pcap for ike, pcap for esp packets, and pcap for ping packets in plain text taken from tun interface tcpdump.

note: the ike pcap is taken from real epdg that has the option to write the decoded packets in the pcap trace, hence you find 2 copies of each ike packet, the encrypted and the decoded.

[fasferraz]

Hi, I can't reproduce your issue. I replicated your scenario with a real ePDG using the same exact algorithms, and I can do a ping to the internet. Nevertheless, when I try to decode your esp.pcap I can the pings in both directions perfectly decoded:

I noticed that your ePDG is using incremental pad, while my tool sets it as zeros. I'm reading RFC 4303, 2406, and 3602 (for AES-CBC), and the pad might need to be changed. It looks my ePDG is not checking the pad format, and yours is. I need to change lines 1580 and 1582, and use the esp_padding function, like i do got GCM.

Can you please change this part:

            if res>1:
                data_to_encrypt += b'\x00'*(res-2) + bytes([res-2]) + bytes([packet_type])
            else:
                data_to_encrypt += b'\x00'*(14+res) + bytes([14+res]) + bytes([packet_type])

to this and try again?

          if res>1:
                data_to_encrypt += self.esp_padding(res-2) + bytes([res-2]) + bytes([packet_type])
            else:
                data_to_encrypt += self.esp_padding(14+res) + bytes([14+res]) + bytes([packet_type])

[mohamedalyk]

Hi Fabricio,

Yes indeed our epdg is checking the pad byte, and it has a counter for that Rx inbound IP packets with an invalid pad byte : 17

after applying your fix, it is working fine now, and reply packets are accepted by epdg.

many thanks for your effort