Subject: [IPsec] Reauthentication extension for IKEv2

From: "Gary Hemminger" <[email-masked]>
Date: Fri, 17 Oct 2008 17:35:33 -0700

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:[email-masked]> >
*	Subject: [IPsec] Reauthentication extension for IKEv2
*	From: Tero Kivinen <kivinen at iki.fi
<mailto:[email-masked]> >
*	Date: Tue, 16 Sep 2008 12:09:14 +0300
*	Cc: ipsec at ietf.org <mailto:[email-masked]> 
*	Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com
<mailto:[email-masked]> 
*	Delivered-to: ipsec at core3.amsl.com
<mailto:[email-masked]> 
*	In-reply-to: <48CF5D7D.7070701 at strongswan.org
<mailto:[email-masked]> >
*	List-archive: <http://www.ietf.org/pipermail/ipsec>
*	List-help: <mailto:[email-masked]?subject=help>
*	List-id: Discussion of IPsec protocols <ipsec.ietf.org>
*	List-post: <mailto:[email-masked]>
*	List-subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>,
<mailto:[email-masked]?subject=subscribe>
*	List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>,
<mailto:[email-masked]?subject=unsubscribe>
*	References: <48CF5D7D.7070701 at strongswan.org
<mailto:[email-masked]> >
*	Sender: ipsec-bounces at ietf.org
<mailto:[email-masked]> 

________________________________

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

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

---

From: Yoav Nir <[email-masked]>
Date: Sat, 18 Oct 2008 23:03:17 +0200

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
>
>
>
> 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:[email-masked]?subject=help>
> List-id: Discussion of IPsec protocols <ipsec.ietf.org>
> List-post: <mailto:[email-masked]>
> List-subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=subscribe 
> >
> List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=unsubscribe 
> >
> References: <48CF5D7D.7070701 at strongswan.org>
> Sender: ipsec-bounces at ietf.org
> Martin Willi writes:
> Follow-Ups:
> Re: [IPsec] Reauthentication extension for IKEv2
> From: Martin Willi
> References:
> 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.
>

---

From: "Gary Hemminger" <[email-masked]>
Date: Mon, 20 Oct 2008 11:26:02 -0700

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:[email-masked]]
Sent: Sat 10/18/2008 2:03 PM
To: Gary Hemminger
Cc: [email-masked]
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

	

	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

	*	To: Martin Willi <martin at strongswan.org <mailto:[email-masked]> > 
	*	Subject: [IPsec] Reauthentication extension for IKEv2 
	*	From: Tero Kivinen <kivinen at iki.fi <mailto:[email-masked]> > 
	*	Date: Tue, 16 Sep 2008 12:09:14 +0300 
	*	Cc: ipsec at ietf.org <mailto:[email-masked]>  
	*	Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com <mailto:[email-masked]>  
	*	Delivered-to: ipsec at core3.amsl.com <mailto:[email-masked]>  
	*	In-reply-to: <48CF5D7D.7070701 at strongswan.org <mailto:[email-masked]> > 
	*	List-archive: <http://www.ietf.org/pipermail/ipsec> 
	*	List-help: <mailto:[email-masked]?subject=help> 
	*	List-id: Discussion of IPsec protocols <ipsec.ietf.org> 
	*	List-post: <mailto:[email-masked]> 
	*	List-subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=subscribe> 
	*	List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=unsubscribe> 
	*	References: <48CF5D7D.7070701 at strongswan.org <mailto:[email-masked]> > 
	*	Sender: ipsec-bounces at ietf.org <mailto:[email-masked]> 

	Martin Willi writes:
	> What do you think about such an extension? Already considered something

	 

	 

	*	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

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 21 Oct 2008 15:09:42 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: [email-masked]
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

  _____  

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

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

  _____  

