Please see In-line.
Paul Wernau wrote:
> ---
>
> 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" .
>
Yes SPI is not required for TCP Signature SA type. The above error message
*Need to define SPI for add* -- should not actually appear. Will get rid
of it.
> ---
>
> 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.
>
The TCP signature module is not implemented as a STREAM module like
ipsecah or ipsecesp. Getting the dump/flush to work would involve major
duplication of the existing IPsec infrastructure. It will be tracked as
an RFE
and when we merge ipsecah/ipsecesp/keysock as one module we can then handle
this RFE elegantly.
> ---
>
> 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.
>
>
Thanks Paul. Haven taken care of it now.
> ---
>
> 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.
>
Actually *update* operation as per RFC 2367 cannot happen an a key
which is in a MATURE state. All the TCP Signature Keys are in MATURE
state to begin with and hence non relevance of Update.
Will modify the code to fail on using update for *tcpsig*.
> ----
>
> ----------------------------------------------------------------
>
> /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.
>
As you said itś known bug in the current IPsec infrastructure and you said
you will be raising a Bug for this. The workaround is to use the *-n*
option.
thanks
~Girish
_______________________________________________
networking-discuss mailing list
[email protected]
