Subject: [IPsec] Diet-ESP

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Feb 2015 04:08:04 +0100

Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We
have implemented and tested Diet-ESP. Compared to the standard IPsec/ESP,
Diet-ESP can reduce the networking overhead added to unprotected data from
100% to a few percent. I will be happy to present these draft next IETF.

Feel free to make comments!

The drafts includes:
    1) draft-mglt-6lo-diet-esp-requirements
<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-requirements/>:
lists the requirements for Diet-ESP
    2) draft-mglt-6lo-aes-implicit-iv
<http://datatracker.ietf.org/doc/draft-mglt-6lo-aes-implicit-iv/>:
indicates how to avoid carrying the IV in each ESP packet. It is instead
generated by each peers. The protocols described in the draft can be used
with the regular IPsec/ESP.
    3) draft-mglt-6lo-diet-esp
<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp/> describes the
core Diet-ESP protocol, that is how to compress/decompress each fields of
the standard IPsec/ESP. Compression is discribed through a Diet-ESP Context.
    4) draft-mglt-6lo-diet-esp-payload-compression
<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-payload-compression/>:
describes how the clear text can be compressed before encryption. In fact
unless IPsec/ESP is used with NULL encryption, the data in the ESP packet
is encrypted. Encryption makes compression hard to perform. Instead
compressing before encrypting can be very efficient. This makes possible to
remove UDP/TPC/IP tunnel headers.
    5) draft-mglt-6lo-diet-esp-context-ikev2-extension
<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-context-ikev2-extension/>:
describes how to negociate Diet-ESP with IKEv2. In fact this mostly result
in an agreement for the DIet-ESP Context. This exchange may then be
extended to Diet-HIP Exchange.

BR,
Daniel
-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 17 Feb 2015 05:28:04 +0000

Here’s an issue with this draft; it doesn’t meet the requirements that it claims.  In particular, it claims that it is based on standard IPsec, and that its security is equivalent to IPsec (R1-R3).  However, it allows (and, as far as I am concerned, encourages) the use of tiny ICVs; these tiny ICVs introduce security vulnerabilities that do not occur within sane configurations of IPsec (where sane includes using an integrity transform).  In particular, using tiny ICVs with GCM is a known security issue.

Now, it would be possible to have an encryption protocol that would not have issues with small ICVs (say, by using a wide block cipher); however this would be rather different than standard IPsec (in part because IPsec was never designed with these minimal bandwidth constraints); either we need to stay with an IPsec-based protocol (which implies a largish ICV), or go with something else (which would have less overhead, but doesn’t look that much like IPsec internally).

Oh, and a minor note on the IV generation: it’s actually secure to use the same key you use to encrypt to encrypt the counter for the IV; you don’t need a separate key.

From: IPsec [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Monday, February 16, 2015 10:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: [IPsec] Diet-ESP

Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We have implemented and tested Diet-ESP. Compared to the standard IPsec/ESP, Diet-ESP can reduce the networking overhead added to unprotected data from 100% to a few percent. I will be happy to present these draft next IETF.

The drafts includes:
    1) draft-mglt-6lo-diet-esp-requirements<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-requirements/>: lists the requirements for Diet-ESP
    2) draft-mglt-6lo-aes-implicit-iv<http://datatracker.ietf.org/doc/draft-mglt-6lo-aes-implicit-iv/>: indicates how to avoid carrying the IV in each ESP packet. It is instead generated by each peers. The protocols described in the draft can be used with the regular IPsec/ESP.
    3) draft-mglt-6lo-diet-esp<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp/> describes the core Diet-ESP protocol, that is how to compress/decompress each fields of the standard IPsec/ESP. Compression is discribed through a Diet-ESP Context.
    4) draft-mglt-6lo-diet-esp-payload-compression<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-payload-compression/>: describes how the clear text can be compressed before encryption. In fact unless IPsec/ESP is used with NULL encryption, the data in the ESP packet is encrypted. Encryption makes compression hard to perform. Instead compressing before encrypting can be very efficient. This makes possible to remove UDP/TPC/IP tunnel headers.
    5) draft-mglt-6lo-diet-esp-context-ikev2-extension<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-context-ikev2-extension/>: describes how to negociate Diet-ESP with IKEv2. In fact this mostly result in an agreement for the DIet-ESP Context. This exchange may then be extended to Diet-HIP Exchange.
BR,
Daniel
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Feb 2015 16:47:46 +0100

Hi Scott,

Thank you for the feed back. I agree that compressing the ICV reduces
security related to authentication. Let's call this a "weak
authentication".

