IPSEC

IPSEC

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Hello!

I opened an overview about Linux IPSec implementations at
http://linux.schottelius.org/ipsec/
I would like to add recent kernel changes in IPSec to the site.
So it would be very nice if someone could forward
latest IPSec news to nico-ipsec@schottelius.org..do you think this is possible?

Greetings,

Nico

PS: please CC me.. I am not subscribed..


-- 
Please send your messages pgp-signed and/or pgp-encrypted (don't encrypt mails
to mailing list!). If you don't know what pgp is visit www.gnupg.org.
(public pgp key: ftp.schottelius.org/pub/familiy/nico/pgp-key)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: IPSEC

[Dax Kelson]

On Tue, 2003-07-08 at 06:40, Nico Schottelius wrote:
> Hello!
> 
> I opened an overview about Linux IPSec implementations at
> http://linux.schottelius.org/ipsec/
> I would like to add recent kernel changes in IPSec to the site.
> So it would be very nice if someone could forward
> latest IPSec news to nico-ipsec@schottelius.org..do you think this is possible?

The FreeSWAN/SuperFreeSWAN userland (IKE daemon, etc) has been ported to
work with the 2.5 kernel IPSec code.

Also, the 2.5 kernel IPSec code has been back ported to the 2.4 kernel
by David Miller (more??). It's in the Red Hat Linux rawhide kernel RPMs.

Dax Kelson
Guru Labs

IPsec

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Hi,

Does anyone have any experience with IPsec?  Preferably on Gentoo or 
Linux in general?

I'd like to discuss some things (probably off list) while wading into 
the IPsec pool.  E.g.:

  - ip xfrm ...
  - strongSwan
  - Libraswan
  - X.509 certificate based authentication, preferably /mutual/
  - Opportunistic Encryption
  - Transport Mode
  - Tunnel Mode



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

Re: IPsec

[Erik Auerswald]

Hi,

On Sun, Apr 04, 2021 at 07:54:50PM -0600, Grant Taylor wrote:
> 
> Does anyone have any experience with IPsec?  Preferably on Gentoo or
> Linux in general?

I have some experience with IPsec, mostly with non-Linux systems, but
a bit with Linux as well (but not Gentoo).  But it's been a while since
I last configured IPsec on a Linux system...

> I'd like to discuss some things (probably off list) while wading
> into the IPsec pool.  E.g.:
> 
>  - ip xfrm ...

This affects the kernel part of IPsec, i.e., bulk encryption and/or
integrity protection, only.

>  - strongSwan
>  - Libraswan

This is used to negotiate the parameters that are to be installed in the
kernel.

>  - X.509 certificate based authentication, preferably /mutual/
>  - Opportunistic Encryption

Since I have little experience with the above (back when I had to use
IKE version 1, so no *swan on the Linux side, and there were pre-shared
keys, and I never actually used "ip xfrm"), I can primarily help with
conceptual questions.

>  - Transport Mode
>  - Tunnel Mode

Use of one or the other depends on your requirements.

Thanks,
Erik
-- 
It's impossible to learn very much by simply sitting in a lecture,
or even by simply doing problems that are assigned.
                        -- Richard P. Feynman

IPSEC

[Steve Hill]

This might not be the right place for me to post (is there a better place 
to ask about ipsec problems using the 2.6 kernel's built in IPSEC 
support?).  Anyway, I'm hoping someone can help here:

I'm trying to connect 2 boxes together in transport mode using PSKs with 
Racoon (I'll migrate to X.509 certs and tunnel mode once I've got this 
working).  I'm on the 2.6.10 Fedora Core 3 kernel with Racoon 0.5 and I'm 
running in AH and ESP mode.  When the 2 machines set up the SAs with 
eachother, Racoon thinks everything's ok and logs that the ESP and AH 
sessions are established in both directions, however on one of the 
machines the SAD only contains 3 entries:

(this is setkey -D dumped from the machine with IP address "a.b.c.d"):

   a.b.c.d w.x.y.z
         esp mode=transport spi=230360363(0x0dbb052b) reqid=0(0x00000000)
         E: 3des-cbc  c3f07995 d878c486 55b181ee 15aa670d a4b96fc1 d4099a9c
         A: hmac-sha1  0533aed9 4591125c 6ae8e740 51f3b066 fc5222fc
         seq=0x00000000 replay=4 flags=0x00000000 state=mature
         created: Mar  8 17:05:19 2005   current: Mar  8 17:05:21 2005
         diff: 2(s)      hard: 3600(s)   soft: 2880(s)
         last:                           hard: 0(s)      soft: 0(s)
         current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
         allocated: 0    hard: 0 soft: 0
         sadb_seq=2 pid=3704 refcnt=0
   w.x.y.z a.b.c.d
         esp mode=transport spi=261919355(0x0f9c927b) reqid=0(0x00000000)
         E: 3des-cbc  b1051e37 4482da28 adc8aee8 92046dda 2c5e3dc1 11e62536
         A: hmac-sha1  ea69668e 42cbca96 22b0d941 6bfa5f2d bb39be74
         seq=0x00000000 replay=4 flags=0x00000000 state=mature
         created: Mar  8 17:05:19 2005   current: Mar  8 17:05:21 2005
         diff: 2(s)      hard: 3600(s)   soft: 2880(s)
         last:                           hard: 0(s)      soft: 0(s)
         current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
         allocated: 0    hard: 0 soft: 0
         sadb_seq=1 pid=3704 refcnt=0
   w.x.y.z a.b.c.d
         ah mode=transport spi=2363330(0x00240fc2) reqid=0(0x00000000)
         A: hmac-sha1  702e8bf2 1aa44422 0f46ae1d b213d871 4fc6c57b
         seq=0x00000000 replay=4 flags=0x00000000 state=mature
         created: Mar  8 17:05:19 2005   current: Mar  8 17:05:21 2005
         diff: 2(s)      hard: 3600(s)   soft: 2880(s)
         last:                           hard: 0(s)      soft: 0(s)
         current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
         allocated: 0    hard: 0 soft: 0
         sadb_seq=0 pid=3704 refcnt=0

As you can see, the outbound AH SA isn't in the SAD even though Racoon 
claims it's all fine.  Since this is reliably reproduced I have done some 
debugging on the kernel side but I've ended up rather confused.

During the negotiation, xfrm_state_add is successfully called for both 
outbound SAs.  I added some printk() statements to see what it was doing 
and ended up with:

   xfrm_state_add: Called with seq: 00e74298, Family: 2, seq 1, proto 51
   __xfrm_find_acq_byseq: Returned NULL
   __xfrm_state_insert: Called with seq: 00e74298
   xfrm_state_add: Called with seq: 0dbb052b, Family: 2, seq 1, proto 50
   __xfrm_find_acq_byseq: Returned 00e74298
   __xfrm_state_insert: Called with seq: 0dbb052b
   xfrm_state_delete: Called with seq: 00e74298

>From this logging it seems the AH SA has been added to the SAD ok, but 
then the ESP SA is added and it has the same sequence number (1) as the AH 
SA so the AH SA gets deleted.

The xfrm_state_add() function does:
         x1 = __xfrm_find_acq_byseq(x->km.seq);
         ...
         xfrm_state_delete(x1);
And this is responsible for deleting the AH SA due to it's matching 
sequence number.

I'm not sure what's at fault here - what generates the sequence number?  I 
presume from the checking that's done here that the sequence number is 
always expected to be unique, so it seems that either a unique sequence 
number is never being generated or Racoon is plain not using it.  (Correct 
me if I'm wrong here).

Any help would be appreciated - I've been battling with this problem for 
several days.  Thanks.

- Steve Hill (BSc)
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

Re: IPSEC

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

Steve Hill wrote:

> then the ESP SA is added and it has the same sequence number (1) as the 
> AH SA so the AH SA gets deleted.
> 
> The xfrm_state_add() function does:
>         x1 = __xfrm_find_acq_byseq(x->km.seq);
>         ...
>         xfrm_state_delete(x1);
> And this is responsible for deleting the AH SA due to it's matching 
> sequence number.

This is a bug in the kernel, __xfrm_find_acq_byseq should only return
XFRM_STATE_ACQ states. This patch should fix it.

Signed-off-by: Patrick McHardy <kaber@trash.net>

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 420 bytes --]

===== net/xfrm/xfrm_state.c 1.55 vs edited =====
--- 1.55/net/xfrm/xfrm_state.c	2005-03-07 06:23:53 +01:00
+++ edited/net/xfrm/xfrm_state.c	2005-03-08 18:42:13 +01:00
@@ -609,7 +609,7 @@
 
 	for (i = 0; i < XFRM_DST_HSIZE; i++) {
 		list_for_each_entry(x, xfrm_state_bydst+i, bydst) {
-			if (x->km.seq == seq) {
+			if (x->km.seq == seq && x->km.state == XFRM_STATE_ACQ) {
 				xfrm_state_hold(x);
 				return x;
 			}

Re: IPSEC

[Steve Hill]

On Tue, 8 Mar 2005, Patrick McHardy wrote:

> This is a bug in the kernel, __xfrm_find_acq_byseq should only return
> XFRM_STATE_ACQ states. This patch should fix it.

Thanks - just tested the patch against the current 2.6.10 Fedora 3 kernel 
and it works well.

- Steve Hill (BSc)
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

Re: IPSEC

[David S. Miller]

On Tue, 08 Mar 2005 18:44:39 +0100
Patrick McHardy <kaber@trash.net> wrote:

> Steve Hill wrote:
> 
> > then the ESP SA is added and it has the same sequence number (1) as the 
> > AH SA so the AH SA gets deleted.
> > 
> > The xfrm_state_add() function does:
> >         x1 = __xfrm_find_acq_byseq(x->km.seq);
> >         ...
> >         xfrm_state_delete(x1);
> > And this is responsible for deleting the AH SA due to it's matching 
> > sequence number.
> 
> This is a bug in the kernel, __xfrm_find_acq_byseq should only return
> XFRM_STATE_ACQ states. This patch should fix it.
> 
> Signed-off-by: Patrick McHardy <kaber@trash.net>

Applied, thanks Patrick.
 

IPSec

[latten]

I am configuring IPSec and was wondering are there
any plans to add AES to the crypto algorithms IPSec uses?

Joy

Re: IPSec

[James Morris]

On Fri, 10 Jan 2003 latten@austin.ibm.com wrote:

> I am configuring IPSec and was wondering are there
> any plans to add AES to the crypto algorithms IPSec uses?

AES CBC is supported with 2.5.56 (specify 'rijndael-cbc' for setkey).
AES counter mode is not yet supported.

Also, for those wanting to use Blowfish, you'll need the patch below 
against iputils-ss021109-try.


- James
-- 
James Morris
<jmorris@intercode.com.au>

diff -urN -X dontdif iputils/include-glibc/net/pfkeyv2.h iputils.w1/include-glibc/net/pfkeyv2.h
--- iputils/include-glibc/net/pfkeyv2.h	Sat Nov  9 13:45:52 2002
+++ iputils.w1/include-glibc/net/pfkeyv2.h	Sat Jan 11 11:19:45 2003
@@ -17,7 +17,7 @@
 
 /* private allocations - based on RFC2407/IANA assignment */
 #define SADB_X_EALG_CAST128CBC	5	/*6*/
-#define SADB_X_EALG_BLOWFISHCBC	4	/*7*/
+#define SADB_X_EALG_BLOWFISHCBC	7
 #define SADB_X_EALG_RIJNDAELCBC	12
 #define SADB_X_EALG_AES		12