Hi Quynh,
Thank you Valery and thank you everyone who responded to me.
The approaches in the drafts
https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section-1.1
and
https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 look good
to me.
Not
Hi Quynh,
> An obvious question is that what is the performance impact from this large
KEM using the approaches above when compared with a KEM (if its public key
and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq
signature algorithm has a small signature and a small public ke
Speaking as a previous IPsec implementor, the biggest concern I had over IKE
performance was in the 'flash crowd' scenario; that is, you're an IPsec-based
security gateway, and then suddenly everyone wanted to negotiate with you.
This can happen if it's 8:00 AM (and everyone just arrived at wor
Hi Panos and Scott,
That was exactly what I was thinking. We have been working remotely.
One could have more than 300 kbytes for a pair of (public key + ciphertext and
public key + sig). The latter public key may be replaced by a cert chain.
The impact varies from one situation to another I th
On Thu, 18 Jun 2020, Panos Kampanakis (pkampana) wrote:
> I guess the impact is small generally because an IPsec tunnel normally stays
up for a long time. Does my guess seem ok here ?
> Would there be some noticeable impact on a high-volume connections VPN server
?
We tested this in the cont
On Thu, 18 Jun 2020, Dang, Quynh H. (Fed) wrote:
Hi Panos and Scott,
That was exactly what I was thinking. We have been working remotely.
One could have more than 300 kbytes for a pair of (public key + ciphertext and
public key + sig). The latter public key may be replaced by a
cert chain.
Hi Paul,
I don't know 10,000 or 20,000 users trying to connect to a VPN server around
the same time where each pair is 300 kilobytes or more would have a noticeable
impact or not. It depends on many factors I think. One of the factors is how
the server stores those data for its computations.
L
On Thu, 18 Jun 2020, Dang, Quynh H. (Fed) wrote:
I don't know 10,000 or 20,000 users trying to connect to a VPN server around
the same time where each pair is 300 kilobytes or more would have a
noticeable impact or not. It depends on many factors I think. One of the
factors is how the server s
[talking as individual and one of RFC7296 authors, not as WG chair].
Toerless Eckert writes:
> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
> > The RFC states:
> >
> >The USE_TRANSPORT_MODE notification MAY be included in a request
> >message that also includes an SA payl
[talking as another individual and co-author of RFC7296, not as the other chair]
> On 18 Jun 2020, at 21:03, Tero Kivinen wrote:
>
> [talking as individual and one of RFC7296 authors, not as WG chair].
>
> Toerless Eckert writes:
>> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
Tero Kivinen wrote:
> The MUST/SHOULD etc only give requirements for the implementors, i.e.,
> what features MUST or SHOULD be implemented and what MAY be
> implemented. In the RFCs we cannot use those keywords to instruct
> adminstrators/users what they should use.
Sigh. Again.
THanks, Tero, inline
On Thu, Jun 18, 2020 at 09:03:23PM +0300, Tero Kivinen wrote:
> [talking as individual and one of RFC7296 authors, not as WG chair].
Is there some new IETF liability insurance that make us say this ?
Ok: i am also only talking as an individual and ACP draft author and not was
Picking up some leftover open points.
On Wed, Feb 26, 2020 at 03:10:55PM -0500, Paul Wouters wrote:
> Actually we do. We had to add pkcs7 to ikev2 to be compatible with some
> windows deployments when intermediate certificates were being sent. On
> top of that, Microsoft did it wrong, as the forma
On Jun 18, 2020, at 21:16, Toerless Eckert wrote:
>
> Picking up some leftover open points.
>
> Question: Would a registrar be able to convert the encoding of the certificate
> (chain) between pkcs7 towards a Microsoft CA and whatever RFC7296 prefers,
> i guess "X.509 Certificate - Signature" t
14 matches
Mail list logo
