At 11:57 PM +0200 1/22/10, Yaron Sheffer wrote: >The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might >be helpful. > >Here's a first shot (we'll need to add some descriptive text): > > SA Payload > | > ---------------............- > | | | > Proposal #1 Proposal #2 Proposal #n > ESP ESP > SPIx SPIy > | | > --------------------- -------------------- > | | | | > Transform A Tranform B Transform C Transform D > ENCR AUTH ENCR ESN > AES HMAC-SHA-256 AES-CCM ESN=1 > | > ----------------- > | | | >Attr Ax Attr Ay Attr Az > 128 192 256
In order for this not to be confusing, Transform A should be "ENCR" and "AES-CBC", and Transform C needs to (in fact, MUST) have at least one attribute specified. Transform B should be listed as "INTEG", not "AUTH". Further, is there a good reason for you to have not included an ESN transform on Proposal #1? Section 3.3 says "The number of different transforms is generally determined by the Protocol. ... ESP generally has three: ESN, an encryption algorithm and an integrity check algorithm." Ditto for Proposal #2: is there a good reason for you to not have included an INTEG transform? This begs the related question: given that there is no MUST or should for what goes into a Proposal, what does an ESP proposal that only has an ENCR and INTEG in it mean with respect to what is being proposed for ESN? What does an ESP proposal that has only an ENCR and ESN in it mean with respect to what is being proposed for INTEG? I see no MUSTs or SHOULDs answering this. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
