Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2

Hi Like Valery, I'm a co-author and support adoption. I have seen a lot of customer interest in this draft as it will allow organisations to implement standard based PQC at scale. One main driver being reduction of business risk. This will provide users of IKEv2 to protect themselves when

Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt

Hi Michael >From my limited experience the performance of many applications is degraded >when traffic is received out of order. cheers On 31/03/2019, 02:37, "IPsec on behalf of Michael Richardson" wrote: Graham Bartlett (grbartle) wrote: > I see th

Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt

fic. - Inherit the "worst" value from the encapsulated traffic. Thanks, Chris. Graham Bartlett (grbartle) writes: > Hi Chris > > Thanks for the presentation yesterday. > > I have been thinking about traffic w

Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt

Hi Chris Thanks for the presentation yesterday. I have been thinking about traffic with different DSCP markings. e.g if I have voice, video and web traffic (with their configured DSCP), it looks like all three flows could be sent in a single encrypted payload and the DSCP marking in the outer

Re: [IPsec] Modp-12288 and Modp-16384

Hi Tero I've no issues per se with this, but as per our chat in London, most VPN consumers pick the group with the highest number (of course group24 is more secure than group21, 24 is bigger than 21 ...!).. Maybe some words of warning around potential performance impact. I’m sure someone

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Michael Is the main rational for not having fragmentation in IKE_SA_INIT that it could break the features of IKE that you list below? The reason I ask, we’re working on the current draft and looking to implement optional fragmentation in the IKE_SA_INIT, but this would be friendly to

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Tero So I’m not a big fan of the interim exchange (Scott had suggested something similar). I would imagine that it’s going to decrease the tunnel setup rate on VPN GW’s. Adds at minimum another round trip, which could be >two if the QS blob isn’t correct or many more if fragmentation. It

Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

Hi Paul I’m a bit late to the party, but thought I’d chip in if it helps.. With regards to ‘If the responder has some connections that require a PPK and some connections that require NO PPK, then it has to flip a coin on whether or not to send the PPK_SUPPORT notify and if it guessed wrong’

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Sorry for the late reply. I’ve replied to where I feel I could add some more context to CJ’s reply. GB>inline On 05/08/2017, 14:29, "IPsec on behalf of Cen Jung Tjhai" wrote: Hi Paul, >>> 4. The large quantum

[IPsec] Proposed method to achieve quantum resistant IKEv2

Hi After listening to the Prague meeting Dan Harkins raised the point that the Quantum Resistant IKEv2 implementation should protect passive attacks, where traffic that traffic that is sent and is captured today should be resilient to an adversary with a quantum computer in the future. But

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Paul Would a downgrade attack be possible if the PPK notify is included in the authentication material ? cheers On 03/04/2017, 18:21, "IPsec on behalf of Paul Wouters" wrote: I would think this is the obvious solution. I would not

Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv

Hi Just a minor nit, nowhere in the draft is the term “IIV” defined.. cheers On 29/03/2017, 22:44, "IPsec on behalf of Tero Kivinen" wrote: As discussed in the meeting, we are starting two week working group adoptation call for the

Re: [IPsec] Quantum Resistant IKEv2

Hi I too am in favour of Valery¹s option. The rational being, if an attacker can recover the SKEYSEED using a QC, I would assume that they can then inject traffic into the IKEv2 SA, examples being to use configuration payload to manipulate routing, rekey with amended traffic selector etc.. Simply

Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document

Hi The views below are personal and don¹t reflect the company I am employed by; I¹m in favour of this document, I believe that this will increase the adoption of IKEv2 and secure communication for mobile devices. cheers On 05/06/2016 17:02, "IPsec on behalf of Waltermire, David A. (Fed)"

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

Hi Valery Sorry for the late reply. To answer your Q - sort of.. But I¹ve a few new ideas since on minimising the impact for the small devices. I¹ll be in touch with these.. cheers On 19/04/2016 15:05, "IPsec on behalf of Valery Smyslov"

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

Hi Paul Fair point - thanks. cheers On 20/03/2016 21:33, "Paul Wouters" wrote: > >I don't think mitigation text for blatant RFC errors should be added. The >original error should just be fixed. If they don't comply with 7296, this >document will make no difference either.

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

Hi Valery / Paul Paul - does your implementation send the INFORMATIONAL + other messages (Private Use Error) to a single SA_INIT? Just to clarify the issue observed seemed to be SA_INIT is sent by Initiator, Responder sends an SA_INIT reply plus numerous INFORMATIONAL messages separately to this

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

Hi Updated proposal attached. I¹ve made some amendments to the proposed text based on Valerys comments. I¹ve also added text around the correct sending of INFORMATIONAL messages due to a Responder receiving an SA_INIT, this is a known problem today with a number of implementations. (seen by

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

IKEv2 implementation are vulnerable to an amplification attack, I feel it would be prudent to add some words to remind implementors of the risk. cheers On 16/03/2016 00:51, "Tero Kivinen" <kivi...@iki.fi> wrote: >Graham Bartlett (grbartle) writes: >> Hi >> >> Last n

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

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

(Resending as my 1st attempt didn’t seem to make it to the list..) Hi Valery On 09/03/2016 11:46, "Valery Smyslov" wrote: >Hi Graham, > >a few comments on your text. > > A number of attacks can occur if implementations use the HASH and > URL, malicious parties can send a

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

Hi I¹ve updated the draft (attached). Please see section 6.2, where I describe a method to (potentially) pull your movie in 4k quality.. cheers On 06/03/2016 17:09, "Yoav Nir" wrote: >Sending a request and directing a server to send an entire movie in 4K >quality using

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

Hi The only case I could imagine that this could occur is if the Initiators Nonce and KE were purposely made very small and the Initiator did not perform any validation on this, sending it¹s own reply where the KE and Nonce were considerably larger. I¹ve seen an amplification attack, where an

Re: [IPsec] WG Interest in TCP Encapsulation

Hi >From my personal experience it¹s not as high as 10%, but I¹ve certainly seen a number of cases where either UDP/4500 or ESP, is blocked. (saw a timely example of this at the weekend..) cheers From: IPsec on behalf of Tommy Pauly Date: Saturday,

Re: [IPsec] Some speculations about puzzles

Hi Valery Thanks again. I interoperated the thread as your approach would have 'difficulty' replaced with 'generation_id'. (I now know this isn't the case). thanks On 04/12/2014 11:50, Valery Smyslov sva...@gmail.com wrote: In my approach the level is encoded in the cookie itself, in Yoav's

Re: [IPsec] Some speculations about puzzles

8 had a 20-bit difficulty level. If the attack then gets worse, than generation 9 is created with a 23-bit difficulty level. The responder needs only remember the generation and associated difficulty level. On Dec 4, 2014, at 1:07 AM, Graham Bartlett (grbartle) grbar...@cisco.com wrote

Re: [IPsec] Some speculations about puzzles

If the 1 byte 'difficulty level' has become the 'puzzle id', could we break the 1 byte into two 4 bits? 1st 4 bits is 'puzzle/generation id', next 4bits is 'difficulty level', this allows for 16 cycles for when every secret changes and still allows 16 levels of puzzles.. (just a thought as if

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

Hi Nico On 26/11/2014 22:17, Nico Williams n...@cryptonector.com wrote: For VPN SGs using puzzles all the time would be fine, but for VPN clients it'd be very rude to use them when acting as the responder! The protocol may be symmetric, but some uses aren't. VPN clients probably don't talk to

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-00.txt

Hi Yoav Here's some words I penned regarding some ideas I had to compliment your RFC. cheers RFC5685 describes the use of IKEv2 redirect to a client to another VPN gateway. For large scale implementations this can be used to redirect a client to a geographically closer gateway, thereby group

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-00.txt

Hi Yoav I have some comments, which I have included below, I hope I have interoperated your document correctly. Within section 2 I feel the following (or similar should be added). RFC6989 defines a set of checks to be performed on received DH public values, the checks against a malformed DH

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

, and before generating the IKE shared key. Thanks, Yaron On 10/06/2014 11:31 AM, Graham Bartlett (grbartle) wrote: Hi This is a very interesting attack, I would dismiss (1) as it leaves an implementation open for a semi-easy DOS (just one packet that generates work rate on both

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

Hi This is a very interesting attack, I would dismiss (1) as it leaves an implementation open for a semi-easy DOS (just one packet that generates work rate on both initiator and responder). Basing the behaviour on (2) the attacker would only have the window from when the responder sends the

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

Hi Yoav This is a subject I've spent way too much time thinking about and is close to my heart. :-) I'm actually surprised a Bot hasn't been used to take down a VPN service using the Auth attack that you describe, or not one that I've heard of. I'd like to add, for 1, if 6989 is employed then I

Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol

Hi Thanks for the clarifications. I really like the idea of this - as Daniel has said it's well suited for IoT, but I'm wondering if this could then lend IKEv2 into a similar concept as 'https' - secure channel and authentication of the headend and then initiators credentials are sent by some

Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol

Hi Valery I have one Q. If endpoint receives a request to create an unauthenticated IKE SA from the IP address, which is configured on the endpoint to be authenticated, the request SHOULD be rejected. Why is this not MUST be rejected ? Otherwise an attacker could trick the responder into