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

List:       ipsec
Subject:    RE: [Ipsec] FW: I-D
From:       Stephen Kent <kent () bbn ! com>
Date:       2006-06-28 15:05:54
Message-ID: p06230926c0c84a6f41ad () [128 ! 89 ! 89 ! 106]
[Download RAW message or body]

At 2:01 PM +0300 6/28/06, Yaron Sheffer wrote:
>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.

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

_______________________________________________
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]