Subject: [secdir] Review of draft-ietf-ipsecme-traffic-visibility-11

From: Sean Turner <[email-masked]>
Date: Tue, 08 Dec 2009 18:54:06 -0500

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

Document Abstract:

This document describes the Wrapped Encapsulating Security Payload 
(WESP) protocol, which builds on the Encapsulating Security Payload 
(ESP) [RFC4303], and is designed to allow intermediate devices to (1) 
ascertain if data confidentiality is being employed within ESP and if 
not, (2) inspect the IPsec packets for network monitoring and access 
control functions.

I don't have any comments on the technical contents of the ID.

But, I do have a comment w.r.t. the approach.*  It seems to me that what 
you're looking for is an indication early on that the coming packets are 
encrypted or not.  Don't we already have that with the 50/51 value in 
the protocol header (IPv4, IPv6, or Extension) immediately preceding the 
ESP/AH header.  Why don't we use that as the indication, prohibit those 
NULL encryption algorithms, and then we're done?  We don't have to worry 
about implementing this protocol, the heuristics algorithm in the other 
I-D, and we don't have to complicate the adoption of ESP/AH?

spt

* The only rationale I saw was in the 3rd paragraph of the introduction 
that says AH doesn't work in NAT environments.  Is that really the 
entire reason?  I thought we were trying to kill NATS?

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 9 Dec 2009 16:40:22 +0000

Hi Sean, thanks for the review.

As you noted, the WG decided not to use AH as NATs are unavoidable and a fact of life. Not sure if there were many other reasons, but this one seems to be a show-stopper if one wants to deploy this in any real scenario. 

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Tuesday, 08 December, 2009 3:54 PM
> To: secdir; [email-masked]
> Subject: Review of draft-ietf-ipsecme-traffic-visibility-11
> 
> These comments were written primarily for the benefit of the security area
> directors. Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> Document Abstract:
> 
> ascertain if data confidentiality is being employed within ESP and if not,
> (2) inspect the IPsec packets for network monitoring and access control
> functions.
> 
> encrypted or not.  Don't we already have that with the 50/51 value in the
> protocol header (IPv4, IPv6, or Extension) immediately preceding the
> about implementing this protocol, the heuristics algorithm in the other I-
> D, and we don't have to complicate the adoption of ESP/AH?
> 
> spt
> 
> that says AH doesn't work in NAT environments.  Is that really the entire
> reason?  I thought we were trying to kill NATS?

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 11 Dec 2009 10:22:25 +0530

Hi Sean,

In addition to what Gabriel said, the other issue with AH is that the work involved in taking out the fields that are immutable, hashing the packet and sticking those immutable fields back can be quite challenging. One needs to know the contents surrounding the IP header to calculate the AH field which violates the layering and raises interesting challenges for HW based Ipsec implementations.

Almost all IETF standards (e.g. RFC 4552) that explicitly define how IPSec needs to be used for authentication state ESP-NULL as a MUST and AH as a MAY. I don't think there is any RFC that states AH as MUST. This could also be because RFC 4301 deprecated the use of AH from a MUST to a MAY. It is for these reasons that ESP-NULL is widely implemented and I know of at least two major router vendors that don't even implement the AH standard.

AH has its own use and is really not equivalent to ESP-NULL. If there are intermediaries that are changing the IP addresses then ESP-NULL will not detect the IP address spoof and AH is the only standard that can detect this (i.e. if you care about this). OTOH, if you know that your IP addresses can change, and you want to verify the integrity of the payload then ESP-NULL is the only protocol that can be used!

Cheers, Manav

> From: Gabriel Montenegro [mailto:[email-masked]] 
> Sent: Wednesday, December 09, 2009 10.10 PM
> To: Sean Turner; secdir; 
> [email-masked]
> Subject: RE: Review of draft-ietf-ipsecme-traffic-visibility-11
> 
> As you noted, the WG decided not to use AH as NATs are 
> unavoidable and a fact of life. Not sure if there were many 
> other reasons, but this one seems to be a show-stopper if one 
> wants to deploy this in any real scenario. 
>