Hi Russ, If we are not willing to ever extend WESP then we might as well debate the alternative scheme that i had reviewed long time back (which was shot down citing WESP being more extensible). I see that we are going through the discussions that we've already had in the WG, things that had been decided by majority consensus, approved by everyone in the WG. With this being the case we might as well debate on whether we really want a new protocol type for WESP (again discussed long time back) or if we can just hijack one of the SPI values and treat all packets with that as ESP-NULL. Alternatively, since we seem to be having unlimited bandwidth for discussions, we might as well argue whether we need heuristics also or not, as there are very few people in IPSecMe WG who feel the need for it. Strangely, its that same set of people who are against the idea of using null NULL ciphers for WESP. Is it because by supporting encryption in WESP we make it more generic, and thereby increasing the chances of its widespread implementation as against the other proposal (heuristics)?
Jack On Sat, Dec 19, 2009 at 11:19 PM, Russ Housley <hous...@vigilsec.com> wrote: > Ken: > >> [Ken] I think this is the whole point. All the work on ESP/IPsec this far >> has been considering a two party interaction (outside the multicast >> context!). Now there is a third party - the middle box, which would like to >> gain some additional information in order to provide valuable network >> services. The end boxes already know what is being negotiated, so just >> making changes to IKE to add additional capability is insufficient in >> certain scenarios (while perfectly sufficient in others). We need to provide >> additional information in the data path, hence the need for WESP. > > I do not agree with your assessment of the situation. I agree with Tero's > thoughts. > > The IPsecME charter includes this work item: > > A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet. The starting points for this work item are > draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol. > > Nothing in this description prepared me for WESP processing of ESP packets > with a non-NULL-cipher. It suggests making it easy for the middlebox to > gain access to data that is already plaintext. It does not suggest making > information available to the middlebox that was previously unavailable to > it. > > Further, based on the discussion that has happened since I posted my DISCUSS > position, other IPsecME WG participants are uncomfortable with the direction > that WESP has taken. As the discussion progresses, if I can see that these > people and myself are in the rough, then I will clear. So far, that does > not seem to be the case. > > Russ > _______________________________________________ > 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
