Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)
"Gary Hemminger" <ghemminger@foundrynet.com> Wed, 22 October 2008 17:29 UTC
Return-Path: <ipsec-bounces@ietf.org>
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126AE28C170; Wed, 22 Oct 2008 10:29:42 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156E828C170 for <ipsec@core3.amsl.com>; Wed, 22 Oct 2008 10:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.427
X-Spam-Level:
X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+PpSv1B5JZa for <ipsec@core3.amsl.com>; Wed, 22 Oct 2008 10:29:24 -0700 (PDT)
Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id 1092C3A69B2 for <ipsec@ietf.org>; Wed, 22 Oct 2008 10:29:24 -0700 (PDT)
Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 9E4103E0004; Wed, 22 Oct 2008 10:29:47 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 22 Oct 2008 10:29:48 -0700
Message-ID: <DEFE874FA19CEF4A98F35424DFE7A53E8D9136@xmail.ds.foundrynet.com>
In-Reply-To: <A1E36B4547AAF443BEA10955A159923B0881D81F@rrsmsx505.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)
Thread-Index: Ack0HBFHzdIZKbmYTyadfeP1v1px6AATyJJwAAAkm9A=
References: <DEFE874FA19CEF4A98F35424DFE7A53E88F32C@xmail.ds.foundrynet.com><648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><DEFE874FA19CEF4A98F35424DFE7A53E7363FC@xmail.ds.foundrynet.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com><DEFE874FA19CEF4A98F35424DFE7A53E88F637@xmail.ds.foundrynet.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <A1E36B4547AAF443BEA10955A159923B0881D190@rrsmsx505.amr.corp.intel.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> <DEFE874FA19CEF4A98F35424DFE7A53E8D8FF9@xmail.ds.foundrynet.com> <206900B6-1B1D-45EB-8F6D-D035F4BB3670@checkpoint.com> <A1E36B4547AAF443BEA10955A159923B0881D81F@rrsmsx505.amr.corp.intel.com>
From: Gary Hemminger <ghemminger@foundrynet.com>
To: "Grewal, Ken" <ken.grewal@intel.com>, Yoav Nir <ynir@checkpoint.com>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0729073294=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org
Good point. From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Wednesday, October 22, 2008 10:26 AM To: Yoav Nir; Gary Hemminger Cc: Yaron Sheffer; ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Agreed! ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Tuesday, October 21, 2008 11:40 PM To: Gary Hemminger Cc: Yaron Sheffer; Grewal, Ken; ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Hi Gary If that's the case, then the load balancer would need neither heuristics nor a wrapper. Having terminated the IKE, the load balancer would have the child SA, and would know for certain whether the algorithm is ESP-NULL or something encrypted. In fact, the load balancer would even be able to enforce such a policy. Yoav On Oct 22, 2008, at 2:00 AM, Gary Hemminger wrote: The client would negotiate IKE with the load balancer and would not directly negotiate with the Server. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Hi Ken, Thanks for the clarification. But I still don't understand how your scenario works. Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. Regards, Yaron ________________________________ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Some observations below: 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode. 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads. Thanks, - Ken ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. Thanks, Yaron ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) Hi Gary, I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? Thanks, Yaron ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. Gary ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. Gary [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi <martin at strongswan.org <mailto:martin@DOMAIN.HIDDEN> > * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen <kivinen at iki.fi <mailto:kivinen@DOMAIN.HIDDEN> > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org <mailto:ipsec@DOMAIN.HIDDEN> * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com <mailto:ietfarch-ipsec-web-archive@DOMAIN.HIDDEN> * Delivered-to: ipsec at core3.amsl.com <mailto:ipsec@DOMAIN.HIDDEN> * In-reply-to: <48CF5D7D.7070701 at strongswan.org <mailto:48CF5D7D.7070701@DOMAIN.HIDDEN> > * List-archive: <http://www.ietf.org/pipermail/ipsec> * List-help: <mailto:ipsec-request@ietf.org?subject=help> * List-id: Discussion of IPsec protocols <ipsec.ietf.org> * List-post: <mailto:ipsec@ietf.org> * List-subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe> * List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe> * References: <48CF5D7D.7070701 at strongswan.org <mailto:48CF5D7D.7070701@DOMAIN.HIDDEN> > * Sender: ipsec-bounces at ietf.org <mailto:ipsec-bounces@DOMAIN.HIDDEN> ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec ________________________________ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03108.html> * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html> * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html> * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03108.html> * Previous by thread: [IPsec] Reauthentication extension for IKEv2 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html> * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03108.html> * Index(es): * Date <http://www.ietf.org/mail-archive/web/ipsec/current/maillist.html#03107> * Thread <http://www.ietf.org/mail-archive/web/ipsec/current/threads.html#03107> Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
- [IPsec] Reauthentication extension for IKEv2 Martin Willi
- [IPsec] Reauthentication extension for IKEv2 Tero Kivinen
- Re: [IPsec] Reauthentication extension for IKEv2 Martin Willi
- Re: [IPsec] Reauthentication extension for IKEv2 Tero Kivinen
- Re: [IPsec] Reauthentication extension for IKEv2 David Wierbowski
- [IPsec] Reauthentication extension for IKEv2 David Wierbowski
- Re: [IPsec] Reauthentication extension for IKEv2 Yoav Nir
- Re: [IPsec] Reauthentication extension for IKEv2 Yoav Nir
- [IPsec] Reauthentication extension for IKEv2 Tero Kivinen
- Re: [IPsec] Reauthentication extension for IKEv2 Tero Kivinen
- Re: [IPsec] Reauthentication extension for IKEv2 Martin Willi
- Re: [IPsec] Reauthentication extension for IKEv2 Yoav Nir
- Re: [IPsec] Reauthentication extension for IKEv2 Pasi.Eronen
- Re: [IPsec] Reauthentication extension for IKEv2 Tero Kivinen
- Re: [IPsec] Reauthentication extension for IKEv2 Tero Kivinen
- Re: [IPsec] Reauthentication extension for IKEv2 Pasi.Eronen
- [IPsec] Reauthentication extension for IKEv2 Gary Hemminger
- Re: [IPsec] Reauthentication extension for IKEv2 Yoav Nir
- Re: [IPsec] Reauthentication extension for IKEv2 Gary Hemminger
- [IPsec] Identifying encrypted traffic (was: Reaut… Yaron Sheffer
- Re: [IPsec] Identifying encrypted traffic (was: R… Gary Hemminger
- Re: [IPsec] Identifying encrypted traffic (was: R… Yaron Sheffer
- Re: [IPsec] Identifying encrypted traffic (was: R… Grewal, Ken
- Re: [IPsec] Identifying encrypted traffic (was: R… Yaron Sheffer
- Re: [IPsec] Identifying encrypted traffic (was: R… Gary Hemminger
- Re: [IPsec] Identifying encrypted traffic (was: R… Gary Hemminger
- Re: [IPsec] Identifying encrypted traffic (was: R… Yaron Sheffer
- Re: [IPsec] Identifying encrypted traffic (was: R… Yoav Nir
- Re: [IPsec] Identifying encrypted traffic (was: R… Grewal, Ken
- Re: [IPsec] Identifying encrypted traffic (was: R… Grewal, Ken
- Re: [IPsec] Identifying encrypted traffic (was: R… Grewal, Ken
- Re: [IPsec] Identifying encrypted traffic (was: R… Gary Hemminger
- Re: [IPsec] Identifying encrypted traffic (was: R… Gary Hemminger
- Re: [IPsec] Identifying encrypted traffic (was: R… Yaron Sheffer
- Re: [IPsec] Identifying encrypted traffic (was: R… Gary Hemminger