Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt

[Panwei (William)]

Hi,

I support the adoption of this draft.
I've read the very early version and thought it was quite useful.
I've read it again and still believe it's important and useful. I believe we're 
highly likely to implement this draft.


Some quick comments below:

1) I feel the title "Alternate approach" doesn't reflect the value of this 
draft well. This draft achieves the goals of using PPK to protect the initiated 
IKE SA and creating or rekeying SAs with a new PPK. These are notable 
improvements in how PPK can be better used to defend against quantum attacks. 
I'm a fan of Quantum Key Distribution (QKD) and PPKs can be easily and 
frequently changed when using QKD. This draft is well suited in integrating 
into the solution of QKD. I feel this draft is more useful than RFC 8784, 
especially when used together with QKD. When compared with RFC 8784, the draft 
only has a cost of the round of IKE_INTERMIDATE exchange, and this cost is 
relatively small, at least to me. So I prefer something like "Enhanced 
approach" rather than "Alternate approach".

2) I strongly recommend adding support for using a new PPK for creating the 
first Child SA, i.e., support sending PPK_IDENTITY_KEY notifications in 
IKE_AUTH. This draft already supports using different PPKs for creating the 
first IKE SA, creating the additional Child SAs, and rekeying both IKE and 
Child SAs. For the scenario when a stronger security requirement is needed, for 
example, one PPK for one SA, what is missing in the current draft is using a 
new PPK for creating the first Child SA. Using PPKs in the IKE_AUTH exchange is 
similar to using PPKs in the CREATE_CHILD_SA exchange as defined in section 
3.2. So, I believe adding support for using PPKs in the IKE_AUTH exchange is a 
small modification to the draft but complementary to the whole solution. The 
integration solution of IPsec and QKD would significantly benefit from this 
draft and this complement.

3) For the last paragraph of section 3.1,
   Since the responder selects PPK before it knows the identity of the
   initiator, a situation may occur, when the responder agrees to use
   some PPK in the IKE_INTERMEDIATE exchange, but during the IKE_AUTH
   exchange discovers that this particular PPK is not associated with
   the initiator's identity in its local policy.  Note, that the
   responder does have this PPK, but it is just not listed among the
   PPKs for using with this initiator.  In this case the responder
   SHOULD abort negotiation and return back the AUTHENTICATION_FAILED
   notification to be consistent with its policy.  However, if using PPK
   with this initiator is marked optional in the local policy, then the
   responder MAY continue creating IKE SA using the negotiated "wrong"
   PPK.
Regarding the situation that the PPK is not associated with the initiator's 
identity in the responder's local policy, I think the right choice is to not 
use that PPK, i.e., aborting the negotiation. But, because this seems not to be 
a fatal fault, I can also accept the handling that the responder will use this 
"wrong" PPK if it is configured to do so. But I don't feel the causal logic 
described in the last sentence is correct. If using PPK with this initiator is 
marked optional in the responder's local policy, it only means the responder 
can use PPK or not use PPK with the initiator, but doesn't mean the "wrong" PPK 
can be used. I suggest the last sentence be reworded to " However, the 
responder MAY continue creating IKE SA using the negotiated "wrong" PPK if this 
situation is marked acceptable in its local policy."


Two nits:
1) In the first paragraph of section 3.1.1, there is a missing ")" after "(for 
example, as defined in [RFC9370]".
2) Also in section 3.1.1, suggest the following changes:
OLD: In the formula above Ni and Nr are nonces from the IKE_SA_INIT exchange 
and SPIi, SPIr - SPIs of the IKE SA being created.
NEW: In the formula above, Ni and Nr are nonces from the IKE_SA_INIT exchange, 
and SPIi and SPIr are the SPIs of the IKE SA being created.


Regards & Thanks！
Wei PAN (潘伟)

> -Original Message-
> From: IPsec  On Behalf Of Tero Kivinen
> Sent: Tuesday, November 28, 2023 2:32 AM
> To: ipsec@ietf.org
> Subject: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
> 
> This is two week adoption call for draft-smyslov-ipsecme-ikev2-qr-alt.
> If you support adopting this document as a working group document for
> IPsecME to work on, and then at some point publish this as an RFC, send
> comments to this list.
> 
> This adoption call ends 2023-12-13.
> 
> Note, that I do want to see people saying that they think this document is
> worth of working on, and that they plan to review and comment on it. If I
> only get one or two people (including authors :-) to say they support this
> work, then there is no point of work on this in WG.
> --
> kivi...@iki.fi
> 
> 

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Paul Wouters]

On Dec 11, 2023, at 12:03, Hannes Tschofenig  wrote:I have, however, heard about uses of WireGuard on Linux-based IoT
  devices (these are non-constrained devices, obviously) with the
  argument that it is simple to use and efficient.It’s actually far less efficient because it only supports chacha20poly1305, so when doing benchmarks resulting in similar (within 5%) bandwidth, it ends up using 90% CPU versus like 5% with AES_GCM that’s hardware accelerated.The ESP tunnel mode packet format and the wireguard packet format are basically the same thing.The one thing people claim that can be argued is that configuration of wireguard is easier, but for IoT, I would expect either solution to be so abstracted from the user to not be a relevant consideration.
I believe it is worthwhile to think about the motivation of using
  WireGuard instead of IPsec/IKEv2 instead of spending a lot of time
  on yet another tiny optimization.There is minimal IKEv2 and minimal ESP.
Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2
  work well on Linux-based IoT devices (*)What’s the limiting factor here? usually Linux based iot has “plenty” of RAM, CPU and flash.Paul


*: Forget the constrained IoT device use case - there are better
  solutions available that don't require IPsec/IKEv2Coap? EDHOC ?Paul


Am 11.12.2023 um 14:53 schrieb Daniel
  Migault:


  
  
Hi Hannes, 


One draft is esp, the other is ikev2, I tend to think it
  would be better to have two separate documents.



  Validation of specification SCHC will be supported by
implementations and I am aware of two ongoing
implementations based on openschc. I am also aware of 2
implementations that do not rely on SCHC. One implementation
on contiki and one in python (not public).

https://bitbucket.org/sylvain_www/diet-esp-contiki/src/master/



We are working on an implementation. What is not completely
  clear to me now is how we will be able to have/make public
  implementations for linux implementation and potentially *Swan
  projects. It is a bit too early for now, but I am hoping to
  have a path in the next coming months.  


As far as I know ROHC is still used, but I do not know how
  ROHC is specifically used for IPsec traffic.


Yours, 
Daniel


  On Mon, Dec 11, 2023 at
7:12 AM Hannes Tschofenig 40gmx@dmarc.ietf.org>
wrote:
  
  Shouldn't
the two drafts be merged?


Who of the authors is going to implement the specs?


Ciao
Hannes


@Carsten: I have not been following the ROHC work after
standardization
was completed. Was it actually used? Is it still used?


Am 30.11.2023 um 14:09 schrieb Carsten Bormann:
> As a co-author of draft-mglt-ipsecme-diet-esp, I do
support this work (as well as the accompanying
draft-mglt-ipsecme-ikev2-diet-esp-extension) and plan to
continue working on it.
>
> We did the equivalent of these two drafts for ROHC in
RFC 5856 to 5858.
> The current work is an obvious missing link for SCHC
that needs to be filled in, just as we did for ROHC in 2010.
>
> Grüße, Carsten
>
>
>> On 2023-11-27, at 19:33, Tero Kivinen 
wrote:
>>
>> This is two week adoption call for
draft-mglt-ipsecme-diet-esp. If you
>> support adopting this document as a working group
document for IPsecME
>> to work on, and then at some point publish this as
an RFC, send
>> comments to this list.
>>
>> This adoption call ends 2023-12-13.
>>
>> Note, that I do want to see people saying that they
think this
>> document is worth of working on, and that they plan
to review and
>> comment on it. If I only get one or two people
(including authors :-)
>> to say they support this work, then there is no
point of work on this
>> in WG.
>> --
>> kivi...@iki.fi
>>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
  

Re: [IPsec] [Schc] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Carsten Bormann]

On 2023-12-11, at 13:11, Hannes Tschofenig 
 wrote:
> 
> @Carsten: I have not been following the ROHC work after standardization
> was completed. Was it actually used? Is it still used?

Hi Hannes,

last I looked, ROHC was in wide use in 3GPP environments, probably mostly in 
conjunction with IMS.  But I am not a 3GPP expert.

Grüße, Carsten

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

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Hannes Tschofenig]

Hi Daniel, Hi all,


don't get me wrong: I am trying to be helpful.


Integrating the functionality into SCHC alone is not enough. You need to
integrate it into an implementation of IKEv2/IPsec that is suitable to
the mentioned constrained IoT use cases. I have not seen IPsec/IKEv2
being used in constrained environments so far nor have I seen a
"lightweight" implementation for microcontrollers.


I have, however, heard about uses of WireGuard on Linux-based IoT
devices (these are non-constrained devices, obviously) with the argument
that it is simple to use and efficient.


I believe it is worthwhile to think about the motivation of using
WireGuard instead of IPsec/IKEv2 instead of spending a lot of time on
yet another tiny optimization.


Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2 work well
on Linux-based IoT devices (*)


Ciao

Hannes


*: Forget the constrained IoT device use case - there are better
solutions available that don't require IPsec/IKEv2


Am 11.12.2023 um 14:53 schrieb Daniel Migault:

Hi Hannes,

One draft is esp, the other is ikev2, I tend to think it would be
better to have two separate documents.

Validation of specification SCHC will be supported by implementations
and I am aware of two ongoing implementations based on openschc. I am
also aware of 2 implementations that do not rely on SCHC. One
implementation on contiki and one in python (not public).
https://bitbucket.org/sylvain_www/diet-esp-contiki/src/master/

We are working on an implementation. What is not completely clear to
me now is how we will be able to have/make public implementations for
linux implementation and potentially *Swan projects. It is a bit too
early for now, but I am hoping to have a path in the next coming months.

As far as I know ROHC is still used, but I do not know how ROHC is
specifically used for IPsec traffic.

Yours,
Daniel

On Mon, Dec 11, 2023 at 7:12 AM Hannes Tschofenig
 wrote:

Shouldn't the two drafts be merged?


Who of the authors is going to implement the specs?


Ciao
Hannes


@Carsten: I have not been following the ROHC work after
standardization
was completed. Was it actually used? Is it still used?


Am 30.11.2023 um 14:09 schrieb Carsten Bormann:
> As a co-author of draft-mglt-ipsecme-diet-esp, I do support this
work (as well as the accompanying
draft-mglt-ipsecme-ikev2-diet-esp-extension) and plan to continue
working on it.
>
> We did the equivalent of these two drafts for ROHC in RFC 5856
to 5858.
> The current work is an obvious missing link for SCHC that needs
to be filled in, just as we did for ROHC in 2010.
>
> Grüße, Carsten
>
>
>> On 2023-11-27, at 19:33, Tero Kivinen  wrote:
>>
>> This is two week adoption call for draft-mglt-ipsecme-diet-esp.
If you
>> support adopting this document as a working group document for
IPsecME
>> to work on, and then at some point publish this as an RFC, send
>> comments to this list.
>>
>> This adoption call ends 2023-12-13.
>>
>> Note, that I do want to see people saying that they think this
>> document is worth of working on, and that they plan to review and
>> comment on it. If I only get one or two people (including
authors :-)
>> to say they support this work, then there is no point of work
on this
>> in WG.
>> --
>> kivi...@iki.fi
>>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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



--
Daniel Migault
Ericsson

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

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Daniel Migault]

Hi Paul,

Please find my comments inline.

Yours,
Daniel
On Mon, Dec 11, 2023 at 9:59 AM Paul Wouters  wrote:

>
> >
> > On Dec 11, 2023, at 08:53, Daniel Migault  wrote:
> >
> > 
> > What is not completely clear to me now is how we will be able to
> have/make public implementations for linux implementation and potentially
> *Swan projects. It is a bit too early for now, but I am hoping to have a
> path in the next coming months.
>
> For libreswan to consider this, there would have to be ESP support (or
> plans) by maintainers of IPsec in Linux and/or BSD.
>

One thing is that we have implementations, another is that these
implementations are public and the other thing is that it is supported by
libreswan / Linux.  As I mentioned earlier, I am hoping the publication of
a Linux implementation can be clarified in the next coming months. It
sounds though realistic to me that a Linux implementation be published.

I see support from the SCHC crowd, but haven’t seen the same from the IPsec
> crowd. I’m also myself still a bit unsure who would actually deploy this
> outside proof of concept scenarios.
>

I am personally active on these drafts because we have a deployment
perspective. The PoC phase is over for many years now and I can see a
number of vendors we are willing to interconnect with.

We would also want to look at using an scsh library (GPL compatible) as we
> wouldn’t want to re-implement what seems like a very complicated high cpu
> load parser.
>
>
It is unclear to me who "We" is. However, assuming scsh stands for schc,
and as I tried to mention a few minutes ago, we rely on SCHC for the
specification. Implementations do not have to (see our old implementations
for example). So, whoever is behind "We" does not have to necessarily
re-implement or rely on a GPL SCHC library.
Regarding compression / decompression I do see SCHC as pretty efficient
especially because of the use of static context, so I am wondering 1) why
"We" seesthis as "a very complicated high cpu load parser" and 2) what
compression/decompression alternative "We" would find more efficient.


> Paul
>
>
>

-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Paul Wouters]

> 
> On Dec 11, 2023, at 08:53, Daniel Migault  wrote:
> 
> 
> What is not completely clear to me now is how we will be able to have/make 
> public implementations for linux implementation and potentially *Swan 
> projects. It is a bit too early for now, but I am hoping to have a path in 
> the next coming months.  

For libreswan to consider this, there would have to be ESP support (or plans) 
by maintainers of IPsec in Linux and/or BSD.

I see support from the SCHC crowd, but haven’t seen the same from the IPsec 
crowd. I’m also myself still a bit unsure who would actually deploy this 
outside proof of concept scenarios.

We would also want to look at using an scsh library (GPL compatible) as we 
wouldn’t want to re-implement what seems like a very complicated high cpu load 
parser.

Paul


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

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Daniel Migault]

Hi Hannes,

One draft is esp, the other is ikev2, I tend to think it would be better to
have two separate documents.

Validation of specification SCHC will be supported by implementations and I
am aware of two ongoing implementations based on openschc. I am also aware
of 2 implementations that do not rely on SCHC. One implementation on
contiki and one in python (not public).
https://bitbucket.org/sylvain_www/diet-esp-contiki/src/master/

We are working on an implementation. What is not completely clear to me now
is how we will be able to have/make public implementations for linux
implementation and potentially *Swan projects. It is a bit too early for
now, but I am hoping to have a path in the next coming months.

As far as I know ROHC is still used, but I do not know how ROHC is
specifically used for IPsec traffic.

Yours,
Daniel

On Mon, Dec 11, 2023 at 7:12 AM Hannes Tschofenig  wrote:

> Shouldn't the two drafts be merged?
>
>
> Who of the authors is going to implement the specs?
>
>
> Ciao
> Hannes
>
>
> @Carsten: I have not been following the ROHC work after standardization
> was completed. Was it actually used? Is it still used?
>
>
> Am 30.11.2023 um 14:09 schrieb Carsten Bormann:
> > As a co-author of draft-mglt-ipsecme-diet-esp, I do support this work
> (as well as the accompanying draft-mglt-ipsecme-ikev2-diet-esp-extension)
> and plan to continue working on it.
> >
> > We did the equivalent of these two drafts for ROHC in RFC 5856 to 5858.
> > The current work is an obvious missing link for SCHC that needs to be
> filled in, just as we did for ROHC in 2010.
> >
> > Grüße, Carsten
> >
> >
> >> On 2023-11-27, at 19:33, Tero Kivinen  wrote:
> >>
> >> This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you
> >> support adopting this document as a working group document for IPsecME
> >> to work on, and then at some point publish this as an RFC, send
> >> comments to this list.
> >>
> >> This adoption call ends 2023-12-13.
> >>
> >> Note, that I do want to see people saying that they think this
> >> document is worth of working on, and that they plan to review and
> >> comment on it. If I only get one or two people (including authors :-)
> >> to say they support this work, then there is no point of work on this
> >> in WG.
> >> --
> >> kivi...@iki.fi
> >>
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Hannes Tschofenig]

Shouldn't the two drafts be merged?


Who of the authors is going to implement the specs?


Ciao
Hannes


@Carsten: I have not been following the ROHC work after standardization
was completed. Was it actually used? Is it still used?


Am 30.11.2023 um 14:09 schrieb Carsten Bormann:

As a co-author of draft-mglt-ipsecme-diet-esp, I do support this work (as well 
as the accompanying draft-mglt-ipsecme-ikev2-diet-esp-extension) and plan to 
continue working on it.

We did the equivalent of these two drafts for ROHC in RFC 5856 to 5858.
The current work is an obvious missing link for SCHC that needs to be filled 
in, just as we did for ROHC in 2010.

Grüße, Carsten



On 2023-11-27, at 19:33, Tero Kivinen  wrote:

This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you
support adopting this document as a working group document for IPsecME
to work on, and then at some point publish this as an RFC, send
comments to this list.

This adoption call ends 2023-12-13.

Note, that I do want to see people saying that they think this
document is worth of working on, and that they plan to review and
comment on it. If I only get one or two people (including authors :-)
to say they support this work, then there is no point of work on this
in WG.
--
kivi...@iki.fi


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


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