[Ipsec-tools-devel] racoon: ERROR: unknown Informational exchange received.

[Chong Peng]

Guys:
I am running racoon 0.6.5 on 2 FC6 based linux boxes. The racoon
configuration for both side are identical, and as follows:

sainfo anonymous
{
pfs_group 14;
lifetime time 60 secs;
encryption_algorithm aes ;
authentication_algorithm hmac_sha1;
compression_algorithm deflate ;
}
remote x.x.x.x
{
exchange_mode main;
lifetime time 12 hour; # sec,min,hour
initial_contact on;
dpd_delay 5;
proposal_check obey;

proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 14 ;
}
}


It is consistent that whenever phase 1 SA expires, I will see the error log
"unknown Informational exchange received". Sometime it shows up once,
sometimes it shows up multiple times. Although the racoon will always
re-negociate a new phase 1 SA a while late and my ipsec still working fine,
I just do not understand why is the error log. What is the signifisence of
this error?

Oct 2 17:56:39 Honda racoon: INFO: ISAKMP-SA expired 8.8.8.4[500]-9.9.9.4[500]
spi:3c6272171d9117fd:6abaaadc980472fb
Oct 2 17:56:40 Honda racoon: INFO: ISAKMP-SA deleted 8.8.8.4[500]-9.9.9.4[500]
spi:3c6272171d9117fd:6abaaadc980472fb
Oct 2 17:56:41 Honda racoon: ERROR: unknown Informational exchange
received.
Oct 2 17:57:22 Honda racoon: INFO: IPsec-SA request for 9.9.9.4 queued due
to no phase1 found.
Oct 2 17:57:22 Honda racoon: INFO: initiate new phase 1 negotiation:
8.8.8.4[500]<=>9.9.9.4[500]
Oct 2 17:57:22 Honda racoon: INFO: begin Identity Protection mode.
Oct 2 17:57:22 Honda racoon: INFO: received Vendor ID: DPD
Oct 2 17:57:22 Honda racoon: INFO: ISAKMP-SA established 8.8.8.4[500]-
9.9.9.4[500] spi:a56d010981530732:f707bb1ee2f98a8a
Oct 2 17:57:23 Honda racoon: INFO: initiate new phase 2 negotiation:
8.8.8.4[500]<=>9.9.9.4[500]
Oct 2 17:57:23 Honda racoon: INFO: IPsec-SA established: ESP/Transport
9.9.9.4[0]->8.8.8.4[0] spi=236585571(0xe1a0263)
Oct 2 17:57:23 Honda racoon: INFO: IPsec-SA established: ESP/Transport
8.8.8.4[0]->9.9.9.4[0] spi=90836029(0x56a0c3d)

Oct 3 05:57:22 Honda racoon: INFO: ISAKMP-SA expired 8.8.8.4[500]-9.9.9.4[500]
spi:a56d010981530732:f707bb1ee2f98a8a
Oct 3 05:57:22 Honda racoon: ERROR: unknown Informational exchange
received.
Oct 3 05:57:22 Honda racoon: ERROR: unknown Informational exchange
received.
Oct 3 05:57:23 Honda racoon: INFO: ISAKMP-SA deleted 8.8.8.4[500]-9.9.9.4[500]
spi:a56d010981530732:f707bb1ee2f98a8a
Oct 3 05:57:27 Honda racoon: ERROR: unknown Informational exchange
received.
Oct 3 05:58:01 Honda racoon: INFO: IPsec-SA request for 9.9.9.4 queued due
to no phase1 found.
Oct 3 05:58:01 Honda racoon: INFO: initiate new phase 1 negotiation:
8.8.8.4[500]<=>9.9.9.4[500]
Oct 3 05:58:01 Honda racoon: INFO: begin Identity Protection mode.
Oct 3 05:58:01 Honda racoon: INFO: received Vendor ID: DPD
Oct 3 05:58:01 Honda racoon: INFO: ISAKMP-SA established 8.8.8.4[500]-
9.9.9.4[500] spi:19aef8456b5f40e5:4ffb2c4a36b64966
Oct 3 05:58:02 Honda racoon: INFO: initiate new phase 2 negotiation:
8.8.8.4[500]<=>9.9.9.4[500]
Oct 3 05:58:02 Honda racoon: INFO: IPsec-SA established: ESP/Transport
9.9.9.4[0]->8.8.8.4[0] spi=192713628(0xb7c939c)
Oct 3 05:58:02 Honda racoon: INFO: IPsec-SA established: ESP/Transport
8.8.8.4[0]->9.9.9.4[0] spi=15576823(0xedaef7)

Anybody knows? Thanks in advance.

Chong Peng

[Timo Teräs]

Post by Chong Peng
It is consistent that whenever phase 1 SA expires, I will see the error log
"unknown Informational exchange received". Sometime it shows up once,
sometimes it shows up multiple times. Although the racoon will always
re-negociate a new phase 1 SA a while late and my ipsec still working fine,
I just do not understand why is the error log. What is the signifisence of
this error?

The error tells that we received a message that could not be decrypted.

My guess is that that side A send DPD message, but during transit the
phase 1 SA expires and side B is unable to decrypt it, thus the error
message. We might make some adjustment to DPD to prevent this.

Cheers,
Timo

[Chong Peng]

Timo:
Thanks. I have a general question.

When a phase 1 SA expires, what racoon is going to do? Is it going to

(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.

By looking at the log in my system, I tend to believe that racoon is doing
(2) when phase 1 SA expires.

If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Chong Peng

Post by Timo Teräs

Post by Chong Peng
It is consistent that whenever phase 1 SA expires, I will see the error

log

Post by Chong Peng
"unknown Informational exchange received". Sometime it shows up once,
sometimes it shows up multiple times. Although the racoon will always
re-negociate a new phase 1 SA a while late and my ipsec still working

fine,

Post by Chong Peng
I just do not understand why is the error log. What is the signifisence

of

Post by Chong Peng
this error?

The error tells that we received a message that could not be decrypted.
My guess is that that side A send DPD message, but during transit the
phase 1 SA expires and side B is unable to decrypt it, thus the error
message. We might make some adjustment to DPD to prevent this.
Cheers,
Timo

[Timo Teräs]

Post by Chong Peng
Thanks. I have a general question.
When a phase 1 SA expires, what racoon is going to do? Is it going to
(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.
By looking at the log in my system, I tend to believe that racoon is doing
(2) when phase 1 SA expires.

The latest release does 2. I did some modifications so that racoon
can be configured to do 1, that is in CVS HEAD and will be part of
upcoming 0.8 release.

Post by Chong Peng
If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Yes and no. On racoon hard restart this can happen when the other
party still things phase 1 SA is ok, but since racoon was restarted
it's lost on the other side. You see it because of how DPD timings
currently happen. If we just e.g. modified DPD to not monitor SA
when there's less than 5 seconds left of SA lifetime, you would
not see those errors.

Clearly it's not a hard error. Normally it is a hint that something
fishy might be going on.

Cheers,
Timo

[Chong Peng]

Timo:
Thanks again for the quick reply to my question.

If phase 1 SA expires, does racoon also inform its peer to make sure its
peer knows that the phase 1 SA is expired? If it does not, then we will
probably see "receiving a message that cannot be decrypted" cases other than
DPD.

If racoon peers are configured with different phase 1 SA lifetimes, let's
say, for example, racoon A's phase 1 lifetime is 6 hours and racoon B's
phase 1 SA lifetime is 12 hours, it is possible that the same phase 1 SA has
expired in racoon A but still valid in racoon B. If, racoon B wants to
renigociate a new phase 2 SA with racoon A, racoon B will use the phase 1 SA
(that is already expired in racoon A) and we will end up with "receiving a
message that cannot be decrypted" error in racoon A.

Do I understand right?

Chong Peng

Post by Timo Teräs

Post by Chong Peng
Thanks. I have a general question.
When a phase 1 SA expires, what racoon is going to do? Is it going to
(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.
By looking at the log in my system, I tend to believe that racoon is

doing

Post by Chong Peng
(2) when phase 1 SA expires.

The latest release does 2. I did some modifications so that racoon
can be configured to do 1, that is in CVS HEAD and will be part of
upcoming 0.8 release.

Post by Chong Peng
If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Yes and no. On racoon hard restart this can happen when the other
party still things phase 1 SA is ok, but since racoon was restarted
it's lost on the other side. You see it because of how DPD timings
currently happen. If we just e.g. modified DPD to not monitor SA
when there's less than 5 seconds left of SA lifetime, you would
not see those errors.
Clearly it's not a hard error. Normally it is a hint that something
fishy might be going on.
Cheers,
Timo

[Timo Teräs]

Post by Chong Peng
If phase 1 SA expires, does racoon also inform its peer to make sure its
peer knows that the phase 1 SA is expired? If it does not, then we will
probably see "receiving a message that cannot be decrypted" cases other than
DPD.

No. During phase1 SA negotiation also the lifetime is agreed upon. Both
sides know the exact time when the SA expires. (If racoon is shutdown cleanly
it will notify the other party that the SA:s were deleted. Also after startup
racoon will send initial-connect during first phase1 SA negotiation, it
basically means "remove all old SA:s with me".)

Actually if the other systems system clock is changed, bad things might
happen. We might want to consider using clock_gettime(CLOCK_MONOTONIC) instead
of gettimeofday() as we do now to protect against system clock changes.

Post by Chong Peng
If racoon peers are configured with different phase 1 SA lifetimes, let's
say, for example, racoon A's phase 1 lifetime is 6 hours and racoon B's
phase 1 SA lifetime is 12 hours, it is possible that the same phase 1 SA has
expired in racoon A but still valid in racoon B. If, racoon B wants to
renigociate a new phase 2 SA with racoon A, racoon B will use the phase 1 SA
(that is already expired in racoon A) and we will end up with "receiving a
message that cannot be decrypted" error in racoon A.

Technically, the SA should not establish unless same lifetime is configured
on both ends. There exists a way for the responder to say "I agree, but my
lifetime is actually less than yours". Related fixes where committed not too
long ago.

But in essence the lifetime is negotiated and both parties know when the
phase1 SA expires. Thus no packets should be ever transmitted using expired
phase1 SA.

- Timo

[Timo Teräs]

Post by Chong Peng
If phase 1 SA expires, does racoon also inform its peer to make sure its
peer knows that the phase 1 SA is expired? If it does not, then we will
probably see "receiving a message that cannot be decrypted" cases other than
DPD.

No. During phase1 SA negotiation also the lifetime is agreed upon. Both
sides know the exact time when the SA expires. (If racoon is shutdown cleanly
it will notify the other party that the SA:s were deleted. Also after startup
racoon will send initial-connect during first phase1 SA negotiation, it
basically means "remove all old SA:s with me".)

Actually if the other systems system clock is changed, bad things might
happen. We might want to consider using clock_gettime(CLOCK_MONOTONIC) instead
of gettimeofday() as we do now to protect against system clock changes.

Post by Chong Peng
If racoon peers are configured with different phase 1 SA lifetimes, let's
say, for example, racoon A's phase 1 lifetime is 6 hours and racoon B's
phase 1 SA lifetime is 12 hours, it is possible that the same phase 1 SA has
expired in racoon A but still valid in racoon B. If, racoon B wants to
renigociate a new phase 2 SA with racoon A, racoon B will use the phase 1 SA
(that is already expired in racoon A) and we will end up with "receiving a
message that cannot be decrypted" error in racoon A.

Technically, the SA should not establish unless same lifetime is configured
on both ends. There exists a way for the responder to say "I agree, but my
lifetime is actually less than yours". Related fixes where committed not too
long ago.

But in essence the lifetime is negotiated and both parties know when the
phase1 SA expires. Thus no packets should be ever transmitted using expired
phase1 SA.

- Timo

[Timo Teräs]

Post by Chong Peng
If phase 1 SA expires, does racoon also inform its peer to make sure its
peer knows that the phase 1 SA is expired? If it does not, then we will
probably see "receiving a message that cannot be decrypted" cases other than
DPD.

No. During phase1 SA negotiation also the lifetime is agreed upon. Both
sides know the exact time when the SA expires. (If racoon is shutdown cleanly
it will notify the other party that the SA:s were deleted. Also after startup
racoon will send initial-connect during first phase1 SA negotiation, it
basically means "remove all old SA:s with me".)

Actually if the other systems system clock is changed, bad things might
happen. We might want to consider using clock_gettime(CLOCK_MONOTONIC) instead
of gettimeofday() as we do now to protect against system clock changes.

Post by Chong Peng
If racoon peers are configured with different phase 1 SA lifetimes, let's
say, for example, racoon A's phase 1 lifetime is 6 hours and racoon B's
phase 1 SA lifetime is 12 hours, it is possible that the same phase 1 SA has
expired in racoon A but still valid in racoon B. If, racoon B wants to
renigociate a new phase 2 SA with racoon A, racoon B will use the phase 1 SA
(that is already expired in racoon A) and we will end up with "receiving a
message that cannot be decrypted" error in racoon A.

Technically, the SA should not establish unless same lifetime is configured
on both ends. There exists a way for the responder to say "I agree, but my
lifetime is actually less than yours". Related fixes where committed not too
long ago.

But in essence the lifetime is negotiated and both parties know when the
phase1 SA expires. Thus no packets should be ever transmitted using expired
phase1 SA.

- Timo

[Chong Peng]

Timo:
Thanks again for the quick reply to my question.

If phase 1 SA expires, does racoon also inform its peer to make sure its
peer knows that the phase 1 SA is expired? If it does not, then we will
probably see "receiving a message that cannot be decrypted" cases other than
DPD.

If racoon peers are configured with different phase 1 SA lifetimes, let's
say, for example, racoon A's phase 1 lifetime is 6 hours and racoon B's
phase 1 SA lifetime is 12 hours, it is possible that the same phase 1 SA has
expired in racoon A but still valid in racoon B. If, racoon B wants to
renigociate a new phase 2 SA with racoon A, racoon B will use the phase 1 SA
(that is already expired in racoon A) and we will end up with "receiving a
message that cannot be decrypted" error in racoon A.

Do I understand right?

Chong Peng

Post by Timo Teräs

Post by Chong Peng
Thanks. I have a general question.
When a phase 1 SA expires, what racoon is going to do? Is it going to
(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.
By looking at the log in my system, I tend to believe that racoon is

doing

Post by Chong Peng
(2) when phase 1 SA expires.

The latest release does 2. I did some modifications so that racoon
can be configured to do 1, that is in CVS HEAD and will be part of
upcoming 0.8 release.

Post by Chong Peng
If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Yes and no. On racoon hard restart this can happen when the other
party still things phase 1 SA is ok, but since racoon was restarted
it's lost on the other side. You see it because of how DPD timings
currently happen. If we just e.g. modified DPD to not monitor SA
when there's less than 5 seconds left of SA lifetime, you would
not see those errors.
Clearly it's not a hard error. Normally it is a hint that something
fishy might be going on.
Cheers,
Timo

[Chong Peng]

Timo:
Thanks again for the quick reply to my question.

If phase 1 SA expires, does racoon also inform its peer to make sure its
peer knows that the phase 1 SA is expired? If it does not, then we will
probably see "receiving a message that cannot be decrypted" cases other than
DPD.

If racoon peers are configured with different phase 1 SA lifetimes, let's
say, for example, racoon A's phase 1 lifetime is 6 hours and racoon B's
phase 1 SA lifetime is 12 hours, it is possible that the same phase 1 SA has
expired in racoon A but still valid in racoon B. If, racoon B wants to
renigociate a new phase 2 SA with racoon A, racoon B will use the phase 1 SA
(that is already expired in racoon A) and we will end up with "receiving a
message that cannot be decrypted" error in racoon A.

Do I understand right?

Chong Peng

Post by Timo Teräs

Post by Chong Peng
Thanks. I have a general question.
When a phase 1 SA expires, what racoon is going to do? Is it going to
(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.
By looking at the log in my system, I tend to believe that racoon is

doing

Post by Chong Peng
(2) when phase 1 SA expires.

The latest release does 2. I did some modifications so that racoon
can be configured to do 1, that is in CVS HEAD and will be part of
upcoming 0.8 release.

Post by Chong Peng
If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Yes and no. On racoon hard restart this can happen when the other
party still things phase 1 SA is ok, but since racoon was restarted
it's lost on the other side. You see it because of how DPD timings
currently happen. If we just e.g. modified DPD to not monitor SA
when there's less than 5 seconds left of SA lifetime, you would
not see those errors.
Clearly it's not a hard error. Normally it is a hint that something
fishy might be going on.
Cheers,
Timo

[Chong Peng]

Timo:
Thanks again for the quick reply to my question.

If phase 1 SA expires, does racoon also inform its peer to make sure its
peer knows that the phase 1 SA is expired? If it does not, then we will
probably see "receiving a message that cannot be decrypted" cases other than
DPD.

If racoon peers are configured with different phase 1 SA lifetimes, let's
say, for example, racoon A's phase 1 lifetime is 6 hours and racoon B's
phase 1 SA lifetime is 12 hours, it is possible that the same phase 1 SA has
expired in racoon A but still valid in racoon B. If, racoon B wants to
renigociate a new phase 2 SA with racoon A, racoon B will use the phase 1 SA
(that is already expired in racoon A) and we will end up with "receiving a
message that cannot be decrypted" error in racoon A.

Do I understand right?

Chong Peng

Post by Timo Teräs

Post by Chong Peng
Thanks. I have a general question.
When a phase 1 SA expires, what racoon is going to do? Is it going to
(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.
By looking at the log in my system, I tend to believe that racoon is

doing

Post by Chong Peng
(2) when phase 1 SA expires.

The latest release does 2. I did some modifications so that racoon
can be configured to do 1, that is in CVS HEAD and will be part of
upcoming 0.8 release.

Post by Chong Peng
If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Yes and no. On racoon hard restart this can happen when the other
party still things phase 1 SA is ok, but since racoon was restarted
it's lost on the other side. You see it because of how DPD timings
currently happen. If we just e.g. modified DPD to not monitor SA
when there's less than 5 seconds left of SA lifetime, you would
not see those errors.
Clearly it's not a hard error. Normally it is a hint that something
fishy might be going on.
Cheers,
Timo

[Chong Peng]

Timo:
Thanks. I have a general question.

When a phase 1 SA expires, what racoon is going to do? Is it going to

(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.

By looking at the log in my system, I tend to believe that racoon is doing
(2) when phase 1 SA expires.

If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Chong Peng

Post by Timo Teräs

Post by Chong Peng
It is consistent that whenever phase 1 SA expires, I will see the error

log

Post by Chong Peng
"unknown Informational exchange received". Sometime it shows up once,
sometimes it shows up multiple times. Although the racoon will always
re-negociate a new phase 1 SA a while late and my ipsec still working

fine,

Post by Chong Peng
I just do not understand why is the error log. What is the signifisence

of

Post by Chong Peng
this error?

The error tells that we received a message that could not be decrypted.
My guess is that that side A send DPD message, but during transit the
phase 1 SA expires and side B is unable to decrypt it, thus the error
message. We might make some adjustment to DPD to prevent this.
Cheers,
Timo

[Chong Peng]

Timo:
Thanks. I have a general question.

When a phase 1 SA expires, what racoon is going to do? Is it going to

(1) re-negociate a new phase 1 SA right away, or
(2) just sit there and wait for other events (e.g. phase 2 SA expire)
trigging the re-negociation of a new phase 1 SA.

By looking at the log in my system, I tend to believe that racoon is doing
(2) when phase 1 SA expires.

If my understanding is right, then "receiving a message that cannot be
decrypted" is a normal event rather than an exception.

Chong Peng

Post by Timo Teräs

Post by Chong Peng
It is consistent that whenever phase 1 SA expires, I will see the error

log

Post by Chong Peng
"unknown Informational exchange received". Sometime it shows up once,
sometimes it shows up multiple times. Although the racoon will always
re-negociate a new phase 1 SA a while late and my ipsec still working

fine,

Post by Chong Peng
I just do not understand why is the error log. What is the signifisence

of

Post by Chong Peng
this error?

The error tells that we received a message that could not be decrypted.
My guess is that that side A send DPD message, but during transit the
phase 1 SA expires and side B is unable to decrypt it, thus the error
message. We might make some adjustment to DPD to prevent this.
Cheers,
Timo