Re: [IPsec] First charter draft

From: Grewal, Ken <ken.grewal_at_nospam>
Date: Fri Jun 06 2008 - 22:33:46 GMT
To: "Stephen Kent" <kent@bbn.com>, <Pasi.Eronen@nokia.com>

Hi Steve,
Many thanks for your observations. The initial draft was put together relatively quickly to solicit initial feedback and as you correctly point out, there are some obvious inconsistencies with citations and implicit inferences, instead of explicitly calling out the operations.

I have had other similar responses and suggestions (some outside of the IPsec reflector) and am actively incorporating these into an updated version of the draft, which I will publish shortly. Hopefully, this will help to simplify the payload parsing and essentially combine some of the ideas from both of the current drafts into a single place.

The motivation here is primarily inside the Enterprise and specifically transport mode, which are not the predominant uses of IPsec today. Having some of these capabilities will help to promote these usage models, hence expanding the scope of IPsec - at least IMHO!

Thanks,
- Ken

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Stephen Kent
Sent: Friday, June 06, 2008 9:11 AM
To: Pasi.Eronen@nokia.com
Cc: ipsec@ietf.org
Subject: Re: [IPsec] First charter draft

Pasi,

The I-D draft-grewal-ipsec-traffic-visibility has a number of presentation problems. The text refers to IVs and ICVs, without noting that only for combined mode algorithms would an IV be used in the context of null-encryption. Moreover, combined mode algorithm support was introduced only in ESPv2 (RFC 4303), but the I-D cites only ESP v1 (RFC 2406). Similarly, the text cites 2301, not 4301. In 2301, AH support is mandated, and so one could argue that in an enterprise context where intermediate systems need to examine packet contents, the enterprise could just mandate use of AH. In 4301, support for AH is no longer mandated, and so the encapsulation mechanism proposed in this I-D makes more sense. Thus I think that 4301 is the appropriate cite here. Also, IKEv2 is cited, and it is used only in the 4301 context, so ... The I-D doesn't explain how an intermediate system will determine the end of the real payload, to enable it to "further parse the packet to extract the data portion." That system needs to know the pad length. True, this can be determined by working back from the ICV length and the next header field, but the text fails to mention that. Moreover, if you have to do that processing, you could grab the next header field then, and not have it in the UDP encapsulation header. Finally, the explanation how to validate a UDP-encapsulated ESP-NULL packet, in the face of possible port conflicts appears to be underspecified. One can argue that if there is a viable heuristic to deal with this case, an intermediate system could perform these checks on ESP traffic, cache the SA info (by S/D host addresses and SPI values) and avoid the need for the encapsulation proposed here! This seems especially true given that the scope of this I-D appears to be traffic within an enterprise net, not the more general case of any intermediate system along a path, perhaps at the boundary between an enterprise net and the public internet.

In contrast, the draft-hoffman-esp-null-protocol I-D is very simple and does not impose the burden of an extra encapsulation layer. However it consumes two protocol numbers from a space that has traditionally been consider relatively scarce. Also, these two numbers might not suffice if additional combined mode algorithms, with different IV lengths, are adopted in the future. This I-D needs more details discussing exactly how an intermediate system will perform the necessary packet inspection. Finally, because this I-D tries to address the more general case of an intermediate system along a path (anywhere?), it require more discussion of what set of policies make sense in the more general context. (I think this is needed to that folks don't jump to inaccurate conclusions about what such a facility will buy them.)

So, like Tero, I am not convinced that this topic should be a high priority for the new IPsec WG. I have not yet looked at the GRE proposal, but I do not that defining additional selector values may pose problems for folks who have designed hardware that relies on the fact that the set of selectors has remained fairly static for many years. Also, I agree with Tero that we need to understand very thoroughly why there is a need to use additional data as traffic selectors, so that we don't set a precedent that will haunt us in the future. If we create a number of application-specific variants of IPsec for different contexts, we run the risk of undermining interoperability.

Steve

IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

This message: [ Message body ]
Next message: Scott Fluhrer: "Re: [IPsec] question about RFC 4303 section 3.3.2.1"
Previous message: Grewal, Ken: "Re: [IPsec] First charter draft"
In reply to: Stephen Kent: "Re: [IPsec] First charter draft"
Next in thread: Pasi.Eronen_at_nospam: "Re: [IPsec] First charter draft"

Contemporary messages sorted: [ By Date ] [ By Thread ] [ By Subject ] [ By Author ]