Subject: [Ipsec] Fwd: I-D Action:draft-hoffman-esp-null-protocol-00.txt

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Aug 2007 18:57:43 -0700

Greetings again. David McGrew and I have put together a proposal that 
should help end the ESP NULL vs. AH debate. In that debate, the 
primary argument for AH is "packet-inspecting firewalls don't know 
whether or not to look inside an ESP packet". With this proposal, 
they will know better.

Please let us know what you think.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>	Title           : An Authentication-only Profile for ESP with 
>an IP Protocol Identifier
>	Author(s)       : P. Hoffman, D. McGrew
>	Filename        : draft-hoffman-esp-null-protocol-00.txt
>	Pages           : 7
>	Date            : 2007-08-24
>
>It is desirable to allow firewalls and intrusion detection systems to
>be able to inspect the payload of an ESP packet that has been
>encrypted with the NULL cipher.  This would allow a firewall to read
>the contents and apply the normal policies to it.  However, a device
>in the network cannot reliably determine which ESP packets are NULL
>encrypted, and cannot easily determine other ESP format parameters
>such as the ICV length.  These issues can cause misclassification of
>packets and wasted computational resources.
>
>This document solves this problem by defining an authentication-only
>profile of ESP and reserving IP protocol numbers for it.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.txt
>

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Aug 2007 10:16:24 -0400

At 6:57 PM -0700 8/24/07, Paul Hoffman wrote:
>Greetings again. David McGrew and I have put together a proposal 
>that should help end the ESP NULL vs. AH debate. In that debate, the 

Paul,

This should work. The only question is whether the community is 
willing to consume two protocol numbers to address the problem.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Aug 2007 07:45:13 -0700

At 10:16 AM -0400 8/27/07, Stephen Kent wrote:
>>that should help end the ESP NULL vs. AH debate. In that debate, 
>>the primary argument for AH is "packet-inspecting firewalls don't 
>>know whether or not to look inside an ESP packet". With this 
>>proposal, they will know better.
>>

We hope so. If you look at the protocol numbers registry, you will 
see that over 100 are still available, and they are being used at a 
rate of about one or two a year. Also, it looks like at least half of 
the used ones are for things probably no one can remember. So, we 
think that using two for something that has immediate application in 
security would be a reasonable use.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Mon, 27 Aug 2007 10:36:16 -0400

> whether or not to look inside an ESP packet". With this proposal, 
<SNIP!>

Has anyone considered reserving SPI space for either NULL-encryption case?
This would allow each endsystem to configure whether or not they want their
traffic configured without modifying IKE at all.

For example:

	0xfffe0000 to 0xfffeffff   ===>  0-length IV

	0xffff0000 to 0xffffffff   ===>  8-byte IV (e.g. GMAC)

This proposal would eat up no protocol numbers, AND it would require no IKE
changes.  The only downside is if an SPI in those ranges is picked for a
regular ESP SA, it would have to be corrected.  We're looking at a 1/32768
probability.

Dan

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 27 Aug 2007 08:55:36 -0600

Would you consider instead reserving a certain range of ESP SPI values for 
this use?  This would avoid consuming two additional protocols, and would 
localize the solution to the SA management architecture (manual 
configuration or IKE) without any need for TCP/IP changes or even any 
changes to the IKE proposals sent.  The downside of course is that 
existing implementations will fail to honor this, but environments that 
need this behavior will require updated implementations regardless of the 
approach chosen.

It also occurs to me that we could define IP options that asserted NULL 
ESP, although that seems less elegant and efficient.

Scott Moonen ([email-masked])
http://www.linkedin.com/in/smoonen

Stephen Kent <[email-masked]> 
08/27/2007 10:16 AM

To
Paul Hoffman <[email-masked]>
cc
IPsec WG <[email-masked]>
Subject
Re: [Ipsec] Fwd: I-D Action:draft-hoffman-esp-null-protocol-00.txt

Paul,

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Aug 2007 11:20:41 -0400

>willing to consume two protocol numbers to address the problem.

Paul & Steve:

I can see using a single protocol number here, but I think that two 
is unreasonable.

I think that an IP option could be used in conjunction with the 
protocol number to indicate the offset when an IV or Nonce is 
needed.  The IP option would carry the number of octets that need to 
be shipped to find the front of the encapsulated IP datagram.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Aug 2007 13:19:21 -0400

>be shipped to find the front of the encapsulated IP datagram.

I agree that an option would be an easy way to both mark packets and 
to rovide an offset to the start of the plaintext packet. I worry 
that any IP option might cause packets to be taken off the fast path 
(maybe my perception of this problem is out of date) in every router 
(other than MPLS ones?) along the route, and thus would not be 
attractive. There is also the possible concern that getting an IP 
option approved would be harder than making a change to IPsec, both 
from an IETF and from a vendor implementation perspective.

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Aug 2007 14:05:00 -0400

>>needed.  The IP option would carry the number of octets that need 
>>to be shipped to find the front of the encapsulated IP datagram.
>>
>>Russ
>

Steve & Paul:

That is a good point.  It would impact every router, not just the 
ones that are wanting to parse the IP datagram.

I am still opposed to assigning a protocol number for each crytpo 
variable size.  Since the proposal is to use a protocol number, that 
could define a protocol that is comprised of the offset and the 
payload.  There may be other alternative that do not consume multiple 
protocol numbers.

Russ

Russ

---

From: Dan McDonald <[email-masked]>
Date: Mon, 27 Aug 2007 14:26:50 -0400

Taking you back on-list...

On Mon, Aug 27, 2007 at 11:19:32AM -0700, Paul Hoffman wrote:
> I don't understand how this doesn't require changes to IKE 
> implementations. Both sides would need to know  to use the new SPI 
> range.

I should've said LESS changes to an IKE implementation.

Consider a system that's requesting an SPI for an auth-only SA.  It can do
its moral equivalent of PF_KEY's GETSPI in the appropriate range depending on
the already-selected algorithm(s).

We need no additional on-the-wire changes (like new DOI values) and it's
seamlessly backward compatible, modulo that the pre-noAUTH-aware nodes won't
have clue enough to pick out an appropriate SPI value.

Dan

---

From: Sheila Frankel <[email-masked]>
Date: Mon, 27 Aug 2007 15:35:02 -0400

We're updating our US Government IPv6/IPsec profile, and I have a question 
about the status and prospects of several algorithms recommended in RFC 
4869 (the GCM/GMAC suites doc).

1) Does anyone currently implement any of the ECP groups in RFC 4753? What 
are the prospects for the next 18 months?

2) Same question (current and 18 months from now) for RFC 4754 (ECDSA auth 
in IKEv1 and IKEv2)

3) I assume that IKEv2 implementations will at some point include the 
HMAC-SHA-256 variants and ESP-GCM. Does anyone plan to add (or has anyone 
already added) either of these algorithms to IKEv1?

Thanks in advance for any and all help,
Sheila