Subject: Re: [IPsec] Marking ESP-NULL packets

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Sep 2008 12:08:55 -0400

At 7:18 AM +0300 8/31/08, Yoav Nir wrote:
>...
>
>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.

It depends on where you are :-), and the policy of the boxes in 
question. An IDS might LIKE to examine content, but if if does not 
have a tight link to a firewall, it may just be disappointed by an 
inability to examine content.

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

I'll go back and check; thank's for the pointer.

>...
>
>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.

maybe, maybe not. And

>...
>
>  > 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.

AH is inefficient because one has to "hopscotch" through the IP 
header to compute the ICV. ESP is more efficient because the 
encapsulation is "clean." AH was mildly deprecated in large part 
because of this distinction.

>...
>  >
>>  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.

Your response does not address the first part of my concern, i.e., 
the reduced security offered by a less stringent version of AH, but I 
understand your point that middleboxes need not know the difference, 
IF the format is the same.

I'm guessing, by your comments above re NATs and AH, why you were 
thinking about a new version of AH that would be NAT friendly and 
allow middlebox examination of payloads.  However, even if we develop 
such a version, it is likely to suffer from the same performance 
problems as the current version of AH.

Steve
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 2 Sep 2008 15:13:15 -0600

I agree with Steve's comments from below that AH is probably not the way forward to resolve this.

The two reasons cited are...
- Inability to operate under NAT environments, which would require additional changes to the protocol, so why not use ESP as a base for the changes instead of AH? NATs will be around for the foreseeable future; even as we migrate to IPv6 where in addition to tunneling techniques, we will encounter translation techniques (see renewed interest in specifying a standards-based replacement for NAT-PT).

- Performance costs (especially in HW) due to mutable fields in the headers that need to be removed from the ICV calculation.

There have been extensive debates on deprecating AH based on these and other reasons and proposing to extend AH now will require revisiting those topics again.

Separately, the policy applied by intermediate devices can be dependent on the functionality required and the capabilities of that device and hence vary case by case. An IDS/IPS is one example of such a device. I cited some simple examples of these policies and will let others provide more extensive use cases.

Currently, IT departments often choose to forego IPsec in favor of having network management tools perform routine network functions. The ability to use IPsec AND preserve the existing (and future) network monitoring/diagnostics tools using a simple ESP wrapper further enables the application of IPsec beyond the VPN/remote access environments of today.

Thanks,
- Ken

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Stephen Kent
>Sent: Tuesday, September 02, 2008 9:09 AM
>To: Yoav Nir
>Cc: [email-masked]
>Subject: Re: [IPsec] Marking ESP-NULL packets
>