Hi Paul,
Can't an off-path attacker DoS the gateway if they can guess the SPI
values? We never mandated that SPIs should be random (except for RFC
6290, in Sec. 9.3, but this is rarely implemented), so implementations
are free to use very small integers for the SPIs. In fact I think we
should
Paul Wouters writes:
> Note that requires an observer that can see your cookies/spi.
Yes.
> Which would
> mean a local attacker, whom could just as easilly send you nonsense
> forged from the remote endpoint - as they are guaranteed to answer
> faster. You'd be decrypting thousands of packets to
>> What your draft does, is force the initiator to protect each
>> fragment. To protect a fragment in a way that will cause the
>> responder to store it, requires running the MAC function, and that
>> in turn requires generating the keys (running the PRF), which in
>> turn requires completing the
On Thu, 14 Mar 2013, Tero Kivinen wrote:
As earlier explained not doing that allows very wasy DoS attack, which
allows IKEv2 to finish by just sending very few packets, i.e. you send
one corrupted fragment to the packet and if you do that before
responder gets the correct fragment, the responder
> There is no DH calculating per fragment. DH is calculated once in
> IKE_SA_INIT
> as in ordinary IKE SA establishment (note, that unprotected messages,
> including IKE_SA_INIT
> and IKE_SA_RESUME cannot be fragmented).
If we do IKEv2 fragments the way everyone does IKEv1 fragments, the
initi
On Mar 14, 2013, at 10:29 AM, Tero Kivinen
wrote:
> Yoav Nir writes:
>>> There is no DH calculating per fragment. DH is calculated once in
>>> IKE_SA_INIT as in ordinary IKE SA establishment (note, that
>>> unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME
>>> cannot be fragmented).
On Mar 14, 2013, at 10:27 AM, Paul Wouters wrote:
> On Thu, 14 Mar 2013, Yoav Nir wrote:
>
>> Measurably more, because MAC functions have an initialization part, so
>> running it on a single packet by parts incurs the per-run overhead multiple
>> times. See the differences in the throughput o
Yoav Nir writes:
> > There is no DH calculating per fragment. DH is calculated once in
> > IKE_SA_INIT as in ordinary IKE SA establishment (note, that
> > unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME
> > cannot be fragmented).
>
> If we do IKEv2 fragments the way everyone does IKE
On Thu, 14 Mar 2013, Yoav Nir wrote:
Measurably more, because MAC functions have an initialization part, so running it on a
single packet by parts incurs the per-run overhead multiple times. See the differences in
the throughput of HMAC based on buffer size (obtained by running "opnessl
speed
On Mar 14, 2013, at 9:38 AM, Valery Smyslov wrote:
> Hi Yoav.
>
>> > I agree that term "authenticated" is a bit misleading here.
>> > The better term would be "integrity protected".
>> > In our proposal receiver can be absolutely sure that
>> > each fragment comes from the very peer he/she exch
Hi Yoav.
> I agree that term "authenticated" is a bit misleading here.
> The better term would be "integrity protected".
> In our proposal receiver can be absolutely sure that
> each fragment comes from the very peer he/she exchanged
> DH exponents and calculated shared secret with.
>
> All frag
On Mar 13, 2013, at 10:06 AM, Valery Smyslov wrote:
> Hi Yaron,
>
>> I believe the DoS argument is incorrect, because the message we are most
>> worried about (most likely to get fragmented) is IKE_AUTH, and at this point
>> both peers are not yet authenticated, of course. So fragments and me
On Mar 13, 2013, at 10:58 AM, Paul Wouters wrote:
> On Wed, 13 Mar 2013, Valery Smyslov wrote:
>
>> Or are you talking about the fictional IETF document (not yet written)
>> describing existing IKEv1 fragmentation? Probably it is better that
>> the authors of that solution document it.
>
> I d
Mocana's implementation appears to only support fragmentation for IKEv1,
not IKEv2.
-derek
On Tue, March 12, 2013 3:49 pm, Tero Kivinen wrote:
> Actually I verified the fragmentation support from Finland, and they
> said it was requested, but it is not in any product yet, and as Paul
> Wouters al
On Wed, 13 Mar 2013, Valery Smyslov wrote:
So does it make sense to say in the document that the first packet
must not be fragmented?
If you mean draft-smyslov-ipsecme-ikev2-fragmentation, that limitation must
be already there. If it is not clear enough, I'll make it more explicit.
I have to
Our implementation also does not handle the first packet of an
exchange to be fragmented, because we have no state to store the
fragments for. In practise this does not matter because the first
packet is never large enough to need fragmentation.
We do the same.
So does it make sense to say in
On Wed, 13 Mar 2013, Valery Smyslov wrote:
How is that a DOS attack? In our implementation of the IKEv1
fragmentation, we limit the number of fragments to 16. We will
only need to do any crypto when we received the IKE packet
marked as "last". Then we do crypto once on the assembled packet
and t
Hi Paul,
As for IKEv2, I don't know how Cisco is doing fragmentation in this case
(it seems to have support for it), but if it is done similarly to IKEv1,
than I prefer our own solution -
draft-smyslov-ipsecme-ikev2-fragmentation.
The main difference is that in Microsoft/Cisco solution (for IK
Hi Yaron,
I believe the DoS argument is incorrect, because the message we are most
worried about (most likely to get fragmented) is IKE_AUTH, and at this
point both peers are not yet authenticated, of course. So fragments and
messages can be encrypted but cannot be authenticated. Thus, an atta
On Wed, 13 Mar 2013, Valery Smyslov wrote:
As for IKEv2, I don't know how Cisco is doing fragmentation in this case
(it seems to have support for it), but if it is done similarly to IKEv1,
than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation.
The main difference is that in
Hi Valery,
I believe the DoS argument is incorrect, because the message we are most
worried about (most likely to get fragmented) is IKE_AUTH, and at this
point both peers are not yet authenticated, of course. So fragments and
messages can be encrypted but cannot be authenticated. Thus, an att
Hi,
Anyways, if there is already more implementations doing IKE
framentation, it might be good idea to think whether we should
standardize that. On the other hand I am not sure if they are well
enough documented so that different implementations actually talk each
other...
We support IKEv1 fra
Actually I verified the fragmentation support from Finland, and they
said it was requested, but it is not in any product yet, and as Paul
Wouters already commented to list that the problem with some
implementations sending fragmentation regardless whether it was
negotiated or not has already been f
23 matches
Mail list logo
