OpenSolaris

Printable Version Enter a New Search
Bug ID 6314433
Synopsis in.iked needs to reject identical rule label additions
State 10-Fix Delivered (Fix available in build)
Category:Subcategory network:ipsec
Keywords onnv_triage
Responsible Engineer Paul Wernau
Reported Against
Duplicate Of
Introduced In solaris_9
Commit to Fix snv_27
Fixed In snv_27
Release Fixed solaris_nevada(snv_27) , solaris_10u4(s10u4_01) (Bug ID:2144118)
Related Bugs 6333081
Submit Date 23-August-2005
Last Update Date 9-November-2005
Description
constraints should be deployed so that no identical rule labels could be added, otherwise, del/get sub-commands would get confused.
Can an example of this [confused] behaviour be added to the bug report.
add two rules like this.
/usr/sbin/ikeadm add rule { label "test rule" local_id_type ipv4
local_addr 111.168.13.1 remote_addr 211.168.1.3 local_id "SLOT=123"
remote_id "1.2.3.4" p2_lifetime_secs 30 p1_xform { oakley_group 2
encr_alg 3des auth_alg md5 auth_method rsa_encrypt } }
/usr/sbin/ikeadm add rule { label "test rule" local_id_type ipv4
local_addr 111.168.13.1 remote_addr 211.168.1.3 local_id "SLOT=123"
remote_id "1.2.3.5" p2_lifetime_secs 30 p1_xform { oakley_group 2
encr_alg 3des auth_alg md5 auth_method rsa_encrypt } }

the keywords are the same of "test rule", then how to get/del the second one?
the similar scenario is applicable for preshared key objects with identical localid/remoteid.
To expand on the above example...

In the scenario described, if you do ikeadm get rule "test rule", you'll see just one of the rules.  If you run ikeadm del rule "test rule", you'll delete one.  Then you run ikeadm get rule one more time and you get the second "hidden" rule, i.e. one of the rules becomes completely unaccessible, but it is in fact entered in as a duplicate and not overwritten.  You may subsequently delete the now-exposed rule once it appears again.
Work Around
N/A
Comments
N/A