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
cookie
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 somew
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
"best" value from the encapsulated traffic.
- Inherit the "worst" value from the encapsulated traffic.
Thanks,
Chris.
Graham Bartlett (grbartle) writes:
> Hi Chris
>
> Thanks for the presentation yesterday.
>
>
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
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 migr
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 reve
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 oth
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
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 SA_IN
H public key, so IMHO it's fine
>to postpone the test until IKE_AUTH is received, 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 at
alf-open SA's.
cheers
On 10/10/2014 20:58, "Yoav Nir" wrote:
>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 t
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 D
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 cli
Great point. Puzzles a good tool that will be needed if/when ddos becomes
a serious issue. (I can't think of a silver bullet which will solve this)
They should also not be mandatory (with the option to be configurable as
per cookie notifications) as I would assume some hosts will never be able
to
Hi Nico
On 26/11/2014 22:17, "Nico Williams" 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 more than one
Hi Valery
Would the Timestamp be generated every time cycle? If this wasn't a static
figure (per timecycle - maybe when the secret is changed?, but rather a
rolling unix time), then how would the Responder be able to validate this
Cookie (without trying every previous timestamp or having the times
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 th
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)
>> wrote:
>>
>>
>> If the 1 byte
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" wrote:
>In my approach
>the level is encoded in the cookie itself, in Yoav's approach it i
Hi Paul
Sorry for the late reply. Hopefully the following is more clear?
When designing systems which will provide connectivity for
non-authenticated users, the system SHOULD be designed with the capacity
to support not only the maximum intended number of peers, but also include
an additional nu
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, 19 September 2015 00:44
To: Valery Smyslov
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 imp
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 RTP in an interesting am
(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 URL to redirect a V
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
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" wrote:
>Graham Bartlett (grbartle) writes:
>> Hi
>>
>> Last night I
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 Tero
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
s
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.
smime.p7s
Descripti
Hi Valery / Tero
Sorry for the late reply.
GB> Comments inline.
cheers
On 21/03/2016 12:57, "Valery Smyslov" wrote:
>I don't think we are in a position to impose such a requirement in the
>draft.
GB>I feel we should explain WHY it’s a security benefit to link the ID and
certificate. Not to
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"
wrote:
>> If RSASSA-PSSv2 is done because RSASSA-PSS is
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)"
wrote
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
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 draft-mglt-ipsecme-implicit-iv.
Please read t
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 want to run a
connection definition that you can co
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 t
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 resistant ‘blob’ of data is only sent when it
is known that t
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’
If
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 s
40 matches
Mail list logo
