Re: [IPsec] AD VPN: discussion kick off

Hi I think one of the most striking things is how similar all three mechanisms are. They all begin with a node doing what the DMVPN guys call a "hairpin" - it decrypts packets from one peer, then re-encrypts them and sends them to another peer. In all three proposals, the node doing the hairpi

Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation

Hi I think the draft is in good shape and is almost ready for publication. There is a bunch of grammatical issues with it, but I think the RFC editor is much better at fixing those than most of us. Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and

Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation

On Oct 25, 2013, at 11:23 PM, Yaron Sheffer wrote: >> >> Section 2.5.1 recommends using 1280-byte max IP datagram size for >> IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big >> difference between those two RFCs is not some technical difference >> between IPv6 and IPv4, but

Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation

On Oct 26, 2013, at 12:14 PM, Yaron Sheffer wrote: > > > On 2013-10-25 23:51, Yoav Nir wrote: >> >> On Oct 25, 2013, at 11:23 PM, Yaron Sheffer wrote: >> >>>> >>>> Section 2.5.1 recommends using 1280-byte max IP datagram size for >>

Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation

On Oct 26, 2013, at 2:25 PM, Yoav Nir wrote: > > On Oct 26, 2013, at 12:14 PM, Yaron Sheffer wrote: > >> >> >> On 2013-10-25 23:51, Yoav Nir wrote: >>> >>> On Oct 25, 2013, at 11:23 PM, Yaron Sheffer wrote: >>> >>>>>

Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I guess the idea is that if the packet is still bigger than the PMTU, then the IKE host gets back a "fragmentation needed" ICMP, and the IKE daemon learns of that and resends packets with appropriately small size. There are some issues with this: 1. It requires yet another retransmission 2. Th

Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

Sent: Monday, October 28, 2013 4:05 PM To: Yoav Nir Cc: Valery Smyslov; tsvwg; Joe Touch; ; ; ; Matt Mathis; Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Yoav Nir writes: > 3. While the TCP stack has access to these ICMP packets and the PMTU >

Re: [IPsec] Fwd: New Version Notification fordraft-nir-ipsecme-cafr-03.txt

On Oct 30, 2013, at 9:23 AM, Valery Smyslov wrote: > Hi Yoav, > >> Third version of this draft, now including Tero's comments. > > some comments on new version. > > First, some stuff seems to be left from previous version, which > supposed that new IKE SPIs are sent in both directions: > - t

Re: [IPsec] New Version Notificationfordraft-nir-ipsecme-cafr-03.txt

On Oct 30, 2013, at 12:32 PM, Valery Smyslov wrote: >>> I think, that it could be solved, if we define new notification, >>> that could be optionally sent from gateway to client, informing him >>> that gateway is going to delete IKE SA in some time >>> interval (indicating that interval in the n

Re: [IPsec] Update to RFC4307 too?

On Nov 1, 2013, at 10:07 PM, Michael Richardson wrote: > Tero Kivinen wrote: >> Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ to >> SHOULD. > > this is the only one which I didn't understand. > Which one? There's two parts there. AES-XCBC was supposed to take the world

Re: [IPsec] Query regarding Qos with IKE

Hi, Paul I'm not sure I understand the issue. IPsec is carrying some IP-based protocol from the UE, through some gateway to a host in the service provider's network. Those IP packets can have QoS indication like any other IP packets, through the TOS field in IPv4 or the Traffic Class field in I

Re: [IPsec] Query regarding Qos with IKE

e not seen any Qos parameter in the IKE messages. So how the Qos is negotiated between end parties using IKE SAs ? Can you explain little bit on Qos agreement. Thanks, Paul On Mon, Nov 4, 2013 at 3:12 PM, Yoav Nir mailto:y...@checkpoint.com>> wrote: Hi, Paul I'm not sure I understand t

Re: [IPsec] Query regarding Qos with IKE

anyways, because it needs to be handled with QoS at the provider network too. If you do it in the app layer, it doesn't require any modifications to IKE. Yoav On Nov 4, 2013, at 3:18 PM, Michael Richardson wrote: > > Yoav Nir wrote: >> There are currently no attributes in

Re: [IPsec] Query regarding Qos with IKE

ould be better if we can accommodate Qos as one of the parameter in IKE negotiation messages. Thanks, Paul On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir mailto:y...@checkpoint.com>> wrote: Like I said, Paul can submit an I-D. But if the UE applies the diffserv to the clear packet, 4301 says

Re: [IPsec] //Please remove me from this group ..//

t; [mailto:ipsec-boun...@ietf.org<mailto:boun...@ietf.org>] On Behalf Of Yoav Nir Sent: Tuesday, November 05, 2013 12:15 PM To: Paul Simon Cc: mailto:ipsec@ietf.org>>; Michael Richardson Subject: Re: [IPsec] Query regarding Qos with IKE Is what you're looking for multiple DS for t

Re: [IPsec] AD VPN: discussion kick off

On Nov 5, 2013, at 1:45 PM, Paul Wouters wrote: > On Tue, 5 Nov 2013, Manish Kumar (manishkr) wrote: > >> "I don't like that DMVPN does not let http traffic continue to travel via >> HQ's >> virus/trojan/netnanny while RTP takes the shortcut." >> >> While I do appreciate that the following cou

Re: [IPsec] Other documents to upgrade to internet standard

On Nov 5, 2013, at 9:58 PM, Yaron Sheffer wrote: > > Do we have enough implementations of EC groups to progress RFC 5903? I > realize that NSA RFCs are not that popular nowadays… How many is "enough"? I have one. Besides, the NSA is very popular nowadays. In fact, where dedicating both tomor

Re: [IPsec] AD VPN: discussion kick off

On Nov 6, 2013, at 7:53 AM, Manish Kumar (manishkr) mailto:manis...@cisco.com>> wrote: Steve, NHRP is used to resolve the remote peer which serves/owns the address we're interested in. The information in this resolution culminates in the creation of SPD. Manish Hi, Manish Wouldn't it be mo

Re: [IPsec] Other documents to upgrade to internet standard

On Nov 7, 2013, at 6:46 AM, wrote: > > On Nov 7, 2013, at 2:11 AM, Yaron Sheffer wrote: > >> ... >> IIRC we published RFC 5903 using the old code points because there was no >> objection, i.e. no indication that people had deployed pre-errata 4753. >> Whether this was the right thing to do

Re: [IPsec] Other documents to upgrade to internet standard

On Nov 7, 2013, at 7:46 AM, Paul Wouters wrote: > On Thu, 7 Nov 2013, Yoav Nir wrote: > >>>> So, seeing that people are slowly moving to ECC, I would like some input >>>> from the group on whether to progress RFC 5903. We will need to >>>> demons

Re: [IPsec] Other documents to upgrade to internet standard

On Nov 7, 2013, at 8:32 AM, Paul Wouters wrote: > On Thu, 7 Nov 2013, Yoav Nir wrote: > >>> openswan / libreswan do not support ecc at this moment. >> >> That's the trouble with open source. You never know which fork. >> https://rhn.redhat.com/errata/

Re: [IPsec] Other documents to upgrade to internet standard

On Nov 7, 2013, at 9:43 AM, Tero Kivinen wrote: > Yoav Nir writes: >> The VPN products from Cisco, Juniper and Check Point support them, >> as well as both StrongSwan and OpenSwan. I'm sure there are others >> as well. > > But which version of their products

[IPsec] ADVPN vs opportunistic VPN

[Changing the subject to avoid poisoning the protocol selection thread with my author-ness] On 6/12/13 8:05 PM, Paul Wouters wrote: We have agreed-upon requirements [1]. I was unfortunately not really active during the requirements phase. While I believe there is a need for auto-discovery wit

Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt

On Jan 12, 2014, at 7:15 AM, Paul Wouters wrote: >> Regarding audit, we can mandate that each record should say something like >> "Snow White (claimed but unauthenticated identity)". > > You are suggesting client side security? I don't understand. If I would > write software where an ID is sen

[IPsec] Fwd: I-D Action: draft-nir-ipsecme-chacha20-poly1305-00.txt

m the on-line Internet-Drafts > directories. > > >Title : ChaCha20 and Poly1305 and their use in IPsec >Author : Yoav Nir > Filename: draft-nir-ipsecme-chacha20-poly1305-00.txt > Pages : 16 > Date: 2014-01-2

Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03

In addition to what Praveen said, I'd like to point out that draft-sathyanarayan defines a two-tier network. On the top tier are security gateways that are (presumably) always-on and know the union protected domain of the VPN. The second tier are devices that do not know the entire protected d

Re: [IPsec] AD-VPN Protocol Selection

On Feb 3, 2014, at 5:02 PM, Michael Richardson wrote: > > Harms, Patrick wrote: >> - is allowing to add 'spokes' without configuration changes on the 'hub' >> devices (8.1 dmvpn draft) > >> For me, this is an important point. Changing the configuration on the hub >> routers, everytime a spoke

Re: [IPsec] AD-VPN Protocol Selection

On Feb 4, 2014, at 5:39 PM, Michael Richardson wrote: > > Harms, Patrick wrote: > Based on the theories (advpn draft and dmvpn) and real world > experience (dmvpn), I would favor dmvpn, because the handling and > operating sounds less complex. (eg. lower amount of steps in tunnel >

Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

Hi I think this document is ready. A quick glance at the tables in section two lead me to ask some questions: Why is DES singled out, while things like HMAC-MD5 are not discouraged? Why is there no algorithm diversity? Why is HMAC-SHA-256 not there? However, reading section 4 answered all of th

Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts

With vendor hat on: years ago we measured the performance and found that the performance of AES-256-CBC and AES-192-CBC were virtually identical. We removed AES-192-CBC from our UI because we didn't see a point to it - less security for no performance gain. I don't have any more recent measurement

[IPsec] ChaCha20 & Poly1305, AEAD and other modes

Hi draft-nir-ipsecme-chacha20-poly1305 currently specifies three transforms: 1. chacha20 as a stand-alone cipher 2. Poly1305 as a stand-alone MAC 3. ChaCha20-Poly1305 as an AEAD. Some people in the room said that we should only do the AEAD and skip the stand-alone algorithms. This woul

Re: [IPsec] ChaCha20 & Poly1305, AEAD and other modes

On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer wrote: > Hi Yoav, > > Can you explain why we need Poly1305 at all? We have SHA-2 and will > probably adopt Keccak (SHA-3), so it's not like we don't have a backup. > Sure. Poly1305 is fast.Faster than SHA-1, SHA-2, and Keccak. I haven't compared it

Re: [IPsec] ChaCha20 & Poly1305, AEAD and other modes

g the AEAD chacha20-poly1305 may be helpful > for end users or admins. Especially if security consideration > recommends AEAD. Would it bring too much complexity to also define > AEAD chacha20-poly1305? > > BR > Daniel > > > > On Mon, Mar 10, 2014 at 9:15 AM, Yoav N

[IPsec] My view of the requirements from AD-VPN

As promised, here's my view of what a short list of requirements for AD-VPN should be like. First, a few terms: An AD-VPN is a subset of the hosts on the Internet, such that all traffic between two nodes within the AD-VPN must be protected by IPsec when it traverses nodes outside of the AD-VPN.

Re: [IPsec] My view of the requirements from AD-VPN

On Mar 21, 2014, at 7:20 PM, Yaron Sheffer wrote: > Hi Yoav, > > I like your attempt at reducing the requirement set to the minimum. > > Parts of the text I think do not distinguish well between IPsec hosts (such > as remote access clients) and (simple) hosts, that are non-IPsec hosts > prot

[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-chacha20-poly1305-02.txt

covers only ESP) Yoav Begin forwarded message: > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-nir-ipsecme-chacha20-poly1305-02.txt > Date: March 31, 2014 at 9:44:43 AM GMT+3 > To: Yoav Nir , "Yoav Nir" > > > A new version

Re: [IPsec] New Version Notification for draft-nir-ipsecme-chacha20-poly1305-02.txt

est, > Yaron > > On 03/31/2014 10:12 AM, Yoav Nir wrote: >> Hi. >> >> I’ve posted a new version of the ChaCha20-Poly1305 draft. > > [...] > >> >> Comments are, of course, welcome, and I’d like to repeat my questions >> from the Lo

Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

On Apr 3, 2014, at 1:13 AM, Paul Wouters wrote: > On Wed, 2 Apr 2014, RJ Atkinson wrote: > >>> The IPsec community generally prefers ESP with NULL encryption over AH. >>> AH is still required in some protocols and operational environments >>> when there are security-sensitive options in the IP

Re: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard

Hi, Tony Thanks for the review. I assume you mean that you don’t sign with public keys. Replacing “sign” with “validate” makes for a strange sentence, because the sentence is about sending (and presumably signing) rather than receiving (and validating). How about: “If multiple certificate are

Re: [IPsec] Simultaneous Child SA Creation tigger from both the side.

Hi The reason that we don’t have any mention of simultaneous SA creation is that this issue has not come up in practice. When two IPsec hosts don’t have an SA for a particular flow (because said flow hasn’t had traffic in a while), it’s highly unlikely that bidirectional traffic on this flow w

Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)

Hi Vijay I’m no expert on REDIRECT, and my implementation does not support it. Your issue seems to be about implementations that have the REDIRECT functionality, but don’t advertise as much when they connect to the peer gateway. So it’s as if this feature is disabled by configuration. Am I un

Re: [IPsec] Simultaneous Child SA Creation tigger from both the side.

The premise is that the implementation supports just one set of SAs. So both send out a request, and both receive the other request first, and then the response to their respective original request. If both peers now send out a DELETE to remove the SA initiated by the other side, they will end u

Re: [IPsec] Stopping work on Auto-Discovery VPN

On May 23, 2014, at 8:22 PM, Yaron Sheffer wrote: > Dear WG members, > > After being unable to reach consensus on a protocol that solves the AD VPN > problem, we set up a smaller group to discuss the solutions on the table and > try to reach agreement between the competing proposals. Unfortun

Re: [IPsec] Stopping work on Auto-Discovery VPN

On May 26, 2014, at 5:36 PM, Michael Richardson wrote: > > Yoav Nir wrote: >> FWIW, I think this is the wrong decision. Both the working group and >> apparently the market have shown a desire for a dynamic, large-scale >> VPN, and we have enough people willing

Re: [IPsec] Stopping work on Auto-Discovery VPN

On May 26, 2014, at 10:00 PM, Paul Wouters wrote: > > We are definitely adding more features than we can obsolete :/ Perhaps > our parents should tell us to get rid of some of our old barely toys > before we can ask for new ones :P Can we trade in AH and IKEv1’s “new group mode” for a dynamic p

[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-chacha20-poly1305-04.txt

ersion Notification for > draft-nir-ipsecme-chacha20-poly1305-04.txt > Date: June 1, 2014 at 4:20:22 PM GMT+3 > To: Yoav Nir , "Yoav Nir" > > > A new version of I-D, draft-nir-ipsecme-chacha20-poly1305-04.txt > has been successfully submitted by Yoav Nir and poste

Re: [IPsec] Any reason to meet in Toronto?

Well, there’s my puzzles draft ([1]). And we could argue some more about dynamic VPN (and the dropping thereof). In fact, just stick an “open mic” part on the agenda, and such an argument is sure to come. Yoav [1] http://tools.ietf.org/html/draft-nir-ipsecme-puzzles-00 On Jun 3, 2014, at 1:56

Re: [IPsec] draft-smyslov-ipsecme-ikev2-null-auth-01

On Jun 4, 2014, at 11:03 PM, Michael Richardson wrote: > > Paul Wouters wrote: >>> Valery Smyslov wrote: >> Paul ps. i also still >>> prefer AUTH_NONE over "NULL AUTH", as to me NULL >> looks more like an >>> error while "none" conveys intent. >>> I remember it. However I'm still waitin

Re: [IPsec] draft-nir-ipsecme-puzzles-00 comments

I think doing this would cause clients to calculate the puzzle solution, when in fact they don’t have to, and sending back the COOKIE would be enough. What I envision is for the IKE gateway to measure its load (probably based on amount of half-open IKE SAs). As long as the load level is low, the

Re: [IPsec] Garage door - let's pick a different example

Hi Hannes I tend to agree. The beauty of IP (with or without “sec”) is that I can open a connection in one place to a server that is located in another location half-way around the world. The garage door opener is used from a short distance, so you don’t really need routing. You still might wan

[IPsec] Puzzles draft - another idea

Hi all After the meeting on Friday, I talked to Tero and Brian Weis, and Tero suggested a different sort of puzzle that could make it easier to support both strong and weak clients. This is sort of like the proof-of-work used by BitCoin. Calculate the cookie as before. For an example, let’s ass

Re: [IPsec] Puzzles draft - another idea

o it, > because they do not have any information about the effort currently needed), > I will configure my botnet to always do 11, and push out any legitimate > clients. > > Thanks, > Yaron > > On 07/30/2014 07:45 AM, Yoav Nir wrote: >> Hi all >> >> After

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 16, 2014, at 12:48 PM, Les Leposo wrote: > Hi > > some points of discussion below. > >> A scheme like this would drain the battery on top of the current >> re-establishing draining, that already prevents me from using an >> always-on profile - my iphone won't last for 4 hours. >> >> Pe

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 18, 2014, at 8:23 PM, Les Leposo wrote: > > On Aug 18, 2014, at 5:44 PM, Tero Kivinen wrote: > >> Les Leposo writes: The iphone (which is only rumored to do IKEv2 with iOS8 likely to be released in September this year) currently has a terrible record of continuously re-e

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 19, 2014, at 5:48 PM, Les Leposo wrote: >>> >>> Now, today's client devices need to be energy efficient - so the device >>> sleeps/hibernates to save battery. >>> Sleeping past the nat keepalives is bound to happen (either by design or >>> error). >>> At some point the device will wake

Re: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996

+1 On Aug 21, 2014, at 2:49 PM, Valery Smyslov wrote: > Hi Tero, > >> This is also question what should we do for the rfc5996bis. >> We have two options, we removed the text saying section 2.9.2 was >> added in the RFC5996, or we add the section 2.9.2 from the ticket #12, >> and add note that s

Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD

Hi, Avishek English is not my first language, so I’m not sure what “exclusive” means below, but I hope I can clarify anyways. Suppose Responder policy is to allow certain groups (say, 19 and 20), while the Initiator’s request includes groups 2, 5, and 14 in the SA payload, and group 2 in the K

Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD

On Sep 1, 2014, at 12:01 PM, Avishek Ganguly wrote: > Thanks Yoav for your explanation. > > > English is not my first language, so I’m not sure what “exclusive” means > > below, but I hope I can clarify anyways. > > By exclusive I mean NO_PROPOSAL_CHOSEN is an error that is not generated >

Re: [IPsec] IKEv1 Interop issue: Transform number mismatch

Hi, Dharma. This mailing list is intended for discussion of standards, not the conformance (or lack thereof) of particular implementations. I will contact you off-list Yoav From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of dharmanandana pothulam Sent: Tuesday, September 09, 2014 7:24 PM

Re: [IPsec] Call for adoption: Client Puzzles

Hi. As I’m the document author, it’s no surprise that my vote is Yes. Much like Paul Wouters, I would have liked to have a kind of puzzle that did not give an advantage to attacking desktops over legitimate smartphones. But all proposals for puzzles have been just as CPU-bound as the partial ha

Re: [IPsec] Call for adoption: Client Puzzles

On Sep 23, 2014, at 9:24 PM, Michael Richardson wrote: > > Yoav Nir wrote: >> One proposal that I kind of liked (and I’m sorry I’ve forgotten who >> suggested it) was to relegate the puzzle to a second line of defense, >> through the use of some kind of anti-dos ticke

Re: [IPsec] Call for adoption: Client Puzzles

On Sep 25, 2014, at 2:27 PM, Tero Kivinen wrote: > Michael Richardson writes: >> Yoav Nir wrote: >>> One proposal that I kind of liked (and I’m sorry I’ve forgotten who >>> suggested it) was to relegate the puzzle to a second line of defense, >>> through the

[IPsec] A strategy against DoS/DDoS for IKE responders

Hi Here are some thoughts about DoS and DDoS protection for an IKE daemon. I think this should be discussed before submitting any drafts, because the acceptance thread reflected that the problem we want to solve is DoS and DDoS, not just the lack of a puzzle mechanism. If we break down what a

Re: [IPsec] A strategy against DoS/DDoS for IKE responders

Hi, Yaron On Oct 5, 2014, at 10:56 PM, Yaron Sheffer wrote: > > - I'm not sure what is special about "[the case] when an Authentication > request fails to decrypt." Seems to me this is a verified DoS attack from a > specific IP. I see I wasn’t clear about this, because both you and Graham mi

Re: [IPsec] A strategy against DoS/DDoS for IKE responders

Hi, Graham. Thanks for the endorsement, but see below. On Oct 10, 2014, at 2:31 PM, Graham Bartlett (grbartle) wrote: > Hi Yaron / Yoav > > I'm summarising my thoughts below, I've spoken to a few folk offlist and > hopefully the following will help my understanding and also theirs. > > So as

Re: [IPsec] A strategy against DoS/DDoS for IKE responders

On Oct 10, 2014, at 9:25 PM, Michael Richardson wrote: > > Graham Bartlett (grbartle) wrote: >> Now the only issue I can see is alluded to in the draft, where a VPN >> headend is serving clients with varying resource. So say a botnet >> attacks this headend and the puzzle is enabled, you have

Re: [IPsec] A strategy against DoS/DDoS for IKE responders

On Oct 13, 2014, at 1:04 AM, Graham Bartlett (grbartle) wrote: > Hi Yoav > > Thanks for the explanation, just for my understanding, why does this > rate-limiting have to (strictly) rely on the cookie (or puzzle) > notification? Is it more of the case that it guarantees that the attacker > is t

Re: [IPsec] sending a certificate without receiving certificate request from sender

It’s possible, but then why not send it? The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate a

[IPsec] DDoS Protection issue #226 - Do we need puzzles at all?

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/226 Hi. I think this one we should get out of the way first. Puzzles limit the rate at which a particular host can create half-open SAs. If the puzzle takes 2 seconds to solve then a parti

Re: [IPsec] Some speculations about puzzles

I think it’s simpler to keep a short list (a queue actually, but usually with no more than 2-5 entries) or pairs. Generate a new pair every 10 seconds or whenever the difficulty level needs to change. Remember all entries for the last 20 seconds. Calculate the cookie as described in the RFC.

Re: [IPsec] Some speculations about puzzles

> On Dec 3, 2014, at 5:44 PM, Valery Smyslov wrote: > > Hi Scott, > > this is almost identical to what I proposed in my original e-mail, > if you substitute "difficulty level" with "puzzle id”. Or call it “generation id”, and increment it whenever you generate a new secret and/or change the d

Re: [IPsec] Some speculations about puzzles

allows for 16 cycles for when every secret changes and still allows > 16 levels of puzzles.. > > (just a thought as if the difficulty level disappears you loose the > ability to set a the hardness of the puzzle) > > > On 03/12/2014 16:01, "Yoav Nir" wrote: >

Re: [IPsec] Some speculations about puzzles

> On Dec 4, 2014, at 9:20 AM, Valery Smyslov wrote: > >>> Hi Scott, >>> >>> this is almost identical to what I proposed in my original e-mail, >>> if you substitute "difficulty level" with "puzzle id”. >> >> Or call it “generation id”, and increment it whenever you generate a new >> secret an

[IPsec] Status of IKE DDoS

Hi all A few updates about the IKE DDoS draft: 1. Valery Smyslov has agreed to join as co-author. Thanks, Valery 2. We have moved the source onto github [1], so now anyone can easily create pull requests. 3. I’ve been asked by the chairs to emphasize that despite (2), the discussion is to ta

[IPsec] Puzzle algorithm negotiation

Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2 Hi, Valery has created this pull request. During the meeting in Honolulu and subsequent discussion on the list, several people requested that there be a negotiation of the algorithm used

Re: [IPsec] Puzzle algorithm negotiation

> On Jan 25, 2015, at 8:58 PM, Yaron Sheffer wrote: > > Hi Yoav, Valery, > > I agree with Valery's proposed redefinition of the proof-work-work, based on > the PRF. > > I am currently off-line so my question may have been answered in the pull > request, but: can we make it very clear that th

Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd)

> On Jan 26, 2015, at 5:24 PM, Tero Kivinen wrote: > > Paul Wouters writes: I think it is a server's policy issue. It can always restrict the number of IPsec SAs from a single peer by using NO_ADDITIONAL_SAS notification. The document should not impose any restrictions here,

[IPsec] DDoS puzzle: PRF vs Hash

Hi all. Following Valery’s suggestion, I’ve created a pull request for replacing the puzzle mechanism: OLD: appending a string to the cookie so that the hash of the extended string has enough zero bits at the end. NEW: finding a PRF key such that PRF(k, cookie) has enough zero bits at the end.

Re: [IPsec] DDoS puzzle: PRF vs Hash

8 solved puzzles > of the given strength? Of course, the responder would request 2-3 bits of > strength less. The net effect should be a lower variance in run times, i.e. > more deterministic run time for any particular type of client. > > Thanks, > Yaron > >

Re: [IPsec] DDoS puzzle: PRF vs Hash

e the times, > that the results will be less erratic (it would also be great > to measure the deviation of times for each level, not only average). > > Regards, > Valery. > > >> - Original Message - >> From: Yoav Nir <mailto:ynir.i...@gmail.com> >

Re: [IPsec] DDoS puzzle: PRF vs Hash

> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer wrote: > > What I would suggest is: we give the client a single puzzle, and ask it to > return 16 different solutions. Indeed each puzzle then should be 16X easier. > The nice thing is, the server should only check *one* of them, at random. The > c

