Hi Scott,
I just felt that the _why_ the tokens had to be protected was not so precisely
covered (clarity). My re-write was only intended for the beginning of the
section.
I agree that knowing the SA state is the only solution that we can think of but
it is barely a solution in practice. This is why I stated it in a negative way
("MUST NOT send" rather than "MUST verify"). But I agree the statement is
roughly the same.
I also agree that 5.2 does not solve all problems and I do not mean to remove
that part. It is good to keep it.
One more comment on section 9.3 (QCD Token Enumeration):
-8<---
The methods in Section 5.1 and Section 5.2 allow for a periodic
change of the QCD_SECRET. Any such change invalidates the entire
dictionary.
-8<---
Don't we mean that section 4.4 allows the replacement of the tokens should the
QCD_SECRET change ?
thanks and regards,
fred
On 04 Feb 2011, at 17:21, Scott C Moonen wrote:
> I'm ok with Frederic's first paragraph as an introduction to the issue; I
> don't have a strong preference for his text there or for mine.
>
> His second paragraph is lacking a warning that the approach of section 5.2
> does not solve all problems in all cases (e.g., what I communicate in my
> sentence "It is important to note ..."). But I'm ok with either (1) using my
> paragraph as-is, (2) making some change to how my paragraph states "MUST be
> able to tell ...," (3) or making some change to Frederick's second paragraph
> to better convey this.
>
>
> Scott Moonen ([email protected])
> z/OS Communications Server TCP/IP Development
> http://www.linkedin.com/in/smoonen
>
> <graycol.gif>David Wierbowski---02/02/2011 09:40:42 AM---I'm not sure what
> Frederic means by this statement should "be moved under Security
> Considerations."
>
> From: David Wierbowski/Endicott/IBM@IBMUS
> To: Yoav Nir <[email protected]>
> Cc: "[email protected]" <[email protected]>, [email protected]
> Date: 02/02/2011 09:40 AM
> Subject: Re: [IPsec] Fwd: Failure Detection - issue #202
> Sent by: [email protected]
>
>
>
> I'm not sure what Frederic means by this statement should "be moved under
> Security Considerations." Section 9.2 is already in the Security
> Considerations section.
>
> As far as his proposed text, I feel that Scott's text does a better job
> describing the concern. Frederic's own text does not help with his concern
> of hiding the complexity in the statement that "all members MUST be able to
> tell whether a particular IKE SA is active anywhere in the cluster." He
> just reworded the statement to be "Practically, IPsec Failure Detection is
> thus not applicable to deployments where the QCD token is shared by
> multiple gateways and the gateways can not assess whether the token can be
> legitimately sent in the clear while another gateway may actually still own
> the SA's." Both statements mean the same thing and impose the same
> requirement.
>
> If consensus is that others prefer Frederic's statement over the one that
> Scott provided us, then I believe the "Practically" should be deleted from
> the sentence that I mentioned above and the last sentence should be changed
> to, "Load balancer designs may fall in this category." I don't think we
> should presume to know what is typical in load balancers.
>
>
> Dave Wierbowski
>
>
> z/OS Comm Server Developer
>
> Phone:
> Tie line: 620-4055
> External: 607-429-4055
>
>
>
>
>
>
> From: Yoav Nir <[email protected]>
> To: "[email protected]" <[email protected]>
> Date: 02/01/2011 04:30 PM
> Subject: [IPsec] Fwd: Failure Detection - issue #202
> Sent by: [email protected]
>
>
>
> Adding the IPsec list.
>
> Begin forwarded message:
>
> From: Frederic Detienne <[email protected]>
> Date: February 1, 2011 9:37:33 PM GMT+02:00
> To: Paul Hoffman <[email protected]>
> Cc: Yoav Nir <[email protected]>, Pratima Sethi <[email protected]>,
> Yaron Sheffer <[email protected]>
> Subject: Re: [IPsec] Failure Detection - issue #202
>
> Hi Paul, Yoav,
>
> thanks. We are rather puzzled and have been debating how to address
> this.
>
> The proposal should either properly support Load Balancers or should
> step down and rule out that use case.
>
> The statement:
>
> -8<---
> IPsec gateways would work, but in order to support this
> specification, all members MUST be able to tell whether
> a particular
> IKE SA is active anywhere in the cluster
>
> -8<---
>
> Hides a lot of complexity behind a single sentence. This sentence
> actually makes Failure Detection impractical. Simplicity of
> implementation (as compared to SA state synchronization) were key
> drivers for us in this proposal.
>
> The statement should be more precise about the general scenario and
> be moved under Security Considerations.
>
> -8<---
> If an attacker can somehow access a QCD token while the SA's are
> still active, this attacker will be able to tear down the sessions at
> will. In particular, avoiding false positives is critical to the
> security of the proposal and a token maker MUST NOT send a QCD token
> in an unprotected message for an existing IKE SA.
>
> Practically, IPsec Failure Detection is thus not applicable to
> deployments where the QCD token is shared by multiple gateways and
> the gateways can not assess whether the token can be legitimately
> sent in the clear while another gateway may actually still own the
> SA's. Load balancer designs typically fall in this category.
> -8<---
>
> thanks and regards,
>
> Frederic
>
> On 01 Feb 2011, at 17:51, Paul Hoffman wrote:
>
> Pratima and Frederic: Please respond to Yaron and I ASAP,
> either way, whether or not you agree with the wording. Given
> that this was your issue and you did not comment during WG LC,
> we are concerned that we have lost contact with you.
>
> If you do not agree with the wording, you need to say so on the
> mailing list before Friday.
>
> --Paul Hoffman
>
> On 2/1/11 7:05 AM, Yoav Nir wrote:
> Hi all.
>
> Following last week's conf call, Scott Moonen has
> proposed text to resolve issue #202. The idea is to
> remove section 9.4 entirely, and change section 9.2 as
> follows:
>
>
> OLD:
>
> 9.2. QCD Token Transmission
>
> A token maker MUST NOT send a QCD token in an
> unprotected message for
> an existing IKE SA. This implies that a conforming QCD
> token maker
> MUST be able to tell whether a particular pair of IKE
> SPIs represent
> a valid IKE SA.
>
> This requirement is obvious and easy in the case of a
> single gateway.
> However, some implementations use a load balancer to
> divide the load
> between several physical gateways. It MUST NOT be
> possible even in
> such a configuration to trick one gateway into sending
> a QCD token
> for an IKE SA which is valid on another gateway.
>
> This document does not specify how a load sharing
> configuration of
> IPsec gateways would work, but in order to support this
> specification, all members MUST be able to tell whether
> a particular
> IKE SA is active anywhere in the cluster. One way to
> do it is to
> synchronize a list of active IKE SPIs among all the
> cluster members.
>
>
> NEW:
>
> 9.2. QCD Token Transmission
>
> A token maker MUST NOT send a valid QCD token in an
> unprotected
> message for an existing IKE SA.
>
> This requirement is obvious and easy in the case of a
> single gateway.
> However, some implementations use a load balancer to
> divide the load
> between several physical gateways. It MUST NOT be
> possible even in
> such a configuration to trick one gateway into sending
> a valid QCD
> token for an IKE SA which is valid on another gateway.
> This is true
> whether the attempt to trick the gateway uses the token
> taker's IP
> address or a different IP address.
>
> Because it includes the token taker's IP address in the
> token
> generation, the method in Section 5.2 prevents
> revealing the QCD
> token for an existing pair of IKE SPIs to an attacker
> who is using a
> different IP address. Note that the use of this method
> causes the
> tokens to be invalidated whenever the token taker's
> address changes.
> It is important to note that this method does not
> prevent revealing
> the QCD token to a man-in-the-middle attacker who is
> spoofing the
> token taker's IP address, if that attacker is able to
> direct messages
> to a cluster member other than the member responsible
> for the IKE SA.
> This document does not specify how a load-sharing
> configuration of
> IPsec gateways would work, but in order to support this
> specification, all members MUST be able to tell whether
> a particular
> IKE SA is active anywhere in the cluster. One way to
> do it is to
> synchronize a list of active IKE SPIs among all the
> cluster members.
>
>
> Please discuss this issue this week, as I intend to
> publish version -04 on Friday if there are no objections
> to this change.
>
> Yoav
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
>
> Scanned by Check Point Total Security Gateway.
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
