> As per IPSEC ESP RFC 4303, for both tunnel mode or transport mode, > next proto 50, so we cannot identify a packet is for tunnel mode or > transport mode by just packet parsing. > Am I missing something ? You are absolutely correct, the only way to tell the difference is to parse the next_proto field in the ESP header itself. But this field is encrypted, according to RFC, and not really available for parsing.
> Currently there is already a PTYPE `RTE_PTYPE_TUNNEL_ESP` being used > by all drivers / ipsec-secgw to indicate ESP packet. So why is this > needed ? The idea was to add the possibility to distinguish packets in these two modes. But you are right, it doesn't seem achievable without decrypting the packet first. > There is also a documentation issue with `RTE_PTYPE_TUNNEL_ESP` where > it indicates next-proto of 51 but it should have been 50. > next-proto of 51 is for IPSEC AH. Yes, documentation is incorrect there. Thanks for bringing this up, Nithin, I think we can live with RTE_PTYPE_TUNNEL_ESP.
