Hi Alan, > I finally fixed this issue with RIM devices. The problem was the > Reserved Field in the IDi sent by the RIM. It was putting junk in this > field.
I see. > The RFC says the receiver should ignore the field and use zeros but > charon was using the junk. This is not true for this special case. While RESERVED fields should be ignored, here the full payload is part of the data that gets hashed for the AUTH payload. We initially used just zeros to create the hash, but the general consent is that it was wrong: we must use those bytes actually found in the RESERVED field [1]. We changed this some time ago to fix compatibility with other implementations. > It's just a simple one line change. It is, but I can't push this without breaking compatibility with other implementations. The best thing would be if RIM can fix these two RFC 5996 violations (or just one of them), send zero RESERVED bytes and use the RESERVED bytes to calculate the AUTH payload. If RIM is unable to fix this, we need a way to detect such broken devices (Vendor ID payload?) and use your work around just for them. Regards Martin [1]http://tools.ietf.org/html/rfc5996#section-2.15 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
