[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKE Notify message - Status types
antonio.barrera@nokia.com writes:
> Are there other Status messages besides the CONNECTED one defined in
> IKE (RFC2408). I've seen in some documentation the existance of at least 2
> more (RESPONDER-LIFETIME and REPLAY-STATUS) but I don't know where to find
> info about them. Just a reference of a draft or RFC would be enough.
> Thanks in advance!
IPsec DOI RFC 2407:
----------------------------------------------------------------------
Network Working Group D. Piper
Request for Comments: 2407 Network Alchemy
Category: Standards Track November 1998
The Internet IP Security Domain of Interpretation for ISAKMP
...
4.6.3 IPSEC Notify Message Types
ISAKMP defines two blocks of Notify Message codes, one for errors and
one for status messages. ISAKMP also allocates a portion of each
block for private use within a DOI. The IPSEC DOI defines the
following private message types for its own use.
Notify Messages - Error Types Value
----------------------------- -----
RESERVED 8192
Notify Messages - Status Types Value
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
Notification Status Messages MUST be sent under the protection of an
ISAKMP SA: either as a payload in the last Main Mode exchange; in a
separate Informational Exchange after Main Mode or Aggressive Mode
processing is complete; or as a payload in any Quick Mode exchange.
These messages MUST NOT be sent in Aggressive Mode exchange, since
Aggressive Mode does not provide the necessary protection to bind the
Notify Status Message to the exchange.
Nota Bene: a Notify payload is fully protected only in Quick Mode,
where the entire payload is included in the HASH(n) digest. In Main
Mode, while the notify payload is encrypted, it is not currently
included in the HASH(n) digests. As a result, an active substitution
attack on the Main Mode ciphertext could cause the notify status
message type to be corrupted. (This is true, in general, for the
last message of any Main Mode exchange.) While the risk is small, a
corrupt notify message might cause the receiver to abort the entire
negotiation thinking that the sender encountered a fatal error.
Piper Standards Track [Page 22]
RFC 2407 IP Security Domain of Interpretation November 1998
Implementation Note: the ISAKMP protocol does not guarantee delivery
of Notification Status messages when sent in an ISAKMP Informational
Exchange. To ensure receipt of any particular message, the sender
SHOULD include a Notification Payload in a defined Main Mode or Quick
Mode exchange which is protected by a retransmission timer.
4.6.3.1 RESPONDER-LIFETIME
The RESPONDER-LIFETIME status message may be used to communicate the
IPSEC SA lifetime chosen by the responder.
When present, the Notification Payload MUST have the following
format:
o Payload Length - set to length of payload + size of data (var)
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
cookies) or four (4) (one IPSEC SPI)
o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
o SPI - set to the two ISAKMP cookies or to the sender's inbound
IPSEC SPI
o Notification Data - contains an ISAKMP attribute list with the
responder's actual SA lifetime(s)
Implementation Note: saying that the Notification Data field contains
an attribute list is equivalent to saying that the Notification Data
field has zero length and the Notification Payload has an associated
attribute list.
4.6.3.2 REPLAY-STATUS
The REPLAY-STATUS status message may be used for positive
confirmation of the responder's election on whether or not he is to
perform anti-replay detection.
When present, the Notification Payload MUST have the following
format:
o Payload Length - set to length of payload + size of data (4)
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
cookies) or four (4) (one IPSEC SPI)
o Notify Message Type - set to REPLAY-STATUS
o SPI - set to the two ISAKMP cookies or to the sender's inbound
IPSEC SPI
o Notification Data - a 4 octet value:
Piper Standards Track [Page 23]
RFC 2407 IP Security Domain of Interpretation November 1998
0 = replay detection disabled
1 = replay detection enabled
4.6.3.3 INITIAL-CONTACT
The INITIAL-CONTACT status message may be used when one side wishes
to inform the other that this is the first SA being established with
the remote system. The receiver of this Notification Message might
then elect to delete any existing SA's it has for the sending system
under the assumption that the sending system has rebooted and no
longer has access to the original SA's and their associated keying
material. When used, the content of the Notification Data field
SHOULD be null (i.e. the Payload Length should be set to the fixed
length of Notification Payload).
When present, the Notification Payload MUST have the following
format:
o Payload Length - set to length of payload + size of data (0)
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
o Notify Message Type - set to INITIAL-CONTACT
o SPI - set to the two ISAKMP cookies
o Notification Data - <not included>
...
--
kivinen@iki.fi Work : +358 303 9870
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: