Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/n

2017-04-04 Thread Mike Tancsa
On 4/4/2017 7:18 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 13:55, Mike Tancsa wrote:
> 
> Yes, you need SA for both directions.
> 
>> The man page for setkey implies I only need one entry.
>>
>> Also, should the SPI always been the same, or unique ?
> 
> SPI is not used by this code, it only needed for compatibility with
> SADB. Better to use unique SPI for each SA, but for TCP-MD5 it will work
> anyway. :)
> 

Perhaps to the man pages, this small change ?

--- sbin/setkey/setkey.8.prev   2017-04-04 15:11:03.312911000 -0400
+++ sbin/setkey/setkey.82017-04-04 15:53:31.296152000 -0400
@@ -696,6 +696,7 @@
 Use TCP MD5 between two numerically specified hosts:
 .Bd -literal -offset indent
 add 10.1.10.34 10.1.10.36 tcp 0x1000 -A tcp-md5 "TCP-MD5 BGP secret" ;
+add 10.1.10.36 10.1.10.34 tcp 0x1000 -A tcp-md5 "TCP-MD5 BGP secret" ;
 .Ed
 .\"
 .Sh SEE ALSO

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/n

2017-04-04 Thread Mike Tancsa
On 4/4/2017 7:18 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 13:55, Mike Tancsa wrote:
>>> You have many SAs with the same destination address, it seems to me,
>>> that this should not work with old IPsec code, because it uses SA
>>> lookups using only destination address. So, if you have not the same
>>> password for each SA, it should not work.
>>>
>>> Can you try the attached patch?

Thanks, the patch works!  I am able to load all 42 rules now.  I am
going to test them in the lab against a few VMs prior to deployment.

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/n

2017-04-04 Thread Andrey V. Elsukov
On 04.04.2017 13:55, Mike Tancsa wrote:
>> You have many SAs with the same destination address, it seems to me,
>> that this should not work with old IPsec code, because it uses SA
>> lookups using only destination address. So, if you have not the same
>> password for each SA, it should not work.
>>
>> Can you try the attached patch?
>>
> 
> It did. In the past, inbound sigs I think just didnt work, but it was
> uninteresting for the purpose of this app.  In this case, it was for bgp

Yes, I checked stable/10 code, it seems TCP-MD5 always used one SA for
both inbound and outbound direction.

> passwords.  I was more concerned with sending the correct password to
> the peer.  So it was one source IP with many destination addresses (over
> a dozen). For the old config I just had the policy in one direction as
> well.  It seems now with the new ipsec code, I must have the policy in
> both directions ?

Yes, you need SA for both directions.

> The man page for setkey implies I only need one entry.
> 
> Also, should the SPI always been the same, or unique ?

SPI is not used by this code, it only needed for compatibility with
SADB. Better to use unique SPI for each SA, but for TCP-MD5 it will work
anyway. :)

-- 
WBR, Andrey V. Elsukov




signature.asc
Description: OpenPGP digital signature


Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/n

2017-04-04 Thread Mike Tancsa
On 4/4/2017 2:24 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 00:39, Mike Tancsa wrote:
> It seems you have encrypted your config, because I don't see IP with 128
> octets :)

:)

> 
> One question, does this even worked before?


> You have many SAs with the same destination address, it seems to me,
> that this should not work with old IPsec code, because it uses SA
> lookups using only destination address. So, if you have not the same
> password for each SA, it should not work.
>
> Can you try the attached patch?
>

It did. In the past, inbound sigs I think just didnt work, but it was
uninteresting for the purpose of this app.  In this case, it was for bgp
passwords.  I was more concerned with sending the correct password to
the peer.  So it was one source IP with many destination addresses (over
a dozen). For the old config I just had the policy in one direction as
well.  It seems now with the new ipsec code, I must have the policy in
both directions ?

The man page for setkey implies I only need one entry.

Also, should the SPI always been the same, or unique ?

compiling the patch now.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/n

2017-04-04 Thread Andrey V. Elsukov
On 04.04.2017 00:39, Mike Tancsa wrote:
> Hi,
>   I ran into a strange problem when migrating a box that makes use of tcp
> md5 signatures. Having these two policies that have IPs which happen to
> be 128 octets apart get rejected

It seems you have encrypted your config, because I don't see IP with 128
octets :)

One question, does this even worked before?
You have many SAs with the same destination address, it seems to me,
that this should not work with old IPsec code, because it uses SA
lookups using only destination address. So, if you have not the same
password for each SA, it should not work.

Can you try the attached patch?

-- 
WBR, Andrey V. Elsukov
Index: sys/netipsec/key.c
===
--- sys/netipsec/key.c	(revision 316434)
+++ sys/netipsec/key.c	(working copy)
@@ -863,7 +863,8 @@ key_allocsa_tcpmd5(struct secasindex *saidx)
 		kdebug_secash(sah, "  "));
 		if (sah->saidx.proto != IPPROTO_TCP)
 			continue;
