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

["Gary Hemminger" <[e-mail]>]

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
<mailto:[e-mail]> > 
*	Subject: [IPsec] Reauthentication extension for IKEv2 
*	From: Tero Kivinen <kivinen at iki.fi
<mailto:[e-mail]> > 
*	Date: Tue, 16 Sep 2008 12:09:14 +0300 
*	Cc: ipsec at ietf.org <mailto:[e-mail]>  
*	Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com
<mailto:[e-mail]>  
*	Delivered-to: ipsec at core3.amsl.com
<mailto:[e-mail]>  
*	In-reply-to: <48CF5D7D.7070701 at strongswan.org
<mailto:[e-mail]> > 
*	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
<mailto:[e-mail]> > 
*	Sender: ipsec-bounces at ietf.org
<mailto:[e-mail]> 

________________________________

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec