Motivation for ESP-null marking

headers Yoav Nir | 6 Aug 2008 22:12

Thinking it over, it doesn't have to be very deep inspection. It could  
be as simple as "drop all FTP, even if it's tunneled"

On Aug 6, 2008, at 11:07 PM, Yoav Nir wrote:

>
> On Aug 6, 2008, at 7:47 PM, Nicolas Williams wrote:
>
> <snip>
>>>  * What is the security/threat environment that we are dealing with?
>>>    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  
>> made
>> public or otherwise shared with interested third parties.  That's  
>> what
>> 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 so.
>
> 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.

Re: Motivation for ESP-null marking