📄 rfc2407.txt
字号:
Piper Standards Track [Page 12]
RFC 2407 IP Security Domain of Interpretation November 1998
Attribute Types
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Group Description 3 B
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B
Compress Dictionary Size 8 B
Compress Private Algorithm 9 V
Class Values
SA Life Type
SA Duration
Specifies the time-to-live for the overall security
association. When the SA expires, all keys negotiated under
the association (AH or ESP) must be renegotiated. The life
type values are:
RESERVED 0
seconds 1
kilobytes 2
Values 3-61439 are reserved to IANA. Values 61440-65535 are
for private use. For a given Life Type, the value of the
Life Duration attribute defines the actual length of the
component lifetime -- either a number of seconds, or a number
of Kbytes that can be protected.
If unspecified, the default value shall be assumed to be
28800 seconds (8 hours).
An SA Life Duration attribute MUST always follow an SA Life
Type which describes the units of duration.
See Section 4.5.4 for additional information relating to
lifetime notification.
Group Description
Specifies the Oakley Group to be used in a PFS QM
negotiation. For a list of supported values, see Appendix A
of [IKE].
Piper Standards Track [Page 13]
RFC 2407 IP Security Domain of Interpretation November 1998
Encapsulation Mode
RESERVED 0
Tunnel 1
Transport 2
Values 3-61439 are reserved to IANA. Values 61440-65535 are
for private use.
If unspecified, the default value shall be assumed to be
unspecified (host-dependent).
Authentication Algorithm
RESERVED 0
HMAC-MD5 1
HMAC-SHA 2
DES-MAC 3
KPDK 4
Values 5-61439 are reserved to IANA. Values 61440-65535 are
for private use.
There is no default value for Auth Algorithm, as it must be
specified to correctly identify the applicable AH or ESP
transform, except in the following case.
When negotiating ESP without authentication, the Auth
Algorithm attribute MUST NOT be included in the proposal.
When negotiating ESP without confidentiality, the Auth
Algorithm attribute MUST be included in the proposal and the
ESP transform ID must be ESP_NULL.
Key Length
RESERVED 0
There is no default value for Key Length, as it must be
specified for transforms using ciphers with variable key
lengths. For fixed length ciphers, the Key Length attribute
MUST NOT be sent.
Key Rounds
RESERVED 0
There is no default value for Key Rounds, as it must be
specified for transforms using ciphers with varying numbers
of rounds.
Piper Standards Track [Page 14]
RFC 2407 IP Security Domain of Interpretation November 1998
Compression Dictionary Size
RESERVED 0
Specifies the log2 maximum size of the dictionary.
There is no default value for dictionary size.
Compression Private Algorithm
Specifies a private vendor compression algorithm. The first
three (3) octets must be an IEEE assigned company_id (OUI).
The next octet may be a vendor specific compression subtype,
followed by zero or more octets of vendor data.
4.5.1 Required Attribute Support
To ensure basic interoperability, all implementations MUST be
prepared to negotiate all of the following attributes.
SA Life Type
SA Duration
Auth Algorithm
4.5.2 Attribute Parsing Requirement (Lifetime)
To allow for flexible semantics, the IPSEC DOI requires that a
conforming ISAKMP implementation MUST correctly parse an attribute
list that contains multiple instances of the same attribute class, so
long as the different attribute entries do not conflict with one
another. Currently, the only attributes which requires this
treatment are Life Type and Duration.
To see why this is important, the following example shows the binary
encoding of a four entry attribute list that specifies an SA Lifetime
of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a
complete description of the attribute encoding format.)
Attribute #1:
0x80010001 (AF = 1, type = SA Life Type, value = seconds)
Attribute #2:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x00015180 (value = 0x15180 = 86400 seconds = 24 hours)
Attribute #3:
0x80010002 (AF = 1, type = SA Life Type, value = KB)
Piper Standards Track [Page 15]
RFC 2407 IP Security Domain of Interpretation November 1998
Attribute #4:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x000186A0 (value = 0x186A0 = 100000KB = 100MB)
If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED
Notification Payload SHOULD be returned and the security association
setup MUST be aborted.
4.5.3 Attribute Negotiation
If an implementation receives a defined IPSEC DOI attribute (or
attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT
SHOULD be sent and the security association setup MUST be aborted,
unless the attribute value is in the reserved range.
If an implementation receives an attribute value in the reserved
range, an implementation MAY chose to continue based on local policy.
4.5.4 Lifetime Notification
When an initiator offers an SA lifetime greater than what the
responder desires based on their local policy, the responder has
three choices: 1) fail the negotiation entirely; 2) complete the
negotiation but use a shorter lifetime than what was offered; 3)
complete the negotiation and send an advisory notification to the
initiator indicating the responder's true lifetime. The choice of
what the responder actually does is implementation specific and/or
based on local policy.
To ensure interoperability in the latter case, the IPSEC DOI requires
the following only when the responder wishes to notify the initiator:
if the initiator offers an SA lifetime longer than the responder is
willing to accept, the responder SHOULD include an ISAKMP
Notification Payload in the exchange that includes the responder's
IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the
RESPONDER-LIFETIME Notification Message type which MUST be used for
this purpose.
4.6 IPSEC Payload Content
The following sections describe those ISAKMP payloads whose data
representations are dependent on the applicable DOI.
4.6.1 Security Association Payload
The following diagram illustrates the content of the Security
Association Payload for the IPSEC DOI. See Section 4.2 for a
description of the Situation bitmap.
Piper Standards Track [Page 16]
RFC 2407 IP Security Domain of Interpretation November 1998
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 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (IPSEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation (bitmap) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Labeled Domain Identifier !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integrity Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integ. Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Security Association Payload Format
The Security Association Payload is defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of
the next payload in the message. If the current payload is the
last in the message, this field will be zero (0).
o RESERVED (1 octet) - Unused, must be zero (0).
o Payload Length (2 octets) - Length, in octets, of the current
payload, including the generic header.
o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
which has been assigned the value one (1).
o Situation (4 octets) - Bitmask used to interpret the remainder
of the Security Association Payload. See Section 4.2 for a
complete list of values.
Piper Standards Track [Page 17]
RFC 2407 IP Security Domain of Interpretation November 1998
o Labeled Domain Identifier (4 octets) - IANA Assigned Number used
to interpret the Secrecy and Integrity information.
o Secrecy Length (2 octets) - Specifies the length, in octets, of
the secrecy level identifier, excluding pad bits.
o RESERVED (2 octets) - Unused, must be zero (0).
o Secrecy Level (variable length) - Specifies the mandatory
secrecy level required. The secrecy level MUST be padded with
zero (0) to align on the next 32-bit boundary.
o Secrecy Category Length (2 octets) - Specifies the length, in
bits, of the secrecy category (compartment) bitmap, excluding
pad bits.
o RESERVED (2 octets) - Unused, must be zero (0).
o Secrecy Category Bitmap (variable length) - A bitmap used to
designate secrecy categories (compartments) that are required.
The bitmap MUST be padded with zero (0) to align on the next
32-bit boundary.
o Integrity Length (2 octets) - Specifies the length, in octets,
of the integrity level identifier, excluding pad bits.
o RESERVED (2 octets) - Unused, must be zero (0).
o Integrity Level (variable length) - Specifies the mandatory
integrity level required. The integrity level MUST be padded
with zero (0) to align on the next 32-bit boundary.
o Integrity Category Length (2 octets) - Specifies the length, in
bits, of the integrity category (compartment) bitmap, excluding
pad bits.
o RESERVED (2 octets) - Unused, must be zero (0).
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -