> > 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. Ok, we will remove he talbe and only keep reference. > > > 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. So, we will add sentences in section 3 (encrypted payload) to enphasize again that: sender is not required to pad plaintext; pad SHOULD be zero following the "SHOULD be minimun" in rfc4306; also the difference of pad requirement between ikev2 and esp will be helpful here.
Thanks, Sean _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
