Dear Timo,

If I make the following change will it solve my purpose has described below
Changes to be made:
in function pfkey_sockaddr_fill() in file net/key/af_key.c
        --   sin->sin_port = port;
        ++ sin->sin_port = sa->sin_port;

Thanks and Regards
Naveen BN wrote:
Is this the function which will fill the SADB from the pf_key messages , is this the right place to fixed my requirement
file: net/key/af_key.c
function: static unsigned int pfkey_sockaddr_fill(xfrm_address_t *xaddr, __be16 port,  struct sockaddr *sa,     unsigned short family)
port ->is sent zero here.
*sa -> will this contain port filled from application. After the SADB_EXT_ADDRESS_SRC in the pf_key message sent to update the SADB.

Naveen BN wrote:
Dear All,
Does any body know which file and where in the  linux kernel version can I fix for PF_KEY engine in order  read  and  consider the ports from the  struct sockaddr_in filled after the SADB_EXT_ADDRESS_SRC extension in PF_KEY message in PF_KEY engine.


Timo Teräs wrote:
Naveen BN wrote:
Can I do the same fix for the linux version PF_KEY engine in order  read  and  consider the ports from the
 struct sockaddr_in filled after the SADB_EXT_ADDRESS_SRC extension in PF_KEY message in PF_KEY engine.

I think the ports were used for something else at some point. But
in theory that would work. However, you would need to maintain your
own kernel fork as linux kernel people have made it very clear that
they will not accept such patches in mainstream kernel.

- Timo

Naveen BN wrote:
I have a problem using SA with selectors based on <src IP>, <dest IP> and <dst port>  for outbound traffic.
I have written two out bound SA's for the same destination IP with different destination port, but I am seeing
wrong SA has been selected for outbound traffic. My concern is why the SA is not getting selected based on
ports  mentioned security  policy.

content of file setkey.conf
/************************* start setkey.conf ************************/

add[*800]* esp 0x201 -m tunnel -E 3des-cbc
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

add[500] esp 0x301 -m tunnel -E 3des-cbc
-A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

add[*500] *esp 0x208 -m tunnel -E 3des-cbc
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

# Security policies
spdadd[*800]* esp -P out ipsec

spdadd[*800] * esp  -P in ipsec
/************************* end setkey.conf ************************/

*When a packet is sent to dest port 800 , SA which is getting selected is  0x208[spi] with dstport 500 instead of 0x201[spi] **with dstport 800 instead**.*

Please provide the criteria for outboud SA selection, please guide me regarding this issue .
My Linux kernel version is


The port number is not settable via pf_key programming API in Linux.
This kind of functionality is possible via XFRM API, but it is not
supported by setkey/racoon. If you need this, you should use some
IKE software that supports the XFRM API such as strongSwan or OpenSwan.

- Timo

Naveen BN wrote:
Thanks you for the reply , Can i know why is that pf_key API does not support adding ports to
SADB is there an specific reason  .

Racoon runs on multiple platforms and is based on pf_key api.

pf_key api originates from *BSD world, and was implemented in linux
too. However, there were several problems with the API: it did not
support all things needed and most importantly it never gained the
standardization it was intended to have. There are many variants of
this API.

Linux people decided to ditch this API and implemented the same
things in Netlink XFRM API in a more robust manner with additional
features. Consequently pf_key got deprecated in Linux. However, it
is still the only option in *BSD.

The BSD variants allow the port numbers. There used to be quite a
bit of differences on details, but it's supposedly better now. After
Linux developer deprecated the pf_key api they are refusing to add
new features to it. So to get the functionality you want in Linux
you need to use the native Linux API: Netlink XFRM. Or implement
the same things in Linux pf_key code (but these will not get accepted
to mainline kernel due to policy).

If you just need static IPsec SA's with port specific stuff in
Linux, you should be able to create them with "ip xfrm" command
from iproute2 package. If you need IKE keying, you need to use
some IKE daemon that talks to kernel with Linux Netlink XFRM as
I told before.

There are some option on the Linux IKE implementations. I generally
prefer ipsec-tools since it uses openssl: it runs on my crypto
hardware and has smaller code size. However, {open,strong}swan seem
to implement the XFRM API and IKEv2 amongst other interesting
things not supported by ipsec-tools.

I'm currently tempted to write simple IKE for my special needs
based on openssl and xfrm api. But I've been recently more busy
than I anticipated, so we'll see how that goes.

- Timo

Naveen BN wrote:
Thanks for the info.
Is there an RFC for using XFRM API like rfc2367 for PF_KEY.
I am using PF_KEY programming API for writing  SADB  contents , but i had a requirement
for creating Session Based SA[ port based SA selection ] , so this may be not possible.
I have to move to XFRM API for my requirement right.

Yes, you'd need to use entries with reqid field, and those can
be created only with xfrm api.

No RFC. Use the source.

- Timo

Naveen BN wrote:
Will it effect the portability of the application using xfrm api .
XFRM API is implemented in Linux only. So your application will
be Linux specific.

- Timo