gabriel montenegro writes: > Perhaps we need more details on what exactly we mean by "the > endpoint thus must verify the sanity of the WESP header before accepting > the packet"? And the action to drop the offending packet?
Yes. I think we need very specific rules with MUSTs in them to say that packet MUST be dropped if ESP-NULL packet has Next header field in WESP header which do not match the real Next Header field in the end. Also final recipient MUST check that the HdrLen or TrailerLen fields in the WESP header match the negotiate SA and MUST drop the packet if they do not match. Next question is what values are used for HdrLen and TrailerLen if encrypted ESP is used. If we use real values we do leak out information, but on the other hand there is no point of giving that information out as middle nodes cannot do anything with it. Actually what are we trying to do if we send encrypted ESP with WESP wrapper. If we are just making so that we can extend the WESP header in the future, isn't the version bits enough for that? I mean if we do not know why someone would want to use WESP encoding for encrypted ESP now, why do we allow it? -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
