Subject: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt

From: Yaron Sheffer <[email-masked]>
Date: Fri, 16 Jun 2006 15:31:27 +0300

Hi All,

This is an individual submission, but I would appreciate your comments to the IPsec mailing list.

Thanks,
	Yaron 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 15, 2006 22:50
To: [email-masked]
Subject: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Secure Beacon: Securely Detecting a Trusted Network
	Author(s)	: Y. Sheffer
	Filename	: draft-sheffer-ipsec-secure-beacon-00.txt
	Pages		: 15
	Date		: 2006-6-15
	
Remote access clients, in particular IPsec-based ones, are heavily deployed in enterprise environments.  In many enterprises the security policy allows remote-access clients to switch to unprotected operation when entering the trusted network.  This document specifies a method that lets a client detect this situation in a secure manner, with the help of a security gateway.  We propose a minor extension to
IKEv2 to achieve this goal.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-secure-beacon-00.txt

To remove yourself from the I-D Announcement list, send a message to [email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
	"get draft-sheffer-ipsec-secure-beacon-00.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sheffer-ipsec-secure-beacon-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Jun 2006 15:19:11 -0400

>comments to the IPsec mailing list.

Yaron,

The I-D talks about the extension to IKE to support the indicated 
functionality. It  does not say how the client behaves (in the 
context of the IPsec model in 4301) in response to the 
SECURE_NETWORK_DETECTED notification in message 2. for example, this 
notification might be interpreted as temporarily changing the SPD 
entry for the address space in the IKE proposal, to make it a BYPASS 
entry. Or maybe the intent is to leave the SPD entry alone, but put 
an SAD (and SPD cache) entry in place for the specified 
address/protocol/port fields.  However, the document provides no 
description of the intended behavior relative to 4301, so it is 
incomplete in that important respect.

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jun 2006 14:01:08 +0300

Hi Kent,

Thanks for your review.

Please let me know if the following added text would address the issue that you raised:

3.5 Client Security Policy

If the client sent the SECURE_NETWORK_DETECT notification and did not receive an indication of a secure network, it SHOULD NOT change its existing SPD.

If the client sent the SECURE_NETWORK_DETECT notification and received the SECURE_NETWORK_DETECTED notification, it should alter its behavior depending on how the SPD is configured.

3.5.1 Statically configured SPD
If the SPD is pre-configured, then upon receiving the SECURE_NETWORK_DETECTED notification, the client SHOULD temporarily convert all PROTECT entries in the SPD which are associated with the peer gateway into BYPASS entries. An entry is said to be associated with this peer gateway if it is a transport mode entry and the remote address is the peer gateway address, or if it is a tunnel mode entry, and the remote tunnel address is the peer gateway address.

3.5.2 Dynamically discovered SPD
IKEv2 allows the client to populate the SPD dynamically based on the INTERNAL_IPv*_SUBNET attributes in the configuration payload (see section 6.3 in [clarifications]). However the client cannot reach this state in the current protocol, in the case of SECURE_NETWORK_DETECTED.

Best regards,

	Yaron

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, June 26, 2006 22:19
> To: Yaron Sheffer
> Cc: [email-masked]
> Subject: Re: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-
> 00.txt
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Jun 2006 11:05:54 -0400

At 2:01 PM +0300 6/28/06, Yaron Sheffer wrote:
>If the client sent the SECURE_NETWORK_DETECT notification and did 
>not receive an indication of a secure network, it SHOULD NOT change 
>its existing SPD.
>
>If the client sent the SECURE_NETWORK_DETECT notification and 
>received the SECURE_NETWORK_DETECTED notification, it should alter 
>its behavior depending on how the SPD is configured.
>
>If the SPD is pre-configured, then upon receiving the 
>SECURE_NETWORK_DETECTED notification, the client SHOULD temporarily 
>convert all PROTECT entries in the SPD which are associated with the 
>peer gateway into BYPASS entries. An entry is said to be associated 
>with this peer gateway if it is a transport mode entry and the 
>remote address is the peer gateway address, or if it is a tunnel 
>mode entry, and the remote tunnel address is the peer gateway 
>address.

We have no notion of "temporarily converting" SPD entries in 4301. 
Maybe it would be better to say that all SPD cache entries created in 
response to this response will be set to BYPASS, even if they were 
marked as PROTECT in the SPD. That sort of description is consistent 
with the current processing model, although it still raises the 
question of when to time out these entries.

Steve