Scott C Moonen writes: > 7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be > the last payload in the message. Often, it is the only payload in the > message." Out of curiosity, do we know of any cases where this payload is > not the only payload in the message? It strikes me as odd to allow for > some payloads prior to this one to be integrity protected but not > encrypted. I suppose since RFC 4306 allows it we don't have a lot of > wiggle room here.
For example older versions of the resumption draft used constructs where the had Nonce and some notifications before the encrypted payload, so that those could be used to find the state which is then used to decrypt the rest of the packet. Current version of the resumption does not use that kind of thing anymore, but some future version might use. Anyways currently there is no need to support other payloads before encrypted payload and if implementation would support such it would need to be very careful to keep the encrypted and authenticated payloads and cleartext and not-authenticated payloads separate when parsing the message. > > 8) Section 4, "Every implementation MUST be capable of responding to an > INFORMATIONAL exchange, but a minimal implementation MAY respond to any > INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true > even if the INFORMATIONAL request contained a Delete payload for a Child > SA? Yes. I.e. you can have minimal implementation which only supports exactly one IPsec SA and IKE SA and does not support rekeying or creating additional SAs using CREATE_CHILD_SA exchange. > 9) Appendix D -- we need to fill this in. I think that was moved to be section 1.7, so we should remove this appendix. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
