ipsec-tools-devel — Development discussion of IPsec Tools

Re: [Ipsec-tools-devel] Documentation for PlainRSA Authentication

[<ma...@ne...>]

Simon Chang <sim...@gm...> wrote:

> 2)  This write-up talks about a few important options that are missing
> from the version 0.6.6 manpages for racoon.conf.  If someone could let
> me know how I can submit a more formal correction to the
> documentations, I would really appreciate it.

A diff -U against the man page is the best way of contributing a
documentation fix.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@ne...

[Ipsec-tools-devel] Documentation for PlainRSA Authentication

[Simon C. <sim...@gm...>]

Hi there,

I am new to this list and had started using racoon this past year at
my house as part of VPN over wireless.  In working with
racoon/ipsec-tools, however, I have noticed that there is very scant
documentation on how to do plain RSA authentication (there is adequate
amount of docs on pre-shared keys).  After consulting with Michal
Ludvig, the developer who initially coded in RSA support for version
0.4, I decided to write this documentation to help those people who
might be having similar issues as I did and to help out with the
project as a whole.

I have two requests for you, the list readers:

1)  Please let me know how I can improve on this documentation.  This
doc is based on my personal experience in setting up my own gears at
home, and I am not immune to "mental blind spots".  So please let me
know of anything I can do better.

2)  This write-up talks about a few important options that are missing
from the version 0.6.6 manpages for racoon.conf.  If someone could let
me know how I can submit a more formal correction to the
documentations, I would really appreciate it.

Without further ado, here is my "how-to" for plain RSA authentication.

=======================================

HOW-TO

I wrote this documentation in response to the fact that there is only
one sample file in the samples directory that gives any hint as to the
proper way of setting up ipsec-tools to use plain RSA keys for
authentication.  I had to email Michal Ludvig himself for assistance
(Michal is the original developer who coded in support for plain RSA
authentication).  Additionally, the manpage for racoon.conf itself is
missing a few necessary options.  So here is a step-by-step
description of the process.

Before you begin, you should understand that the RSA authentication
mechanism hinges upon the idea of a split cryptographic key:  one used
by the public, the other readable only to you.  Any data that is
encrypted by a public key can be decrypted only by the corresponding
private key, so that the private key user can be assured that the
content of the transmission has not been examined by unauthorized
parties.  Similarly, any data encrypted by the private key can be
decrypted by the public key so that the public knows that this
transmission came from this user and nobody else (this idea is called
non-repudiation).  Also, the longer the key length, the more difficult
it would be for potential attacker to conduct brute-force discovery of
the keys.  So, what all this means for the security administrator is
that the setup needs a pair of reasonably long keys for each host that
wishes to authenticate in this manner.

With this in mind, it should be relatively straightforward to set up
RSA authentication.  For the purpose of this document, we assume that
we are setting up RSA authentication between two networked hosts
called Boston and Chicago.  Unless otherwise noted, all steps should
be performed on both hosts with corresponding key names.  Here are the
steps:

1)  Included in each default installation of ipsec-tools is a binary
called plainrsa-gen.  This executable is used to generate a pair of
RSA keys for the host.  There are only two parameters that you should
be concerned about: -b, which sets the number of bits for the keys,
and -f, which specifies the output file for plainrsa-gen to send the
results.  On an ordinary Pentium-II with 128 MB of RAM, it takes only
seconds to generate keys that are 2048 bits long, and only slightly
longer to generate 4096-bit keys.  Either key length should be
sufficient; any longer key length actually reduces performance and
does not increase security significantly.  You should therefore run it
as:

	/usr/local/ipsec-tools/sbin/plainrsa-gen -b 2048 -f /var/tmp/boston.keys

2)  When the process completes, you should have a text file that
includes both public and private keys.  GUARD THIS FILE CAREFULLY,
because once a private key is compromised it is no longer any good,
and you must generate a new pair from scratch.  Reading the file
itself, you should see several very long lines of alphanumeric data.
The only line you should be concerned with is the line towards the top
of the output file that begins with "# pubkey=0sAQPAmBdT/" or
something to that effect.  This line is your public key, which should
be made available to the other host that you are setting up.  Copy
this line to a separate file called "boston.pub" and change the
beginning of the line so that it reads ": PUB 0sAQPAmBdT/".
Alternatively, you can also grab the first line of the boston.keys
file and uncomment the line so that it reads the same as above.  Now
rename the file you generated initially to "boston.priv".

3)  You should now have two files, boston.priv and boston.pub
(chicago.priv and chicago.pub on Chicago).  The first file contains
your private key and the second file your public key.  Next you should
find a way to get the public key over to the other host involved.
Boston should have (1) its own key pair, and (2) Chicago's public key
ONLY.  Do not copy Chicago's private key over to Boston, because (a)
it is not necessary, and (b) you would now have two potential places
for losing control of your private key.

4)  You should now configure the racoon.conf configuration file for
each host to (a) turn on RSA authentication, and (b) designate each
host's private key and the remote host(s)'s public key(s).  Take all
your keys and place it in one directory and use the global directive
"path certificate" to specify the location of the keys.  This step is
especially important if you are running racoon with privilege
separation, because if racoon cannot find the keys inside the
directory you have just specified it will fail the authentication
process.  So, write the directive like the following:

	path certificate "/usr/local/ipsec-tools/var/racoon" ;

Next, you need to specify the host's own private key and the public
keys of all the remote peers involved.  Now, the manpages for
racoon.conf are missing several options under the Remote Node
Specifications section, all of which are critical to making this setup
work.  For your local private key and remote public key(s), you should
use the following directives:

	certificate_type plain_rsa "/usr/local/ipsec-tools/var/racoon/boston.priv";
	peers_certfile plain_rsa "/usr/local/ipsec-tools/var/racoon/chicago.pub";

Notice the option "plain_rsa" for both directives.

Finally, under the "proposal" statement section, you should specify
the "rsasig" option for "authentication_method".

5)  You have finished configuring the host for RSA authentication.
Now use racoonctl to reload the configuration or simply restart the
machine and you should be all set.

TROUBLESHOOTING

In the event that the hosts fail to communicate, first go back to the
instructions above and make sure that:

1)  You have placed all the keys in the directory that is specified by
the "path certificate" directive.  Keep in mind that privilege
separation will force racoon to look into that directory and nowhere
else.
2)  You have specified correctly the host's own private key and the
remote peer's public key.
3)  You have specified the "rsasig" method for authentication in the
proposal statement.

If you run into any further problems, you should try to use "racoon
-v" to debug the setup, and send a copy of the debug messages to the
mailing list so that we can help you determine what the problem is.

If you have any questions or comments about this document, email
sim...@gm....

-Last modified:  November 30, 2006

Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[Darrel G. <dgo...@tr...>]

Matthew Grooms wrote:

<snip>

> If you don't mind me asking, how does this cause a consistency problem
> when interfacing with the NetBSD kernel? Can ipsec-tools not rely on a
> set of NATT port extensions being returned as part of an SA for some
> platforms that also support NATT?

Here is what I found checking out the kernel code for the pfkey socket on
NetBSD and Linux (please keep in mind that this was not an exhaustive
analysis).

For SADB_ADDs and SADB_UPDATEs, the NetBSD kernel is taking the NATT port
information from the SADB_X_EXT_NAT_T_*PORT blobs and storing it in the
src and dst sockaddr port fields.  For SADB_DUMPs and SADB_GETSs, the NATT
port info from the SAa src and dst sockaddrs is returned via the
SADB_X_EXT_NAT_T_*PORT, in addition to still being in the sockaddrs.

On the other hand, Linux has a different place to store the NATT port
information.  It never lives in the SAa sockaddrs, this never gets returned
via that mechanism.  The NATT port info is handled only by the
SADB_X_EXT_NAT_T_*PORT blobs.

The ipsec-tools code seems to be expecting that the NATT port info is
contained within the src and dst addrs.

> 
>>>For what its worth, I think your patch contains the correct approach. 
>>
>>I had a very quick look at it. It will fix the Linux issue, but will
>>break again some configurations on Net/FreeBSD.
>>
> 
> 
> I should look at that patch again after its applied.

I think I have a better one now, read on :)

>>>I'm just wondering if this couldn't be solved at the libipsec level so 
>>>we don't have to include multiple special cases throughout racoon. I'm 
>>>sure Manu and Yvan will chime in as they have quite a bit more NATT 
>>>knowhow than I do.
>>
>>We will always need a CMPSADDR macro, because in racoon, if we support
>>multiple peers behind the same IP, the ports info is stored in the
>>addess structs.
>>
>>But at pfkey level, some cleanup is needed !
>>
> 
> 
> In my head, the suggestion was that the next lower pfkey API call could
> be possibly modified to return the data in a consistent fashion so that
> special casing the use of CMPSADDR could be avoided. I apparently don't
> understand the problem completely ( or the scope of libipsec ) :)

That sure seemed like a good idea to me as well.  The following patch get as
close as it can to the actual SA dump as it can in racoon and modifies the port
information there to meet the assumption in the rest of the code.  I'm sure
that there is cleaner way to do this, but I am not wanting to change to much of
the code at this point to get things working in my environment.  I'd appreciate
any feedback on this approach (and thanks again for the help so far).
It seems to be doing the trick for me here.  Note that this only "fixes" racoon,
I have not modified the code that setkey uses to display the SAs information.

--

Darrel


diff --git a/src/racoon/pfkey.c b/src/racoon/pfkey.c
index d775aa4..b3a003b 100644
--- a/src/racoon/pfkey.c
+++ b/src/racoon/pfkey.c
@@ -326,6 +326,54 @@ pfkey_dump_sadb(satype)
 				"failed to reallocate buffer to dump.\n");
 			goto fail;
 		}
+
+#if defined(__linux__) && defined(SADB_X_EXT_NAT_T_TYPE)
+		/*
+		 * NetBSD returns the NAT-T ports in the src and dst sockaddrs
+		 * in addition to the SADB_X_EXT_NAT_T_*PORT structs.
+		 *
+		 * Linux only returns them in the SADB_X_EXT_NAT_T_*PORT
+		 * structs.  The racoon codebase is making the assumption that
+		 * the NAT-T ports are reflected by the ports in the src and
+		 * dst sockaddrs.  We stick that information into those structs
+		 * here to meet the assumptions elsewhere.
+		 */
+		{
+		caddr_t mhp[SADB_EXT_MAX + 1];
+		struct sadb_sa *sa;
+		struct sockaddr *src, *dst;
+		struct sadb_x_nat_t_type *natt_type;
+		struct sadb_x_nat_t_port *natt_port;
+
+		if (pfkey_align(msg, mhp) || pfkey_check(mhp)) {
+			plog(LLV_ERROR, LOCATION, NULL,
+				"pfkey_check (%s)\n", ipsec_strerror());
+			break;
+		}
+
+		sa = (struct sadb_sa *)(mhp[SADB_EXT_SA]);
+		if (!sa ||
+		    !mhp[SADB_EXT_ADDRESS_SRC] ||
+		    !mhp[SADB_EXT_ADDRESS_DST]) {
+			break;
+		}
+
+		src = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_SRC]);
+		dst = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_DST]);
+
+		natt_type = (struct sadb_x_nat_t_type *)(mhp[SADB_X_EXT_NAT_T_TYPE]);
+
+		if (natt_type && natt_type->sadb_x_nat_t_type_type) {
+			/* fake up the src port */
+			natt_port = (struct sadb_x_nat_t_port *)(mhp[SADB_X_EXT_NAT_T_SPORT]);
+			((struct sockaddr_in *)src)->sin_port = natt_port->sadb_x_nat_t_port_port;
+			/* fake up the dst port */
+			natt_port = (struct sadb_x_nat_t_port *)(mhp[SADB_X_EXT_NAT_T_DPORT]);
+			((struct sockaddr_in *)dst)->sin_port = natt_port->sadb_x_nat_t_port_port;
+		}
+		}
+#endif /* __linux__ && SADB_X_EXT_NAT_T_TYPE */
+
 		memcpy(buf->v + bl, msg, ml);
 
 		if (msg->sadb_msg_seq == 0)

Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[<ma...@ne...>]

Darrel Goeddel <dgo...@tr...> wrote:

> Can you point me to that patch please?  A pointer the the NetBSD code may
> be helpful as well.

Look for IPSEC_NAT_T in the source tree:

src/sys/netinet/udp_usrreq.c:udp4_realinput()
 -> This is the IPv4 UDP input function. Here we check if the socket was
set with ESP over UDP. If it was, then we call udp4_espinudp()

src/sys/netinet/udp_usrreq.c:udp4_espinudp()
 -> Ignore NAT-T keepalives
 -> If it does not has the non IKE marker, go back to normal UDP
processing
 -> Get the port information and attach it to the mbuf chain with a tag
 -> Remove the UDP header from the packet
 -> Call esp4_input()

src/sys/netinet6/esp_input.c:esp4_input()
 -> This is the IPv4 ESP input function. Here we retreive the ports from
the mbuf tag, and we use them for looking up the SA.

You can look for the output path in src/sys/netinet6/esp_output.c, but
it's much more simple.

The ugly stuff happens when we have to lookup the SA.
  
-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@ne...

Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[Darrel G. <dgo...@tr...>]

VANHULLEBUS Yvan wrote:
> On Tue, Nov 28, 2006 at 10:20:34PM -0600, Matthew Grooms wrote:
> [....]
> 
>>If I understand the problem correctly, the ports are being compared 
>>because there may be multiple peers behind a NAT device which share the 
>>same address but will have different translated ports specified. If the 
>>comparison is performed without the ports, you could potentially remove 
>>SAs that are still valid and in use.
> 
> 
> Exactly.

Yeah, I made sure that actually worked with the patch I sent.  Not that I
can actually get two initiators behind the same NAT to talk to the same
responder, but I could at least get them to negotiate SAs on different
encapsulation ports (data on the first initiator is disappearing in the
stack somewhere...).  If anyone has successfully run with two initiators
behind the same NAT talking to the same responder on the other side of
the NAT, (all on Linux) feel free to drop me an email - I'd love to talk :)

> 
>>My guess is that there is a subtle platform difference when dumping sad 
>>entries where BSD returns the NATT ports as part of the sadb_address 
>>extension and Linux returns 0 values. This would explain why the 
>>CMPSADDR would cause problems on Linux but not on BSD.
> 
> 
> The difference is that NetBSD and FreeBSD (with a patch I maintain)
> have some code on kernel size to handle the ports issue.

Can you point me to that patch please?  A pointer the the NetBSD code may
be helpful as well.

> However, some people raised issues with the way the ports are
> exchanged between kernel and userland, which seems to generate
> problems for Linux stack.
> 
> I know that, have to fix it as soon as possible, but it is not a small
> issue (I'll have to fix all pfkey commands on userland, have a
> complete check of all cmp*addr* uses, will have to do quite the same
> think on all three IPSec stacks, then we'll have the compatibility
> problem with actuel NetBSD kernels (FreeBSD is not so much a problem,
> as the feature is actually a separate patch, not provided with the
> official releases).
> 
> And my TODO list is as big as usual.....

IIUC, the ipsec-tools code assumes that the ports in the sockaddrs for
*all* SAs refer to the isakmp port being used?  Even in the case where
there is no NAT traversal being used (always isakmp on 500)?  If that
is the case, I will see what I can do to doctor ports at dump time in
libipsec and setkey.  If the dump contains the same info on all platforms,
I think my problem should be solved since it apparently is working on
the some BSDs.

I should gain a better understanding of this once I check out the
implementations in the 3 kernels.

Thanks for the help so far.

> 
>>For what its worth, I think your patch contains the correct approach. 
> 
> 
> I had a very quick look at it. It will fix the Linux issue, but will
> break again some configurations on Net/FreeBSD.
> 
> The fist stet to fix the issue would be to be able to determine, at
> compile time, for which kind of kernel we'll have to run:
> 
> - No NATT support
> - NAT-T support "a la Linux" (and I don't know exactly if this stack
>   does something specific for ports)
> - NAT-T "a la NetBSD" (with the actual way of sending ports
>   information between kernel/userland).
> - NAT-T with the future "clean" implementation (using PFKey extensions
>   SADB_X_EXT_NAT_T_*).
> 
> Then we could at least have an appropriate CMPSADDR macro for each
> situation, and a few other defines to help fixing all actual
> configurations.
> 
> 
> 
>>I'm just wondering if this couldn't be solved at the libipsec level so 
>>we don't have to include multiple special cases throughout racoon. I'm 
>>sure Manu and Yvan will chime in as they have quite a bit more NATT 
>>knowhow than I do.
> 
> 
> We will always need a CMPSADDR macro, because in racoon, if we support
> multiple peers behind the same IP, the ports info is stored in the
> addess structs.
> 
> But at pfkey level, some cleanup is needed !
> 
> 
> Yvan.
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel


-- 

Darrel

Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[Matthew G. <mg...@sh...>]

VANHULLEBUS Yvan wrote:

Thanks. This is very educational so I hope you don't mind me picking
your brain here with a few more questions.

> On Tue, Nov 28, 2006 at 10:20:34PM -0600, Matthew Grooms wrote:
> 
>> My guess is that there is a subtle platform difference when dumping sad 
>> entries where BSD returns the NATT ports as part of the sadb_address 
>> extension and Linux returns 0 values. This would explain why the 
>> CMPSADDR would cause problems on Linux but not on BSD.
> 
> The difference is that NetBSD and FreeBSD (with a patch I maintain)
> have some code on kernel size to handle the ports issue.
> 
> However, some people raised issues with the way the ports are
> exchanged between kernel and userland, which seems to generate
> problems for Linux stack.
> 

Were the issues raised related to the reliance of NATT port values being
returned in the sadb_address or is the problem more involved?

> I know that, have to fix it as soon as possible, but it is not a small
> issue (I'll have to fix all pfkey commands on userland, have a
> complete check of all cmp*addr* uses, will have to do quite the same
> think on all three IPSec stacks, then we'll have the compatibility
> problem with actuel NetBSD kernels (FreeBSD is not so much a problem,
> as the feature is actually a separate patch, not provided with the
> official releases).
> 

If you don't mind me asking, how does this cause a consistency problem
when interfacing with the NetBSD kernel? Can ipsec-tools not rely on a
set of NATT port extensions being returned as part of an SA for some
platforms that also support NATT?

>> For what its worth, I think your patch contains the correct approach. 
> 
> I had a very quick look at it. It will fix the Linux issue, but will
> break again some configurations on Net/FreeBSD.
> 

I should look at that patch again after its applied.

>> I'm just wondering if this couldn't be solved at the libipsec level so 
>> we don't have to include multiple special cases throughout racoon. I'm 
>> sure Manu and Yvan will chime in as they have quite a bit more NATT 
>> knowhow than I do.
> 
> We will always need a CMPSADDR macro, because in racoon, if we support
> multiple peers behind the same IP, the ports info is stored in the
> addess structs.
> 
> But at pfkey level, some cleanup is needed !
> 

In my head, the suggestion was that the next lower pfkey API call could
be possibly modified to return the data in a consistent fashion so that
special casing the use of CMPSADDR could be avoided. I apparently don't
understand the problem completely ( or the scope of libipsec ) :)

Thanks again,

-Matthew

Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[VANHULLEBUS Y. <va...@fr...>]

On Tue, Nov 28, 2006 at 10:20:34PM -0600, Matthew Grooms wrote:
[....]
> If I understand the problem correctly, the ports are being compared 
> because there may be multiple peers behind a NAT device which share the 
> same address but will have different translated ports specified. If the 
> comparison is performed without the ports, you could potentially remove 
> SAs that are still valid and in use.

Exactly.


> My guess is that there is a subtle platform difference when dumping sad 
> entries where BSD returns the NATT ports as part of the sadb_address 
> extension and Linux returns 0 values. This would explain why the 
> CMPSADDR would cause problems on Linux but not on BSD.

The difference is that NetBSD and FreeBSD (with a patch I maintain)
have some code on kernel size to handle the ports issue.

However, some people raised issues with the way the ports are
exchanged between kernel and userland, which seems to generate
problems for Linux stack.

I know that, have to fix it as soon as possible, but it is not a small
issue (I'll have to fix all pfkey commands on userland, have a
complete check of all cmp*addr* uses, will have to do quite the same
think on all three IPSec stacks, then we'll have the compatibility
problem with actuel NetBSD kernels (FreeBSD is not so much a problem,
as the feature is actually a separate patch, not provided with the
official releases).

And my TODO list is as big as usual.....


> For what its worth, I think your patch contains the correct approach. 

I had a very quick look at it. It will fix the Linux issue, but will
break again some configurations on Net/FreeBSD.

The fist stet to fix the issue would be to be able to determine, at
compile time, for which kind of kernel we'll have to run:

- No NATT support
- NAT-T support "a la Linux" (and I don't know exactly if this stack
  does something specific for ports)
- NAT-T "a la NetBSD" (with the actual way of sending ports
  information between kernel/userland).
- NAT-T with the future "clean" implementation (using PFKey extensions
  SADB_X_EXT_NAT_T_*).

Then we could at least have an appropriate CMPSADDR macro for each
situation, and a few other defines to help fixing all actual
configurations.


> I'm just wondering if this couldn't be solved at the libipsec level so 
> we don't have to include multiple special cases throughout racoon. I'm 
> sure Manu and Yvan will chime in as they have quite a bit more NATT 
> knowhow than I do.

We will always need a CMPSADDR macro, because in racoon, if we support
multiple peers behind the same IP, the ports info is stored in the
addess structs.

But at pfkey level, some cleanup is needed !


Yvan.

Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[Matthew G. <mg...@sh...>]

Darrel Goeddel wrote:
> 
> In the case that it should be checking phase1 ports against the encapsulation
> port of the phase2, I have included a patch below that addresses two instances
> where the change should occur.  These two changes alleviate the problems that were
> standing in my way, but I suspect that the other invocations of CMPSADDR should
> also be examined.  I'd appreciate any feedback on the approach, including the
> possibility that we are way off on what I think is/should be happening.  It may
> be that I am just confused about the way ports are being treated...  In the case
> of the latter, I'd appreciate a schooling on what racoon is doing.
> 

If I understand the problem correctly, the ports are being compared 
because there may be multiple peers behind a NAT device which share the 
same address but will have different translated ports specified. If the 
comparison is performed without the ports, you could potentially remove 
SAs that are still valid and in use.

My guess is that there is a subtle platform difference when dumping sad 
entries where BSD returns the NATT ports as part of the sadb_address 
extension and Linux returns 0 values. This would explain why the 
CMPSADDR would cause problems on Linux but not on BSD.

For what its worth, I think your patch contains the correct approach. 
I'm just wondering if this couldn't be solved at the libipsec level so 
we don't have to include multiple special cases throughout racoon. I'm 
sure Manu and Yvan will chime in as they have quite a bit more NATT 
knowhow than I do.

-Matthew

Re: [Ipsec-tools-devel] HowTo Enable Dead Peer Detection

[Matthew G. <mg...@sh...>]

Gordon Zeng wrote:
> I'm using Transport Mode to create IPSEC connection between two hosts.  
> When I enabled the Dead Peer Detection, racoon debug would give me the 
> ERROR message "DPD support not compiled in" I have the following 
> contents as my racoon.conf:
> 

If you are using a pre-compiled binary, it is possible that it was not
built with dpd support. The --enable-dpd option must be specified on the
configure command when compiling from source.

-Matthew

[Ipsec-tools-devel] HowTo Enable Dead Peer Detection

[Gordon Z. <gor...@ho...>]

I'm using Transport Mode to create IPSEC connection between two hosts.  
When I enabled the Dead Peer Detection, racoon debug would give me the 
ERROR message "DPD support not compiled in" I have the following contents 
as my racoon.conf:

 

timer

{

         phase1     30 sec;

         phase2     20 sec;

}

 

 

remote anonymous

{

         exchange_mode main;

 

         my_identifier     address;

 

         lifetime time 15 min;          #sec,min,hour

         proposal_check obey;       #obey, strict, or claim

 

         dpd_delay         10;

         dpd_retry  5;

         dpd_maxfail 5;

 

         proposal

         {

                   encryption_algorithm        des;           

                   hash_algorithm        md5;         

                   authentication_method     pre_shared_key;

                   dh_group 1;

         }        

}

 

sainfo anonymous

{

         lifetime time 30 min;

         encryption_algorithm des;                  #3des

         authentication_algorithm hmac_md5;                #hmac_sha1;   

         compression_algorithm deflate;

}

 

Thanks in advance!

 

Gordon

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  

Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[Darrel G. <dgo...@tr...>]

Venkat Yekkirala wrote:
> Hello,
> 
> When we use NAT-Traversal with racoon on Linux 2.6.18
> we encounter a problem with the SAs not getting purged
> when the peer racoon goes down. Specifically, the following
> logic doesn't seem to be using the SA ports to compare them
> to the Phase1 ports while it seems like it should actually
> use the encap ports that are tied to the SA when comparing
> with the Phase1 ports.

To add a bit more information...  We are experiencing this behavior with
linux kernels from 2.6.14 - 2.6.18.  It also makes no difference whether or
not we are actually using NAT-T - it is simply a matter of compiling in the
support for NAT-T that causes the problem.

> In purge_remote():
> 
>                 /* check in/outbound SAs */
>                 if ((CMPSADDR(iph1->local, src) ||
> CMPSADDR(iph1->remote, dst)) &&
>                         (CMPSADDR(iph1->local, dst) ||
> CMPSADDR(iph1->remote, src))) {
>                         msg = next;
>                         continue;
>                 }

Without ENABLE_NATT, the above comparisons are using cmpsaddrwop (compares
addresses without ports).  This allows the IPsec-SAs associated with an
ISAKMP-SA to be purged along with the ISAKMP-SA.  I'm hoping that is the
correct behavior because that is indeed the behavior that we like ;)  When
ENABLE_NATT is defined, the comparison is changed to include the ports of
the SAs.  As Venkat mentioned, that is a comparison of the isakmp port (from
the ISAKMP-SA) and the ports specified in the IPsec-SA.  This port comparison
always fails because the IPsec-SAs always have the ports set to 0 (so we are
comparing 500 to 0 in the "normal" case).  If a remote goes down, we flush the
phase1 SA, but not the phase2 SAa because the ports do not match.  When the
remote comes back, we are still trying to use the old phase2s and communication
is never restored (in the not ENABLE_NATT case, communication is restored
because a new set of IPsec SAs are negotiated).  DPD monitoring is also
affected because it uses purge_remote to delete SAs from a dead peer.

> 
> The above boils down to a cmpsaddrstrict() comparison
> of the Phase1 address/port to the SA address/port. But
> shouldn't it really be between the Phase1 address/port
> to the SA address/encap_port?

In the case that it should be checking phase1 ports against the encapsulation
port of the phase2, I have included a patch below that addresses two instances
where the change should occur.  These two changes alleviate the problems that were
standing in my way, but I suspect that the other invocations of CMPSADDR should
also be examined.  I'd appreciate any feedback on the approach, including the
possibility that we are way off on what I think is/should be happening.  It may
be that I am just confused about the way ports are being treated...  In the case
of the latter, I'd appreciate a schooling on what racoon is doing.

diff --git a/src/racoon/isakmp.c b/src/racoon/isakmp.c
index d8b529c..452b6c1 100644
--- a/src/racoon/isakmp.c
+++ b/src/racoon/isakmp.c
@@ -3085,6 +3085,9 @@ purge_remote(iph1)
 	u_int proto_id;
 	struct ph2handle *iph2;
 	struct ph1handle *new_iph1;
+#if defined(ENABLE_NATT) && defined(SADB_X_EXT_NAT_T_TYPE)
+	struct sadb_x_nat_t_type *natt_type;
+#endif /* ENABLE_NATT && SADB_X_EXT_NAT_T_TYPE */
 
 	plog(LLV_INFO, LOCATION, NULL,
 		 "purging ISAKMP-SA spi=%s.\n",
@@ -3144,12 +3147,35 @@ purge_remote(iph1)
 		}
 
 		/* check in/outbound SAs */
-		if ((CMPSADDR(iph1->local, src) || CMPSADDR(iph1->remote, dst)) &&
-			(CMPSADDR(iph1->local, dst) || CMPSADDR(iph1->remote, src))) {
+		if ((cmpsaddrwop(iph1->local, src) || cmpsaddrwop(iph1->remote, dst)) &&
+			(cmpsaddrwop(iph1->local, dst) || cmpsaddrwop(iph1->remote, src))) {
 			msg = next;
 			continue;
 		}
 
+#if defined(ENABLE_NATT) && defined(SADB_X_EXT_NAT_T_TYPE)
+		/* check the isakmp port of the in/outbound SAs */
+		natt_type = (void *)mhp[SADB_X_EXT_NAT_T_TYPE];
+
+		if (natt_type && natt_type->sadb_x_nat_t_type_type) {
+			struct sadb_x_nat_t_port *natt_sport, *natt_dport;
+			u_short ph1_lp, ph1_rp, natt_sp, natt_dp;
+
+			natt_sport = (void *)mhp[SADB_X_EXT_NAT_T_SPORT];
+			natt_dport = (void *)mhp[SADB_X_EXT_NAT_T_DPORT];
+			natt_sp = natt_sport->sadb_x_nat_t_port_port;
+			natt_dp = natt_dport->sadb_x_nat_t_port_port;
+			ph1_lp = ((struct sockaddr_in *)iph1->local)->sin_port;
+			ph1_rp = ((struct sockaddr_in *)iph1->remote)->sin_port;
+	
+			if ((ph1_lp != natt_sp || ph1_rp != natt_dp) &&
+			    (ph1_lp != natt_dp || ph1_rp != natt_sp)) {
+				msg = next;
+				continue;
+			}
+		}
+#endif /* ENABLE_NATT && SADB_X_EXT_NAT_T_TYPE */
+
 		proto_id = pfkey2ipsecdoi_proto(msg->sadb_msg_satype);
 		iph2 = getph2bysaidx(src, dst, proto_id, sa->sadb_sa_spi);
 
diff --git a/src/racoon/isakmp_inf.c b/src/racoon/isakmp_inf.c
index 9112bfd..65c7ce8 100644
--- a/src/racoon/isakmp_inf.c
+++ b/src/racoon/isakmp_inf.c
@@ -967,6 +967,9 @@ purge_ipsec_spi(dst0, proto, spi, n)
 	struct ph2handle *iph2;
 	size_t i;
 	caddr_t mhp[SADB_EXT_MAX + 1];
+#ifdef SADB_X_EXT_NAT_T_TYPE
+	struct sadb_x_nat_t_type *natt_type;
+#endif /* ENABLE_NATT && SADB_X_EXT_NAT_T_TYPE */
 
 	buf = pfkey_dump_sadb(ipsecdoi2pfkey_proto(proto));
 	if (buf == NULL) {
@@ -1014,11 +1017,29 @@ purge_ipsec_spi(dst0, proto, spi, n)
 
 		/* don't delete inbound SAs at the moment */
 		/* XXX should we remove SAs with opposite direction as well? */
-		if (CMPSADDR(dst0, dst)) {
+		if (cmpsaddrwop(dst0, dst)) {
 			msg = next;
 			continue;
 		}
 
+#if defined(ENABLE_NATT) && defined(SADB_X_EXT_NAT_T_TYPE)
+		/* check the isakmp port of the in/outbound SAs */
+		natt_type = (void *)mhp[SADB_X_EXT_NAT_T_TYPE];
+
+		if (natt_type && natt_type->sadb_x_nat_t_type_type) {
+			struct sadb_x_nat_t_port *natt_dport;
+			u_short dp, natt_dp;
+
+			natt_dport = (void *)mhp[SADB_X_EXT_NAT_T_DPORT];
+			dp = ((struct sockaddr_in *)dst0)->sin_port;
+			natt_dp = natt_dport->sadb_x_nat_t_port_port;
+			if (dp != natt_dp) {
+				msg = next;
+				continue;
+			}
+		}
+#endif /* ENABLE_NATT && SADB_X_EXT_NAT_T_TYPE */
+
 		for (i = 0; i < n; i++) {
 			plog(LLV_DEBUG, LOCATION, NULL,
 				"check spi(packet)=%u spi(db)=%u.\n",

-- 

Darrel

Re: [Ipsec-tools-devel] [PATCH 1/2]: allow racoon to use security contexts

[Joy L. <la...@au...>]

OK, I will give this a try. I will send a patch as soon as I can.
If I run into a few questions, I will send you some email.

Regards,
Joy 

On Tue, 2006-11-28 at 06:54 +0100, Emmanuel Dreyfus wrote:
> Joy Latten <la...@au...> wrote:
> 
> > I was wondering if anyone had gotten a chance to take a look at this patch
> > and if there were any review comments. I'd be happy to help in any way
> > that I can. I can also re-submit the patch. :-)
> 
> Well, I wanted to make a little improvement but found no time for that.
> Indeed you can help.
> 
> You added even more arguments to pfkey_send_update() and friends. That
> has a minor cost, which is a plain loss to systems not using security
> contexts.
> 
> A better way would be to change the fonction prototype so that they get
> a struct, and have the security context part of the struct being ifdef
> HAVE_SECCTX. Similarily, other parts of the struct shoulf be ifdef for
> NAT-T, IKE Frag and so on, but I bet we can keep that for later, as it
> makes the change really bigger. 
> 

Re: [Ipsec-tools-devel] [PATCH 1/2]: allow racoon to use security contexts

[<ma...@ne...>]

Joy Latten <la...@au...> wrote:

> I was wondering if anyone had gotten a chance to take a look at this patch
> and if there were any review comments. I'd be happy to help in any way
> that I can. I can also re-submit the patch. :-)

Well, I wanted to make a little improvement but found no time for that.
Indeed you can help.

You added even more arguments to pfkey_send_update() and friends. That
has a minor cost, which is a plain loss to systems not using security
contexts.

A better way would be to change the fonction prototype so that they get
a struct, and have the security context part of the struct being ifdef
HAVE_SECCTX. Similarily, other parts of the struct shoulf be ifdef for
NAT-T, IKE Frag and so on, but I bet we can keep that for later, as it
makes the change really bigger. 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@ne...

Re: [Ipsec-tools-devel] [PATCH 1/2]: allow racoon to use security contexts

[Joy L. <la...@au...>]

>Joy Latten <la...@au...> wrote:
>
>>  int pfkey_send_update __P((int, u_int, u_int, struct sockaddr *,
>>       struct sockaddr *, u_int32_t, u_int32_t, u_int,
>>       caddr_t, u_int, u_int, u_int, u_int, u_int, u_int32_t, u_int64_t,
>> -     u_int64_t, u_int64_t, u_int32_t));
>> +     u_int64_t, u_int64_t, u_int32_t,
>> +     u_int8_t, u_int8_t, caddr_t, u_int16_t));
>
>I'll take care of your patch, but I have a concern about pfkey_*
>arguments: the list is getting insane. At some point we will have to
>pass a pointer to a struct instead of such a bunch of arguments. The
>question is: before forking the 0.7 branch or after?
>
>Anyone has an opinion?

I was wondering if anyone had gotten a chance to take a look at this patch
and if there were any review comments. I'd be happy to help in any way 
that I can. I can also re-submit the patch. :-)

Regards,
Joy

Re: [Ipsec-tools-devel] Cryptography

[Marcelo M. <mar...@gm...>]

Thanks a lot for all the answers.
Now I will look at kernel. Then I will change the parser. Is it easier to
change the parser using flex or manually?

Best Regards.
Marcelo

2006/11/25, Kimmo Koivisto <ko...@gm...>:
>
> On Saturday 25 November 2006 22:38, Marcelo Marleta wrote:
> > Ipsec-tools calls an cryptographyc algorithm to do authentication and
> > encryption/decryption of the packets.
>
> Only true for IKE but not for encrypting or decrypting ESP data, and ESP
> is
> what you want.
>
> Read Matthew's post and try to understand what racoon and setkey do and
> what
> kernel does in IPsec.
>
> > I want that  Ipsec-tools calls MY cryptographic algorithm.
>
> Wrong, you want to kernel use your function (that uses hardware) when
> doing
> AES operations.
>
> > For example, in setkey.conf:
> > Instead of use "-E 3des-cbc" I will put "- E hwaes" and the setkey will
> > call my cryptographic algorithm.
>
> Setkey does not call any cryptographic algorithms. It just tells kernel
> what
> to do when kernel sees traffic from A to B.
>
> Racoon does encryption and decryption, but not for ESP, only for IKE.
> Kernel
> handles ESP encryption and decryption.
>
> For more information, read this:
>
> http://www.freescale.com/files/technology_publications/doc/Papers/Eintell5076PAPER.pdf
>
> Best Regards
> Kimmo Koivisto
>
> >
> > 2006/11/25, Matthew Grooms <mg...@sh...>:
> > > Marcelo Marleta wrote:
> > > > Thanks for the answers.
> > > > But I think I was not very clear.
> > > > I have an AES implemented in hardware and I call it using C.  I just
> > > > want to make a branch in the ipsec-tools to call my AES instead of
> the
> > > > one that comes with ipsec-tools.
> > > > I'm changing the parser and I want to know what all the things I
> have
> > > > to change in setkey and racoon.
> > > > For example: which function calls the cryptographyc algorithm?
> > > > I'm looking at the struct m_sa. I have to use it to make the branch?
> > >
> > > Marcelo,
> > >
> > >         What do you need to accelerate using your AES hardware? The
> > > ipsec-tools
> > > package only includes an internet key exchange daemon and the pfkey
> > > utilities. If you want to accelerate ipsec packet processing, you need
> > > to look at the kernel sources as Emmanuel suggested. If you want to
> > > accelerate key exchange, racoon uses the openssl libcrypto which has a
> > > framework for hardware acceleration.
> > >
> > > -Matthew
>

Re: [Ipsec-tools-devel] How to to drop tunnels without killing everybody ?

[Wilfried B. (PERSO) <wba...@on...>]

Aarh also :
When I do=20

"echo delete A.B.C.D I.F.G.H esp 124571628 | setkey -c "

I get that in the logs:

racoon: INFO: unsupported PF_KEY message REGISTER

And the SA does not end, so what ?


Wilfried


Wilfried Barnavon (PERSO) a =E9crit :
> Hello Yvan
>
> VANHULLEBUS Yvan a =E9crit :
>  =20
>> What do you mean exactly by "drop" ?
>> Just removing SAs, or completly disable the tunnel ?
>>
>> In the first case, you can just try to delete the SAs directly by
>> using setkey, but that won't send DELETE-SAs to the peer.
>>
>>  =20
>>    =20
> Well. I can set the SA down with the "delete" command of setkey. I just=
=20
> need to get the SPI. That's true ?
>
>  =20
>> In the second case, you can use the config reload function, but you'll
>> need to use HEAD version to have it, or wait for the 0.7 branch.
>>  =20
>>    =20
> Arrh ... what is HEAD version ? how to get it ?
>
>  =20
>> Are you talking about the conf reload mode, or about the "purge SAs"
>> in the monitor ?
>>
>>  =20
>>    =20
> I can have to purge a SA from a freezed peer, in this case I need to=20
> purge the SA. But if I have to test a config, I can need to reload=20
> config of racoon without dropping any other tunnel.
>  =20
>> I reported the first one to HEAD (so it will be included in 0.7.x),
>> but the second uses a custom PFKey message, which is not (yet ?)
>> public (as I didn't expect other people would need it), which is
>> mainly a kernel patch.
>>
>>  =20
>>    =20
> Where can I get such a kernel patch ?
> Do you know when the 0.7 mainline stream will be out ?
> Thanks for your answers
>
> Wilfried
>  =20
>> Yvan.
>>
>>  =20
>>    =20
>
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share=
 your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
>  =20

Re: [Ipsec-tools-devel] How to to drop tunnels without killing everybody ?

[Wilfried B. (PERSO) <wba...@on...>]

Hello Yvan

VANHULLEBUS Yvan a =E9crit :
> What do you mean exactly by "drop" ?
> Just removing SAs, or completly disable the tunnel ?
>
> In the first case, you can just try to delete the SAs directly by
> using setkey, but that won't send DELETE-SAs to the peer.
>
>  =20
Well. I can set the SA down with the "delete" command of setkey. I just=20
need to get the SPI. That's true ?

> In the second case, you can use the config reload function, but you'll
> need to use HEAD version to have it, or wait for the 0.7 branch.
>  =20
Arrh ... what is HEAD version ? how to get it ?

> Are you talking about the conf reload mode, or about the "purge SAs"
> in the monitor ?
>
>  =20
I can have to purge a SA from a freezed peer, in this case I need to=20
purge the SA. But if I have to test a config, I can need to reload=20
config of racoon without dropping any other tunnel.
> I reported the first one to HEAD (so it will be included in 0.7.x),
> but the second uses a custom PFKey message, which is not (yet ?)
> public (as I didn't expect other people would need it), which is
> mainly a kernel patch.
>
>  =20
Where can I get such a kernel patch ?
Do you know when the 0.7 mainline stream will be out ?
Thanks for your answers

Wilfried
> Yvan.
>
>  =20

Re: [Ipsec-tools-devel] How to to drop tunnels without killing everybody ?

[VANHULLEBUS Y. <va...@fr...>]

On Wed, Nov 22, 2006 at 09:21:13PM +0100, Wilfried BARNAVON wrote:
> Hello all !

Hi.

> I have built many tunnels from satellites sites to one central site.
> 
> My central site has 10.26.1.0/24 as network address. Each satellite
> site has 10.26.x.0/24 as network address.
> My tunnels are up and all is OK but sometimes I need to drop only
> one tunnel. Today I can't do that:  I have to kill racoon in order
> to drop one tunnel. This makes all tunnels down .... which is not
> really what I want and is also wery tedious !

What do you mean exactly by "drop" ?
Just removing SAs, or completly disable the tunnel ?

In the first case, you can just try to delete the SAs directly by
using setkey, but that won't send DELETE-SAs to the peer.

In the second case, you can use the config reload function, but you'll
need to use HEAD version to have it, or wait for the 0.7 branch.



[.....]
> With racoonctl, I intend to drop IPSEC-SA (this should set down the
> IPSEC tunnel): 
[...]

Can't help you for that, I don't use racoonctl....


> Thank you for your answers... I'm sure that I will get one, because
> ipsec-tools are used in commercial firewall/vpngateway like NetASQ,
> and they can drop only one tunnel. 

Are you talking about the conf reload mode, or about the "purge SAs"
in the monitor ?

I reported the first one to HEAD (so it will be included in 0.7.x),
but the second uses a custom PFKey message, which is not (yet ?)
public (as I didn't expect other people would need it), which is
mainly a kernel patch.



Yvan.

-- 
NETASQ
http://www.netasq.com

Re: [Ipsec-tools-devel] Cryptography

[Kimmo K. <ko...@gm...>]

On Saturday 25 November 2006 22:38, Marcelo Marleta wrote:
> Ipsec-tools calls an cryptographyc algorithm to do authentication and
> encryption/decryption of the packets.

Only true for IKE but not for encrypting or decrypting ESP data, and ESP is 
what you want.

Read Matthew's post and try to understand what racoon and setkey do and what 
kernel does in IPsec.

> I want that  Ipsec-tools calls MY cryptographic algorithm.

Wrong, you want to kernel use your function (that uses hardware) when doing 
AES operations. 

> For example, in setkey.conf:
> Instead of use "-E 3des-cbc" I will put "- E hwaes" and the setkey will
> call my cryptographic algorithm.

Setkey does not call any cryptographic algorithms. It just tells kernel what 
to do when kernel sees traffic from A to B.

Racoon does encryption and decryption, but not for ESP, only for IKE. Kernel 
handles ESP encryption and decryption.

For more information, read this:
http://www.freescale.com/files/technology_publications/doc/Papers/Eintell5076PAPER.pdf

Best Regards
Kimmo Koivisto

>
> 2006/11/25, Matthew Grooms <mg...@sh...>:
> > Marcelo Marleta wrote:
> > > Thanks for the answers.
> > > But I think I was not very clear.
> > > I have an AES implemented in hardware and I call it using C.  I just
> > > want to make a branch in the ipsec-tools to call my AES instead of the
> > > one that comes with ipsec-tools.
> > > I'm changing the parser and I want to know what all the things I have
> > > to change in setkey and racoon.
> > > For example: which function calls the cryptographyc algorithm?
> > > I'm looking at the struct m_sa. I have to use it to make the branch?
> >
> > Marcelo,
> >
> >         What do you need to accelerate using your AES hardware? The
> > ipsec-tools
> > package only includes an internet key exchange daemon and the pfkey
> > utilities. If you want to accelerate ipsec packet processing, you need
> > to look at the kernel sources as Emmanuel suggested. If you want to
> > accelerate key exchange, racoon uses the openssl libcrypto which has a
> > framework for hardware acceleration.
> >
> > -Matthew

Re: [Ipsec-tools-devel] Cryptography

[Marcelo M. <mar...@gm...>]

Ipsec-tools calls an cryptographyc algorithm to do authentication and
encryption/decryption of the packets.
I want that  Ipsec-tools calls MY cryptographic algorithm.

For example, in setkey.conf:

# ESP SAs using 192 bit long keys (168 + 24 parity)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;


Instead of use "-E 3des-cbc" I will put "- E hwaes" and the setkey will call
my cryptographic algorithm.


2006/11/25, Matthew Grooms <mg...@sh...>:
>
> Marcelo Marleta wrote:
> > Thanks for the answers.
> > But I think I was not very clear.
> > I have an AES implemented in hardware and I call it using C.  I just
> > want to make a branch in the ipsec-tools to call my AES instead of the
> > one that comes with ipsec-tools.
> > I'm changing the parser and I want to know what all the things I have to
> > change in setkey and racoon.
> > For example: which function calls the cryptographyc algorithm?
> > I'm looking at the struct m_sa. I have to use it to make the branch?
> >
>
> Marcelo,
>
>         What do you need to accelerate using your AES hardware? The
> ipsec-tools
> package only includes an internet key exchange daemon and the pfkey
> utilities. If you want to accelerate ipsec packet processing, you need
> to look at the kernel sources as Emmanuel suggested. If you want to
> accelerate key exchange, racoon uses the openssl libcrypto which has a
> framework for hardware acceleration.
>
> -Matthew
>

Re: [Ipsec-tools-devel] Cryptography

[Matthew G. <mg...@sh...>]

Marcelo Marleta wrote:
> Thanks for the answers.
> But I think I was not very clear.
> I have an AES implemented in hardware and I call it using C.  I just 
> want to make a branch in the ipsec-tools to call my AES instead of the 
> one that comes with ipsec-tools.
> I'm changing the parser and I want to know what all the things I have to 
> change in setkey and racoon.
> For example: which function calls the cryptographyc algorithm?
> I'm looking at the struct m_sa. I have to use it to make the branch?
> 

Marcelo,

	What do you need to accelerate using your AES hardware? The ipsec-tools 
package only includes an internet key exchange daemon and the pfkey 
utilities. If you want to accelerate ipsec packet processing, you need 
to look at the kernel sources as Emmanuel suggested. If you want to 
accelerate key exchange, racoon uses the openssl libcrypto which has a 
framework for hardware acceleration.

-Matthew

Re: [Ipsec-tools-devel] Cryptography

[Marcelo M. <mar...@gm...>]

Thanks for the answers.
But I think I was not very clear.
I have an AES implemented in hardware and I call it using C.  I just want to
make a branch in the ipsec-tools to call my AES instead of the one that
comes with ipsec-tools.
I'm changing the parser and I want to know what all the things I have to
change in setkey and racoon.
For example: which function calls the cryptographyc algorithm?
I'm looking at the struct m_sa. I have to use it to make the branch?

Thanks in advance!

2006/11/24, Emmanuel Dreyfus <ma...@ne...>:
>
> Marcelo Marleta <mar...@gm...> wrote:
>
> > Hi all! I'm new in the list.
> > I ported sucessfully ipsec-tools to uClinux on Nios CPU (that doesn't
> have
> > MMU).
> > Now I need to put my own AES cryptographyc algorithm that is fully
> > implemented in hardware to improve the performance.
> >
> > Can someone help me ? What changes I need to do in the code to use my
> own
> > AES instead the kernel one?
>
> BSD systems have an alternative kernel IPsec implementation called
> FAST_IPSEC that is designed to allow async crypto computing so that it
> can be deletagted to a specialized CPU. I don't know if Linux has
> something similar.  If it does not, I bet you'll have to create it.
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> ma...@ne...
>

Re: [Ipsec-tools-devel] How to to drop tunnels without killingeverybody ?

[Krzysztof O. <ol...@an...>]

On Fri, 24 Nov 2006, Wilfried BARNAVON wrote:

> So nobody can help me ?
>
> Wilfried
>  ----- Original Message -----
>  From: Wilfried BARNAVON
>  To: ips...@li...
>  Sent: Wednesday, November 22, 2006 9:21 PM
>  Subject: [Ipsec-tools-devel] How to to drop tunnels without killingevery=
body ?
>
>
>  Hello all !
>
>  I have built many tunnels from satellites sites to one central site.
>
>  My central site has 10.26.1.0/24 as network address. Each satellite site=
 has 10.26.x.0/24 as network address.
>  My tunnels are up and all is OK but sometimes I need to drop only one tu=
nnel. Today I can't do that:  I have to kill racoon in order to drop one tu=
nnel. This makes all tunnels down .... which is not really what I want and =
is also wery tedious !
>
>  I had planned racoonctl usage. But it seems broken. I use Linux kernel 2=
=2E6.15.6 and ipsec-tools-0.6.6

<CUT>
>  [root@phoenix ~]#racoonctl delete-sa esp inet 10.26.1.0/24/any 10.26.2.0=
/24/any any
>
>  And here is what racoon says in the logs:
>  ERROR: phase 1 for 10.26.1.0 -> 10.26.2.0 not found
>
>  Where is my error ? I read in racoonctl man page:
>
>       delete-sa saopts
>               Delete an SA, either an ISAKMP SA, IPsec ESP SA, or IPsec A=
H SA.
>
>
>               saopts has the following format:
>
>               isakmp {inet|inet6} src dst
>
>               {esp|ah} {inet|inet6} src/prefixlen/port dst/prefixlen/port
>                 {icmp|tcp|udp|any}
>
>
>  If racoonctl is buggy .... is there another way to drop one tunnel but a=
ll ?

How about:

racoonctl vpn-disconnect A.B.C.D

Best regards,


 =09=09=09=09Krzysztof Ol=EAdzki

Re: [Ipsec-tools-devel] How to to drop tunnels without killingeverybody ?

[Wilfried B. <wba...@on...>]

So nobody can help me ?

Wilfried
  ----- Original Message -----=20
  From: Wilfried BARNAVON=20
  To: ips...@li...=20
  Sent: Wednesday, November 22, 2006 9:21 PM
  Subject: [Ipsec-tools-devel] How to to drop tunnels without =
killingeverybody ?


  Hello all !

  I have built many tunnels from satellites sites to one central site.

  My central site has 10.26.1.0/24 as network address. Each satellite =
site has 10.26.x.0/24 as network address.=20
  My tunnels are up and all is OK but sometimes I need to drop only one =
tunnel. Today I can't do that:  I have to kill racoon in order to drop =
one tunnel. This makes all tunnels down .... which is not really what I =
want and is also wery tedious !

  I had planned racoonctl usage. But it seems broken. I use Linux kernel =
2.6.15.6 and ipsec-tools-0.6.6

  First here is a part of my racoon.conf
  --racoon.conf
  path include "/etc/racoon";
  path pre_shared_key "/etc/racoon/psk.txt";
  path certificate "/etc/racoon/certs";

  log notify;

  listen {
          isakmp A.B.C.D [500];
          isakmp_natt A.B.C.D [4500];
          adminsock "/var/racoon/racoon.sock" "root" "root" 0600 ;

  }
  padding {
    maximum_length 20;
    randomize off;
    strict_check off;
    exclusive_tail off;
  }

  timer {
    counter 5;
    interval 10 sec;
    persend 1;
    phase1 30 sec;
    phase2 30 sec;
  }

  remote E.F.G.H {
    exchange_mode main;
    doi ipsec_doi;
    ike_frag on;
    situation identity_only;
    proposal_check strict;
    peers_identifier address E.F.G.H;
    my_identifier address A.B.C.D;
    verify_identifier on;
    lifetime time 28800 seconds;
    nat_traversal on;
    proposal {
      encryption_algorithm 3des;
      hash_algorithm md5;
      authentication_method pre_shared_key;
      dh_group modp768;
   }
  }

  sainfo address 10.26.1.0/24 any address 10.26.3.0/24 any {
    pfs_group modp1024;
    lifetime time 28800 seconds;
    encryption_algorithm 3des;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
  }

  remote I.J.K.L {
    exchange_mode main;
    doi ipsec_doi;
    ike_frag on;
    situation identity_only;
    proposal_check strict;
    peers_identifier address I.J.K.L;
    my_identifier address A.B.C.D;
    verify_identifier on;
    lifetime time 28800 seconds;
    nat_traversal on;
    dpd_delay=3D30;
    proposal {
      encryption_algorithm 3des;
      hash_algorithm md5;
      authentication_method pre_shared_key;
      dh_group modp1024;
    }
  }

  sainfo address 10.26.1.0/24 any address 10.26.2.0/24 any {
    pfs_group modp1024;
    lifetime time 28800 seconds;
    encryption_algorithm 3des;
    authentication_algorithm hmac_md5;
    compression_algorithm deflate;
  }

  # .... and so on...
  --end of racoon.conf

  I have also an ipsec.conf file that builds the Security Pocily =
Database:

  -- ipsec.conf
  #!/sbin/setkey -f
  #
  # Flush SAD and SPD
  flush;
  spdflush;

  # Create policies for racoon

  spdadd 10.26.1.0/24 10.26.3.0/24 any -P out ipsec
             esp/tunnel/A.B.C.D-E.F.G.H/unique;
  spdadd 10.26.3.0/24 10.26.1.0/24  any -P in ipsec
             esp/tunnel/E.F.G.H-A.B.C.D/unique;


  spdadd 10.26.1.0/24 10.26.2.0/24 any -P out ipsec
             esp/tunnel/A.B.C.D-I.J.K.L/unique;
  spdadd 10.26.2.0/24 10.26.1.0/24  any -P in ipsec
             esp/tunnel/I.J.K.L-A.B.C.D/unique;

  # and so on ...
  -- end of ipsec.conf

  With racoonctl, I intend to drop IPSEC-SA (this should set down the =
IPSEC tunnel):

  [root@phoenix ~]#racoonctl delete-sa esp inet 10.26.1.0/24/any =
10.26.2.0/24/any any

  And here is what racoon says in the logs:
  ERROR: phase 1 for 10.26.1.0 -> 10.26.2.0 not found

  Where is my error ? I read in racoonctl man page:

       delete-sa saopts
               Delete an SA, either an ISAKMP SA, IPsec ESP SA, or IPsec =
AH SA.


               saopts has the following format:

               isakmp {inet|inet6} src dst

               {esp|ah} {inet|inet6} src/prefixlen/port =
dst/prefixlen/port
                 {icmp|tcp|udp|any}


  If racoonctl is buggy .... is there another way to drop one tunnel but =
all ?

  Thank you for your answers... I'm sure that I will get one, because =
ipsec-tools are used in commercial firewall/vpngateway like NetASQ, and =
they can drop only one tunnel.


  Wilfried=20



-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
  opinions on IT & business topics through brief surveys - and earn cash
  =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV


-------------------------------------------------------------------------=
-----


  _______________________________________________
  Ipsec-tools-devel mailing list
  Ips...@li...
  https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel

Re: [Ipsec-tools-devel] Xauth Support

[Matthew G. <mg...@sh...>]

Eric Boudrand wrote:
> Hello,
> 
>> It seems to me that Xauth has been implemented for a few years now...
> 
> My question is related to what is written in the 0.6.6 code.
> 

Eric,

	The only user authentication modes available in 0.6.x are 
hybrid_rsa_server hybrid_rsa_client which equate to HybridInitRSA and 
HybridRespRSA. You can use the cvs version to support plain Xauth PSK 
and RSA modes or wait for the 0.7 release which should be out at some 
point in the near future.

-Matthew