-		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0))
+		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0) &&
+		!key_sockaddrcmp(>src.sa, >saidx.src.sa, 0))
 			break;
 	}
 	if (sah != NULL) {
@@ -4962,7 +4963,8 @@ key_getsav_tcpmd5(struct secasindex *saidx, uint32
 	LIST_FOREACH(sah, SAHADDRHASH_HASH(saidx), addrhash) {
 		if (sah->saidx.proto != IPPROTO_TCP)
 			continue;
-		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0))
+		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0) &&
+		!key_sockaddrcmp(>src.sa, >saidx.src.sa, 0))
 			break;
 	}
 	if (sah != NULL) {


signature.asc
Description: OpenPGP digital signature


Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/n

2017-04-03 Thread Mike Tancsa
Hi,
I ran into a strange problem when migrating a box that makes use of tcp
md5 signatures. Having these two policies that have IPs which happen to
be 128 octets apart get rejected


add 10.50.34.158 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

Similarly, if I have the entries

add 10.50.34.159 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

it errors out as well
# setkey -F ; setkey -FP ; setkey -F ; setkey -f test.ipsec.2
The result of line 2: File exists.
The result of line 4: File exists.

# cat test.ipsec.2
add 10.50.34.158 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
add 10.50.34.159 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

But if the IPs are not 128 apart, its fine

# cat test.ipsec.3
add 10.50.34.157 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
add 10.50.34.160 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

# setkey -F ; setkey -FP ; setkey -F ; setkey -f test.ipsec.3
#



On 3/18/2017 6:04 PM, Andrey V. Elsukov wrote:
> Author: ae
> Date: Sat Mar 18 22:04:20 2017
> New Revision: 315514
> URL: https://svnweb.freebsd.org/changeset/base/315514
> 
> Log:
>   MFC r304572 (by bz):
> Remove the kernel optoion for IPSEC_FILTERTUNNEL, which was deprecated
> more than 7 years ago in favour of a sysctl in r192648.
>   
>   MFC r305122:
> Remove redundant sanity checks from ipsec[46]_common_input_cb().
>   
> This check already has been done in the each protocol callback.
>   
>   MFC r309144,309174,309201 (by fabient):
> IPsec RFC6479 support for replay window sizes up to 2^32 - 32 packets.
>   
> Since the previous algorithm, based on bit shifting, does not scale
> with large replay windows, the algorithm used here is based on
> RFC 6479: IPsec Anti-Replay Algorithm without Bit Shifting.
> The replay window will be fast to be updated, but will cost as many bits
> in RAM as its size.
>   
> The previous implementation did not provide a lock on the replay window,
> which may lead to replay issues.
>   
> Obtained from:emeric.pou...@stormshield.eu
> Sponsored by: Stormshield
> Differential Revision:https://reviews.freebsd.org/D8468
>   
>   MFC r309143,309146 (by fabient):
> In a dual processor system (2*6 cores) during IPSec throughput tests,
> we see a lot of contention on the arc4 lock, used to generate the IV
> of the ESP output packets.
>   
> The idea of this patch is to split this mutex in order to reduce the
> contention on this lock.
>   
> Update r309143 to prevent false sharing.
>   
> Reviewed by:  delphij, markm, ache
> Approved by:  so
> Obtained from: emeric.pou...@stormshield.eu
> Sponsored by: Stormshield
> Differential Revision:https://reviews.freebsd.org/D8130
>   
>   MFC r313330:
> Merge projects/ipsec into head/.
>   
>  Small summary
>  -
>   
> o Almost all IPsec releated code was moved into sys/netipsec.
> o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel
>   option IPSEC_SUPPORT added. It enables support for loading
>   and unloading of ipsec.ko and tcpmd5.ko kernel modules.
> o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by
>   default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type
>   support was removed. Added TCP/UDP checksum handling for
>   inbound packets that were decapsulated by transport mode SAs.
>   setkey(8) modified to show run-time NAT-T configuration of SA.
> o New network pseudo interface if_ipsec(4) added. For now it is
>   build as part of ipsec.ko module (or with IPSEC kernel).
>   It implements IPsec virtual tunnels to create route-based VPNs.
> o The network stack now invokes IPsec functions using special
>   methods. The only one header file 
>   should be included to declare all the needed things to work
>   with IPsec.
> o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed.
>   Now these protocols are handled directly via IPsec methods.
> o TCP_SIGNATURE support was reworked to be more close to RFC.
> o PF_KEY SADB was reworked:
>   - now all security associations stored in the single SPI namespace,
> and all SAs MUST have unique SPI.
>   - several hash tables added to speed up lookups in SADB.
>   - SADB now uses rmlock to protect access, and concurrent threads
> can do SA lookups in the same time.
>   - many PF_KEY message handlers were reworked to reflect changes
> in SADB.
>   - SADB_UPDATE message was extended to support new PF_KEY headers:
>