[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    RE: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt
From:       Yaron Sheffer <yaronf () checkpoint ! com>
Date:       2006-06-28 11:01:08
Message-ID: 200606281101.k5SB18NH029456 () michael ! checkpoint ! com
[Download RAW message or body]

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

> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Monday, June 26, 2006 22:19
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: Re: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-
> 00.txt
> 
> At 3:31 PM +0300 6/16/06, Yaron Sheffer wrote:
> > Hi All,
> > 
> > This is an individual submission, but I would appreciate your
> > comments to the IPsec mailing list.
> > 
> > Thanks,
> > 	Yaron
> > 
> 
> 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



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]