[dpdk-dev] [EXT] [PATCH v4 02/10] security: add UDP params for IPsec NAT-T

[Nicolau, Radu]

On 9/24/2021 10:11 AM, Hemant Agrawal wrote:
>
>
> On 9/6/2021 4:39 PM, Nicolau, Radu wrote:
>>
>> On 9/5/2021 3:19 PM, Akhil Goyal wrote:
>>> Hi Radu,
>>>
>>>> Add support for specifying UDP port params for UDP encapsulation 
>>>> option.
>>>>
>>>> Signed-off-by: Declan Doherty <declan.doherty at intel.com>
>>>> Signed-off-by: Radu Nicolau <radu.nicolau at intel.com>
>>>> Signed-off-by: Abhijit Sinha <abhijit.sinha at intel.com>
>>>> Signed-off-by: Daniel Martin Buckley <daniel.m.buckley at intel.com>
>>> Do we really need to specify the port numbers for NAT-T?
>>> I suppose they are fixed as 4500.
>>> Could you please specify what the user need to set here for session
>>> creation?
>>
>> From what I'm seeing here 
>> https://datatracker.ietf.org/doc/html/rfc3948#section-2.1 there is no 
>> requirement in general for UDP encapsulation so I think it's better 
>> to make the API flexible as to allow any port to be used.
>
>
> This section states that :
>
> o  the Source Port and Destination Port MUST be the same as that used by IKE traffic,
>
> IKE usages port 4500
>
> am I missing something?


I think there's enough confusion in the RFCs so I think it's better to 
keep this option flexible:

For example https://datatracker.ietf.org/doc/html/rfc5996#section-2.23:

>     It is a common practice of NATs to translate TCP and UDP port numbers
>     as well as addresses and use the port numbers of inbound packets to
>     decide which internal node should get a given packet.  For this
>     reason, even though IKE packets MUST be sent to and from UDP port 500
>     or 4500, they MUST be accepted coming from any port and responses
>     MUST be sent to the port from whence they came.  This is because the
>     ports may be modified as the packets pass through NATs.  Similarly,
>     IP addresses of the IKE endpoints are generally not included in the
>     IKE payloads because the payloads are cryptographically protected and
>     could not be transparently modified by NATs.