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

From: mcgrew <[email-masked]>
Date: Wed, 12 Sep 2007 13:25:31 -0700

Hi Russ,

You're absolutely right that a new encapsulation can be used which removes
the need for a second IP protocol number assignment.  Despite that benefit,
I fear that the implementation cost for the new encapsulation could make the
authentication-only profile less attractive for potential adopters.   I've
never implemented a new encapsulation into an existing protocol stack, but
my impression is that it is non-trival because of the need to avoid data
copying and to handle stuff like MTUs properly, plus the fact that new IP
protocols are typically implemented inside of a kernel rather than in
application space.   But I haven't done a complete analysis yet, of course.

As an aside, the IP, ESP, TCP, and UDP headers are all 32-bit aligned, so if
an offset field is used, I would expect that we'd want to have it be 32 bits
long to preserve that alignment.   Also, we could have the offset field
indicate the number of bytes until the start of the ESP payload, which might
be slightly more convenient.

David

On 9/12/07 12:53 PM, "Russ Housley" <[email-masked]> wrote:

> Dave:
> 
> Thanks for the summary.
> 
> It occurs to me that the use of a new IP protocol number gives us the
> opportunity to define an encapsulation of the authenticated-with-ESP
> datagram.  I have not thought this out all of the way, so I am
> offering this up for discussion with no ego.
> 
> Say the new protocol number is associated with a very simple syntax,
> as follows:
> 
>     - OFFSET
>     - ESP
> 
> The first field tells the number of octets that need to be skipped to
> avoid the IV.  For many ciphersuites it will be zero.  It seems to me
> that carrying this extra word of zeros is a small price to pay for
> consistent processing of all ciphersuites.  It also has the benefit
> that only one port is used.
> 
> The second field is the ESP packet.  Of course, this encapsulation
> should only be used when authentication without encryption is used.
> 
> Russ
> 
> 
> At 01:07 PM 9/12/2007, David McGrew wrote:
>> Hi All,
>> 
>> I wanted to follow up on some of the comments raised about draft-
>> hoffman-esp-null-protocol-00.
>> 
>> Paul and I did consider the use of a SPI range to indicate which
>> packets are NULL encrypted, but we rejected this method because there
>> are existing ESP implementations, some of which are in silicon, that
>> choose their own SPI values.  These implementations could not easily
>> support the use of a SPI range.  Also, if we relied on SPI semantics
>> to tell which ESP packets were using NULL encryption, then there
>> would be a large number of false positives due to the fact that all
>> of the ESP implementations currently fielded are not selecting their
>> SPIs to conform to some classification scheme.
>> 
>> As Steve points out, the use of an IPv4 Option is not tenable because
>> the majority of routers will use "slow path" processing on packets
>> with such an option, i.e. they would handle it at a software process
>> level rather than at the hardware interrupt level.    Unfortunately,
>> this perception is not out of date ;-)
>> 
>> It is a valid question whether or not it is worth two IP protocol
>> numbers to solve the problem that we need to indicate when an IV is
>> present.  I am not the best person to judge the cost of assigning a
>> second protocol number.  However, I can't see any robust solution
>> without a second number.  There isn't a way to explicitly indicate
>> that an IV is present in the ESP packet without adding another field
>> (or overloading the semantics of an existing field, like the SPI).
>> It's highly desirable to not add or overload a field, so that we
>> retain compatibility with all of the existing implementations.
>> Without an explicit indication, we're back to guessing.  It *might*
>> be possible to make recommendations that would make this guessing
>> more robust (i.e. an IV should only take certain values), but Paul
>> and I looked at this possibility and we did not see anything that
>> looked good.
>> 
>> David
>> 
>> 
>> _______________________________________________
>> Ipsec mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipsec
>> 
>> 

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