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

From: Saroop Mathur <[email-masked]>
Date: Thu, 13 Sep 2007 11:39:12 -0700 (PDT)

David and Paul,

One other way to achieve this feature is to have the signaling in IKE in such a way that the firewalls can look into the IKE packets and determine the null encryption. I believe that IKEv2 allows an unencrypted payload along with an encrypted payload. This unencrypted payload can include the two SPI values in addition to the IV offset. This payload can either be a NOTIFICATION or a new payload type. This would require no changes to IPSEC data path and does not require any new IP protocol numbers. It also has the advantage that both ipsec end nodes do not need to support this feature for it to be used making it easy to deploy.

The disadvantages I see are that this new payload will be unauthenticated and it does not apply to IKEv1.

Saroop

----- Original Message ----
From: mcgrew <[email-masked]>
To: Russ Housley <[email-masked]>; [email-masked]
Sent: Wednesday, September 12, 2007 1:25:31 PM
Subject: Re: [Ipsec] Fwd: I-D Action:draft-hoffman-esp-null-protocol-00.txt

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

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

---

From: Jyothi <[email-masked]>
Date: Fri, 14 Sep 2007 09:41:29 +0530

Hi,

My understanding is that:
While applying IPSEC to the plain pkt, In outer IP hdr, you are 
thinking another protocol number in case of esp-null.

Assuming the above understanding is right,
what about the NAT traversal scenarios???
In NAT case outer IP header contains the UDP protocol and it is 
assumed as always ESP.

Thanks
Jyothi

At 12:09 AM 9/14/2007, Saroop Mathur wrote:
>David and Paul,
>
>One other way to achieve this feature is to have the signaling in 
>IKE in such a way that the firewalls can look into the IKE packets 
>and determine the null encryption. I believe that IKEv2 allows an 
>unencrypted payload along with an encrypted payload. This 
>unencrypted payload can include the two SPI values in addition to 
>the IV offset. This payload can either be a NOTIFICATION or a new 
>payload type. This would require no changes to IPSEC data path and 
>does not require any new IP protocol numbers. It also has the 
>advantage that both ipsec end nodes do not need to support this 
>feature for it to be used making it easy to deploy.
>
>The disadvantages I see are that this new payload will be 
>unauthenticated and it does not apply to IKEv1.
>
>Saroop
>
> <https://www1.ietf.org/mailman/listinfo/ipsec>https://www1.ietf.org/mailman/listinfo/ipsec
> >>
> >>
>
>
><https://www1.ietf.org/mailman/listinfo/ipsec>https://www1.ietf.org/mailman/listinfo/ipsec
>

********************************************************************************
This email message (including any attachments) is for the sole use of the intended recipient(s) 
and may contain confidential, proprietary and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended recipient, 
please immediately notify the sender by reply email and destroy all copies of the original message. 
Thank you.
 
Intoto Inc.

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 14 Sep 2007 07:53:15 +0200

Hi,

Saroop Mathur <[email-masked]> writes:

> One other way to achieve this feature is to have the signaling in IKE
> in such a way that the firewalls can look into the IKE packets and
> determine the null encryption.
> [...]

This makes the assumption that the IKE negotiation occurs using the same
path. This is not always the case. Best example is IPsec-protected MIPv6
traffic. IKE negotiation occurs on some network and then you move to
another network (transparently for transport mode and using update of
tunnels endpoint through PF_KEY MIGRATE). No IKE exchange occurs from
the new network. 

Regards,

a+

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 14 Sep 2007 15:21:44 +0300

> feature for it to be used making it easy to deploy. 

Hmm... that sounds interesting idea, and might be quite usable. It
would of course require firewalls to be able to do filtering based on
the SPIs, but that should fall in to the category they can do fast
anyways.

Inspecting IKE packets would not be that big problem, and as the
exchange type which tells if this is CREATE_CHILD_SA is in clear they
can even block the CREATE_CHILD_SA exchange which do not provide them
the SPIs to look at (which will cause the IKEv2 SA being teared down).

Of course they would need to trus the end nodes to send and check the
SPI numbers sent in the clear text packets, so that again requires
trust to the misconfigured nodes they are trying to protect.

If the modes are properly configured and have secure IPsec policy
there is no need for firewall to inspect anything. If the nodes are
not properly configured and have insecure IPsec policy then they might
even have this feature turned off. On the other hand then we can block
the connection and we know something is wrong as nothing works for
that insecure node. Protection against both ends having corrupted
IPsec code which sends wrong SPI numbers in the outside of the IKEv2
packets, but uses different once inside, is outside the scope of
protection what is tried here (we need to protect the one node (i.e.
the attacker node outside) sending wrong information in that outer
notification).

> unauthenticated and it does not apply to IKEv1.

As IKEv1 is already obsoleted, and should not be used anymore for new
work, I do not consider this a problem. 
-- 
[email-masked]