Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Dr. Karan Verma]

yes, it's right

+1

On Wed, Mar 16, 2016 at 6:21 AM, Tero Kivinen  wrote:

> Graham Bartlett (grbartle) writes:
> > Hi
> >
> > Last night I noticed the following,
> >
> > https://community.akamai.com/docs/DOC-5289
> >
> > It talks of various results when using a single packet to generate an
> > amplification attack. (well worth a read..)
>
> And it does NOT talk about IKEv2 at all. The whole text is only
> covering IKEv1, even if they claim to cover both IKE and IKEv2.
>
> RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers
> IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies
> completely different transmission policy, i.e. it does not use what is
> defined in the RFC2408.
>
> This paper is just completely wrong and the conclusions for it is also
> completely wrong for IKEv2.
>
> It should really say that everybody simply should DISABLE IKEv1 and
> only enable IKEv2 in their configuration and that should fix the issue.
>
> The paper does not even have any kind of contact information, so there
> is no way to send in comments to try to get them to understand that
> their paper is completely wrong when related to the IKEv2.
>
> > As we discussed last week, all implementations that send multiple replies
> > to a single SA_INIT would be broken in some form. Because of the impact
> of
> > this (and these shocking results), I¹d like to add the following words to
> > the security considerations around retransmissions with respect to
> > amplification attacks using SA_INIT / IKE_AUTH;
>
> In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets
> sent. All the frames used Exchange Type of 2 (Identity Protect ==
> IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH
> etc).
>
> > "As described in RFC7296 Use of Retransmission Timers. For every pair of
> > message it is the responsibility of the initiator to retransmit should a
> > message be lost. A responder MUST only send a single reply to an SA_INIT
> > or IKE_AUTH message and MUST never engage the retransmission mechanism,
> > even if a reply is not received. This mitigates the chances that a
> > response will become a victim of an amplification attack where a single
> > packet is used to generate multiple replies."
>
> This requirement is already in the RFC7296 section 2.1, and there is
> no point of say it again here. Even if we say it here, it does not
> change the retransmissions for the IKEv1, as this draft does not cover
> IKEv1.
>
> What we could say in the DDoS draft is to add saying that IKEv1
> protocol is obsoleted, and will be common avenue for the DDoS attacks,
> and because of that it MUST be disabled.
>
> Or perhaps we need the IKEv1 considered harmful draft /
> ikev1-diediediediedie...
> --
> kivi...@iki.fi
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 
Best Regards

Dr. Karan Verma
Assistant Professor
Computer Science and Engineering Dept.
Central University Rajasthan, India
Website: www.drkaranverma.com
Phone: +917568169258
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Tero Kivinen]

Graham Bartlett (grbartle) writes:
> Hi
> 
> Last night I noticed the following,
> 
> https://community.akamai.com/docs/DOC-5289
> 
> It talks of various results when using a single packet to generate an
> amplification attack. (well worth a read..)

And it does NOT talk about IKEv2 at all. The whole text is only
covering IKEv1, even if they claim to cover both IKE and IKEv2.

RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers
IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies
completely different transmission policy, i.e. it does not use what is
defined in the RFC2408.

This paper is just completely wrong and the conclusions for it is also
completely wrong for IKEv2.

It should really say that everybody simply should DISABLE IKEv1 and
only enable IKEv2 in their configuration and that should fix the issue.

The paper does not even have any kind of contact information, so there
is no way to send in comments to try to get them to understand that
their paper is completely wrong when related to the IKEv2.

> As we discussed last week, all implementations that send multiple replies
> to a single SA_INIT would be broken in some form. Because of the impact of
> this (and these shocking results), I¹d like to add the following words to
> the security considerations around retransmissions with respect to
> amplification attacks using SA_INIT / IKE_AUTH;

In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets
sent. All the frames used Exchange Type of 2 (Identity Protect ==
IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH
etc). 

> "As described in RFC7296 Use of Retransmission Timers. For every pair of
> message it is the responsibility of the initiator to retransmit should a
> message be lost. A responder MUST only send a single reply to an SA_INIT
> or IKE_AUTH message and MUST never engage the retransmission mechanism,
> even if a reply is not received. This mitigates the chances that a
> response will become a victim of an amplification attack where a single
> packet is used to generate multiple replies."