Re: [IPsec] DDoS puzzle: PRF vs Hash

> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: > > >> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer wrote: >> >> What I would suggest is: we give the client a single puzzle, and ask it to >> return 16 different solutions. Indeed each puzzle then should be

Re: [IPsec] DDoS puzzle: PRF vs Hash

And now it’s really attached. data.xlsx Description: MS-Excel 2007 spreadsheet > On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: > > >> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >> >> >>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer wrote: >>&

Re: [IPsec] DDoS puzzle: PRF vs Hash

have a lot of uncertainty. > For comparison, could you try again with 64 replacing the 16 tries, and with > lower bit lengths? > > Thanks, > Yaron > > On 02/01/2015 11:46 AM, Yoav Nir wrote: >> And now it’s really attached. >> >> >> >>

Re: [IPsec] DDoS puzzle: PRF vs Hash

-language implementation. As it is, it’s about 4 bits behind the Intel i5. Yoav data64.xlsx Description: MS-Excel 2007 spreadsheet > On Feb 2, 2015, at 8:31 AM, Yoav Nir wrote: > > The three-sigma rule applies even with a non-normal distribution. > > Anyway, I tried the 64-key samp

Re: [IPsec] DDoS puzzle: PRF vs Hash

Before I respond, here’s one more data point: I’ve compiled OpenSSL 1.0.2 for ARM and got ~60,500 SHA-256 hashes (it’s close enough to not matter to the result for HMAC-SHA-256) per second. That says that assuming 1 second as the “reasonable” time to solve a puzzle, we can expect to do about 16

Re: [IPsec] DDoS puzzle: PRF vs Hash

> On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) > wrote: > > If you want to tighten up the time between worse case and average case time > taken by the problem solver, might I suggest this: > > - When the verifier is asked to generate a problem, it pick a nonce N, and > use it to comp

Re: [IPsec] DDoS puzzle: PRF vs Hash

Thinking it over, you don’t really need AES at all, and in any case it doesn’t matter. The initiator doesn’t know the key and doesn’t know the algorithm, so it’s entirely a local matter. For example, the responder could pick HMAC-SHA256 with a fixed key, and calculate HMAC-SHA256(K,cookie). An

Re: [IPsec] DDoS puzzle: PRF vs Hash

> On Feb 9, 2015, at 4:03 AM, Paul Wouters wrote: > > On Sun, 8 Feb 2015, Yaron Sheffer wrote: > >> I think we've come a full circle. We now have a proposal that makes >> proof-of-work more deterministic for each type of client (which I find very >> useful). But the weaker clients will always

Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

> On Feb 24, 2015, at 1:21 PM, Yoav Nir wrote: > > In the meantime, I have updated my draft to only define the AEAD. Since we > not have CFRG’s “stamp of approval” … * Since we **now** have... ___ IPsec mailing list IPsec@ie

Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

> On Feb 24, 2015, at 4:24 PM, Michael Richardson wrote: > > > Yoav Nir wrote: >>> On Feb 24, 2015, at 1:21 PM, Yoav Nir wrote: >>> >>> In the meantime, I have updated my draft to only define the >>> AEAD. Since we now have CFRG’s “stamp

Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

