Enabling Notification of Invalid Cookies
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.
ipsec option tx-invalid-cookie
•
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.
Configuration Examples
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.
Configuration Notes
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.
152
JunosE 11.2.x IP Services Configuration Guide
Содержание JUNOSE 11.2.X IP SERVICES
Страница 6: ...Copyright 2010 Juniper Networks Inc vi...
Страница 8: ...Copyright 2010 Juniper Networks Inc viii JunosE 11 2 x IP Services Configuration Guide...
Страница 18: ...Copyright 2010 Juniper Networks Inc xviii JunosE 11 2 x IP Services Configuration Guide...
Страница 22: ...Copyright 2010 Juniper Networks Inc xxii JunosE 11 2 x IP Services Configuration Guide...
Страница 28: ...Copyright 2010 Juniper Networks Inc 2 JunosE 11 2 x IP Services Configuration Guide...
Страница 116: ...Copyright 2010 Juniper Networks Inc 90 JunosE 11 2 x IP Services Configuration Guide...
Страница 144: ...Copyright 2010 Juniper Networks Inc 118 JunosE 11 2 x IP Services Configuration Guide...
Страница 230: ...Copyright 2010 Juniper Networks Inc 204 JunosE 11 2 x IP Services Configuration Guide...
Страница 262: ...Copyright 2010 Juniper Networks Inc 236 JunosE 11 2 x IP Services Configuration Guide...
Страница 294: ...Copyright 2010 Juniper Networks Inc 268 JunosE 11 2 x IP Services Configuration Guide...
Страница 328: ...Copyright 2010 Juniper Networks Inc 302 JunosE 11 2 x IP Services Configuration Guide...
Страница 345: ...PART 2 Index Index on page 321 319 Copyright 2010 Juniper Networks Inc...
Страница 346: ...Copyright 2010 Juniper Networks Inc 320 JunosE 11 2 x IP Services Configuration Guide...
Страница 356: ...Copyright 2010 Juniper Networks Inc 330 JunosE 11 2 x IP Services Configuration Guide...