IPsec needs to support both UDP and TCP according to standards RFC 3261 and 3GPP 33.203

[GoogleCodeExporter]

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
Latest branch 2.0; Windows 7

Please provide any additional information below.

As summary; IPsec needs to support both UDP and TCP accoring to standards RFC 
3261 and 3GPP 33.203.

From RFC 3261 Section 18.1.1
   “If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed.  This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages.  However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size.  For UDP, this size is 65,535 bytes, including
   IP and UDP headers.

      The 200 byte "buffer" between the message size and the MTU
      accommodates the fact that the response in SIP can be larger than
      the request.  This happens due to the addition of Record-Route
      header field values to the responses to INVITE, for example.  With
      the extra buffer, the response can be about 170 bytes larger than
      the request, and still not be fragmented on IPv4 (about 30 bytes
      is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when
      path MTU is not known, based on the assumption of a 1500 byte
      Ethernet MTU.”

From 3GPP 33.203 Clause 6.2
“The method to set up ESP security associations (SAs) during the SIP 
registration procedure is specified in clause 7. As a result of an 
authenticated registration procedure, two pairs of unidirectional SAs between 
the UE and the P CSCF all shared by TCP and UDP, shall be established in the P 
CSCF and later in the UE. One SA pair is for traffic between a client port at 
the UE and a server port at the P CSCF and the other SA is for traffic between 
a client port at the P CSCF and a server port at the UE. For a detailed 
description of the establishment of these security associations see clause 7.”

From my reading this requires that UDP and TCP be supported over the same SAs.  
This makes sense me because to create ‘two pairs of unidirectional SAs’ 
once for UDP and later for TCP would require further signaling between client 
and server (the client would not know the SPI associated with the TCP ‘pairs 
of unidirectional SAs’).

Original issue reported on code.google.com by alistair...@gmail.com on 26 Feb 2014 at 1:28

[GoogleCodeExporter]

Also from 3GPP 33.203 Annex H:
"It is assumed that the underlying IPsec implementation supports selectors that 
allow all transport protocols supported by SIP to be protected with a single 
SA."

Original comment by alistair...@gmail.com on 5 Mar 2014 at 3:20

[GoogleCodeExporter]

Should be fixed by r1038.
To use same SAs for all protocols (TCP, UDP...), use "tipsec_ipproto_all" 
(https://code.google.com/p/doubango/source/browse/branches/2.0/doubango/tinyIPSe
c/src/tipsec.h?spec=svn1038&r=1038#169) as ipproto.

Original comment by boss...@yahoo.fr on 5 Mar 2014 at 11:48

• Changed state: Fixed