You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Janne Peltonen 2018-10-03 10:20:21 UTC
Separate IP ID allocation for transport and tunnel mode SAs may cause duplicate IDs.
The IPsec implementation allocates IPv4 IDs for tunnel mode packets but copies the ID from the plain text packet in transport mode.
This can violate the IP ID uniquenes requirement when there are both transport mode and tunnel mode SAs between the same endpoints.
The ODP API does not explicitly say how IPv4 IDs are generated in transport mode. If the unstated intent of the API is to have ODP implementation generate the IP ID in all cases, then this problem should be fixed as a bug in the current implementation and maybe also the API text should be clarified. Alternatively, this can be seen as a change request to the API and then corresponding implementation change (i.e. not a bug).
I am filing this as a bug now based on my interpretation of the discussion in the architecture meeting this Monday.
Comment 1 Bill Fischofer 2018-10-03 20:22:08 UTC
Assigning to Dmitry for IPsec review.
Comment 2 Dmitry Eremin-Solenikov 2018-12-06 13:29:10 UTC
Well. Please correct me if I'm wrong, but IPsec RFCs do not specify that in Transport mode IPv4 ID should be constructed. So, if I understand correctly, is that it should not be changed when transforming the packet.
Comment 3 Janne Peltonen 2018-12-10 13:18:01 UTC
RFC 791 and RFC 6864 specify uniqueness criteria for the IP ID field. Those criteria have to be met also with IPsec even if IPsec RFCs do not say so explicitly.
Now an IP host/router implementation that is using ODP and ODP IPsec may end up sending two AH or ESP packets (one transport mode packet, one tunnel mode packet) with the same source and destination and with the same IP ID value very close to each other. This is wrong and can prevent successful reassembly of those packets if they get fragmented.
To put it in another way, an IP endpoint cannot generate the IP ID value independently for different packets that have the same (source, destination, protocol) -tuple, but that is what now happens with ODP.
The text was updated successfully, but these errors were encountered:
Janne Peltonen 2018-10-03 10:20:21 UTC
Separate IP ID allocation for transport and tunnel mode SAs may cause duplicate IDs.
The IPsec implementation allocates IPv4 IDs for tunnel mode packets but copies the ID from the plain text packet in transport mode.
This can violate the IP ID uniquenes requirement when there are both transport mode and tunnel mode SAs between the same endpoints.
The ODP API does not explicitly say how IPv4 IDs are generated in transport mode. If the unstated intent of the API is to have ODP implementation generate the IP ID in all cases, then this problem should be fixed as a bug in the current implementation and maybe also the API text should be clarified. Alternatively, this can be seen as a change request to the API and then corresponding implementation change (i.e. not a bug).
I am filing this as a bug now based on my interpretation of the discussion in the architecture meeting this Monday.
Comment 1 Bill Fischofer 2018-10-03 20:22:08 UTC
Assigning to Dmitry for IPsec review.
Comment 2 Dmitry Eremin-Solenikov 2018-12-06 13:29:10 UTC
Well. Please correct me if I'm wrong, but IPsec RFCs do not specify that in Transport mode IPv4 ID should be constructed. So, if I understand correctly, is that it should not be changed when transforming the packet.
Comment 3 Janne Peltonen 2018-12-10 13:18:01 UTC
RFC 791 and RFC 6864 specify uniqueness criteria for the IP ID field. Those criteria have to be met also with IPsec even if IPsec RFCs do not say so explicitly.
Now an IP host/router implementation that is using ODP and ODP IPsec may end up sending two AH or ESP packets (one transport mode packet, one tunnel mode packet) with the same source and destination and with the same IP ID value very close to each other. This is wrong and can prevent successful reassembly of those packets if they get fragmented.
To put it in another way, an IP endpoint cannot generate the IP ID value independently for different packets that have the same (source, destination, protocol) -tuple, but that is what now happens with ODP.
The text was updated successfully, but these errors were encountered: