Subject: [IPsec] Re: I-D ACTION:draft-grewal-ipsec-traffic-visibility-00.txt

From: Yaron Sheffer <[email-masked]>
Date: Sun, 06 Jan 2008 14:14:03 +0200

Hi,

A new draft was published on distinguishing ESP-null traffic from 
regular encrypted ESP traffic. I agree with the motivation, but I also 
have some comments on the specific solution proposed. I suggest that 
further discussion be on the IPsec list.

    * The draft does not mention, and should contain a comparison with
      the recent I-D,
      http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.txt.
    * This whole mechanism is mostly useful in the internal "trusted"
      network, where NAT traversal (and UDP encapsulation) is usually
      *not* deployed.
    * Since both IKE and IPsec run over the same port, you need to
      magically know in advance that IKE negotiation will result in
      ESP-null being selected, at the time when you select the port for
      the IKE negotiation.
    * Also, the new draft extends the UDP encapsulation RFC, which I
      find strange.

Regards,
    Yaron

Begin forwarded message:

> *From: [email-masked] <mailto:[email-masked]>
> *Date: *January 3, 2008 7:15:01 PM GMT+02:00
> *To: [email-masked] <mailto:[email-masked]>
> *Subject: **I-D ACTION:draft-grewal-ipsec-traffic-visibility-00.txt *
> *Reply-To: [email-masked] <mailto:[email-masked]>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : Traffic visibility using IPsec ESP NULL encryption  
> Author(s) : K. Grewal, et al.
> Filename : draft-grewal-ipsec-traffic-visibility-00.txt
> Pages : 8
> Date : 2008-1-3
>
>   This document describes leveraging UDP encapsulation for IPsec, using
>   ESP NULL encryption in order for intermediary devices to inspect the
>   IPsec packets. Currently in the IPsec standard, there is no way to
>   differentiate between ESP encryption and ESP NULL encryption by
>   simply examining a packet.  
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibility-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-grewal-ipsec-traffic-visibility-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-grewal-ipsec-traffic-visibility-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 7 Jan 2008 11:02:35 -0800

Hi Yaron, 

Many thanks for the prompt response. I did not realize that the IPsec
mailing list was still active (looks like the WG is concluded according
to the IETF website!), hence was not aware of the Hoffman draft and
associated discussions.

Some comments below and I will separately post comments on some threads
for the Hoffman draft.

*	The draft does not mention, and should contain a comparison with
the recent I-D,
http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t
xt.

Agreed - I will include this as a reference in the next revision and the
only reason for not doing so earlier is that I was not aware of this
draft!

*	This whole mechanism is mostly useful in the internal "trusted"
network, where NAT traversal (and UDP encapsulation) is usually *not*
deployed.

I disagree. In my experience, large corporations still employ NAT
heavily, even within the internal trusted network and will continue to
do so in the foreseeable future. This is primarily used to segregate
satellite offices and also for 'hiding' sensitive domains / topology
from the remainder of the internal network, so taking a UDP based
approach is more applicable for these environments. 

*	Since both IKE and IPsec run over the same port, you need to
magically know in advance that IKE negotiation will result in ESP-null
being selected, at the time when you select the port for the IKE
negotiation.

Valid point - I need to update the draft with a new transform that is
included for IKE, which will synchronize the two peers in leveraging
this encapsulation. Having just today looked at the Hoffman draft, this
can be handled in a similar way with little or no disruption to the IKE
protocol. If the peer understands the new transform, it will accept,
otherwise this will default to legacy IKE / IPsec. 

The rationale here was to use what is already there in the UDP
encapsulation draft and then simply extend the mechanism to include
additional semantic information about the payload as a 32-bit extension
following the UDP header. Having spent some time looking at the IPsec
mailing list archives this morning, it looks like Russ Housley proposed
a similar mechanism for the Hoffman draft. This extension is valuable
for two reasons: 1. To provide algorithm agility in the proposal (so
that new methods employing larger IVs in the future can be easily
comprehended, without a need to modify this proposal in the future). 2.
Allowing the intermediate device an easy way to parse the packet
(without employing expensive lookup tables), where the data offset for
upper layer protocols is directly contained within the packet. 

I look forward to additional comments...

Thanks, 

- Ken

________________________________

From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Sunday, January 06, 2008 4:14 AM
To: Grewal, Ken; Durham, David; Long, Men; [email-masked]
Subject: Re: I-D ACTION:draft-grewal-ipsec-traffic-visibility-00.txt

Hi,

*	The draft does not mention, and should contain a comparison with
the recent I-D,
http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t
xt.
*	This whole mechanism is mostly useful in the internal "trusted"
network, where NAT traversal (and UDP encapsulation) is usually *not*
deployed.
*	Since both IKE and IPsec run over the same port, you need to
magically know in advance that IKE negotiation will result in ESP-null
being selected, at the time when you select the port for the IKE
negotiation.
*	Also, the new draft extends the UDP encapsulation RFC, which I
find strange.

Regards,
    Yaron

Begin forwarded message:

From: [email-masked]

Date: January 3, 2008 7:15:01 PM GMT+02:00

To: [email-masked]

Subject: I-D ACTION:draft-grewal-ipsec-traffic-visibility-00.txt 

Reply-To: [email-masked]

 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibilit
y-00.txt

Send a message to:
 [email-masked].
In the body type:

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[email-masked]>
<mailto:[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 08 Jan 2008 18:12:34 +0200

Hi Ken,

Regarding the 3rd point (use of a special port): if your solution uses a 
special port, say 5500, for ESP-null traffic, then you'd presumably use 
port 5500 for both IKE and IPsec - this is how RFC 3948 works. So the 
very fact that someone is listening on port 5500 implies that they 
support this extension, and you don't need to negotiate it in IKE.

OTOH, if no-one is listening on this port, the IKE messages will be 
silently ignored and you will have a time delay before you detect that 
the extension is not supported by your IPsec gateway. This is an issue.

So if we go for a port-based solution, I suggest we use the standard 
port (4500), plus IKE-level negotiation of the NAT-T extension.

Thanks,

    Yaron

Grewal, Ken wrote:

> mailing list was still active (looks like the WG is concluded 
> according to the IETF website!), hence was not aware of the Hoffman 
> draft and associated discussions.
>
>  
>
> Some comments below and I will separately post comments on some 
> threads for the Hoffman draft.
>
> Agreed -- I will include this as a reference in the next revision and 
> the only reason for not doing so earlier is that I was not aware of 
> this draft!
>
>       ESP-null being selected, at the time when you select the port
>       for the IKE negotiation.
>
> this encapsulation. Having just today looked at the Hoffman draft, 
> this can be handled in a similar way with little or no disruption to 
> the IKE protocol. If the peer understands the new transform, it will 
> accept, otherwise this will default to legacy IKE / IPsec.
>
> additional semantic information about the payload as a 32-bit 
> extension following the UDP header. Having spent some time looking at 
> the IPsec mailing list archives this morning, it looks like Russ 
> Housley proposed a similar mechanism for the Hoffman draft. This 
> extension is valuable for two reasons: 1. To provide algorithm agility 
> in the proposal (so that new methods employing larger IVs in the 
> future can be easily comprehended, without a need to modify this 
> proposal in the future). 2. Allowing the intermediate device an easy 
> way to parse the packet (without employing expensive lookup tables), 
> where the data offset for upper layer protocols is directly contained 
> within the packet.
>

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 8 Jan 2008 09:26:23 -0800

Yaron, 

The intent is to use the same ports for the IKE negotiation (4500) as
per RFC 3948. Within the IKE handshake, a new transform can be exchanged
that indicates usage of a new port (say 5500) for the data path. We
cannot use 4500 for the data path (IPsec) as we need to differentiate
between the proposed encapsulation (which will allow intermediate
devices to easily parse the packet) and legacy IPsec packets using 4500.

Is this in line with your recommendations?

Thanks, 

- Ken

From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2008 8:13 AM
To: Grewal, Ken
Cc: [email-masked]; Durham, David; Long, Men
Subject: [IPsec] Re: I-D
ACTION:draft-grewal-ipsec-traffic-visibility-00.txt

Hi Ken,

Thanks,

    Yaron

Grewal, Ken wrote:

	Hi Yaron, 

	Many thanks for the prompt response. I did not realize that the
IPsec mailing list was still active (looks like the WG is concluded
according to the IETF website!), hence was not aware of the Hoffman
draft and associated discussions.

	*	The draft does not mention, and should contain a
comparison with the recent I-D,
http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t
xt.

	Agreed - I will include this as a reference in the next revision
and the only reason for not doing so earlier is that I was not aware of
this draft!

	*	This whole mechanism is mostly useful in the internal
"trusted" network, where NAT traversal (and UDP encapsulation) is
usually *not* deployed.

	I disagree. In my experience, large corporations still employ
NAT heavily, even within the internal trusted network and will continue
to do so in the foreseeable future. This is primarily used to segregate
satellite offices and also for 'hiding' sensitive domains / topology
from the remainder of the internal network, so taking a UDP based
approach is more applicable for these environments. 

	*	Since both IKE and IPsec run over the same port, you
need to magically know in advance that IKE negotiation will result in
ESP-null being selected, at the time when you select the port for the
IKE negotiation.

	Valid point - I need to update the draft with a new transform
that is included for IKE, which will synchronize the two peers in
leveraging this encapsulation. Having just today looked at the Hoffman
draft, this can be handled in a similar way with little or no disruption
to the IKE protocol. If the peer understands the new transform, it will
accept, otherwise this will default to legacy IKE / IPsec. 

	*	Also, the new draft extends the UDP encapsulation RFC,
which I find strange.

	Thanks, 

	- Ken

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 08 Jan 2008 19:52:23 +0200

Hi Ken,

No it's not. As RFC 3948 notes, there's value in keeping a single 
port/connection per client. You'd also have a race condition if the 
first ESP-protected packet is initiated on the network side (this is 
rare of course).

I see your point on why using port 4500 is problematic. One way out, 
staying on port 4500, would be to add a large (64-bit?) magic value 
between your new extension field and the ESP header.

Thanks,

    Yaron

Grewal, Ken wrote:

> per RFC 3948. Within the IKE handshake, a new transform can be 
> exchanged that indicates usage of a new port (say 5500) for the data 
> path. We cannot use 4500 for the data path (IPsec) as we need to 
> differentiate between the proposed encapsulation (which will allow 
> intermediate devices to easily parse the packet) and legacy IPsec 
> packets using 4500.
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Yaron Sheffer [mailto:[email-masked]]
> *Sent:* Tuesday, January 08, 2008 8:13 AM
> *To:* Grewal, Ken
> *Cc:* [email-masked]; Durham, David; Long, Men
> *Subject:* [IPsec] Re: I-D 
> Regarding the 3rd point (use of a special port): if your solution uses 
> a special port, say 5500, for ESP-null traffic, then you'd presumably 
> use port 5500 for both IKE and IPsec - this is how RFC 3948 works. So 
> the very fact that someone is listening on port 5500 implies that they 
>>     * The draft does not mention, and should contain a comparison
>>       with the recent I-D,
>> heavily, even within the internal trusted network and will continue 
>> to do so in the foreseeable future. This is primarily used to 
>> segregate satellite offices and also for 'hiding' sensitive domains / 
>> topology from the remainder of the internal network, so taking a UDP 
>> based approach is more applicable for these environments.
>>
>> extension is valuable for two reasons: 1. To provide algorithm 
>> agility in the proposal (so that new methods employing larger IVs in 
>> the future can be easily comprehended, without a need to modify this 
> Scanned by Check Point Total Security Gateway.
>