*	To: Martin Willi <martin at <mailto:[email-masked]>
strongswan.org> 
*	Subject: [IPsec] Reauthentication extension for IKEv2 
*	From: Tero Kivinen <kivinen at iki.fi <mailto:[email-masked]>
*	Date: Tue, 16 Sep 2008 12:09:14 +0300 
*	Cc: ipsec at ietf.org <mailto:[email-masked]>  
*	Delivered-to: ietfarch-ipsec-web-archive
<mailto:[email-masked]>  at core3.amsl.com 
*	Delivered-to: ipsec at core3.amsl.com <mailto:[email-masked]>  
*	In-reply-to: <48CF5D7D.7070701 at
<mailto:[email-masked]>  strongswan.org> 
*	List-archive: <http://www.ietf.org/pipermail/ipsec> 
*	List-help: <mailto:[email-masked]?subject=help> 
*	List-id: Discussion of IPsec protocols <ipsec.ietf.org> 
*	List-post: <mailto:[email-masked]> 
*	List-subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>,
<mailto:[email-masked]?subject=subscribe> 
*	List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>,
<mailto:[email-masked]?subject=unsubscribe> 
*	References: <48CF5D7D.7070701 at
<mailto:[email-masked]>  strongswan.org> 
*	Sender: ipsec-bounces at ietf.org
<mailto:[email-masked]> 

  _____  

 

 

 

  _____  

*	Follow-Ups: 

*	 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03108.html>
Re: [IPsec] Reauthentication extension for IKEv2 

*	From: Martin Willi

*	References: 

*	 <http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html>
[IPsec] Reauthentication extension for IKEv2 

*	From: Martin Willi

*	Prev by Date: [IPsec]
<http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html>
Reauthentication extension for IKEv2 
*	Next by Date: Re:
<http://www.ietf.org/mail-archive/web/ipsec/current/msg03108.html>  [IPsec]
Reauthentication extension for IKEv2 
*	Previous by thread: [IPsec]
<http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html>
Reauthentication extension for IKEv2 
*	Next by thread: Re:
<http://www.ietf.org/mail-archive/web/ipsec/current/msg03108.html>  [IPsec]
Reauthentication extension for IKEv2 
*	Index(es): 

*
*

Note: Messages sent to this list are the opinions of the senders and do not
imply endorsement by the IE

---

From: "Gary Hemminger" <[email-masked]>
Date: Tue, 21 Oct 2008 10:01:30 -0700

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:[email-masked]] 
Sent: Tuesday, October 21, 2008 6:10 AM
To: Gary Hemminger; Yoav Nir
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
Of Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: [email-masked]
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

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.

to re-authenticate early enough, so that connections are not broken. The

Yoav

 

Gary

something

 

 

*	Follow-Ups: 

		*	From: Martin Willi

*	References: 

		*	From: Martin Willi

	*	Date

	*	Thread

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 21 Oct 2008 22:36:52 +0200

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:[email-masked]] 
Sent: Tuesday, October 21, 2008 19:02
To: Yaron Sheffer; Yoav Nir
Cc: [email-masked]
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

Hi Gary,

Thanks,

            Yaron

  _____  

Gary

  _____  

Hi Gary. 

Yoav

 

Gary

  _____  

  _____  

 

 

 

  _____  

*	Follow-Ups: 

*	From: Martin Willi

*	References: 

*	From: Martin Willi

*	Prev by Date: [IPsec]

*

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 21 Oct 2008 15:55:39 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Tuesday, October 21, 2008 1:37 PM
To: Gary Hemminger; Yoav Nir
Cc: [email-masked]
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

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:[email-masked]]
Sent: Tuesday, October 21, 2008 6:10 AM
To: Gary Hemminger; Yoav Nir
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] Reauthentication extension for IKEv2

Gary

Yoav

Gary

 *   To: Martin Willi <martin at strongswan.org<mailto:[email-masked]>>
 *   Subject: [IPsec] Reauthentication extension for IKEv2
 *   From: Tero Kivinen <kivinen at iki.fi<mailto:[email-masked]>>
 *   Date: Tue, 16 Sep 2008 12:09:14 +0300
 *   Cc: ipsec at ietf.org<mailto:[email-masked]>
 *   Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com<mailto:[email-masked]>
 *   Delivered-to: ipsec at core3.amsl.com<mailto:[email-masked]>
 *   In-reply-to: <48CF5D7D.7070701 at strongswan.org<mailto:[email-masked]>>
 *   List-archive: <http://www.ietf.org/pipermail/ipsec>
 *   List-help: <mailto:[email-masked]?subject=help>
 *   List-id: Discussion of IPsec protocols <ipsec.ietf.org>
 *   List-post: <mailto:[email-masked]>
 *   List-subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=subscribe>
 *   List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=unsubscribe>
 *   References: <48CF5D7D.7070701 at strongswan.org<mailto:[email-masked]>>
 *   Sender: ipsec-bounces at ietf.org<mailto:[email-masked]>

all?

fingerprint or similar)?

--

IPsec mailing list

