Yoav, > Oh, and one more thing: I’d really appreciate it if somebody checked my > examples. All I can be sure of is that they work in my code.
I've hit two issues when verifying the IKEv2 example in our code: >From appendix B: > Padding as required by RFC 7296 is 4 bytes long. Do we have such a padding requirement for IKEv2? For ChaCha20 we have no requirement for input lengths, so no padding is needed. While we have 4 byte padding in ESP, I don't think this is true for IKEv2 Encrypted Payloads, is it? >From RFC 7296 3.14: > o Padding MAY contain any value chosen by the sender, and MUST have > a length that makes the combination of the payloads, the Padding, > and the Pad Length to be a multiple of the encryption block size. > This field is encrypted with the negotiated cipher. > > o Pad Length is the length of the Padding field. The sender SHOULD > set the Pad Length to the minimum value that makes the combination > of the payloads, the Padding, and the Pad Length a multiple of the > block size, but the recipient MUST accept any length that results > in proper alignment. This field is encrypted with the negotiated > cipher. So while the used padding is not invalid, it is not what we SHOULD use, and if so probably not a good example. Maybe we should also add a note about IKEv2 padding to section 3? The other issue I've seen is about the Next Payload: > Encrypted Payload: > 000 00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70 ...,........a..p The Next Payload field in the Encrypted Payload is 0. However, RFC 7296 defines: > Next Payload - The payload type of the first embedded payload. So I think Next Payload should be Notify (0x29). Kind Regards Martin _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
