Table of Contents
Advertisement
JunosE 11.2.x IP Services Configuration Guide
Enabling Notification of Invalid Cookies
ipsec option tx-invalid-cookie
Configuration Examples
Configuration Notes
152
The IKE protocol enables peers to exchange informational messages. The payload of
these messages can be a notify type or a delete type. These messages are expected to
be protected (encrypted) by the keys negotiated by the peers when they establish a
security association as a result of the IKE phase 1 exchange.
If a responder peer does not recognize the initiator-responder cookie pair, it can send an
invalid cookie notification message to the initiator. The responder might fail to recognize
the cookie pair because it has lost the cookie, or because it deleted the cookie and then
the peer lost the delete notification. Upon receipt of the invalid cookie notification, the
initiator peer can delete the phase 1 state.
The ability to send the invalid cookie message is disabled by default. You can issue the
ipsec option tx-invalid-cookie command to enable the feature on a per-transport-VR
basis.
Even when you configure this feature, the E Series router does not respond when it receives
an invalid cookie notification. These notifications are unprotected by a phase 1 key
exchange and therefore are subject to denial-of-service (DOS) attacks. Instead, the
E Series router can determine when a phase 1 relationship has gone stale by timeouts or
use of dead peer detection (DPD). For this reason, this feature is useful only when the
E Series router is a responding peer for non–E Series devices that cannot detect when
the phase 1 relationship goes stale.
Use to enable the router to send an invalid cookie notification to an IKE peer when the
router does not recognize the initiator-responder cookie pair.
Example
host1(config)#ipsec option tx-invalid-cookie
Use the no version to restore the default, disabling the ability to send an invalid cookie
notification.
See ipsec option tx-invalid-cookie.
This section contains examples of two IPSec applications. The first example shows a
customer who replaces a leased line network with an IPSec network that allows the
company to connect its corporate locations over the Internet. The second example
provides leased line replacement to two customers who use address schemes in the
same range.
Both the local and remote identities shown in these examples serve two purposes:
They identify multiple IPSec tunnels between the same endpoints.
Copyright © 2010, Juniper Networks, Inc.
Advertisement
Table of Contents