IPsec at ietf.org

 *   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>

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 22 Oct 2008 00:22:47 +0200

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:[email-masked]] 
Sent: Tuesday, October 21, 2008 23:56
To: Yaron Sheffer; Gary Hemminger; Yoav Nir
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaron Sheffer
Sent: Tuesday, October 21, 2008 1:37 PM
To: Gary Hemminger; Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication
extension for IKEv2)

Thanks,

            Yaron

  _____  

Gary

Hi Gary,

Thanks,

            Yaron

  _____  

Gary

  _____  

Hi Gary. 

Yoav

 

Gary

  _____  

  _____  

 

 

 

  _____  

*	Follow-Ups: 

*	From: Martin Willi

*	References: 

*	From: Martin Willi

*	Prev by Date: [IPsec]

*

---

From: "Gary Hemminger" <[email-masked]>
Date: Tue, 21 Oct 2008 16:53:57 -0700

Ken,

These are accurate depictions of the scenarios we will face.  Server
persistence is very important.  And yes, I was a bit concerned about the
"heuristics approach," but I haven't seen what these heuristics might
be.  Any heuristics would need to use either proprietary hardware or
done in software.  Maybe it wouldn't be difficult, but it might change
over time.  With the payload wrapper approach, we could have the
merchant silicon vendor add it to their products (hopefully).

Gary

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Grewal, Ken
Sent: Tuesday, October 21, 2008 2:56 PM
To: Yaron Sheffer; Gary Hemminger; Yoav Nir
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
Of Yaron Sheffer
Sent: Tuesday, October 21, 2008 1:37 PM
To: Gary Hemminger; Yoav Nir
Cc: [email-masked]
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:[email-masked]] 
Sent: Tuesday, October 21, 2008 19:02
To: Yaron Sheffer; Yoav Nir
Cc: [email-masked]
Subject: RE: Identifying encrypted traffic (was: [IPsec]
Reauthentication extension for IKEv2)

Gary

Hi Gary,

Thanks,

            Yaron

Gary

Hi Gary. 

Yoav

 

Gary

something

 

 

*	Follow-Ups: 

		*	From: Martin Willi

*	References: 

		*	From: Martin Willi

	*	Date

	*	Thread

---

From: "Gary Hemminger" <[email-masked]>
Date: Tue, 21 Oct 2008 17:00:02 -0700

The client would negotiate IKE  with the load balancer and would not
directly negotiate with the Server.

Gary

From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 3:23 PM
To: Grewal, Ken; Gary Hemminger; Yoav Nir
Cc: [email-masked]
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

Subject: RE: [IPsec] Identifying encrypted traffic (was:

Some observations below:

Thanks, 

- Ken

Thanks,

            Yaron

Gary

Hi Gary,

Thanks,

            Yaron

Gary

Hi Gary. 

Yoav

 

Gary

something

 

 

*	Follow-Ups: 

		*	From: Martin Willi

*	References: 

		*	From: Martin Willi

	*	Date

	*	Thread

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 22 Oct 2008 09:03:15 +0200

In that case, the load balancer can identify the traffic using the normal
ESP SPI field, and knows exactly what kind of traffic it is and whether it
is encrypted. There is no need to change the ESP protocol for this scenario.

Thanks,

            Yaron

  _____  

From: Gary Hemminger [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 2:00
To: Yaron Sheffer; Grewal, Ken; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication
extension for IKEv2)

Gary

Hi Ken,

Regards,

            Yaron

  _____  

Some observations below:

Thanks, 

- Ken

  _____  

Thanks,

            Yaron

  _____  

Gary

Hi Gary,

Thanks,

            Yaron

  _____  

Gary

  _____  

Hi Gary. 

Yoav

 

Gary

  _____  

  _____  

 

 

 

  _____  

*	Follow-Ups: 

*	From: Martin Willi

*	References: 

*	From: Martin Willi

*	Prev by Date: [IPsec]

*

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 Oct 2008 08:40:12 +0200

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:

> Thanks for the clarification. But I still don’t understand how your  
> scenario works.
>
> 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
>
> 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  
> 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
>
> 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
>
> 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
>
> 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  
> 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  
> 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.
>
> 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
>

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 22 Oct 2008 11:03:39 -0600

Hi Yaron, 

The scenario I was referring to requires the servers behind the load
balancer to act as a cluster and hence on the first ESP packet, obtain the
IPsec SA from another member of the cluster with which the SA was negotiated
(this may be inherently done on the completion of an IKE SA also). I have
seen this deployed using a back-end dedicated management interface for state
synchronization. Remember, as far as the client is concerned, it is talking
to just one server and does not see a cluster, so the cluster of servers
have to act as one to some degree, including synchronization between them. 

Now, state synchronization on the first packet (e.g. of a new TCP
connection) is one thing and achievable, but the real benefit of the load
balancer is to 'peg' all subsequent packets for that TCP session to the same
server. This ensures that within a given TCP (or another stateful protocol)
session, there is no need to continually synchronize the TCP state between
all members of the server cluster - if this was to be done, then the
management / synchronization port between the cluster members would generate
more traffic then being received into the cluster, which is not desirable or
practical. 

So, from a load balancer point of view, it can look into the ESP (null)
packet and see if this is a new connection (i.e. no existing rules based on
IP/port information). If a new connection, it can use whatever internal
rules to assign this packet to any server with the least load. On doing
this, the load balancer updates internal rules to ensure any subsequent
packets for the same stream as sent to the same server as the initial packet
- that is the benefit (this is what load balancers do today for clear text
traffic). 

I have also seen alternative solutions proposed - e.g. A given server
completing an IKE negotiation can communicate 3-tuple (IP, SPI, protocol)
information back to a load balancer and the load balancer can utilize this
for any subsequent decisions on assigning load for IPsec encapsulated
packet, but solutions like this require synchronization between the load
balancer and the servers, which is less desirable. For any cluster of
resources acting together to accommodate load balancing solutions, a certain
amount of inter-cluster communication is expected and that fits in with the
former solution above. 

Also remember, that IPsec E2E is not widely deployed because of problems
exactly like this one (loss of visibility / control / functionality for
intermediary devices) and this is what we are trying to address.

Thanks, 

- Ken

  _____  

Hi Ken,

Regards,

            Yaron

  _____  

Some observations below:

Thanks, 

- Ken

  _____  

Thanks,

            Yaron

  _____  

Gary

Hi Gary,

Thanks,

            Yaron

  _____  

Gary

  _____  

Hi Gary. 

Yoav

 

Gary

  _____  

  _____  

 

 

 

  _____  

*	Follow-Ups: 

*	From: Martin Willi

*	References: 

*	From: Martin Willi

*	Prev by Date: [IPsec]

*

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 22 Oct 2008 11:09:24 -0600

Hi Gary, 

I agree with Yaron here. The scenario you are describing can be done today
if the load balancer can act as an IPsec termination point and nothing new
is needed. 

Also, please see my other response on using a load balancer which does not
terminate IPsec, but can benefit from the changes being proposed.

Let me know if I am missing something. 

Thanks, 

- Ken

  _____  

From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 12:03 AM
To: Gary Hemminger; Grewal, Ken; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication
extension for IKEv2)

Thanks,

            Yaron

  _____  

Gary

Hi Ken,

Regards,

            Yaron

  _____  

Some observations below:

Thanks, 

- Ken

  _____  

Thanks,

            Yaron

  _____  

Gary

Hi Gary,

Thanks,

            Yaron

  _____  

Gary

  _____  

Hi Gary. 

Yoav

 

Gary

  _____  

  _____  

 

 

 

  _____  

*	Follow-Ups: 

*	From: Martin Willi

*	References: 

*	From: Martin Willi

*	Prev by Date: [IPsec]

*

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 22 Oct 2008 11:26:23 -0600

Agreed!

________________________________
From: Yoav Nir [mailto:[email-masked]]
Sent: Tuesday, October 21, 2008 11:40 PM
To: Gary Hemminger
Cc: Yaron Sheffer; Grewal, Ken; [email-masked]
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

The client would negotiate IKE  with the load balancer and would not directly negotiate with the Server.

Gary

From: Yaron Sheffer [mailto:[email-masked]]
Sent: Tuesday, October 21, 2008 3:23 PM
To: Grewal, Ken; Gary Hemminger; Yoav Nir
Cc: [email-masked]<mailto:[email-masked]>
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:[email-masked]]
Sent: Tuesday, October 21, 2008 23:56
To: Yaron Sheffer; Gary Hemminger; Yoav Nir
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

Some observations below:

Thanks,
- Ken

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Tuesday, October 21, 2008 1:37 PM
To: Gary Hemminger; Yoav Nir
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

Thanks,
            Yaron

Cc: [email-masked]<mailto:[email-masked]>

Gary

Cc: [email-masked]<mailto:[email-masked]>

Hi Gary,

Thanks,
            Yaron

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] Reauthentication extension for IKEv2

Gary

Cc: [email-masked]<mailto:[email-masked]>

Yoav

Gary

all?

fingerprint or similar)?

--

IPsec mailing list

IPsec at ietf.org

 *   Follow-Ups:

       *   From: Martin Willi

 *   References:

       *   From: Martin Willi

---

From: "Gary Hemminger" <[email-masked]>
Date: Wed, 22 Oct 2008 10:29:48 -0700

Good point.

From: Grewal, Ken [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:26 AM
To: Yoav Nir; Gary Hemminger
Cc: Yaron Sheffer; [email-masked]
Subject: RE: [IPsec] Identifying encrypted traffic (was:
Reauthentication extension for IKEv2)

Agreed!

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

Gary

Hi Ken,

Regards,

            Yaron

Some observations below:

Thanks,

- Ken

Thanks,

            Yaron

Gary

Hi Gary,

Thanks,

            Yaron

Gary

Hi Gary.

Yoav

 

Gary

something

 

 

*	Follow-Ups:

		*	From: Martin Willi

*	References:

		*	From: Martin Willi

	*	Date

	*	Thread

---

From: "Gary Hemminger" <[email-masked]>
Date: Wed, 22 Oct 2008 12:17:06 -0700

You are absolutely correct Ken.  I think I switched the names of the
parties I agree with in a previous email sorry.  Anyway, we need to do
the termination.  Very few organizations use load balancers where the
servers all have to share state with each other.  This is simply too
difficult to get working, and to debug.

Gary

Sent: Wednesday, October 22, 2008 10:09 AM

Hi Gary, 

I agree with Yaron here. The scenario you are describing can be done
today if the load balancer can act as an IPsec termination point and
nothing new is needed. 

Also, please see my other response on using a load balancer which does
not terminate IPsec, but can benefit from the changes being proposed.

Thanks, 

- Ken

In that case, the load balancer can identify the traffic using the
normal ESP SPI field, and knows exactly what kind of traffic it is and
whether it is encrypted. There is no need to change the ESP protocol for
this scenario.

Thanks,

            Yaron

Gary

Hi Ken,

Regards,

            Yaron

Some observations below:

Thanks, 

- Ken

Thanks,

            Yaron

Gary

Hi Gary,

Thanks,

            Yaron

Gary

Hi Gary. 

Yoav

 

Gary

something

 

 

*	Follow-Ups: 

		*	From: Martin Willi

*	References: 

		*	From: Martin Willi

	*	Date

	*	Thread

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 23 Oct 2008 09:59:02 +0200

Hi Ken,

This is obviously complex to implement, as Gary mentioned.

Also, there are weird interactions with ESP anti-replay. You are proposing
in demultiplex one SPI between multiple servers at the backend. The load
balancer may be able to keep track of the replay window for the whole SPI
(which each server would not be able to do on its own), but it will not be
able to send back notifications if any problems are detected.

Thanks,

            Yaron

  _____  

From: Grewal, Ken [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 19:04
To: Yaron Sheffer; Gary Hemminger; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication
extension for IKEv2)

Hi Yaron, 

Thanks, 

- Ken

  _____  

Hi Ken,

Regards,

            Yaron

  _____  

Some observations below:

Thanks, 

- Ken

  _____  

Thanks,

            Yaron

  _____  

Gary

Hi Gary,

Thanks,

            Yaron

  _____  

Gary

  _____  

Hi Gary. 

Yoav

 

Gary

  _____  

  _____  

 

 

 

  _____  

*	Follow-Ups: 

*	From: Martin Willi

*	References: 

*	From: Martin Willi

*	Prev by Date: [IPsec]

*

---

From: "Gary Hemminger" <[email-masked]>
Date: Thu, 23 Oct 2008 18:12:45 -0700

This is correct.  We would only need the new wrapper if we were
inspecting, but not load balancing.  Once we are configured to load
balance, we would know, but if we were in inspection only mode, then we
would need the wrapper to determine that the payload is encrypted.

Gary

Thanks,

            Yaron

Gary

Hi Ken,

Regards,

            Yaron

Some observations below:

Thanks, 

- Ken

Thanks,

            Yaron

Gary

Hi Gary,

Thanks,

            Yaron

Gary

Hi Gary. 

Yoav

 

Gary

something

 

 

*	Follow-Ups: 

		*	From: Martin Willi

*	References: 

		*	From: Martin Willi

	*	Date

	*	Thread