|Main Archive Page > Month Archives > ipsec archives|
Thanks Yoav - you hit the nail on the head and I do like the 'deep inspection welcome' bit instead of the 'insecure bit', as the packet is still integrity protected.
As for the processing time overhead, please see my other response on this thread where the proposed solution is deterministic and 'HW friendly', as well as motivation for doing this in HW.
>From: email@example.com [mailto:firstname.lastname@example.org] On Behalf
>Sent: Wednesday, August 06, 2008 1:08 PM
>To: Nicolas Williams
>Subject: Re: [IPsec] Motivation for ESP-null marking
>On Aug 6, 2008, at 7:47 PM, Nicolas Williams wrote:
>>> * What is the security/threat environment that we are dealing
>>> In other words, what is the security policy for which we want an
>>> efficient enforcement?
>> Clearly the security policy would be: use confidentiality protection.
>> Of course, there's no way to ensure that the SAs' keys haven't be
>> public or otherwise shared with interested third parties. That's
>> makes ESP-null marking seem silly -- it's like the reverse of the
>> "secure" bit gag, an "insecure" bit which tells you nothing about the
>> security of packets that don't have that bit set.
>I don't think this was the author's intention. The two parties could
>of course use AES and post their secret keys to Wikipedia, but if the
>policy is to drop marked ESP-NULL packets, all the parties really have
>to do, is to negotiate ESP-NULL and use the old ESP with no markings.
>I think the policy is "don't send encrypted stuff out, because I (the
>middlebox) want to deep inspect all traffic". That would translate to
>dropping all ESP-non-NULL traffic. Otherwise, I agree that an
>"insecure" bit is ridiculous. A "deep inspection welcome" bit is less
>But you can't just pass the packet marked as ESP-NULL - you need to
>really make sure they're not running encrypted stuff, and also you
>need to deep inspect. So the question is whether it really adds any
>processing time to make sure a packet is really not encrypted, given
>that you're running all kinds of other filtering.