I am not saying it is a valid argument, but since IPsec enables NULL
authentication too, we considered that enabling "weak authentication" would
be possible with a clear warning in the security consideration.

The reason we are looking we are looking for weak authentication is to be
able to balance authentication with bandwidth optimization. In fact,
suppose you compute the mean/median over a thousand different value, that
one or two values are corrupted may not have much impact overall, and we
may prefer to extend the life time of the mote for 5 years instead.

Regarding you comment I think the issue ou raised is more related to GCM.
-- By the way I would be interested to have a description or relevant doc
describing  why ICV in GCM particularly matters. One way to address the
issue you raised would be:
    - 1) mention the need for weak authentication in the requirement draft
    - 2) remove ICV compression from Diet-ESP
    - 3) Define encryption protocols with weak authentication with
different sizes of the ICV. For example suppose AES-MODEX has an ICV of N,
then we may need to add AES-MODEX_i with i in [0 ... N-1].

The advantage of doing so is that it avoids end user to weaken the
protocols especially when one compression is fine with one protocol but not
with the others. In that sense it looks a better design.

However, I see the following drawbacks:
    - It requires to create multiple encryption protocols. Unlike
compression, implementation cannot use existing implementation of AES-MODEX.
    - Negociation for hosts accepting all AES-MODEX_i with i in [0 ... N-1]
requires many SA payload in the IKEv2 negotiation. However, we may deal
with this with a AES-MODEX_ALL to indicate the responder choses its
compression.

BR,
Daniel

On Tue, Feb 17, 2015 at 6:28 AM, Scott Fluhrer (sfluhrer) <
[email-masked]> wrote:

>  Here’s an issue with this draft; it doesn’t meet the requirements that
> it claims.  In particular, it claims that it is based on standard IPsec,
> and that its security is equivalent to IPsec (R1-R3).  However, it allows
> (and, as far as I am concerned, encourages) the use of tiny ICVs; these
> tiny ICVs introduce security vulnerabilities that do not occur within sane
> configurations of IPsec (where sane includes using an integrity
> transform).  In particular, using tiny ICVs with GCM is a known security
> issue.
>
>
>
> Now, it would be possible to have an encryption protocol that would not
> have issues with small ICVs (say, by using a wide block cipher); however
> this would be rather different than standard IPsec (in part because IPsec
> was never designed with these minimal bandwidth constraints); either we
> need to stay with an IPsec-based protocol (which implies a largish ICV), or
> go with something else (which would have less overhead, but doesn’t look
> that much like IPsec internally).
>
>
>
>
>
> Oh, and a minor note on the IV generation: it’s actually secure to use the
> same key you use to encrypt to encrypt the counter for the IV; you don’t
> need a separate key.
>
>
>
> *From:* IPsec [mailto:[email-masked]] *On Behalf Of *Daniel
> Migault
> *Sent:* Monday, February 16, 2015 10:08 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [IPsec] Diet-ESP
>
>
>

-- 
Daniel Migault
Ericsson

---

From: <[email-masked]>
Date: Tue, 17 Feb 2015 16:07:49 +0000

> On Feb 17, 2015, at 10:47 AM, Daniel Migault <[email-masked]> wrote:
> 
> Hi Scott, 
> 
> Thank you for the feed back. I agree that compressing the ICV reduces security related to authentication. Let's call this a "weak authentication".  
> 
> I am not saying it is a valid argument, but since IPsec enables NULL authentication too, we considered that enabling "weak authentication" would be possible with a clear warning in the security consideration. 

That is not a valid analogy.  NULL authentication specifically delivers no authentication at all.  The security properties of “no authentication” are reasonably obvious even to people not skilled in cryptography.

On the other hand, weak authentication can easily be mistaken for real authentication, in the same way that DES (or worse yet, DES-40) was in the past mistaken for real confidentiality.  If we build a system with weak security properties, we run the very real risk that it may end up being widely used “to save bandwidth”, when in fact it should be considered as a niche solution that is only valid for extremely unusual scenarios.  It’s not clear to me that a note in teh security considerations section will be sufficient.

	paul

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Feb 2015 17:30:33 +0100

Hi,

Do you have any opinion on the proposed alternative?

    - 3) Define encryption protocols with "weak authentication" with

BR,
Daniel

On Tue, Feb 17, 2015 at 5:07 PM, <[email-masked]> wrote:

> security related to authentication. Let's call this a "weak authentication".
> >
> That is not a valid analogy.  NULL authentication specifically delivers no
> authentication at all.  The security properties of “no authentication” are
> reasonably obvious even to people not skilled in cryptography.
>
> On the other hand, weak authentication can easily be mistaken for real
> authentication, in the same way that DES (or worse yet, DES-40) was in the
> past mistaken for real confidentiality.  If we build a system with weak
> security properties, we run the very real risk that it may end up being
> widely used “to save bandwidth”, when in fact it should be considered as a
> niche solution that is only valid for extremely unusual scenarios.  It’s
> not clear to me that a note in teh security considerations section will be
> sufficient.
>
>         paul
>
>

-- 
Daniel Migault
Ericsson

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Feb 2015 17:36:47 +0100

Daniel,

I understand that you spend a lot of time in writing these
specifications but, as mentioned in the past I just do not see the need
for this type of standardization activity. Nobody I have spoken with
asks for this functionality.

If there is indeed a need for IPsec ESP use in IoT then I am not sure
that the proposed optimizations are so useful given the impact for
security.

Ciao
Hannes

On 02/17/2015 04:08 AM, Daniel Migault wrote:
> have implemented and tested Diet-ESP. Compared to the standard
> IPsec/ESP, Diet-ESP can reduce the networking overhead added to
> unprotected data from 100% to a few percent. I will be happy to present
> these draft next IETF.
> 
> generated by each peers. The protocols described in the draft can be
> used with the regular IPsec/ESP.
> core Diet-ESP protocol, that is how to compress/decompress each fields
> of the standard IPsec/ESP. Compression is discribed through a Diet-ESP
> Context.
> describes how the clear text can be compressed before encryption. In
> fact unless IPsec/ESP is used with NULL encryption, the data in the ESP
> packet is encrypted. Encryption makes compression hard to perform.
> Instead compressing before encrypting can be very efficient. This makes
> possible to remove UDP/TPC/IP tunnel headers.
> describes how to negociate Diet-ESP with IKEv2. In fact this mostly
> result in an agreement for the DIet-ESP Context. This exchange may then
> be extended to Diet-HIP Exchange.
> 
> BR,
> Daniel
> -- 
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Feb 2015 13:32:57 -0500 (EST)

> that the proposed optimizations are so useful given the impact for

I agree. I think it would be very useful to describe a barebones minimal
IKEv2 feature set and even an ESP minimal set for such use, but tweaking
a byte here and there of the ESP protocol parameters makes we very
nervous.

Paul

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 17 Feb 2015 21:17:11 +0000

Others have addressed my other points; let me talk about the specific issues with GCM.

One summary of the issues found is http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.297.9568&rep=rep1&type=pdf ; the problem with GCM is that:

-          With one successful forgery, the attacker can modify other packets the same way without detection.

-          With a handful of successful forgeries, the attacker can learn enough to be able to forge arbitrary messages.
Now, with the full 16 byte ICV, this is not a concern (because the probability of the attacker finding one successful forgery is tiny); however once you start reducing the ICV value, well, various guessing strategies start working better.

Now, neither HMAC nor CMAC has this problem; yes, with a tiny ICV, someone can generate a forgery by blindly guessing; however a successful forgery doesn’t give the attacker any information about how to generate a second successful forgery, or any information about the internal state.  Instead, generating a second forgery requires just as much work as you’d expect (that is, the same amount of work taken to generate the first forgery).

Hence, while I would suggest that you rethink the strategy of allowing tiny ICVs, if you do go ahead, I would strongly urge you to mandate the use of either HMAC or CMAC to generate those tiny ICVs – those won’t make a poor situation even worse.

From: Daniel Migault [mailto:[email-masked]]
Sent: Tuesday, February 17, 2015 10:48 AM
To: Scott Fluhrer (sfluhrer)
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] Diet-ESP

Hi Scott,
Thank you for the feed back. I agree that compressing the ICV reduces security related to authentication. Let's call this a "weak authentication".
I am not saying it is a valid argument, but since IPsec enables NULL authentication too, we considered that enabling "weak authentication" would be possible with a clear warning in the security consideration.
The reason we are looking we are looking for weak authentication is to be able to balance authentication with bandwidth optimization. In fact, suppose you compute the mean/median over a thousand different value, that one or two values are corrupted may not have much impact overall, and we may prefer to extend the life time of the mote for 5 years instead.

Regarding you comment I think the issue ou raised is more related to GCM. -- By the way I would be interested to have a description or relevant doc describing  why ICV in GCM particularly matters. One way to address the issue you raised would be:
    - 1) mention the need for weak authentication in the requirement draft
    - 2) remove ICV compression from Diet-ESP
    - 3) Define encryption protocols with weak authentication with different sizes of the ICV. For example suppose AES-MODEX has an ICV of N, then we may need to add AES-MODEX_i with i in [0 ... N-1].
The advantage of doing so is that it avoids end user to weaken the protocols especially when one compression is fine with one protocol but not with the others. In that sense it looks a better design.
However, I see the following drawbacks:
    - It requires to create multiple encryption protocols. Unlike compression, implementation cannot use existing implementation of AES-MODEX.
    - Negociation for hosts accepting all AES-MODEX_i with i in [0 ... N-1] requires many SA payload in the IKEv2 negotiation. However, we may deal with this with a AES-MODEX_ALL to indicate the responder choses its compression.

BR,
Daniel

On Tue, Feb 17, 2015 at 6:28 AM, Scott Fluhrer (sfluhrer) <[email-masked]<mailto:[email-masked]>> wrote:
Here’s an issue with this draft; it doesn’t meet the requirements that it claims.  In particular, it claims that it is based on standard IPsec, and that its security is equivalent to IPsec (R1-R3).  However, it allows (and, as far as I am concerned, encourages) the use of tiny ICVs; these tiny ICVs introduce security vulnerabilities that do not occur within sane configurations of IPsec (where sane includes using an integrity transform).  In particular, using tiny ICVs with GCM is a known security issue.

From: IPsec [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Migault
Sent: Monday, February 16, 2015 10:08 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [IPsec] Diet-ESP

The drafts includes:
+33 6 70 72 69 58<tel:%2B33%206%2070%2072%2069%2058>

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Feb 2015 03:38:08 +0100

Hi Scott,

Thanks for the feed back, this is clearly some text that needs to be added
to draft. So options to deal with the compression of the ICV are:
    - a) Allowing ICV compression with some restrictions like the ones you
mention.
    - b) Not allowing ICV compression and explicitly listing encryption
algorithms with small ICV

BR,
Daniel

On Tue, Feb 17, 2015 at 10:17 PM, Scott Fluhrer (sfluhrer) <
[email-masked]> wrote:

> One summary of the issues found is
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.297.9568&rep=rep1&type=pdf
> ; the problem with GCM is that:
>
> -          With a handful of successful forgeries, the attacker can learn
> enough to be able to forge arbitrary messages.
>
> Now, with the full 16 byte ICV, this is not a concern (because the
> probability of the attacker finding one successful forgery is tiny);
> however once you start reducing the ICV value, well, various guessing
> strategies start working better.
>
>
>
> Now, neither HMAC nor CMAC has this problem; yes, with a tiny ICV, someone
> can generate a forgery by blindly guessing; however a successful forgery
> doesn’t give the attacker any information about how to generate a second
> successful forgery, or any information about the internal state.  Instead,
> generating a second forgery requires just as much work as you’d expect
> (that is, the same amount of work taken to generate the first forgery).
>
>
>
> Hence, while I would suggest that you rethink the strategy of allowing
> tiny ICVs, if you do go ahead, I would strongly urge you to mandate the use
> of either HMAC or CMAC to generate those tiny ICVs – those won’t make a
> poor situation even worse.
>
>
>
>
>
> *From:* Daniel Migault [mailto:[email-masked]]
> *Sent:* Tuesday, February 17, 2015 10:48 AM
> *To:* Scott Fluhrer (sfluhrer)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [IPsec] Diet-ESP
>
>
>
> Hi Scott,
>
>     - Negociation for hosts accepting all AES-MODEX_i with i in [0 ...
> N-1] requires many SA payload in the IKEv2 negotiation. However, we may
> deal with this with a AES-MODEX_ALL to indicate the responder choses its
> compression.
>
>
> BR,
> Daniel
>
>
>
> Here’s an issue with this draft; it doesn’t meet the requirements that it
> claims.  In particular, it claims that it is based on standard IPsec, and
> that its security is equivalent to IPsec (R1-R3).  However, it allows (and,
> as far as I am concerned, encourages) the use of tiny ICVs; these tiny ICVs
> introduce security vulnerabilities that do not occur within sane

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Feb 2015 04:44:40 +0100

Hi Hannes,

We designing Diet-ESP was to enable motes to secure their communications
and provide end-to-end security. This function is important for us and I
guess we are not the only one interested in this functionality.

We believe it is worth exposing how IPsec can be use to fit the IoT
constraints, regardless of what other protocols are providing.

There are probably other alternatives (like DTLS), however :
    - a) DTLS/IPsec address different use cases
    - b) no real comparison have been made possible between these security
protocols designed for IoT, and we believe IPsec is pretty efficient.

Current spec may not be perfect. However, the impact on security can
largely be under control. First of all Diet-ESP results in the combination
of ROHC ROHCoverIPsec which are already standard with deep security
reviews. Then most of the compressed fields are not security related.
Padding, Pad Len, Next Header have nothing to deal with security.

Security related fields are SN, ICV, SPI. SN and SPI are compressed means
that they have to be decompressed before applying IPsec/ESP. Because of the
compression/decompression these fields are not altered and from an
IPsec/ESP perspective compression is transparent. On the other hand,
appropriate values MUST be chosen so compression/decompression can occur.

In the case of the ICV, this value cannot be decompressed, and thus we have
to make things right. Two alternatives are proposed and I would be happy to
update the draft with the best one.

If you have specific security impacts in mind, please let us know.

BR,
Daniel

On Tue, Feb 17, 2015 at 5:36 PM, Hannes Tschofenig <
[email-masked]> wrote:

> > <
> http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-payload-compression/
> >:
> > <
> http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-context-ikev2-extension/
> >:

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Feb 2015 05:08:32 +0100

Hi Paul,

The bare minimal implementation of IKEv2 and IPsec/ESP have been proposed
in lwig WG: draft-ietf-lwig-ikev2-minimal-01.txt
<https://tools.ietf.org/html/draft-ietf-lwig-ikev2-minimal-01> and
draft-mglt-lwig-minimal-esp-01.txt
<http://www.ietf.org/archive/id/draft-mglt-lwig-minimal-esp-01.txt>

Diet-ESP is definitely not "tweaking a byte here and there". Instead, it
combines ROHC ROHCoverIPsec and IPsec/ESP. This provides the necessary
flexibility to provide the appropriated security in any situation.

I appreciate you provide feed back, however, I need more technical argument
to make you less nervous.

BR,
Daniel

BR,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Feb 2015 05:12:37 +0100

Hi Paul,

I click send too quickly. I agree that providing the minimal description
for ESP and IKEv2 is useful, however Diet-ESP and minimal implementations
have different goals.

BR,
Daniel

On Wed, Feb 18, 2015 at 5:08 AM, Daniel Migault <[email-masked]> wrote:

> I appreciate you provide feed back, however, I need more technical
> argument to make you less nervous.
>
> BR,
> Daniel
>
> BR,
> Daniel
>

-- 
Daniel Migault
Ericsson

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Feb 2015 09:24:49 +0100

Hi Daniel,

I would like to understand your use case a bit better. Just securing
sensor communication is not enough.

What application layer protocols do you expect to run on these devices?
What radio technologies do you assume are going to be used?
How does the envisioned stack on these devices look like?

Ciao
Hannes

On 02/18/2015 04:44 AM, Daniel Migault wrote:
>     - b) no real comparison have been made possible between these
> security protocols designed for IoT, and we believe IPsec is pretty
> efficient.
> 
> largely be under control. First of all Diet-ESP results in the
> combination of ROHC ROHCoverIPsec which are already standard with deep
> security reviews. Then most of the compressed fields are not security
> related. Padding, Pad Len, Next Header have nothing to deal with security.
> 
> Security related fields are SN, ICV, SPI. SN and SPI are compressed
> means that they have to be decompressed before applying IPsec/ESP.
> Because of the compression/decompression these fields are not altered
> and from an IPsec/ESP perspective compression is transparent. On the
> other hand, appropriate values MUST be chosen so
> compression/decompression can occur.
> 
> In the case of the ICV, this value cannot be decompressed, and thus we
> have to make things right. Two alternatives are proposed and I would be
> happy to update the draft with the best one.
> 
> On Tue, Feb 17, 2015 at 5:36 PM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Daniel,
> 
>     > +33 6 70 72 69 58 <tel:%2B33%206%2070%2072%2069%2058>
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 14:46:02 +0000

> On Feb 17, 2015, at 9:38 PM, Daniel Migault <[email-masked]> wrote:
> 
> Hi Scott, 
> 
> Thanks for the feed back, this is clearly some text that needs to be added to draft. So options to deal with the compression of the ICV are:
>     - a) Allowing ICV compression with some restrictions like the ones you mention. 
>     - b) Not allowing ICV compression and explicitly listing encryption algorithms with small ICV

I am opposed to any “diet ESP” proposal that weakens the security properties of the protocol.  Bandwidth reduction is a somewhat interesting goal, and if you can trim down ESP while leaving its strength unchanged (or improved of course), fine.  If it weakens it, I disapprove.

	paul