OK. I did not understand that this was about 5.2 rather than the whole extension.
In that case, does section 10.4 address this? If not, can you suggest some text? Yoav On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: > Hi Dave, > > an active MITM, i.e. the sys admin at your local Starbucks, needs to > only drop a few packets of an open IKE SA (a few retransmissions) for > the peers to decide that they have a problem and attempt to renegotiate > the SA. This attack is trivial to mount if you're at the right spot. > > On the other hand, Sec. 5.2 of the document is designed to prevent > another kind of DoS attack that eventually does the same thing: resets > the SA. > > So we need to explain why we add a mechanism to prevent one kind of DoS > attacks even though we have other potential DoS issues. I'm not saying > this is wrong, I'm saying it needs to be rationalized. > > Thanks, > Yaron > > On 10/20/2010 02:57 PM, David Wierbowski wrote: >> I'm not sure I understand Yaron's concern. Yaron, can you elaborate how a >> MITM attacker can easily cause an IKE SA to be reset? I would think he >> could only do so if he hi-jacked the original IKE_SA negotiation and is >> now impersonating the remote security endpoint. In that case you have >> bigger issues. >> >> Dave Wierbowski >> >> >> >> >> From: Yoav Nir<y...@checkpoint.com> >> To: IPsecme WG<ipsec@ietf.org> >> Date: 10/20/2010 04:10 AM >> Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss >> the threat >> Sent by: ipsec-boun...@ietf.org >> >> >> >> One week, and no replies... >> >> I will leave this issue open unless I get some suggested security >> considerations text. >> >> The first paragraph in section 10.1 says the following. What else is >> missing? >> >> Tokens MUST be hard to guess. This is critical, because if an >> attacker can guess the token associated with an IKE SA, she can tear >> down the IKE SA and associated tunnels at will. When the token is >> delivered in the IKE_AUTH exchange, it is encrypted. When it is sent >> again in an unprotected notification, it is not, but that is the last >> time this token is ever used. >> >> Yoav >> >> On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: >> >>> Yaron: The security considerations are focused on details of the QCD >> solution, rather then on the threats we are dealing with. These threats are >> non-trivial to describe, since an active MITM attacker can easily cause an >> IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be >> able to do so. We need to analyze the threats in order to select a secure, >> but not overly complex solution. >>> >>> >>> >>> Suggested text would be most welcome. >>> >>> Yoav >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> Scanned by Check Point Total Security Gateway. >> >> _______________________________________________ >> 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 > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
