Scott, I agree that there is relationship between sections 9.2 and 9.4. The statement that "all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster" which is found in 9.2 is consistent with my comment that " the algorithms in 5.1 and 5.2 should not be used in cases where load balancing cluster members share the same QCD token and do not share IKE SA state." Although I suppose I should have said same QCD_SECRET instead of QCD token to be more accurate.
I could see why you would say that the algorithm in 5.2 as justified in
section 9.4 is being used to meet the requirement that "A token maker MUST
NOT send a QCD token in an unprotected message for an existing IKE SA."
Certainly if we do not include IP address it is possible that a cluster
member could send the QCD token of an existing IKE SA to an attacker using
a different source IP address. In that case we'd be unknowingly violating
the rule. By adding the ip address of the taker we prevent this.
I think you are correct that the two sections could be combined, but I'll
defer to Yoav on that.
As an aside I see that I cut and paste the wrong paragraph in my append. I
had actually intended to cut and paste the last paragraph of 9.4 and I now
see that I cut and paste the next to last paragraph in section 9.4 :>).
Dave Wierbowski
From: Scott C Moonen/Raleigh/IBM@IBMUS
To: David Wierbowski/Endicott/IBM@IBMUS
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-boun...@ietf.org, Yoav
Nir <y...@checkpoint.com>
Date: 01/13/2011 09:50 AM
Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB
Sent by: ipsec-boun...@ietf.org
Combining the two sections could also make it clearer that 5.2/9.4 may not
be a "complete" solution for any given environment. The approach of 5.2/9.4
solves the problem of an independent attacker using a different source IP
address, but not a proximate/MitM attacker as is currently addressed in
9.2.
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
(Embedded image moved to file: pic34804.gif)Inactive hide details for Scott
C Moonen---01/12/2011 03:54:03 PM---I wonder if there's a way to merge
sections 9.2 and 9.4. IScott C Moonen---01/12/2011 03:54:03 PM---I wonder
if there's a way to merge sections 9.2 and 9.4. I think that using the
algorithm in 5.2 as
From: Scott C Moonen/Raleigh/IBM
To: David Wierbowski/Endicott/IBM@IBMUS
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-boun...@ietf.org, Yoav Nir
<y...@checkpoint.com>
Date: 01/12/2011 03:54 PM
Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB
I wonder if there's a way to merge sections 9.2 and 9.4. I think that using
the algorithm in 5.2 as specified in 9.4 is really just an extension of
this requirement from section 9.2: "A token maker MUST NOT send a QCD token
in an unprotected message for an existing IKE SA."
It might be possible to remove a lot of the detail in 9.4 and generalize
9.2 to hint at there being several ways of solving this problem -- 9.2's
state synchronization and 5.2/9.4's including the remote IP address.
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
(Embedded image moved to file: pic11871.gif)Inactive hide details for David
Wierbowski---01/11/2011 12:39:21 PM---I agree with Tero that it is unsafe
to assume how a load David Wierbowski---01/11/2011 12:39:21 PM---I agree
with Tero that it is unsafe to assume how a load balancer decides to
distribute traffic. Si
From: David Wierbowski/Endicott/IBM@IBMUS
To: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-boun...@ietf.org
Cc: Yoav Nir <y...@checkpoint.com>
Date: 01/11/2011 12:39 PM
Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB
Sent by: ipsec-boun...@ietf.org
I agree with Tero that it is unsafe to assume how a load balancer decides
to distribute traffic. Since section 9.4 (previously 10.4) is in the
Security Considerations section it seems reasonable to me that we'd warn
that the algorithms in 5.1 and 5.2 should not be used in cases where load
balancing cluster members share the same QCD token and do not share IKE SA
state.
I don't think this restriction precludes the use of QCD in the hot-standby
cluster scenario that Yoav mentioned in his previous append. By definition
in a hot-standby cluster only one of the cluster members is active at any
one time and it is not doing load balancing with its standby members.
In the same append Yoav stated that to achieve scalability with your hot
standby-cluster, you implement load sharing. If you add load balancing to
your hot standby-cluster then the warning in the previous paragraph
applies. In otherwords if you want one of your standby members to be a
load balancing target for the active member in the cluster then you need to
share the IKE SA state between the active member and the standby member.
I'd recommend that the following text from 9.4 be changed:
To thwart this possible attack, such configurations should use a
method that considers the taker's IP address, such as the method
described in Section 5.2.
Dave Wierbowski
From: Yoav Nir <y...@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 01/10/2011 03:04 AM
Subject: [IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB
Sent by: ipsec-boun...@ietf.org
Greetings.
We have just submitted version -03 of the draft. This closes issues, #198,
#199, #200, and #201.
Which leaves us with just one issue: #202
========= Issue #202: Token makers generating the same tokens without
synchronized DB
Section 10.4 of the draft has a use-case where a cluster of gateways share
the same QCD token secret, because they back each other up.
The twist in this case, is that they don't have synchronized databases, so
a fail-over is very much like a reboot - the IKE SA is gone, and QCD is
effective in getting the other side to restart IKE quickly.
The problem is, that without a failover, it may be possible to get a member
that does not own the IKE SA to send the QCD token to an attacker. The
attacker can then use this QCD token to tear down the IKE SA.
The method in section 5.2 tries to address this, by considering the IP
address of the token taker in the calculation.
Tero claims that this is a scenario that we should not address, and that
predicting or prescribing load balancer behavior in inherently dangerous.
=======================
Please send your opinions to the list. This one actually addresses the
scope of the document, so it's strange that this comes up as the last
issue, but we still have to decide on this.
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<<attachment: pic34804.gif>>
<<attachment: pic11871.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
