Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

[Yoav Nir <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, October 21, 2008 3:23 PM
> To: Grewal, Ken; Gary Hemminger; Yoav Nir
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Tuesday, October 21, 2008 23:56
> To: Yaron Sheffer; Gary Hemminger; Yoav Nir
> Cc: [e-mail]
> Subject: RE: [IPsec] Identifying encrypted traffic (was:  
> Reauthentication extension for IKEv2)
>
> Some observations below:
>
> 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.
> 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.
> 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: [e-mail] [mailto:[e-mail]] On  
> Behalf Of Yaron Sheffer
> Sent: Tuesday, October 21, 2008 1:37 PM
> To: Gary Hemminger; Yoav Nir
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Tuesday, October 21, 2008 19:02
> To: Yaron Sheffer; Yoav Nir
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Tuesday, October 21, 2008 6:10 AM
> To: Gary Hemminger; Yoav Nir
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On  
> Behalf Of Gary Hemminger
> Sent: Monday, October 20, 2008 20:26
> To: Yoav Nir
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Sat 10/18/2008 2:03 PM
> To: Gary Hemminger
> Cc: [e-mail]
> 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>
> Subject: [IPsec] Reauthentication extension for IKEv2
> From: Tero Kivinen <kivinen at iki.fi>
> Date: Tue, 16 Sep 2008 12:09:14 +0300
> Cc: ipsec at ietf.org
> Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com
> Delivered-to: ipsec at core3.amsl.com
> In-reply-to: <48CF5D7D.7070701 at strongswan.org>
> List-archive: <http://www.ietf.org/pipermail/ipsec>
> List-help: <mailto:[e-mail]?subject=help>
> List-id: Discussion of IPsec protocols <ipsec.ietf.org>
> List-post: <mailto:[e-mail]>
> List-subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[e-mail]?subject=subscribe 
> >
> List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[e-mail]?subject=unsubscribe 
> >
> References: <48CF5D7D.7070701 at strongswan.org>
> Sender: ipsec-bounces at ietf.org
> 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
> From: Martin Willi
> References:
> [IPsec] Reauthentication extension for IKEv2
> From: Martin Willi
> Prev by Date: [IPsec] Reauthentication extension for IKEv2
> Next by Date: Re: [IPsec] Reauthentication extension for IKEv2
> Previous by thread: [IPsec] Reauthentication extension for IKEv2
> Next by thread: Re: [IPsec] Reauthentication extension for IKEv2
> Index(es):
> Date
> Thread
> 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
> [e-mail]
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec