Home » Eclipse Projects » Eclipse Titan » IPsec over UDP(How to configure an UDP port to use a fixed src port number )
| | |
| Re: IPsec over UDP [message #1823702 is a reply to message #1823700] |
Tue, 31 March 2020 10:59   |
|
Hi Olaf,
that's right, you can request a specific local port (src) in ASP_UDP_open:
type record ASP_UDP_open{
AddressType remote_addr optional,
PortType remote_port optional,
AddressType local_addr optional,
PortType local_port optional
}
Of course, local_port should be given the value of the desired src port.
This will be acknowledged with ASP_UDP_open_result:
type record ASP_UDP_open_result{
AddressType local_addr,
PortType local_port,
integer id
}
BR
Elemer
|
|
| |
| Re: IPsec over UDP [message #1824422 is a reply to message #1823705] |
Wed, 15 April 2020 07:05 |
 Olaf Bergengruen
Messages: 127
Registered: November 2018 |
Senior Member |
|
|
Hi all,
may be one of you have an idea how can I solve my next problem.
In case I have several pairs of ports which shall be connected over IPsec, I don't know how to set the IPsec configuration, such that the OS selects the right spi when I, the Tester, sends an UDP packet over a particular port.
In detail:
IUT Tester
Port-x <--------------------> Port-1
<-- spi-1 --
Port-y <--------------------> Port-2
<-- spi-2 --
Port-z <--------------------> Port-3
<-- spi-3 --
The configuration in the Tester (only the configuration in direction Tester --> IUT):
f_IPsec_SADB_add (Tester_IPaddr, IUT_IPaddr, esp, spi_1,...);
f_IPsec_SADB_add (Tester_IPaddr, IUT_IPaddr, esp, spi_2,...);
f_IPsec_SADB_add (Tester_IPaddr, IUT_IPaddr, esp, spi_3,...);
f_IPsec_SPDB_add (Tester_IPaddr, -, port_1, IUT_IPaddr, -, -, udpProto, outDir, ...);
f_IPsec_SPDB_add (Tester_IPaddr, -, port_2, IUT_IPaddr, -, -, udpProto, outDir, ...);
f_IPsec_SPDB_add (Tester_IPaddr, -, port_3, IUT_IPaddr, -, -, udpProto, outDir, ...);
But how can the OS know, when sending via Port_1.sendto, that it shall use spi-1?
I would appreciate any hint on this issue,
Olaf
|
|
|
| Re: IPsec over UDP [message #1824534 is a reply to message #1824422] |
Fri, 17 April 2020 05:57 |
|
Hi Olaf,
f_IPsec_SPDB_add and f_IPsec_SADB_add are only wrappers to the corresponding Linux kernel functions, so
details about IPSec can be obtained from Linux kernel implementation and configuration descriptions.
For outbound packets:
IPSec founds the first match (based on srcAddress,srcPort,dstAddress,dstPort) in the
Security Policy Database (SPD)
If the policy requires protection, IPSec maps the packet to the right Security Association (SA) in the
Security Association Database (SAD)
If no SA exists, IPSec invokes the IKE service to create an SA pair
If SA exists, the packet is encrypted/authenticated
(see figure below)
For incoming IPSec packets, IPSec looks up the inbound SA in the SAD based on SPI (Security Parameter Index)
(this is exchanged between sender and receiver during the initial negotiation and it is contained in the IPSec packet )
IPSec then processes (decrypts/authenticates) the packet based on SA
For incoming non-IPSec packets, IPSec finds the first matching policy in SPD and verifies that the action
is BYPASS; if not , the packet is dropped.
(see figure below)
So how does this look in practice?
For outgoing packets, SPD is built with f_IPsec_SPDB_add (see TCCIPsec_Functions.ttcn)
external function f_IPsec_SPDB_add (
in charstring srcAddress,
in integer srcPrefixLen := c_TCCIPsec_prefixAll,
in integer srcPort := c_TCCIPsec_anyPort,
in charstring dstAddress,
in integer dstPrefixLen := c_TCCIPsec_prefixAll,
in integer dstPort := c_TCCIPsec_anyPort,
in TCCIPsec_TranspProto transpProto := anyTranspProto,
in TCCIPsec_PolicyDirection dir,
in TCCIPsec_PolicyRule rule
) return TCCIPsec_Result;
where(see TCCIPsec_Definitions.ttcn)
type union TCCIPsec_PolicyRule {
TCCIPsec_DiscardRule discard, //DISCARD
TCCIPsec_NoneRule noneRule, //BYPASS
TCCIPsec_RuleList ipSec //PROTECT
};
type record of TCCIPsec_Rule TCCIPsec_RuleList;
type record TCCIPsec_Rule {
TCCIPsec_Protocol protocol, //ah, esp
TCCIPsec_Mode mode, //transport or tunnel
TCCIPsec_RuleLevel level
};
type union TCCIPsec_RuleLevel {
TCCIPsec_DefaultLevel defaultLevel,
TCCIPsec_UseLevel use,
TCCIPsec_RequireLevel require,
TCCIPsec_UniqueLevel unique
};
type record TCCIPsec_DefaultLevel {};
type record TCCIPsec_UseLevel {};
type record TCCIPsec_RequireLevel {};
type record TCCIPsec_UniqueLevel {
integer id
}
//An SA is linked to an SP when the SA has a policyId extension with the
//value of the SP's id.
According to
http://manpages.ubuntu.com/manpages/bionic/man3/ipsec_set_policy.3.html
about IPSec rule level
"level must be set to one of the following: default, use, require, or
unique.
default means that the kernel should consult the system default policy defined by sysctl(8), such as net.inet.ipsec.esp_trans_deflev. See ipsec(4) regarding the system default.
use means that a relevant SA can be used when available, since the kernel may perform IPsec operation against packets when possible. In this case, packets can be transmitted in clear (when SA is not available), or encrypted (when SA is available).
require means that a relevant SA is required, since the kernel must
perform IPsec operation against packets.
unique is the same as require, but adds the restriction that the SA for outbound traffic is used only for this policy. You may need the identifier in order to relate the policy and the SA when you define the SA by manual keying. You can put the decimal number as the identifier after unique like unique: number. number must be between 1 and 32767 .
If the request string is kept unambiguous, level and slash prior to level can be omitted. However, it is encouraged to specify them explicitly to avoid unintended behavior. If level is omitted, it will be interpreted as default."
Example:
res := f_IPsec_SPDB_add ( "192.168.1.1", -, 2001, "192.168.1.2", -, 3001,
udpProto, outDir,
{ ipSec := { { protocol := esp, mode := { transport := {} }, level := { unique := { id := 101 } } } } } ); //pointer to SA
res := f_IPsec_SADB_add ( "192.168.1.1", "192.168.1.2", esp,
11001, //this is SPI
{ { policyId := 101 }, { hardLifetime := 180 }, { softLifetime := 60 } }, //policyId links SA to SP
{ encrAndAuth := {
ealgo := EALG_3DESCBC, ekey := { text := "123456789012345678901234" },
aalgo := AALG_MD5HMAC, akey := { text := "1234567890123456" } } } );
where f_IPsec_SADB_add builds the SAD:
external function f_IPsec_SADB_add (
in charstring srcAddress,
in charstring dstAddress,
in TCCIPsec_Protocol protocol, //ah or esp
in integer spi,
in TCCIPsec_ExtensionList extensionList := {}, //this contains policyId
in TCCIPsec_Algorithm alg,
in boolean setparitybit := false,
in boolean useNatt := false,
in TCCIPsec_IPsecMode ipSecMode := anyMode //transport or tunnel
) return TCCIPsec_Result;
type union TCCIPsec_Extension {
integer policyId, //Identifier to link a Security Association (SA) to Security Policy (SP)
integer hardLifetime,
integer softLifetime
};
so for outgoing packets, SPD is looked up (based on src and dst addresses/ports) , and the pointer to SA ( level := { unique := { id := 101 } } ) is found; so the appropriate SA is used to encrypt/authenticate .
On the SA side, policyId ( { policyId := 101 }, )links SA to a Security Policy.
SPI is only used in incoming direction; during initial negotiation, the sender will send information about SA/SPI to the receiver, which will build it's own SAD.
I hope this answers your question.
Best regards
Elemer
Attachment: IPSecOG.png
(Size: 32.53KB, Downloaded 350 times)-
Attachment: IPSecIC.png
(Size: 38.07KB, Downloaded 350 times)
|
|
| |
Goto Forum:
Current Time: Thu Oct 10 05:51:04 GMT 2024
Powered by FUDForum. Page generated in 0.04666 seconds |
] 
Search
Help
Register
Login
Home
