These comments are all editorial.
4.7 Changes in NAT Mappings
In MOBIKE, these messages can also be used to detect if NAT mappings
have changed (for example, if the keepalive internal is too long, or
the NAT box is rebooted).
I think you meant to say keepalive interval not keepalive internal.
-------------------------------------------------------
5. Payload formats
5.1 MOBIKE_SUPPORTED Notify Payload
I think these headers and text should more closely match what is in
IKEv2. Also these messages should be split between what is an error,
5.5 and 5.8, and what is a status message all the rest. This is also
how the split is done in IKEv2. See the template and text below which I
stole from IKEv2.
Here is the new suggested text:
5. Notify Payload
The Notify Payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions, to
an IKE peer. A Notify Payload may appear in a response message (usually
specifying why a request was rejected), in an INFORMATIONAL Exchange (to
report an error not in an IKE request), or in any other message to
indicate sender capabilities or to modify the meaning of the request.
MOBIKE protocol message exchanges use the IKEv2 notify payload as
specified below.
5.1 Notify Message Types
Notify Messages - Status Types Value
----------------------------------------------
MOBIKE_SUPPORTED
ADDITIONAL_IPv4/6_ADDRESS
Etc.
Notify Messages - Error Types Value
----------------------------------------------
UNACCEPTABLE ADDRESSES
UNEXPECTED_NAT_DETECTED
-----------------------------------------------------------------------
In addition, you might want to put in the format of the Notify payload.
Again, this is taken directly from the IKEv2 document. If you decide to
do this, it would be placed at the end of the section 5. but directly
preceding 5.1.
The Notify Payload is defined as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Notification Payload Format
o Protocol ID (1 octet) - If this notification concerns
an existing SA, this field indicates the type of that SA.
For IKE_SA notifications, this field MUST be one (1). For
notifications concerning IPsec SAs this field MUST contain
either (2) to indicate AH or (3) to indicate ESP. For
notifications which do not relate to an existing SA, this
field MUST be sent as zero and MUST be ignored on receipt.
All other values for this field are reserved to IANA for future
assignment.
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE_SA, the SPI Size MUST be zero.
o Notify Message Type (2 octets) - Specifies the type of
notification message.
o SPI (variable length) - Security Parameter Index.
o Notification Data (variable length) - Informational or error data
transmitted in addition to the Notify Message Type. Values for
this field are type specific (see below).
------------------------------------------------------------------------
----
The suggestion to put in the notify payload format is optional. The
other suggestions I think are more relevant.
-- Maureen
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.