This requirement is already in the RFC7296 section 2.1, and there is
no point of say it again here. Even if we say it here, it does not
change the retransmissions for the IKEv1, as this draft does not cover
IKEv1.

What we could say in the DDoS draft is to add saying that IKEv1
protocol is obsoleted, and will be common avenue for the DDoS attacks,
and because of that it MUST be disabled.

Or perhaps we need the IKEv1 considered harmful draft /
ikev1-diediediediedie... 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Valery Smyslov]

Hi Graham,

I don't think it is necessary, since RFC7296 already has
the requirement in Section 2.1:

  For every pair of IKE messages, the initiator is responsible for
  retransmission in the event of a timeout.  The responder MUST never
  retransmit a response unless it receives a retransmission of the
  request.

So, such implementations are obviously broken, and I don't
think we need to duplicate the RFC2119 requirements from IKEv2 spec.
If you think it's worth to emphasize this requirement, then, I think,
it  must be re-worded without using RFC2119 words,
and must refer to the RFC7296 as the source of requirement.
Something like that:

   To prevent amplification attacks the Responder must
   retransmit the response message only if it receives a
   retransmitted request from Initiator, and must not do it
   under any other circumstances. Note, that this behaviour
   is already prescribed in Section 2.1 of RFC7296.

Regards,
Valery.

- Original Message - 
From: "Graham Bartlett (grbartle)" 

To: "Yoav Nir" 
Cc: "Valery Smyslov" ; "Paul Wouters" ; 

Sent: Tuesday, March 15, 2016 6:25 PM
Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04


Hi

Last night I noticed the following,

https://community.akamai.com/docs/DOC-5289

It talks of various results when using a single packet to generate an
amplification attack. (well worth a read..)

As we discussed last week, all implementations that send multiple replies
to a single SA_INIT would be broken in some form. Because of the impact of
this (and these shocking results), I№d like to add the following words to
the security considerations around retransmissions with respect to
amplification attacks using SA_INIT / IKE_AUTH;

"As described in RFC7296 Use of Retransmission Timers. For every pair of
message it is the responsibility of the initiator to retransmit should a
message be lost. A responder MUST only send a single reply to an SA_INIT
or IKE_AUTH message and MUST never engage the retransmission mechanism,
even if a reply is not received. This mitigates the chances that a
response will become a victim of an amplification attack where a single
packet is used to generate multiple replies."

Thoughts?

cheers







On 06/03/2016 17:09, "Yoav Nir"  wrote:


IMHO even in that case this is not an interesting attack. We should be
worried about amplification attacks where little traffic causes a lot of
traffic, not a case where I send a 200-byte packet which results in a
250-byte packet, and not even a 5 250-byte packets. Sending a request and
directing a server to send an entire movie in 4K quality using RTP in an
interesting amplification attack. Using a 10-Mbps uplink to generate
12-Mbps of traffic is not.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Graham Bartlett (grbartle)]

Hi

Last night I noticed the following,

https://community.akamai.com/docs/DOC-5289

It talks of various results when using a single packet to generate an
amplification attack. (well worth a read..)

As we discussed last week, all implementations that send multiple replies
to a single SA_INIT would be broken in some form. Because of the impact of
this (and these shocking results), I¹d like to add the following words to
the security considerations around retransmissions with respect to
amplification attacks using SA_INIT / IKE_AUTH;

"As described in RFC7296 Use of Retransmission Timers. For every pair of
message it is the responsibility of the initiator to retransmit should a
message be lost. A responder MUST only send a single reply to an SA_INIT
or IKE_AUTH message and MUST never engage the retransmission mechanism,
even if a reply is not received. This mitigates the chances that a
response will become a victim of an amplification attack where a single
packet is used to generate multiple replies."

Thoughts?

cheers







On 06/03/2016 17:09, "Yoav Nir"  wrote:

>IMHO even in that case this is not an interesting attack. We should be
>worried about amplification attacks where little traffic causes a lot of
>traffic, not a case where I send a 200-byte packet which results in a
>250-byte packet, and not even a 5 250-byte packets. Sending a request and
>directing a server to send an entire movie in 4K quality using RTP in an
>interesting amplification attack. Using a 10-Mbps uplink to generate
>12-Mbps of traffic is not.
>
>Yoav


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec