📄 rfc2522.txt
字号:
When the event is an ICMP message, special care MUST be taken that
the ICMP message actually includes information that matches a
previously sent IP datagram. Otherwise, this could provide an
opportunity for a clogging attack, by stimulating a new Photuris
Exchange.
2.1. UDP
All Photuris messages use the User Datagram Protocol header [RFC-
768]. The Initiator sends to UDP Destination Port 468.
When replying to the Initiator, the Responder swaps the IP Source and
Destination, and the UDP Source and Destination Ports.
The UDP checksum MUST be correctly calculated when sent. When a
message is received with an incorrect UDP checksum, it is silently
discarded.
Karn & Simpson Experimental [Page 9]
RFC 2522 Photuris Protocol March 1999
Implementation Notes:
It is expected that installation of Photuris will ensure that UDP
checksum calculations are enabled for the computer operating
system and later disabling by operators is prevented.
Internet Protocol version 4 [RFC-791] restricts the maximum
reassembled datagram to 576 bytes.
When processing datagrams containing variable size values, the
length must be checked against the overall datagram length. An
invalid size (too long or short) that causes a poorly coded
receiver to abort could be used as a denial of service attack.
2.2. Header Format
All of the messages have a format similar to the following, as
transmitted left to right in network order (most significant to least
significant):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message |
+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes.
Responder-Cookie 16 bytes.
Message 1 byte. Each message type has a unique value.
Initial values are assigned as follows:
Karn & Simpson Experimental [Page 10]
RFC 2522 Photuris Protocol March 1999
0 Cookie_Request
1 Cookie_Response
2 Value_Request
3 Value_Response
4 Identity_Request
5 Secret_Response (optional)
6 Secret_Request (optional)
7 Identity_Response
8 SPI_Needed
9 SPI_Update
10 Bad_Cookie
11 Resource_Limit
12 Verification_Failure
13 Message_Reject
Further details and differences are elaborated in the individual
messages.
2.3. Variable Precision Integers
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Size 2, 4, or 8 bytes. The number of significant bits
used in the Value field. Always transmitted most
significant byte first.
When the Size is zero, no Value field is present;
there are no significant bits. This means "missing"
or "null". It should not be confused with the value
zero, which includes an indication of the number of
significant bits.
When the most significant byte is in the range 0
through 254 (0xfe), the field is 2 bytes. Both
bytes are used to indicate the size of the Value
field, which ranges from 1 to 65,279 significant
bits (in 1 to 8,160 bytes).
When the most significant byte is 255 (0xff), the
field is 4 bytes. The remaining 3 bytes are added
to 65,280 to indicate the size of the Value field,
which is limited to 16,776,959 significant bits (in
Karn & Simpson Experimental [Page 11]
RFC 2522 Photuris Protocol March 1999
2,097,120 bytes).
When the most significant 2 bytes are 65,535
(0xffff), the field is 8 bytes. The remaining 6
bytes are added to 16,776,960 to indicate the size
of the Value field.
Value 0 or more bytes. Always transmitted most
significant byte first.
The bits used are right justified within byte
boundaries; that is, any unused bits are in the most
significant byte. When there are no unused bits, or
unused bits are zero filled, the value is assumed to
be an unsigned positive integer.
When the leading unused bits are ones filled, the
number is assumed to be a two's-complement negative
integer. A negative integer will always have at
least one unused leading sign bit in the most
significant byte.
Shortened forms SHOULD NOT be used when the Value includes a number
of leading zero significant bits. The Size SHOULD indicate the
correct number of significant bits.
Implementation Notes:
Negative integers are not required to be supported, but are
included for completeness.
No more than 65,279 significant bits are required to be supported.
Other ranges are vastly too long for these UDP messages, but are
included for completeness.
Karn & Simpson Experimental [Page 12]
RFC 2522 Photuris Protocol March 1999
2.4. Exchange-Schemes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheme | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheme 2 bytes. A unique value indicating the Exchange-
Scheme. See the "Basic Exchange-Schemes" for
details.
Size 2 bytes, ranging from 0 to 65,279. See "Variable
Precision Integer".
Value 0 or more bytes. See "Variable Precision Integer".
The Size MUST NOT be assumed to be constant for a particular Scheme.
Multiple kinds of the same Scheme with varying Sizes MAY be present
in any list of schemes.
However, only one of each Scheme and Size combination will be present
in any list of schemes.
2.5. Attributes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 1 byte. A unique value indicating the kind of
attribute. See the "Basic Attributes" for details.
When the value is zero (padding), no Length field is
present (always zero).
Length 1 byte. The size of the Value(s) field in bytes.
When the Length is zero, no Value(s) field is
present.
Value(s) 0 or more bytes. See the "Basic Attributes" for
details.
The Length MUST NOT be assumed to be constant for a particular
Karn & Simpson Experimental [Page 13]
RFC 2522 Photuris Protocol March 1999
Attribute. Multiple kinds of the same Attribute with varying Lengths
MAY be present in any list of attributes.
3. Cookie Exchange
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
3.0.1. Send Cookie_Request
The Initiator initializes local state, and generates a unique
"cookie". The Initiator-Cookie MUST be different in each new
Cookie_Request between the same parties. See "Cookie Generation" for
details.
- If any previous exchange between the peer IP nodes has not expired
in which this party was the Initiator, this Responder-Cookie is
set to the most recent Responder-Cookie, and this Counter is set
to the corresponding Counter.
For example, a new Virtual Private Network (VPN) tunnel is about
to be established to an existing partner. The Counter is the same
value received in the prior Cookie_Response, the Responder-Cookie
remains the same, and a new Initiator-Cookie is generated.
- If the new Cookie_Request is in response to a message of a
previous exchange in which this party was the Responder, this
Responder-Cookie is set to the previous Initiator-Cookie, and this
Counter is set to zero.
For example, a Bad_Cookie message was received from the previous
Initiator in response to SPI_Needed. The Responder-Cookie is
replaced with the Initiator-Cookie, and a new Initiator-Cookie is
generated. This provides bookkeeping to detect bogus Bad_Cookie
messages.
Also, can be used for bi-directional User, Transport, and Process
oriented keying. Such mechanisms are outside the scope of this
document.
- Otherwise, this Responder-Cookie and Counter are both set to zero.
Karn & Simpson Experimental [Page 14]
RFC 2522 Photuris Protocol March 1999
By default, the Initiator operates in the same manner as when all
of its previous exchange state has expired. The Responder will
send a Resource_Limit when its own exchange state has not expired.
The Initiator also starts a retransmission timer. If no valid
Cookie_Response arrives within the time limit, the same
Cookie_Request is retransmitted for the remaining number of
Retransmissions. The Initiator-Cookie value MUST be the same in each
such retransmission to the same IP Destination and UDP Port.
When Retransmissions have been exceeded, if a Resource_Limit message
has been received during the exchange, the Initiator SHOULD begin the
Photuris exchange again by sending a new Cookie_Request with updated
values.
3.0.2. Receive Cookie_Request
On receipt of a Cookie_Request, the Responder determines whether
there are sufficient resources to begin another Photuris exchange.
- When too many SPI values are already in use for this particular
peer, or too many concurrent exchanges are in progress, or some
other resource limit is reached, a Resource_Limit message is sent.
- When any previous exchange initiated by this particular peer has
not exceeded the Exchange TimeOut, and the Responder-Cookie does
not specify one of these previous exchanges, a Resource_Limit
message is sent.
Otherwise, the Responder returns a Cookie_Response.
Note that the Responder creates no additional state at this time.
3.0.3. Send Cookie_Response
The IP Source for the Initiator is examined. If any previous
exchange between the peer IP nodes has not expired, the response
Counter is set to the most recent exchange Counter plus one (allowing
for out of order retransmissions). Otherwise, the response Counter
is set to the request Counter plus one.
If (through rollover of the Counter) the new Counter value is zero
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -