📄 rfc2522.txt
字号:
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 (inKarn & 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 19992.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 particularKarn & 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 schemes3.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 (modulo 256), the value is set to one. If this new Counter value matches some previous exchange initiated by this particular peer that has not yet exceeded the Exchange TimeOut,Karn & Simpson Experimental [Page 15] RFC 2522 Photuris Protocol March 1999 the Counter is incremented again, until a unique Counter value is reached. Nota Bene: No more than 254 concurrent exchanges between the same two peers are supported. The Responder generates a unique cookie. The Responder-Cookie value in each successive response SHOULD be different. See "Cookie Generation" for details. The Exchange-Schemes available between the peers are listed in the Offered-Schemes.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -