Problem Description: Security assotiations manipulation is defined by RFC2367 - PFKEY API. However this specification has some drawbacks and unnecessary limitations. (Maybe RFC2367 would deserve updating as it is rather old.) Specifically there is a need for an IPsec SA which supports simultaneously TCP and UDP. Such behaviour can be required by many applications and is e.g. neccessary for authenticating in 3G according to 3GPP TS 33.203. Current implementation of PFkey in linux (af_key.c) nethertheless doesn't support usage of ports as SA selectors and moreover, if a protocol is specified, the ports are zeroed. I have found that a bug on this issue has been reported against solaris and has been corrected - see bugID 6258318 (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6258318) So, I would appreciate to have similar behaviour in linux as well to be competitive.
Begin forwarded message: Date: Tue, 4 Jul 2006 06:54:01 -0700 From: bugme-daemon@bugzilla.kernel.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 6791] New: ports in SA should not be zeroed when protocol is specified http://bugzilla.kernel.org/show_bug.cgi?id=6791 Summary: ports in SA should not be zeroed when protocol is specified Kernel Version: 2.6.17 and all previous Status: NEW Severity: normal Owner: shemminger@osdl.org Submitter: klimes@centrum.cz Problem Description: Security assotiations manipulation is defined by RFC2367 - PFKEY API. However this specification has some drawbacks and unnecessary limitations. (Maybe RFC2367 would deserve updating as it is rather old.) Specifically there is a need for an IPsec SA which supports simultaneously TCP and UDP. Such behaviour can be required by many applications and is e.g. neccessary for authenticating in 3G according to 3GPP TS 33.203. Current implementation of PFkey in linux (af_key.c) nethertheless doesn't support usage of ports as SA selectors and moreover, if a protocol is specified, the ports are zeroed. I have found that a bug on this issue has been reported against solaris and has been corrected - see bugID 6258318 (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6258318) So, I would appreciate to have similar behaviour in linux as well to be competitive. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
The xfrm interface can already do this so please use that on Linux instead of PFKEY. Extending PFKEY is possible but it'd be as unportable as using xfrm. Since we want people to use xfrm in general there is no point in extending PFKEY at this point in time. If there is any movement in terms of an updated PFKEY standard then we can reconsider this. Cheers,
Actually I just noticed that in the policy part of af_key.c we preserve the port numbers as is. This is all you need for selecting traffic by ports. The port numbers in the SA selector doesn't actually matter.