Hi Girish,
OK, playing around with your bits in a practical sense, some comments
from the administrative point of view.
----------------------------------------------------
/usr/sbin/ipseckey
---
ipseckey> add tcpsig src 1.1.1.1
Need to define SPI for add. <-------
Need SA parameters for add.
Must have at least one key for an add.
Need destination address for add.
Here we don't actually need an SPI. If you enter it, it is ignored, or
really just changed to 0x0.
Further, if you try to add one as 0x0, you get an error:
ipseckey> add tcpsig src 1.1.1.1 dst 4.4.4.4 spi 0x0 authalg md5
authstring junk2
Invalid SPI value "0" .
---
I know this is in the design, but I'm curious about why dump/flush are
not supported. The current implementation requires that you know that
you already added a key in order to view or delete it. This doesn't
give any observability to the user. It seems like it would be a real
problem operationally.
---
Given the above design decision, the save subcommand should stop the
dump attempt from happening and give a better message.
ipseckey> save tcpsig
# This key file was generated by the ipseckey(1m) command's 'save' feature.
Diagnostic code 4: Unknown Security Association type. <---
ipseckey: Dump failed: Invalid argument
It's really unsupported, not unknown.
ipseckey> dump tcpsig
Diagnostic code 4: Unknown Security Association type.
ipseckey: Dump failed: Invalid argument
It is kind of a pre-existing condition, but really before anything is
printed, it should check that the SA type is esp or ah in dodump().
For instance:
ipseckey> save gobbledegook
Unknown SA type (gobbledegook).
# This key file was generated by the ipseckey(1m) command's 'save'
feature. <------
I think tcpsig deserves its own error message here, as it is a known SA
type, but not supported. Changes to dodump() fixes both of these.
---
update and update-pair are also unsupported, but they let me get pretty
far along attempting to update them. An error about update not being
supported would be helpful, especially because update appears to just do
an add.
ipseckey> update tcpsig src 1.1.1.1 dst 2.2.2.2 spi 0x666 authalg md5
authstring junk2
PF_KEY Diagnostic code 26: Duplicate SA extension.
ipseckey> delete tcpsig src 1.1.1.1 dst 2.2.2.2
ipseckey> update tcpsig src 1.1.1.1 dst 2.2.2.2 spi 0x666 authalg md5
authstring junk2
ipseckey> get tcpsig src 1.1.1.1 dst 2.2.2.2
Base message (version 2) type GET, SA type TCP Signature.
Message length 96 bytes, seq=19, pid=100991.
SA: SADB_ASSOC spi=0x0, replay=0, state=MATURE
SA: Authentication algorithm = <unknown 1>
SA: flags=0x0 < >
SRC: Source address (proto=0/<unspecified>)
SRC: AF_INET: port 0, 1.1.1.1 <unknown>.
DST: Destination address (proto=0/<unspecified>)
DST: AF_INET: port 0, 2.2.2.2 <unknown>.
AKY: Authentication key.
AKY: 6a756e6b32/40
ipseckey>
I probably shouldn't have been allowed to do that.
----
----------------------------------------------------------------
/usr/sbin/ipsecconf
----
If I understand correctly, you're supposed to add tcpsig rules with both
src and destination. Check this out:
# ipsecconf -q -a - << EOF
> {raddr 4.4.4.4} tcpsig {tcpsig_algs md5}
> {laddr 5.5.5.5} tcpsig {tcpsig_algs md5}
> EOF
And look what gets reported.
# ipsecconf -l
#INDEX 5
{ raddr /32 dir out } tcpsig { tcpsig_algs md5 sa shared }
#INDEX 7
{ laddr /32 dir out } tcpsig { tcpsig_algs md5 sa shared }
#INDEX 6
{ raddr /32 dir in } tcpsig { tcpsig_algs md5 sa shared }
#INDEX 8
{ laddr /32 dir in } tcpsig { tcpsig_algs md5 sa shared }
Actually, the ipsecconf -l output looks messed up like this in the
address fields even for good input:
# ipsecconf -q -a - << EOF
> {laddr 1.1.1.1 raddr 2.2.2.2} tcpsig {tcpsig_algs md5}
> EOF
# ipsecconf -l
#INDEX 9
{ laddr /32 raddr /32 dir out } tcpsig { tcpsig_algs md5 sa shared }
#INDEX 10
{ laddr /32 raddr /32 dir in } tcpsig { tcpsig_algs md5 sa shared }
If I use src and dst old style paired rules, I get the same result.
-----
In general the error checking for invalid input is very good here as far
as trying to mix ipsec and tcpsig components.
------
Thanks,
Paul
_______________________________________________
networking-discuss mailing list
[email protected]