> On Feb 26, 2015, at 4:48 PM, Paul Wouters wrote: > > On Tue, 24 Feb 2015, Yoav Nir wrote: > >> In the meantime, I have updated my draft to only define the AEAD. Since we >> not have CFRG’s “stamp of approval” if not yet an RFC number, >> I would like to renew m

Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305

> On Mar 6, 2015, at 6:01 PM, Paul Hoffman wrote: > > On Feb 26, 2015, at 2:11 PM, Paul Hoffman wrote: >> Greetings again. A few people have expressed interest in having >> https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG item >> for IPsecME. If you want this as a WG do

Re: [IPsec] Vendor Identifiers

> On Mar 11, 2015, at 8:54 PM, Russ Housley wrote: > > About two years ago, I was at a workshop where someone claimed that the > Vendor Identifiers that are exchanged in IKE are very useful for dealing with > bugs. The claim was that following the report of a bug, others could adjust > their

Re: [IPsec] Vendor Identifiers

> On Mar 12, 2015, at 1:38 AM, paul_kon...@dell.com wrote: > >> >> On Mar 11, 2015, at 5:23 PM, Yoav Nir wrote: >> >> >>> On Mar 11, 2015, at 8:54 PM, Russ Housley wrote: >>> >>> About two years ago, I was at a workshop where

Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305

> On Mar 6, 2015, at 6:01 PM, Paul Hoffman wrote: > > On Feb 26, 2015, at 2:11 PM, Paul Hoffman wrote: >> Greetings again. A few people have expressed interest in having >> https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG item >> for IPsecME. If you want this as a WG do

Re: [IPsec] [saag] looking to hold a TLS VPN side meeting at IETF 92

Hi, Mike > Please discuss on the saag mail list. I will schedule a > meeting time at a local drinking establishment for either Monday or Wednesday > at 7:30 PM (local Dallas time). I’d appreciate feedback on the meeting times > (if you expect to attend) as well as any comment o

[IPsec] Review for ChaCha20 draft (was: Re: IETF092 draft minutes)

> On Mar 27, 2015, at 9:20 PM, p...@nohats.ca wrote: > - chacha20poly1305 > http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-2.pdf > > Yoav presenting > > Yaron: does arm have aes acceleration? > Yoav: no. it has something called neon - not in phones but in tablets. has > some advan

[IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

Hi, There is two questions I would like guidance from the group about. First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The function itself accepts a 96-bit input nonce, so the nonce is constructed from the 6

Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

Arrgh. Please don’t reply-all to my previous message, because it was mistakenly directed to I-D announce… > On Mar 30, 2015, at 5:39 PM, Yoav Nir wrote: > > Hi, > > There is two questions I would like guidance from the group about. > > First is the nonce/IV question:

<    1   2   3   4   5   6   7   8   9   >