Re: [IPsec] Failure detection proposals, stage 2

[David Wierbowski <[e-mail]>]

I also prefer  the QCD draft over the SIR draft.  My reasons are similar to
Scott's.  I feel the method in QCD is sufficient and the SIR method is
overly complex for the problem at hand.  I think SIR would be bigger to
implement and more error prone than QCD.  In short I think the SIR method
is a much bigger stick than needed.

Dave Wierbowski


z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055






From:       Scott C Moonen/Raleigh/IBM@IBMUS
To:         Yaron Sheffer <[e-mail]>
Cc:         IPsecme WG <[e-mail]>, [e-mail]
Date:       08/13/2010 03:10 PM
Subject:    Re: [IPsec] Failure detection proposals, stage 2
Sent by:    [e-mail]



I've looked over the two drafts. My summary impression is that I prefer
QCD, albeit for subjective reasons. It is less complicated and therefore
simpler to implement and test. I think I would have a higher degree of
confidence in planning it for our implementation, and I suspect it would
see more quick and widespread use.

Some comments/questions for the individual drafts:

QCD:
(1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request
message for rekeying the IKE SA?
(2) The draft (perhaps in the section 5 intro) should emphasize that the
tokens MUST be produced in such a way that different IKE SPI pairs are
unlikely to share the same token value.

Recovery:
(1) The draft needs to specify how the IKE message header bits are expected
to be set for the various flows.
(2) The draft should explicitly acknowledge cases where it is (with good
reason) breaking specific MUST NOT statements in ikev2bis (e.g., a couple
of cases of "MUST NOT respond").
(3) I dislike the MITM weakness but I understand that this is not the most
attractive fruit for a MITM.
(4) Nit: acronym plurals shouldn't use apostrophes (i.e., "SAs" is
preferred to "SA's").


Scott Moonen ([e-mail])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

(Embedded image moved to file: pic56651.gif)Inactive hide details for Yaron
Sheffer ---08/10/2010 06:20:17 AM---OK, Paul and I are finally convinced
that we have sufficienYaron Sheffer ---08/10/2010 06:20:17 AM---OK, Paul
and I are finally convinced that we have sufficient WG interest in solving
this problem. N

From: Yaron Sheffer <[e-mail]>
To: IPsecme WG <[e-mail]>
Date: 08/10/2010 06:20 AM
Subject: [IPsec] Failure detection proposals, stage 2
Sent by: [e-mail]



OK, Paul and I are finally convinced that we have sufficient WG interest
in solving this problem. Now, I'd like to ask the people who have
responded (as well as others) to read the two drafts, and to tell us why
they prefer the one over the other.

Quoting myself: "If you speak up, we will expect you to contribute to
the selection of the preferred document".

Please respond with comments to the drafts and/or a comparison within
the next week, i.e. by August 17.

Thanks,
Yaron

> From: Yaron Sheffer<[e-mail]>
> To: IPsecme WG<[e-mail]>
> Date: 08/04/2010 04:48 PM
> Subject: [IPsec] Failure detection proposals
> Sent by: [e-mail]
>
>
>
> In the Maastricht meeting there was just a tiny bit of interest in the
> failure detection idea (reminder: the goal is to ensure that one peer
> discovers that the other IKE peer has restarted, within a short time
> duration, milliseconds instead of minutes). But we didn't see enough
> interest to justify having this as a WG item. So, one last time: if you
> think this is a worthwhile idea, regardless of the proposals on the
> table, please say so publicly. If you speak up, we will expect you to
> contribute to the selection of the preferred document.
>
> If this is of no interest, fine. But if it is an important problem to
> solve and we don't take it on, we could end up with competing non-WG
> proposals. Which would be far from ideal.
>
> Thanks,
> Yaron
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Paul Hoffman
> Sent: Wednesday, July 07, 2010 8:03 PM
> To: IPsecme WG
> Subject: [IPsec] NUDGE: Starting discussion of failure detection
proposals
>
> [[ This topic generated a fair amount of discussion in the past; are
> folks still interested? ]]
>
> Greetings again. The WG has one item on our charter that we have barely
> discussed, namely failure detection. The charter item says that the work
> item is:
>
>> - A standards-track IKEv2 extension that allows an IKE peer to quickly
and
> securely detect that its opposite peer, while currently reachable, has
lost
> its IKEv2/IPsec state. Changes to how the peers recover from this
situation
> are beyond the scope of this work item, as is improving the detection of
an
> unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and
> draft-detienne-ikev2-recovery-03 can be used as starting points.
>
> I gave a brief presentation on failure detection at the last IETF
> meeting in Anaheim. The slides are at
> <http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, and the
> following is directly derived from them.
>
> The basic problem being covered by the new extension is:
> -  Alice and Bob have SAs up and ESP traffic is flowing, but then Bob
> crashes
> -  Alice keeps sending ESP to Bob
> -  When Bob finally comes back up, he replies to Alice's ESP with
> INVALID_SPI notifications
> -  Alice starts sending IKE liveness checks until she is "sure" that the
> INVALID_SPI responses are not a DoS attack; this could be "several
minutes"
> -  Then Alice rekeys
>
> Some other problem cases include:
> -  Bob has two gateways in some failover architecture. One gateway goes
> down, the other gateway detects this and wants to tell Alice to rekey
> -  Bob has a bunch of gateways in some load-balancing or cluster
> architecture. One gateway is taken down on purpose, and the system wants
> to tell Alice to rekey
> -  Protocol robustness:  Bob's gateway loses the SA without going down
>
> Our primary goal is that, as soon as Bob starts sending INVALID_SPI
> responses to Alice's ESP traffic, Bob and Alice should be able to
> quickly determine that this is not an attack and therefore they probably
> want to rekey right away. Note that if Bob and Alice are also using
> session resumption, they can use that instead of rekeying; however, in
> the discussion here, we always use "rekey" to mean "rekey or, if
> appropriate, resume". The proposed extension does not include the actual
> rekeying, just the context for them to do it now.
>
> The WG has seen two proposed solutions, QCD and SIR. The following are
> brief summaries of the two proposals.
>
> In QCD (<http://tools.ietf.org/html/draft-nir-ike-qcd>), Bob gives Alice
> a secret token in the AUTH exchange, and then puts the token in his
> INVALID_SPI response as a way to say "this SPI is gone". Bob must
> remember his tokens across reboots, or derive tokens from a master token
> that he memorizes across reboots, and Alice must remember the token (or
> a hash of it) for each SA.
>
> In SIR
> (<http://tools.ietf.org/id/draft-detienne-ikev2-recovery-03.txt>), Alice
> sends a new Check_SPI query with a stateless cookie, essentially asking
> "do you really not know about this
> SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing
> is stored on either side, so a man-in-the-middle can attack this to
> cause an unnecessary rekey just as they can normal IKE.
>
> The first task for the WG is to decide which of these two quite
> different approaches to take. After we have done that, we can then hone
> the chosen proposal. During earlier discussion of the proposals, the
> following criteria were mentioned as ones that the WG should consider
> when thinking about the approaches:
>
> -  Support for different scenarios (load balancers, active clusters,
> failover)
> -  Security from man-in-the-middle DoS attacks
> -  Resources used
> -  Intellectual property rights
>
> So: please start discussing the two proposals with respect to these
> criteria or other criteria that are important to you. In a few weeks
> (hopefully well before the Maastricht meeting), I make a call for
> consensus and see where it leads us.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec