pasi.ero...@nokia.com writes: > - A question: did the WG discuss the pros and cons of integrity > protecting the WESP header? (This does make WESP more complex to > implement, and currently the WESP header does not contain any data > that would benefit from integrity protection in any way.)
Thats is actually good question, as all of the data in the WESP header is verified by comparing it to data elsewhere (either in packet (Next Header) or data associated to SA (HdrLen, TrailerLen, flags)) already I do not think if protecting WESP header adds anything. I think that if we don't add it to ICV that could simplify implementations as the ICV calculations would be exactly same as they were before, so converting ESP -> WESP would be simple, by just insertting new header and changing protocol number. > - Section 2: "The bits are defined LSB first, so bit 0 would be the > least significant bit of the flags octet." This doesn't match the bit > numbering in Figure 2 (where bit 0 is the most significant bit). > However, the bit numbers are not really used anywhere, so I would just > suggest deleting this sentence. I earlier proposed change that would add those bit numbers to the text, so bit positions would be also given in other place than in the picture. See my earlier message http://www.ietf.org/mail-archive/web/ipsec/current/msg04761.html > - Section 2: the text about TrailerLen is a bit unclearly written -- > the offset from the end of the packet to the last byte of the payload > would be a negative number. I'd suggest phrasing this something like > the "The number of bytes following the payload data in the packet, in > octets: i.e. the total length of TFC Padding (normally not present for > unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), > and ESP ICV." TFC Padding cannot be included in the TrailerLen as it can be too large to expressed in 8 bits. Actually reading the description it would indicate that the Padding, Pad Length and Next Header at the end of packet would be included in the TrailerLen, which would mean that even that might not be expressed in 8 bits in octects. I originally only assumed it includes the ICV field length, nothing else. That is the only thing needed by the intermediate device, as it can see pad length and padding from the packet and it can also skip the TFC padding in the same way recipient will do. With the current wording the TrailerLen would be different for each packet depending how many bytes of padding there is, which will mean that final recipient needs to do some extra calculations while verifying its length is correct (i.e it cannot simply compare the TrailerLen to fixed value based on the SA (12 for HMAC-SHA1 etc), but it needs to calculate Pad Length + ICV length + 2 + TFC Padding length and see that it matches the TralerLen. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
