Subject: [IPsec] Marking ESP-NULL packets

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Aug 2008 16:04:36 +0300

Hi

I've re-read the thread we had 2-3 weeks ago about the rationale for  
ESP-NULL marking, and I have to say that I'm still not convinced that  
this is a good idea.

I agree that there's no way to transmit to middleware boxes the fact  
that an SA is ESP-NULL without a new protocol. But a new protocol has  
some major drawbacks. It's not enough to have both endpoints support  
this new protocol - all middleboxes need to support it, and that will  
take many years.

Now let's look at the problem. We have two nodes, one on either "side"  
of the middlebox, that are communicating using ESP (or whatever  
replacement we define for it). They're allowed to use NULL encryption,  
but not allowed to use another cipher. That's so the middlebox can,  
say, allow only HTTP and FTP, and inspect transfered files for  
viruses. The "attackers" in this case are endpoints who negotiate and  
use ESP with a real cipher. How hard is it to distinguish random data  
from a regular TCP (or UDP, or SCTP) packet?  routers, operating  
systems and such do it very easily. So assuming that the traffic is  
ESP-NULL and dropping things that don't match the security policy is  
such a good heuristic, that it will work every time.  I can't see why  
as a firewall manufacturer, I need to learn this new XESP just to  
inspect it like a regular packet.

If there is some reason to do this that I'm missing, the IPsec  
standards already have a protected-but-not-encrypted way to mark  
packets. Why not make AH work?  You could easily make a variant of AH  
that treats the IP addresses and TCP/UDP ports as mutable fields, and  
negotiate this variation in IKE. The advantage of this, is that you  
don't change the format of the AH packet, so the middlebox can still  
inspect it just like regular AH.  We may or may not want to mark the  
packets (there are 16 reserved bits on the AH header) to hint the  
middleboxes that it's OK to NAT this packet.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Sun, 31 Aug 2008 07:18:43 +0300

On Aug 29, 2008, at 5:03 AM, Stephen Kent wrote:

> I don't think it is fair to say that all middleboxes need to support  
> a new IPsec header, such as the one that has been proposed for XESP.  
> Only middleboxes that need to examine content and that operate in an  
> environment where IPsec is in use (primarily on an E-to-E basis?)  
> will need to become aware of a new header.

I agree, but in today's Internet, end-to-end paths will have some  
middleboxes along the path that actually do examine the content to  
some extent: firewalls, IPS devices, and NAT devices.

>> Now let's look at the problem. We have two nodes, one on either  
>> "side" of the middlebox, that are communicating using ESP (or  
>> whatever replacement we define for it). They're allowed to use NULL  
>> encryption, but not allowed to use another cipher. That's so the  
>> middlebox can, say, allow only HTTP and FTP, and inspect transfered  
>> files for viruses. The "attackers" in this case are endpoints who  
>> negotiate and use ESP with a real cipher. How hard is it to  
>> distinguish random data from a regular TCP (or UDP, or SCTP)  
>> packet?  routers, operating systems and such do it very easily. So  
>> assuming that the traffic is ESP-NULL and dropping things that  
>> don't match the security policy is such a good heuristic, that it  
>> will work every time.  I can't see why as a firewall manufacturer,  
>> I need to learn this new XESP just to inspect it like a regular  
>> packet.
>
> I  don't recall seeing a concise description of the (range of)  
> security policies the proponents of his solution believe motivate  
> this solution approach. (If I missed the message that did this,  
> please excuse me, and provide a copy of the message.)

See discussion in the archives from 6-Aug and 7-Aug entitled  
"Motivation for ESP-null marking", particularly two responses from Ken  
Grewal.

> Absent such a characterization, we can't determine if simpler  
> solutions are preferable. However, even if the only policy to be  
> enforced is the one described above, it is not clear that is is  
> "easy" for a middlebox to  measure the entropy in packet payloads  
> (at high data rates). Some additional justification for this  
> assertion would be helpful.

As you've said, it's only the middlebox that inspects the packets, and  
they already do it at the same data rate. It's not really necessary to  
measure entropy. They only need to run their usual inspection, and get  
random data instead of the protocol they were expecting.

>> packets. Why not make AH work?
>
> AH is inefficient, compared to ESP-NULL. That's why 4301 downgraded  
> support for it to a MAY vs. a MUST.

Why is AH inefficient?  The integrity protection is similar to ESP  
except that you sign some extra fields (or set them to zero). I was  
under the impression that AH was downgraded because NAT boxes break it.

>> You could easily make a variant of AH that treats the IP addresses  
>> and TCP/UDP ports as mutable fields, and negotiate this variation  
>> in IKE. The advantage of this, is that you don't change the format  
>> of the AH packet, so the middlebox can still inspect it just like  
>> regular AH.  We may or may not want to mark the packets (there are  
>> 16 reserved bits on the AH header) to hint the
> Before we consider a variant of AH that provides even less integrity  
> protection, I think we need to have a lot of discussion of the  
> implications of this approach. Also If we create a variant of AH,  
> why is it less intrusive than a new protocol like XESP? We don't  
> carry version numbers in AH and ESP. We rely on IKE to negotiate  
> them, so a middlebox cannot know what version of AH is in use,  
> unless we assign a new protocol number, as has been sggested for XESP.

What I'm suggesting is to change the buffer that is integrity  
protected. The AH packet on the wire would look like regular AH, so  
the middlebox would not need to be aware of the changes. Only the  
endpoints need to be aware.