| From: Andreas Steffen <[EMAIL PROTECTED]>
| The Cisco | Client appends 16 zero bytes to the MI1 proposal that are not | accounted for in the length field. Has anyone else experienced this | phenomenon?
I've not heard of it before. That is quite surprising to me. I've not seen this problem with any interop that I can remember -- Cisco is being quite creative.
| Is Pluto too strict? Shouldn't it just ignore | the superflous bytes as is the case when payloads get padded up to | a multiple of four bytes (e.g. with certificate requests)?
This is the kind of thing that isn't spelled out well in the RFCs. When it is described, it is often not described well, or not in an obvious place.
I found the following on page 57 of RFC 2408 (ISAKMP):
Every ISAKMP message has basic processing applied to insure protocol reliability, and to minimize threats, such as denial of service and replay attacks. All processing SHOULD include packet length checks to insure the packet received is at least as long as the length given in the ISAKMP Header. If the ISAKMP message length and the value in the Payload Length field of the ISAKMP Header are not the same, then the ISAKMP message MUST be rejected. The receiving entity (initiator or responder) MUST do the following:
1. The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the
appropriate system audit file. 2. An Informational Exchange with a Notification payload containing
the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.So I think that Pluto is behaving correctly and Cisco is not.
Hugh Redelmeier [EMAIL PROTECTED] voice: +1 416 482-8253
-----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv
iQCVAwUBPy7A/MFAuQPManGZAQFlAgP+N5al4ok8syEbwByOF8aRN7c+SrNPl3zV XJKL4hN4RxQ+m45ZIiJGHxYzmlAYNHN1Ti6VNiCgJzm+Ya6aXG+QcPeK6IatqwOg DsyTk2IeFqUPluFiCVUQ63l6NiqU+0STGNEaJozRqOZUDEXIKsEMIUY7LwLStXvZ Chl5cSSVMCM= =Ob9P -----END PGP SIGNATURE-----
