Re: [IPsec] Interop with microsoft CA (was: IPsec profile feedback wanted (draft autonomic control) plane)

[Paul Wouters]

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" towards the enrolling/renewing client 
> ?

Yes. 

Paul
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Interop with microsoft CA (was: IPsec profile feedback wanted (draft autonomic control) plane)

['Toerless Eckert']

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 format does not allow a
> chain but they added more than one anyway. So if anything, we DO NOT
> want to see more pkcs7 in IKEv2.

ACP nodes would never need to talk directly to a Microsoft CA, but
an ACP registrar might. Such as a registrar using BRSKI. 

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" towards the enrolling/renewing client ?

If that conversion is possible, we are done, because then its up to
each vendors registrar implementation to do this, at best we might
put a note into the non-normative part of ACP (operations of registrars)
or nothing. But given how ACP is an OPS area document, i think the
WG/area appreciates help operationalizing systems, and not only
creating strict protocol specifications.

Alas, in the pre-standard implementations of ACP i used, we always used
pkcs7 towards client, which is why i haven't been able to try to figure
out the answer to this question. Given how i hope its just container
formats, i hope the answer is yes.

Cheers
Toerless

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Toerless Eckert]

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 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 payload requesting a Child SA.  It
> > >requests that the Child SA use transport mode rather than tunnel mode
> > >for the SA created.  If the request is accepted, the response MUST
> > >also include a notification of type USE_TRANSPORT_MODE.  If the
> > >responder declines the request, the Child SA will be established in
> > >tunnel mode.
> 
> At this point the responder already created an Child SA in tunnel
> mode, and when the initiator receives that message from the responder
> it will also create the Child SA in tunnel mode. Responder might
> already be sending traffic at this point.
> 
> This means both initiator and responder MUST implement tunnel mode, as
> otherwise they cannot perform those actions. Meaning as the fallback
> from the transport mode is tunnel mode, all implementations MUST
> implement it even if it not explictly said in the RFC.

[deleted question i wanted to ask here as you answer it below.]

Sounds as if IKEv2 is effectively not built to allow optimizing the
classical transport option case. For example using IPsec for transport
connections of protocols, such as IGPs, BGP or the like. I 
did write the doc for how to use IPsec transport mode with RFC4601
PIM, alas, security was never widely used for such signaling, so
RFC7761 completely removed it. But if somebody ever wanted to write
a good profile for such use cases, they would run into this
tunnel over transport issue.


> > > If this is unacceptable to the initiator, the initiator
> > >MUST delete the SA.
> 
> This thing happens after the Child SA is created. I.e., now the
> initiator will check whether the Child SA created was following its
> policy, and it is completely valid for the initiators policy to say
> that must use transport mode, and then it will delete the SA as it was
> not following its policy.
> 
> It still means that the initiator implementation MUST implement tunnel
> mode, but it does not have to USE it if it does not feel like doing
> that.
> 
> 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.

I guess it is left up to the implementer to figure out that
implementing support for tunnel mode in IKEv2 doesn't mean that
it does have to actually implement support for it in the
forwarding plane / ESP.

> Quite often, especially in the security considerations section, we try
> to give requirements to the users, but we need to be very carefull not
> to do that. We can give information to users saying "do not use low
> entrypy passwords as PSK as they are known to be unsafe", but we
> cannot say MUST NOT use low entropy passwords, as there is no easy for
> for implementor to enforce that.
> 
> For every single MUST or SHOULD and especially MUST NOT or SHOULD NOT
> you are writing to the RFC, you should think how can you answer to
> question from the customer who says, "show me the lines in your
> implementation which implements this MUST or SHOULD". For MUST and
> SHOULDs, that is usully still quite easy, but when someone asks "Show
> me the lines of code where you implement: This notification MUST NOT
> BE sent by an entity that may be replicated"

Yeah, and it gets more tricky with the distinction of MUST in
IKEv2 which may or may not be read to be inclusive to actual
forwarding plane / ESP requirements.

> (and yes, I have had incoming customer support case, where they asked
> for every single MUST/SHOULD/MUST NOT/SHOULD NOT where it was
> implemented in the source of our toolkit). 

I ould like to imagine it is satisfying to be such a large customer that
you can not only answer but also make your vendor answer those questions,
but in my experience those customers than also had to write long reports
about the ansers ;-)

I would love to see "protocol implementation compliance specification"
or whatever you might call it, but i have given up asking for it in the
IETF itself, and given ho i work for a vendor it is of course
masochism ;-)

> > > But note that the responder has already installed the IPsec SA in tunnel
> > > mode. So if the initiator finds that unacceptable, it must send the
> > > delete. During all this time, connectivity between the nodes will be
> > > blocked. The intention here is that transport mode is optional and
> > > should not 

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Michael Richardson]

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.

The Autonomic Control Plane is established by automatic mechanisms,
not by "administrators". That is, we have a protocol that acts as the
"administrator" in this case.

So, yes, we (ANIMA) can use BCP14 to say what the "configured" policy will be.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

[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:
>>> The RFC states:
>>> 
>>>   The USE_TRANSPORT_MODE notification MAY be included in a request
>>>   message that also includes an SA payload requesting a Child SA.  It
>>>   requests that the Child SA use transport mode rather than tunnel mode
>>>   for the SA created.  If the request is accepted, the response MUST
>>>   also include a notification of type USE_TRANSPORT_MODE.  If the
>>>   responder declines the request, the Child SA will be established in
>>>   tunnel mode.
> 
> At this point the responder already created an Child SA in tunnel
> mode, and when the initiator receives that message from the responder
> it will also create the Child SA in tunnel mode. Responder might
> already be sending traffic at this point.
> 
> This means both initiator and responder MUST implement tunnel mode, as
> otherwise they cannot perform those actions. Meaning as the fallback
> from the transport mode is tunnel mode, all implementations MUST
> implement it even if it not explictly said in the RFC.

I half agree. RFC 7296 describes IKEv2, not IPsec. An IKEv2 implementation must 
support the creation of a tunnel-mode Child SA. It may configure an IPsec layer 
that does not support tunnel-mode.

I think it’s compliant with the letter if not the spirit of RFC 7296 to have a 
specialized IKEv2 implementation that can negotiate a tunnel mode SA, but 
immediately deletes such an SA if it is created, and I think such an 
implementation will also be compliant if it rejects any CREATE_CHILD_SA request 
that does not include the USE_TRANSPORT_MODE notification.

Of course none of us would use such an implementation in our VPN gateway, but 
it can be appropriate for special uses, such as host-to-host within a 
datacenter.

Having said that, supporting tunnel mode as a fallback and making transport a 
SHOULD is still a good idea. Tunnel mode has a per-packet extra cost of 20 or 
40 bytes, but it’s generally better than no communications at all.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Tero Kivinen]

[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 payload requesting a Child SA.  It
> >requests that the Child SA use transport mode rather than tunnel mode
> >for the SA created.  If the request is accepted, the response MUST
> >also include a notification of type USE_TRANSPORT_MODE.  If the
> >responder declines the request, the Child SA will be established in
> >tunnel mode.

At this point the responder already created an Child SA in tunnel
mode, and when the initiator receives that message from the responder
it will also create the Child SA in tunnel mode. Responder might
already be sending traffic at this point.

This means both initiator and responder MUST implement tunnel mode, as
otherwise they cannot perform those actions. Meaning as the fallback
from the transport mode is tunnel mode, all implementations MUST
implement it even if it not explictly said in the RFC.

> > If this is unacceptable to the initiator, the initiator
> >MUST delete the SA.

This thing happens after the Child SA is created. I.e., now the
initiator will check whether the Child SA created was following its
policy, and it is completely valid for the initiators policy to say
that must use transport mode, and then it will delete the SA as it was
not following its policy.

It still means that the initiator implementation MUST implement tunnel
mode, but it does not have to USE it if it does not feel like doing
that.

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.

Quite often, especially in the security considerations section, we try
to give requirements to the users, but we need to be very carefull not
to do that. We can give information to users saying "do not use low
entrypy passwords as PSK as they are known to be unsafe", but we
cannot say MUST NOT use low entropy passwords, as there is no easy for
for implementor to enforce that.

For every single MUST or SHOULD and especially MUST NOT or SHOULD NOT
you are writing to the RFC, you should think how can you answer to
question from the customer who says, "show me the lines in your
implementation which implements this MUST or SHOULD". For MUST and
SHOULDs, that is usully still quite easy, but when someone asks "Show
me the lines of code where you implement: This notification MUST NOT
BE sent by an entity that may be replicated"

(and yes, I have had incoming customer support case, where they asked
for every single MUST/SHOULD/MUST NOT/SHOULD NOT where it was
implemented in the source of our toolkit). 

> > But note that the responder has already installed the IPsec SA in tunnel
> > mode. So if the initiator finds that unacceptable, it must send the
> > delete. During all this time, connectivity between the nodes will be
> > blocked. The intention here is that transport mode is optional and
> > should not be mandated by other protocols. Otherwise, the IKEv1
> > style negoation of transport OR tunnel mode would have been kept.

Also the delete notifications might get lost, and it might takes tens
of seconds, or even minutes before the initiator can finally tell the
responder that the Child SA that didn't follow its policy is deleted.

> How about my mails ask that i read this text such that the initiator will
> delete the SA (not only client SA) if transport mode is not supported
> be responder. Aka: the last two sentences to me describe exactly the
> case where the initiator can/want only support transport mode.

Initiator and responder can delete whatever SAs they like whenever
they like. That does not matter to the actual case here. The issue
there is that if the responder does not want to do transport mode,
then SA will be created in tunnel mode, and the initiator must be able
to cope with tunnel mode ESP packets it is receiving from the
responder. I.e., it needs to be able to implement tunnel mode as much
it understands those packets and does something to them (dropping them
is fine, as if his policy says he wants to get transport mode packets
and do not allow tunnel mode packets, then it is fine to have policy
dropping all tunnel mode packets).

> Aka: i can not read your interpretation into this text.

Anyways, this discussion is not really useful. If the other end does
not support transport mode (as it is allowed to do by IKEv2, as
transport mode is optional), there is nothing you can do to make it
support transport mode, and deleting the Child SA will just cause
initiator to try again few seconds later when it gets next packet to
that direction, with exactly same bad result.

It would be much better to simply say th

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Paul Wouters]

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 stores those data for its computations. 

Let's say each pair is a 0.5 megabyte, 20,000 users would be around 10G of 
memory/storage. So, the over all performance impact could be
noticeable once in a while for some VPN network.  


If you need that much memory to keep state, I don't think it matters
exactly how you receive and send that using IKEv2? Perhaps some
post quantum algorithms are better in that you dont have to keep
so much state during the exchange? And that could be a reason to
favour those. But you are far more qualified to judge that, than I am.

The intermediate exchange allows you to have many additional round trips
if that helps you reduce CPU or memory use. So I think from an IKEv2
point of view, that is all the scaffolding we need to provide. When
the new algorithms appear, we can go and implement those in a new RFC,
using the intermediate exchange.

I think Valery also had some ideas on how in the future, we could avoid
doing a hybrid key exchange with a classic DH that just costs CPU and
no longer gets us any security.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Dang, Quynh H. (Fed)]

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.

Let's say each pair is a 0.5 megabyte, 20,000 users would be around 10G of 
memory/storage. So, the over all performance impact could be noticeable once in 
a while for some VPN network.

Quynh.

From: Paul Wouters 
Sent: Thursday, June 18, 2020 12:23 PM
To: Dang, Quynh H. (Fed) 
Cc: Scott Fluhrer (sfluhrer) ; Panos Kampanakis (pkampana) 
; Valery Smyslov ; 'ipsecme mailing 
list' 
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

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.
>
> The impact varies from one situation to another I think.

> 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 work), or if you’re a back-up gateway, and then the primary 
> gateway just failed.

We have RFC 5685 REDIRECT for that. If your server becomes too busy, it
can redirect new or existing clients to another gateway, provided that
other gateway will authenticate itself identically to this gateway.

I don't think the key sizes really matter here. Even if computation is
2x or 3x more CPU intensively, from an "overloaded server" point of view
that just means like "redirect if at 3000 clients" vs "redirect if at
2000 clients".

Paul
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Paul Wouters]

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.

The impact varies from one situation to another I think. 



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 work), or if you’re a back-up gateway, and then the primary gateway 
just failed.


We have RFC 5685 REDIRECT for that. If your server becomes too busy, it
can redirect new or existing clients to another gateway, provided that
other gateway will authenticate itself identically to this gateway.

I don't think the key sizes really matter here. Even if computation is
2x or 3x more CPU intensively, from an "overloaded server" point of view
that just means like "redirect if at 3000 clients" vs "redirect if at
2000 clients".

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Paul Wouters]

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 context of TLS in https://eprint.iacr.org/2020/071. For a 
tunnel that stays up for a long time (not just a few seconds like
HTTPS) and sends Megabytes of data or more, then the larger key+signatures size 
are amortized over the tunnel data. What becomes more important
then is the keygen, encap, decap, sign/verify time.

In other words, servers that terminate a lot of connections at the same time 
will be impacted by slower operations in the handshake (the server
throughput drops), but their tunnels that send a few more kilobytes of 
handshake data and magnitudes more over the tunnel are not significantly
affected especially if we are talking about UDP and not TCP (with congestion 
control slowing down the handshake).


For libreswan, we recently went through performance enhancements, and we
found a number of issues in our code that once meassured, were easilly
fixed. There are still some linear lookups left in the Linux kernel for
policies/states, but we found that with about 1000 users that keep
connecting/disconnecting, it wasn't a big problem yet.

Hopefully, more clients will use Session Resumption, which would at
least cut out the (EC)DiffieHellman part of starting a session again,
but on larger servers with that many clients, there tends to not be
a guaranteed you can connect to the same server which can resume
your session. Also, I'm not sure if we need to further postquantum
prood the resumption mechanism (I don't think so, but I'm not a
licensed cryptographer)

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Dang, Quynh H. (Fed)]

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 think.

Regards,
Quynh.

From: Scott Fluhrer (sfluhrer) 
Sent: Thursday, June 18, 2020 9:51 AM
To: Panos Kampanakis (pkampana) ; Dang, Quynh H. (Fed) 
; Valery Smyslov ; 'ipsecme 
mailing list' 
Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?


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 work), or if 
you’re a back-up gateway, and then the primary gateway just failed.



That scenario requires a rather lot of care to avoid “congestion”, that is, 
where you’re so busy answering IKE messages that you don’t get enough time to 
complete any exchange before the IKE exchange times out.  What you end up doing 
is effectively triage; deliberately ignore some exchanges for the moment so 
that you can complete others.



Now, if you have large key shares, what that would add to the scenario is 
memory management; while processing the requests, you need to buffer the 
received key shares, and so part of your triage needs to worry about memory 
consumption in addition to the computational costs.  It’s not clear what 
complexity it would add; I would certainly be concerned if I were still an 
IPsec implementor…



From: IPsec  On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 18, 2020 9:32 AM
To: Dang, Quynh H. (Fed) ; Valery Smyslov 
; 'ipsecme mailing list' 
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?



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 key) which would 
> work well in a normal IKEv2's implementation ?

> 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 
> ?

> 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 key) which would 
> work well in a normal IKEv2's implementation ?

> 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 context of TLS in 
https://eprint.iacr.org/2020/071.
 For a tunnel that stays up for a long time (not just a few seconds like HTTPS) 
and sends Megabytes of data or more, then the larger key+signatures size are 
amortized over the tunnel data. What becomes more important then is the keygen, 
encap, decap, sign/verify time.



In other words, servers that terminate a lot of connections at the same time 
will be impacted by slower operations in the handshake (the server throughput 
drops), but their tunnels that send a few more kilobytes of handshake data and 
magnitudes more over the tunnel are not significantly affected especially if we 
are talking about UDP and not TCP (with congestion control slowing down the 
handshake).







From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf 
Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 12:37 PM
To: Valery Smyslov mailto:smyslov.i...@gmail.com>>; 
'ipsecme mailing list' mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?



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

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Scott Fluhrer (sfluhrer)]

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 work), or if 
you're a back-up gateway, and then the primary gateway just failed.

That scenario requires a rather lot of care to avoid "congestion", that is, 
where you're so busy answering IKE messages that you don't get enough time to 
complete any exchange before the IKE exchange times out.  What you end up doing 
is effectively triage; deliberately ignore some exchanges for the moment so 
that you can complete others.

Now, if you have large key shares, what that would add to the scenario is 
memory management; while processing the requests, you need to buffer the 
received key shares, and so part of your triage needs to worry about memory 
consumption in addition to the computational costs.  It's not clear what 
complexity it would add; I would certainly be concerned if I were still an 
IPsec implementor...

From: IPsec  On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 18, 2020 9:32 AM
To: Dang, Quynh H. (Fed) ; Valery Smyslov 
; 'ipsecme mailing list' 
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

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 key) which would 
> work well in a normal IKEv2's implementation ?
> 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 
> ?
> 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 key) which would 
> work well in a normal IKEv2's implementation ?
> 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 context of TLS in https://eprint.iacr.org/2020/071. For a 
tunnel that stays up for a long time (not just a few seconds like HTTPS) and 
sends Megabytes of data or more, then the larger key+signatures size are 
amortized over the tunnel data. What becomes more important then is the keygen, 
encap, decap, sign/verify time.

In other words, servers that terminate a lot of connections at the same time 
will be impacted by slower operations in the handshake (the server throughput 
drops), but their tunnels that send a few more kilobytes of handshake data and 
magnitudes more over the tunnel are not significantly affected especially if we 
are talking about UDP and not TCP (with congestion control slowing down the 
handshake).



From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf 
Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 12:37 PM
To: Valery Smyslov mailto:smyslov.i...@gmail.com>>; 
'ipsecme mailing list' mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

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.

It looks like if/when someone implements them and adds a large key and/or 
ciphertext KEM, the maximum IKEv2 message size must be adjusted if the existing 
implementation does not already support the corresponding message size with the 
new KEM ( for an ephemeral key exchange, it contains a public key and a 
ciphertext) because I don't see any mentioning of the maximum IKEv2 message 
size (it is an implementation specific issue).

Let's say after 10 or 15 years from now, the group trusts the security of some 
PQ KEM and signature algorithms and would like to use them in normal IKEv2 
without the 2 methods above.

In that situation, if the KEM has large public key and/or ciphtertext would 
have the IP fragmentation and packet drop issues. So, this KEM should use the 
approaches in the drafts above to deal with these issues.

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 key) which would work well 
in a normal IKEv2's 

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Panos Kampanakis (pkampana)]

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 key) which
would work well in a normal IKEv2's implementation ? 

> 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 ?

> 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 key) which
would work well in a normal IKEv2's implementation ? 

> 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 context of TLS in https://eprint.iacr.org/2020/071.
For a tunnel that stays up for a long time (not just a few seconds like
HTTPS) and sends Megabytes of data or more, then the larger key+signatures
size are amortized over the tunnel data. What becomes more important then is
the keygen, encap, decap, sign/verify time. 

 

In other words, servers that terminate a lot of connections at the same time
will be impacted by slower operations in the handshake (the server
throughput drops), but their tunnels that send a few more kilobytes of
handshake data and magnitudes more over the tunnel are not significantly
affected especially if we are talking about UDP and not TCP (with congestion
control slowing down the handshake). 

 

 

 

From: IPsec  On Behalf Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 12:37 PM
To: Valery Smyslov ; 'ipsecme mailing list'

Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

 

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.

 

It looks like if/when someone implements them and adds a large key and/or
ciphertext KEM, the maximum IKEv2 message size must be adjusted if the
existing implementation does not already support the corresponding message
size with the new KEM ( for an ephemeral key exchange, it contains a public
key and a ciphertext) because I don't see any mentioning of the maximum
IKEv2 message size (it is an implementation specific issue). 

 

Let's say after 10 or 15 years from now, the group trusts the security of
some PQ KEM and signature algorithms and would like to use them in normal
IKEv2 without the 2 methods above.

 

In that situation, if the KEM has large public key and/or ciphtertext would
have the IP fragmentation and packet drop issues. So, this KEM should use
the approaches in the drafts above to deal with these issues. 

 

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 key) which
would work well in a normal IKEv2's implementation ? 

 

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 ?

 

Regards,

Quynh. 


 
draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the
IKEv2 Protocol

This documents defines a new exchange, called Intermediate Exchange, for the
Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used
for transferring large amount of data in the process of IKEv2 Security
Association (SA) establishment. Introducing Intermediate Exchange allows
re-using existing IKE Fragmentation mechanism, that helps to avoid IP
fragmentation of large IKE ...

tools.ietf.org

 

 

 

  _  

From: Valery Smyslov mailto:smyslov.i...@gmail.com>
>
Sent: Wednesday, June 17, 2020 9:57 AM
To: Dang, Quynh H. (Fed) mailto:quynh.d...@nist.gov>
>; 'ipsecme mailing list' mailto:ipsec@ietf.org> >
Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? 

 

Hi Quinh,

 

please look at the  draft-ietf-ipsecme-ikev2-multiple-ke-00.

It specifically addresses your concern about large public keys of PQ KE
methods.

 

Actually, it's generally OK to have public keys/signatures up to 64Kbytes.

If you need to deal with larger keys, then some update of the specs is
needed.

 

Regards,

Val

Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Valery Smyslov]

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.

 

  Note, that this is essentially the same approach - draft-multiple-ke 
is based on draft-ikev2-intermediate

  and only clarifies its usage for the particular case of KE methods 
with large public keys (and combining several KE too).

 

It looks like if/when someone implements them and adds a large key and/or 
ciphertext KEM, the maximum IKEv2 message size must be
adjusted if the existing implementation does not already support the 
corresponding message size with the new KEM ( for an ephemeral
key exchange, it contains a public key and a ciphertext) because I don't see 
any mentioning of the maximum IKEv2 message size (it is
an implementation specific issue). 

 

  There are already few implementations and they even had an interop 
last November.

  And you are right that the maximum IKEv2 message size is 
implementation dependent

  (in any case it is limited to 64 Kbytes).

 

Let's say after 10 or 15 years from now, the group trusts the security of some 
PQ KEM and signature algorithms and would like to use
them in normal IKEv2 without the 2 methods above.

 

In that situation, if the KEM has large public key and/or ciphtertext would 
have the IP fragmentation and packet drop issues. So,
this KEM should use the approaches in the drafts above to deal with these 
issues. 

 

  These drafts were specifically written to address these issues.

 

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 key) which would work well in a normal IKEv2's 
implementation ? 

 

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 ?

 

  I think it depends on many factors. You are right that generally 
IPsec tunnels are relatively long lived.

  We also have an SA resumption mechanism (RFC 5723) that allows to 
quickly restore SA.

  But of course for the SA establishment we'll do have a penalty of 
performing more exchanges,

  and more data to transfer...

 

  Regards,

  Valery.

 

Regards,

Quynh. 


  
draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate
Exchange in the IKEv2 Protocol

This documents defines a new exchange, called Intermediate Exchange, for the 
Internet Key Exchange protocol Version 2 (IKEv2). This
exchange can be used for transferring large amount of data in the process of 
IKEv2 Security Association (SA) establishment.
Introducing Intermediate Exchange allows re-using existing IKE Fragmentation 
mechanism, that helps to avoid IP fragmentation of
large IKE ...

tools.ietf.org

 

 

 

  _  

From: Valery Smyslov 
Sent: Wednesday, June 17, 2020 9:57 AM
To: Dang, Quynh H. (Fed) ; 'ipsecme mailing list' 

Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? 

 

Hi Quinh,

 

please look at the  draft-ietf-ipsecme-ikev2-multiple-ke-00.

It specifically addresses your concern about large public keys of PQ KE methods.

 

Actually, it's generally OK to have public keys/signatures up to 64Kbytes.

If you need to deal with larger keys, then some update of the specs is needed.

 

Regards,

Valery.

 

 

From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 4:49 PM
To: ipsecme mailing list
Subject: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

 

Hi everyone,

 

I am interested in knowing what are typical maximum sizes for IKEv2 messages 
and UDP messages in implementations. 

 

The reason is that the IKEv2's spec has a must and a should being 1280 and 3000 
bytes respectively for IKEv2 messages, but does not
have a maximum limit.

 

As you know some of the post quantum cryptographic candidates in our 
standardization process have large or very large public key ,
signature and/or ciphertext sizes.

 

My guess is that some updates to the spec and/or implementations would make 
them work. 

 

Your data points and discussions are appreciated.

 

Regards,

Quynh. 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec