In fact I was referring to the whole extension. OK, since you're forcing
my hand...
General
The mechanism must not reduce the security of IKEv2 or IPsec.
Specifically, an eavesdropper must not learn any non-public information
about the peers.
DoS Resistance
The proposed mechanism should
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
At 4:37 PM +0200 10/20/10, Yoav Nir wrote:
Yaron: 10.3: of course, it is possible that *both* implementations
generate predictable/short SPI values
Hi all.
I think this one was solved together with ticket #191 (The danger
of predictable SPIs), but requiring that the token maker randomize
Folks,
We are trying to get this PF_KEY extension document published as an
Informational RFC and it would be beneficial if some IPsec experts on this list
could help us by reviewing the document.
Please let me know if you are willing to review the document.
Thanks.
--julien
PF_KEY
A review from an IPsec implementation perspective would indeed be much
appreciated.
For background, my AD review is here
http://www.ietf.org/mail-archive/web/mext/current/msg04450.html
Jari
___
IPsec mailing list
IPsec@ietf.org
Hi Dave,
if I had known of such an attack, you'd be the first to know :-)
Seriously, I didn't like the approach in Sec. 10, where you start from
the solution and nitpick some of its aspects. I would have preferred a
top-down approach, where you start with a set of security goals and
