On Fri, Jan 08, 2010 at 07:39:47AM +0530, Jack Kohn wrote: > > Yes, but it's useful to know what they could possibly do. If a > > middlebox wants to drop all encrypted IPsec traffic then it needs to > > know if it's encrypted. Knowing WESP -> ESP-null, ESP -> unknown, is > > sufficient. > > Yup, and this is what i was alluding to. All middle boxes may not want > to drop all encrypted traffic, which is why i said that such boxes > must do what their local policy dictates. > > If the local policy dictates, marking all encrypted packets as low > priority, then it must mark all ESP traffic as low prio, as it has no > way of knowing whether the incoming traffic is ESP or ESP-NULL. > > This is what i had meant in my original mail.
That's what I thought. > > Anyone who might want to configure middle boxes to drop ESP-!null is not > > really going to be helped by having a WESP "encrypted bit" -- either way > > they'll have to have a flag day when they impose this policy. > > Yes, if the intent is to drop all encrypted packets. > > However, it can help, if the intent is to do separate processing for > null and encrypted packets. In case of vanilla ESP, we will also have > some false negatives, which may not be desired. Yeah, but if the action to be taken is anything other than "drop" then the false positives do little harm. Also, anything QoS related should really happen outside ESP anyways. What are we left with? Auditing/ logging based on deep inspection? But then you're back to the question of just how paranoid one can get. If you trust the end-points then you might as well trust them to use WESP and ESP-!null as appropriate, else you can't win. This is why I don't see the need for WESP to wrap ESP-!null. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
