Subject: [IPsec] Status of draft-ietf-ipsecme-ddos-protection

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 26 May 2016 16:12:19 +0300

Hi,

in Buenos-Aires it was expressed a proposal to split 
the DDoS protection draft into two. One of them would
describe possible kinds of (D)DoS attacks and would 
suggest some counter measures to thwart them without
introducing anything new into the IKEv2 protocol.
The other document (with Experimental status) would 
describe the puzzles and would define a new IKEv2 
extension defending against (D)DoS attacks using puzzles.

The main motivation for such a proposal was a concern
that puzzles mechanism would not be as effective as it was initially 
intended to be, and might even make things worse for 
"small" devices. 

On the other hand, if we go this way and give the puzzles stuff 
an Experimantal status, then probably very few vendors (if any) 
will implement it and the real problem of defending against
(D)DoS attacks will remain unaddressed.

So, what folks think about this proposal?

Regards,
Valery & Yoav.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 May 2016 17:25:53 +0300

Hi,

On 26 May 2016, at 4:12 PM, Valery Smyslov <[email-masked]> wrote:

> Hi,
> 
> in Buenos-Aires it was expressed a proposal to split the DDoS protection draft into two. One of them would
> describe possible kinds of (D)DoS attacks and would suggest some counter measures to thwart them without
> The other document (with Experimental status) would describe the puzzles and would define a new IKEv2 extension defending against (D)DoS attacks using puzzles.
> 
> that puzzles mechanism would not be as effective as it was initially intended to be, and might even make things worse for "small" devices. 
> On the other hand, if we go this way and give the puzzles stuff an Experimantal status, then probably very few vendors (if any) will implement it and the real problem of defending against

One more data point. My employer has implemented puzzles in older versions of our remote access client and gateway. It worked fine, but we don’t have any numbers on whether it actually stopped DoS attacks. We ended up abandoning it for IPR reasons, which is why this draft uses an entirely different kind of puzzle.

Regards,

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 May 2016 13:14:57 -0400 (EDT)

On Thu, 26 May 2016, Valery Smyslov wrote:

> On the other hand, if we go this way and give the puzzles stuff an 
> Experimantal status, then probably very few vendors (if any) will implement 
> it and the real problem of defending against

I don't think the puzzles implementation adoption will be much different from
whether it is part of the ddos document or a stand-alone document.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 31 May 2016 08:01:24 +0300

Hi Paul,

> whether it is part of the ddos document or a stand-alone document.

The concern is not about stand-alone puzzles document. It is about an Experimental status
of that document versus Standards Track in the current draft. Vendors tend to ignore 
Experimental RFCs.

> Paul

Regards,
Valery.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 31 May 2016 08:43:47 +0300

> On 31 May 2016, at 8:01 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Paul,
> 
> of that document versus Standards Track in the current draft. Vendors tend to ignore Experimental RFCs.

The conventional wisdom is that vendors tend to ignore whatever status the IETF assigns to documents and implement whatever meets their goals.

My preference is to keep it all in one document, and clearly state that the puzzle part of the document is OPTIONAL, meaning that you can comply with the RFC even without implementing it. 

There is a concern about an Initiator that does not implement puzzles connecting to a Responder that does. Things will work fine until there is a DoS attack and then we’re helping the attacker by denying service to the non-implementing Initiator. And that could happen between an Initiator and Responder, both of whom can claim compliance with the document. This isn’t great, but separating them into two documents does not make the problem go away.

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 31 May 2016 09:04:37 +0300

> whatever meets their goals.

That's true in general. However Experimaental status makes vendors more suspicious that
they will spend resources implementing the protocol and gain little, because most other
vendors will refrane from implementing it. For puzzles to work they must become ubiquitous.

> My preference is to keep it all in one document, and clearly state that the puzzle part of the document is OPTIONAL,
> meaning that you can comply with the RFC even without implementing it.

That's my preference too. In fact, the current draft doesn't mandate to implement
(or even to use) puzzles, so they are already optional.

> There is a concern about an Initiator that does not implement puzzles connecting to a Responder that does.
> Things will work fine until there is a DoS attack and then we’re helping the attacker by denying service
> to the non-implementing Initiator. And that could happen between an Initiator and Responder,
> both of whom can claim compliance with the document. This isn’t great, but separating them into two documents
> does not make the problem go away.

That's true.

Regards,
Valery.

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 31 May 2016 16:25:13 +0000

From what I am reading, there isn't an interest in splitting puzzles out as experimental. If you feel strongly that puzzles should be split out into a separate experimental draft, please speak up. If we don't hear anything by Monday, June 6, we will begin making preparations to send the draft as-is to the IESG.

Since we are wrapping up the WGLC, please also consider this a final call for comments on the draft before we send it off.

Thanks,
Dave

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Valery Smyslov
> Sent: Tuesday, May 31, 2016 2:05 AM
> To: Yoav Nir <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection
> 
> >> The concern is not about stand-alone puzzles document. It is about an
> >> Experimental status of that document versus Standards Track in the
> current draft. Vendors tend to ignore Experimental RFCs.
> >
> > The conventional wisdom is that vendors tend to ignore whatever status
> > the IETF assigns to documents and implement whatever meets their goals.
> 
> That's true in general. However Experimaental status makes vendors more
> suspicious that they will spend resources implementing the protocol and gain
> little, because most other vendors will refrane from implementing it. For
> puzzles to work they must become ubiquitous.
> 
> > My preference is to keep it all in one document, and clearly state
> > that the puzzle part of the document is OPTIONAL, meaning that you can
> comply with the RFC even without implementing it.
> 
> That's my preference too. In fact, the current draft doesn't mandate to
> implement (or even to use) puzzles, so they are already optional.
> 
> > Things will work fine until there is a DoS attack and then we’re
> > helping the attacker by denying service to the non-implementing
> > Initiator. And that could happen between an Initiator and Responder,
> > both of whom can claim compliance with the document. This isn’t great,
> but separating them into two documents does not make the problem go
> away.
> 
> That's true.
> 
> > Yoav
> 
> Regards,
> Valery.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 May 2016 16:35:48 -0400 (EDT)

> From what I am reading, there isn't an interest in splitting puzzles out as experimental. If you feel strongly that puzzles should be split out into a separate experimental draft, please speak up.…

I still prefer the puzzles going into a seperate document, so we as an
implementor could say we implement the anti-ddos RFC without having to
explain we implement some parts and not other parts. I don't think this
matters much for the structure of the document, as it just puts Section
7 to 11 in a separate document.

> Since we are wrapping up the WGLC, please also consider this a final call for comments on the draft before we send it off.

Responding to this in a separate email.

Paul