Sean Shen writes: > The point here is to say that integrity protection is needed with aes-ctr, > not trying to specify which integrity algorithm to choose. rfc4306 already > required integrity for ikev2 and we refered to 4306 here. The choice of > integrity algorithm is up to rfc4307 or some update document, we just listed > what rfc4307 chooses to make this document more rich of information. If you > think the table gives misleading impression of only requiring these > particular algorithms, we may add another sentence to hint that integrity > algorithm requirement may change over time, please check 4307 and 4307's > update, the following listed algorithm is just showing current 4307's > requirement.
I think it is better to remove the table, and just refer to RFC4307 directly. > > One thing that is not 100% clear from the draft is that > > whether there is any padding in the encrypted payload. > > RFC4306 says that encrypted part is padded up to the block > > size of the cipher. In AES-CTR the block size is 1, thus that > > does not require any padding. Normal ESP requires padding for > > at least up to 4-byte boundary, regardless of the block size > > of the cipher, thus even AES-CTR uses padding up to 4-byte > > boundary. The IKEv2 SA does not require thus. > > > > I think it would be better to add text explictly saying this. > > I.e. add text like this to the end of 2.3: > > > > ... For this > > reason, AES-CTR does not require the plaintext to be padded to a > > multiple of the block size. For Encrypted Payload this means that > > Padding field is always empty, and Pad Length field will always be > > 0. > I don't agree with this. Specifying Padding field to be empty and Pad Length > to be zero here is not proper, because rfc4306 requires that recipient MUST > accept any lenght that results in proper alignment (section 3.14). Yes, it MUST accept, and it says SHOULD set Pad Length to minimum value, which in this case is zero. I think it is important to note that no padding is required, thus Pad Length field can be zero, and if the SHOULD in the RFC4306 is followed it will be zero. As this is different from the ESP, I think it is important to note this difference. In ESP the padding length MUST be selected so that provides 4-byte alignment for the encrypted data, but for IKEv2 there is no such requirement, and this should be even more explictly mentioned in the draft. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
