On Tue, 31 May 2016, Tommy Pauly wrote:
iOS and Mac OS X do not support ESP TFC, and mark ESP_TFC_PADDING_NOT_SUPPORTED
in the IKE_AUTH packets. I have not heard of problems with interop in this area.
So I just did an interop, enabled TFC and it worked great with iOS :)
22:10:29.449629 IP
This is a partial review of draft-ietf-ipsecme-ddos-protection-06
up to Section 6. I hope to complete the rest in the next few days.
I think this document needs another revision before continuing.
(and I would prefer it to be split in two)
Issues / Questions:
An obvious defense, which is
On Tue, 31 May 2016, Waltermire, David A. (Fed) wrote:
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,
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
Hi vendors,
I am wondering how common it is for stacks to support ESP TFC ?
And also, how common it is for stacks that do NOT support ESP TFC, to
properly signal that with ESP_TFC_PADDING_NOT_SUPPORTED.
That is, has anyone ever encountered an interop problem when enabling
ESP TFC?
I would be
On Tue, 31 May 2016, Kathleen Moriarty wrote:
I'd like to thank Paul for his many years chairing IPSecMe! We look
forward to your continued participation.
Tero Kivinen has volunteered to co-chair the working group and still
be active as a individual as not to impact the working group.
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
