I agree in the most part. From other comments, it appears that the Next Header is providing a useful function and if we are keeping it anyway, then the Next Header value of zero also provide a useful function (i.e. payload protocol is opaque, hence data is encrypted).
I also agree that the text for packet handling by intermediate nodes and ultimate recipients could be improved and we need explicit verbiage (with MUSTs) to describe the behavior. Perhaps it would be useful to get an early next rev of the draft out with these changes to ensure that we have the correct verbiage in place... I will send out a separate summary of where we are with the open ticket items. >Yaron Sheffer writes: >> I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted >WESP. >> So yes, we use WESP for encrypted traffic to get: >> >> - Extensibility (with the 8-bit Flags field). > >This is future extensibility, which is needed only after we define >some future extensions using this. When we define those future >extensions we can also define that encrypted traffic can be used. > >I would rather keep this for future extension, i.e. only define the >use after we find out what we want to do, as all the end nodes needs >to be updated anyways before those new extensions can be used (and the >intermediate nodes too perhaps). > >The current document is not very clear what to do if reserved bits are >set. It says "On receiving a packet, these values must be checked to >ensure that they are as indicated above.". This does not specify >whether this is only for the final receiver (i.e. the node talking >IPsec), or also all intermediate nodes, or only those intermediate >nodes who actually look inside the WESP or what. It also does not >specify what needs to be done if those fields are not as specified. > >I.e. we need more text for that, i.e. specific processing rules for a) >intermediate nodes who parse WESP header, b) end IPsec entity. In some >cases the dropping / passbying the packet depends on the policy. On >the other hand if flags is set or version number does not match then >that usually means that the format of the WESP header might be >different thus it might be that intermediate nodes cannot parse header >any further. > >> - A single protocol that can do both cases. > >By wasting extra 4 bytes and using protocol which might not be >supported by other end. I think it is better to use plan normal ESP >for encrypted traffic, but I agree that we should probably define the >WESP header so that if Next Header in WESP header is 0 then contents >is encrypted, and intermediate nodes MUST NOT try to parse it. > >I would still recommend using normal ESP for encrypted traffic... >-- >kivi...@iki.fi >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
